Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On Thu, Nov 21, 2019 at 5:09 PM Matt Turner wrote:
>
> On Thu, Nov 21, 2019 at 4:54 PM Dennis Schridde wrote:
> >
> > On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote:
> > > See also this related old thread:
> > > https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09
> > > 211
> >
> > I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good
> > idea. Generally, all these probably have to distinguish between "support
> > for
> > XYZ" and "use only XYZ", the latter hopefully being the exception, so that
> > the
> > former can take the shorter use-flag. That's what I don't like about the
> > proposal from 2018: Globally enabling USE=gles will have different effects
> > on
> > different packages. That's also what I like about the recent proposal: The
> > flags are more explicit.
>
> Totally agree. FWIW, we have bugs filed about this for USE=wayland [0]
> and USE=USE={egl,gles{,1,2,3}}.
>
> I would be happy to see someone take up this project. I'll be happy to help.
Is anyone planning to work on this?
> [0] https://bugs.gentoo.org/627714
> [1] https://bugs.gentoo.org/627758
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On Thu, Nov 21, 2019 at 4:54 PM Dennis Schridde wrote:
>
> On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote:
> > See also this related old thread:
> > https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09
> > 211
>
> I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good
> idea. Generally, all these probably have to distinguish between "support for
> XYZ" and "use only XYZ", the latter hopefully being the exception, so that the
> former can take the shorter use-flag. That's what I don't like about the
> proposal from 2018: Globally enabling USE=gles will have different effects on
> different packages. That's also what I like about the recent proposal: The
> flags are more explicit.
Totally agree. FWIW, we have bugs filed about this for USE=wayland [0]
and USE=USE={egl,gles{,1,2,3}}.
I would be happy to see someone take up this project. I'll be happy to help.
[0] https://bugs.gentoo.org/627714
[1] https://bugs.gentoo.org/627758
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On 21/11/19 21:53, Dennis Schridde wrote: > On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote: >> See also this related old thread: >> https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09 >> 211 > I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good > idea. Generally, all these probably have to distinguish between "support for > XYZ" and "use only XYZ", the latter hopefully being the exception, so that the > former can take the shorter use-flag. That's what I don't like about the > proposal from 2018: Globally enabling USE=gles will have different effects on > different packages. That's also what I like about the recent proposal: The > flags are more explicit. > > --Dennis I don't think the problem is so much in the principle of making a change, or even the specifics of any particular permutation of change, it's who gets to manage and implement the change in a maintainable fashion, and who has to deal with the fallout of any changes occurring where a particular scenario 'slips through the net' If you can convince the latter people that there is no problem arising from making said changes, and you ensure that there genuinely *is* minimal impact (by whatever means) then you stand a much better chance of this change actually being implemented .. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote: > See also this related old thread: > https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09 > 211 I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good idea. Generally, all these probably have to distinguish between "support for XYZ" and "use only XYZ", the latter hopefully being the exception, so that the former can take the shorter use-flag. That's what I don't like about the proposal from 2018: Globally enabling USE=gles will have different effects on different packages. That's also what I like about the recent proposal: The flags are more explicit. --Dennis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On Wed, Nov 20, 2019 at 10:32 PM Haelwenn (lanodan) Monnier wrote: > > Hello gentoo-dev, > > First proposition on this list so hopefully not missing some kind of > netiquette/policy. > > I noticed for some time that there seems to be two use cases for the > gles[123] family of USE flags in gentoo repo: > 1. enabling support of OpenGL ES, which seems interesting to have for > more runtime choices, probably better usage of the drivers and better > binary-compat support. > 2. switching from OpenGL (so the full API) to Open GL ES (reduced API), > which is an entirely different kind of action as that reduces it quite > significantly but might be useful for machines where the drivers do not > provide (good) OpenGL. > > To reflect this I think the "gles[123]" USE flags should be renamed, > first kind to "gles[123]support" and second kind to "gles[123]only". > Might also be the time to globalize them? I'm not sure but I think that > would help in signalling which USE flags are to be used in packages. > (and I'm probably not the only one which tends to only put global USE > flags in make.conf, this kind of USE flags being the reason) I think this is a good idea. I would suggest gles[123] and gles[123]-only to avoid some of the churn. Changing gles[123] to gles[123]-support would mean changing a ton of reverse dependencies of Mesa, and I think that's a bad idea. > ## Second kind, switch from OpenGL to OpenGL ES (20 packages) > dev-libs/weston:gles2 - Use GLESv2 cairo instead of full GL > dev-python/PyQt5:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qt3d:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtdatavis3d:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtdeclarative:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtgui:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtmultimedia:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtopengl:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtprintsupport:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtwebkit:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtwidgets:gles2 - Use GLES 2.0 or later instead of full OpenGL > games-emulation/mupen64plus-core:gles2 - Use GLES2 instead of OpenGL > games-emulation/mupen64plus-video-glide64mk2:gles2 - Use GLES2 instead of > OpenGL > games-emulation/mupen64plus-video-rice:gles2 - Use GLES2 instead of OpenGL > kde-apps/kdenlive:gles2 - Use GLES 2.0 or later instead of full OpenGL > kde-frameworks/plasma:gles2 - Use GLES 2.0 or later instead of full OpenGL > kde-plasma/kwin:gles2 - Use OpenGL ES 2 instead of full GL > sci-libs/opencascade:gles2 - Use OpenGL ES 2.0 > www-plugins/freshplayerplugin:gles2 - Use system GLESv2 libraries instead of > ANGLE for shader translation > www-plugins/lightspark:gles - Replace default OpenGL renderer with GLESv2 Making a pull request to change these seems like a great plan. I'll be happy to help or review.
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On 11/20/19 10:32 PM, Haelwenn (lanodan) Monnier wrote: > > To reflect this I think the "gles[123]" USE flags should be renamed, > first kind to "gles[123]support" and second kind to "gles[123]only". > Might also be the time to globalize them? I'm not sure but I think that > would help in signalling which USE flags are to be used in packages. > (and I'm probably not the only one which tends to only put global USE > flags in make.conf, this kind of USE flags being the reason) > +1 for making them consistent, but... Setting USE flags globally has never worked, despite portage encouraging you to do it. Better to set them in package.use, because whether we admit it or not, the meaning of every USE flag is local.
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
See also this related old thread: https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09211
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
Hello everyone! On Donnerstag, 21. November 2019 04:32:34 CET Haelwenn (lanodan) Monnier wrote: > I noticed for some time that there seems to be two use cases for the > gles[123] family of USE flags in gentoo repo: > 1. enabling support of OpenGL ES, which seems interesting to have for > more runtime choices, probably better usage of the drivers and better > binary-compat support. > 2. switching from OpenGL (so the full API) to Open GL ES (reduced API), > which is an entirely different kind of action as that reduces it quite > significantly but might be useful for machines where the drivers do not > provide (good) OpenGL. I just recently ran into this, putting USE=gles2 in make.conf, thinking that only the first kind of flags existed. Thus I second this proposal. We could start bikeshedding about the naming (e.g. 1. gles2, 2. only-gles2, to keep it shorter), but I don't think that will lead us anywhere and will just delay the execution of this plan. Thanks for proposing this! --Dennis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Addressing split usage of USE=gles[123]
Hello gentoo-dev, First proposition on this list so hopefully not missing some kind of netiquette/policy. I noticed for some time that there seems to be two use cases for the gles[123] family of USE flags in gentoo repo: 1. enabling support of OpenGL ES, which seems interesting to have for more runtime choices, probably better usage of the drivers and better binary-compat support. 2. switching from OpenGL (so the full API) to Open GL ES (reduced API), which is an entirely different kind of action as that reduces it quite significantly but might be useful for machines where the drivers do not provide (good) OpenGL. To reflect this I think the "gles[123]" USE flags should be renamed, first kind to "gles[123]support" and second kind to "gles[123]only". Might also be the time to globalize them? I'm not sure but I think that would help in signalling which USE flags are to be used in packages. (and I'm probably not the only one which tends to only put global USE flags in make.conf, this kind of USE flags being the reason) Here is splitting use.local.desc in groups so you get a view of the more-or-less current state: ## First kind, enable support (19 packages) dev-games/ogre:gles2 - Build OpenGL ES 2.x RenderSystem dev-games/ogre:gles3 - Enable OpenGL ES 3.x Features dev-libs/efl:gles2 - Enable the OpenGL ES GL implementation kde-plasma/kinfocenter:gles2 - Show OpenGL ES information in kinfocenter media-libs/cogl:gles2 - Enable OpenGL ES 2.0 support media-libs/gst-plugins-bad:gles2 - Enable GLES2 support media-libs/gst-plugins-base:gles2 - Enable OpenGL library and plugin via GLESv2 API (requires egl) media-libs/libprojectm:gles2 - Provide support for OpenGL ES 2 and 3 media-libs/libsdl2:gles - include OpenGL ES support media-libs/mesa:gles1 - Enable GLESv1 support. media-libs/mesa:gles2 - Enable GLESv2 support. media-plugins/gst-plugins-gtk:gles2 - Enable gtkglsink OpenGL sink based on GLESv2 API media-plugins/gst-plugins-vaapi:gles2 - Enable GLESv2 and GLESv3 support media-tv/kodi:gles - Enable support for GLES net-libs/webkit-gtk:gles2 - Enable GLESv2 support sys-apps/kmscon:gles2 - Enable GLES2 for backend x11-apps/mesa-progs:gles2 - Build OpenGL ES 2 utilities x11-libs/cairo:gles2 - Build the OpenGL ES 2 backend x11-wm/mutter:gles2 - Enable OpenGL ES 2.0 support ## Second kind, switch from OpenGL to OpenGL ES (20 packages) dev-libs/weston:gles2 - Use GLESv2 cairo instead of full GL dev-python/PyQt5:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qt3d:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qtdatavis3d:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qtdeclarative:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qtgui:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qtmultimedia:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qtopengl:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qtprintsupport:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qtwebkit:gles2 - Use GLES 2.0 or later instead of full OpenGL dev-qt/qtwidgets:gles2 - Use GLES 2.0 or later instead of full OpenGL games-emulation/mupen64plus-core:gles2 - Use GLES2 instead of OpenGL games-emulation/mupen64plus-video-glide64mk2:gles2 - Use GLES2 instead of OpenGL games-emulation/mupen64plus-video-rice:gles2 - Use GLES2 instead of OpenGL kde-apps/kdenlive:gles2 - Use GLES 2.0 or later instead of full OpenGL kde-frameworks/plasma:gles2 - Use GLES 2.0 or later instead of full OpenGL kde-plasma/kwin:gles2 - Use OpenGL ES 2 instead of full GL sci-libs/opencascade:gles2 - Use OpenGL ES 2.0 www-plugins/freshplayerplugin:gles2 - Use system GLESv2 libraries instead of ANGLE for shader translation www-plugins/lightspark:gles - Replace default OpenGL renderer with GLESv2
