vaapi use flag is not relevant to all cards. builds and should require radeon or nouveau video cards in order to use.. See: https://github.com/mesa3d/mesa/blob/master/src/gallium/targets/va/meson.build ---snip--- dependencies : [ dep_libdrm, dep_thread, driver_r600, driver_radeonsi, driver_nouveau, ], ---snip--- REQUIRED_USE should add vaapi? ( || ( video_cards_radeonsi video_cards_nouveau video_cards_r600 ) ) or something like that..
Same with vdpau: >meson.build:401:4: ERROR: Problem encountered: VDPAU state tracker requires at least one of the following gallium drivers: r300, r600, radeonsi, nouveau.
According to this https://wiki.gentoo.org/wiki/VAAPI , intel cards should also support VAAPI, isn't it?
(In reply to Michael Perlov from comment #2) > According to this https://wiki.gentoo.org/wiki/VAAPI , intel cards should > also support VAAPI, isn't it? vaapi for intel doesn't come from mesa its provided by libva-intel-driver, intel drivers via mesa are all classic not gallium.. this use flag enables a gallium specific vaapi support
In addition to REQUIRED_USE=" vaapi? ( gallium || ( video_cards_{r600,radeon,nouveau} ) ) d3d9? ( gallium || (video_cards_{i915,r300,r600,radeonsi,nouveau} ) ) vdpau? ( gallium || ( video_cards_{r300,r600,radeonsi,nouveau} ) )" We also need REQUIRED_USE="... xvmc? ( gallium || ( video_cards_{r600,nouveau} ) ) xa? ( gallium || ( video_cards_{i915,freedreno,nouveau} ) ) omx? ( gallium || ( video_cards_{r600,radeonsi,nouveau} ) ) See-Also: https://bugs.gentoo.org/663470 See-Also: https://bugs.gentoo.org/663418 See-Also: https://bugs.gentoo.org/663546 See-Also: https://bugs.gentoo.org/663660
*** Bug 663546 has been marked as a duplicate of this bug. ***
I think we can go one of two ways: 1) Add REQUIRED_USE to ensure users are enabling meaningful combinations of USE flags Pro: Users know what they're getting Con: Users have to manually configure use flags 2) Silently ignore unusable combinations Pro: Users don't have to tediously configure use flags Con: Users will be confused by USE flags not doing anything Thoughts? I'm sort of leaning towards 2) with some messages in pkg_preinst to alert users that they're enabling something that doesn't make sense.
(In reply to Matt Turner from comment #6) > I think we can go one of two ways: > > 1) Add REQUIRED_USE to ensure users are enabling meaningful combinations of > USE flags > > Pro: Users know what they're getting > Con: Users have to manually configure use flags > > 2) Silently ignore unusable combinations > > Pro: Users don't have to tediously configure use flags > Con: Users will be confused by USE flags not doing anything > > Thoughts? > > I'm sort of leaning towards 2) with some messages in pkg_preinst to alert > users that they're enabling something that doesn't make sense. I would prefer 1. I see no reason to dilute the meaning of a use flags. If a user is novice and doesn't want to or understand the use flags then the default setting would not force a compile error or any user intervention. If a more advanced user wishes to enable these flags, why not just give them a helpful error message? I know of no cases where use flags do nothing, and many where they cause a failure to compile.
The use flag should just not be available if the drivers aren't selected. Much like USE=vaapi emerge some-random-package does nothing, USE=vaapi emerge mesa should do nothing if the appropriate drivers aren't selected. Otherwise you can't just stick vaapi in globally and expect things to work, which is an unfortunate state to be in.
(In reply to Ilia Mirkin from comment #8) > The use flag should just not be available if the drivers aren't selected. > Much like USE=vaapi emerge some-random-package does nothing, USE=vaapi > emerge mesa should do nothing if the appropriate drivers aren't selected. > > Otherwise you can't just stick vaapi in globally and expect things to work, > which is an unfortunate state to be in. Right, that's my thinking (and the the case I think comment #7 is missing). In fact, vaapi is a good example -- i965 users would want USE=vaapi, but not on media-libs/mesa, so they currently have to configure it away with package.use. There are plenty of cases where USE flags don't do anything. Take www-client/lynx's gnutls USE flag: ssl? ( !gnutls? ( !libressl? ( dev-libs/openssl:0= ) libressl? ( dev-libs/libressl:= ) ) gnutls? ( dev-libs/libgcrypt:0= >=net-libs/gnutls-2.6.4:= ) ) It does nothing if ssl is not enabled. Same for libressl.
(In reply to Matt Turner from comment #9) > (In reply to Ilia Mirkin from comment #8) > > The use flag should just not be available if the drivers aren't selected. > > Much like USE=vaapi emerge some-random-package does nothing, USE=vaapi > > emerge mesa should do nothing if the appropriate drivers aren't selected. > > > > Otherwise you can't just stick vaapi in globally and expect things to work, > > which is an unfortunate state to be in. > > Right, that's my thinking (and the the case I think comment #7 is missing). > > In fact, vaapi is a good example -- i965 users would want USE=vaapi, but not > on media-libs/mesa, so they currently have to configure it away with > package.use. I think that is very much desireable. If I enable USE=vaapi globally, I would want portage to tell me that for my video card it is not actually supported, so that I know what to expect from my system. If it is supported, just through a different package, I would rather be informed very early, so I can take measures and more importantly so I know how my system behaves. I think that is one of the most important points of Gentoo: You know how your system works down to the details and it provides you with help to learn about these things. There are other distros for doing the right thing in the hopes it is what the user actually desired to do. > There are plenty of cases where USE flags don't do anything. Take > www-client/lynx's gnutls USE flag: > > ssl? ( > !gnutls? ( > !libressl? ( dev-libs/openssl:0= ) > libressl? ( dev-libs/libressl:= ) > ) > gnutls? ( > dev-libs/libgcrypt:0= > >=net-libs/gnutls-2.6.4:= > ) > ) > > It does nothing if ssl is not enabled. Same for libressl. In that case it should be protected by REQUIRED_USE, in order to warn the user that the configuration he believes to work actually does not. And I even think many ebuilds behave in that way.
No there's no need for REQUIRED_USE because the output of required use is simply unreadable and doesn't inform the user about the real problem. in the case of mesa choose a working configuration based on the gibe useflags and the selected driver and inform the user in pkg_preinst what the ebuild ajusted. If I only select i965 as driver, the ebuild should disable all useflags which requires a radeon/... driver and inform me about that. furthermore the local useflag description should be expanded to really inform the user in a meaningful way what the useflag does or not does in combination with a certain driver. (in general useflag description like 'FEATURE: add support for FEATURE' should be banned as they are completely meaningless)
(In reply to Martin Gysel (bearsh) from comment #11) > No there's no need for REQUIRED_USE because the output of required use is > simply unreadable and doesn't inform the user about the real problem. > > in the case of mesa choose a working configuration based on the gibe > useflags and the selected driver and inform the user in pkg_preinst what the > ebuild ajusted. > > If I only select i965 as driver, the ebuild should disable all useflags > which requires a radeon/... driver and inform me about that. > I think this is a reasonable compromise. > furthermore the local useflag description should be expanded to really > inform the user in a meaningful way what the useflag does or not does in > combination with a certain driver. (in general useflag description like > 'FEATURE: add support for FEATURE' should be banned as they are completely > meaningless) I'd also add that the wiki for mesa could be updated as well. So I think I'm flipping sides here and going for Comment 6 proposed option 2. Its probably more important that mesa reflects its existing behavior than it throw informative errors when users enable incompatible use flags. Current stable branch (17.3.9) doesn't inform users that vaapi for intel cards actually has no effect (i believe this is also the case for d3d9 and vdpau, but i'm not sure) As a compromise some informative elog isn't a terrible idea.
(In reply to Martin Gysel (bearsh) from comment #11) > No there's no need for REQUIRED_USE because the output of required use is > simply unreadable and doesn't inform the user about the real problem. Shouldn't we fix REQUIRED_USE then, instead of working around it by mangling the user's choices?
(In reply to Dennis Schridde from comment #13) > (In reply to Martin Gysel (bearsh) from comment #11) > > No there's no need for REQUIRED_USE because the output of required use is > > simply unreadable and doesn't inform the user about the real problem. > > Shouldn't we fix REQUIRED_USE then, instead of working around it by mangling > the user's choices? probably but this goes beyond the scope of this report ;) just for the record, in my view REQUIRED_USE seems fine for example two features which only one can be selected at once. but here the case is a little bit different. in the end the user wants a certain set of features and also gives information about his hardware setup (intel/ati/nvidia). this is most probably set in make.conf. the user doesn't care if this feature is coming from mesa and/or something else. and if mesa can't provide that feature for a certain hardware, simply don't try to provide it but also don't fail.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0ece8925e0d757751a9b9d26eeae2796f5aa4b8 commit a0ece8925e0d757751a9b9d26eeae2796f5aa4b8 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2018-08-18 04:36:07 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2018-08-18 04:53:17 +0000 media-libs/mesa: Replace REQUIRED_USE with ewarns Mesa has a lot of configuration options and many of them are only meaningful when specific Gallium drivers are enabled. Previously we attempted to specify all of those dependencies with REQUIRED_USE logic which was tedious for users to configure but ensured they knew what they were getting. With the transition to Meson, some configuration combinations that had not been specified in REQUIRED_USE (and with autotools were silently ignored) began producing configuration errors. Rather than extend REQUIRED_USE instead provide a warning in pkg_prepare(). Closes: https://bugs.gentoo.org/658892 Closes: https://bugs.gentoo.org/658938 Closes: https://bugs.gentoo.org/663418 Closes: https://bugs.gentoo.org/663470 Closes: https://bugs.gentoo.org/663660 media-libs/mesa/mesa-9999.ebuild | 126 ++++++++++++++++++++++++++++++++++----- 1 file changed, 111 insertions(+), 15 deletions(-)
