[gentoo-dev] Addressing split usage of USE=gles[123]

[gentoo-dev] Addressing split usage of USE=gles[123]

[Haelwenn (lanodan) Monnier]

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

Re: [gentoo-dev] Addressing split usage of USE=gles[123]

[Dennis Schridde]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [gentoo-dev] Addressing split usage of USE=gles[123]

[Mart Raudsepp]

See also this related old thread:
https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09211

Re: [gentoo-dev] Addressing split usage of USE=gles[123]

[Dennis Schridde]

[-- Attachment #1: Type: text/plain, Size: 700 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [gentoo-dev] Addressing split usage of USE=gles[123]

[Michael 'veremitz' Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1361 bytes --]

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 ..


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Addressing split usage of USE=gles[123]

[Matt Turner]

On Thu, Nov 21, 2019 at 4:54 PM Dennis Schridde <devurandom@gmx.net> 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]

[Matt Turner]

On Thu, Nov 21, 2019 at 5:09 PM Matt Turner <mattst88@gentoo.org> wrote:
>
> On Thu, Nov 21, 2019 at 4:54 PM Dennis Schridde <devurandom@gmx.net> 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]

[Michael Orlitzky]

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]

[Matt Turner]

On Wed, Nov 20, 2019 at 10:32 PM Haelwenn (lanodan) Monnier
<contact@hacktivis.me> 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.