* [gentoo-dev] Addressing split usage of USE=gles[123]
@ 2019-11-21 3:32 Haelwenn (lanodan) Monnier
2019-11-21 7:24 ` Dennis Schridde
` (3 more replies)
0 siblings, 4 replies; 9+ messages in thread
From: Haelwenn (lanodan) Monnier @ 2019-11-21 3:32 UTC (permalink / raw
To: gentoo-dev
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-dev] Addressing split usage of USE=gles[123]
2019-11-21 3:32 [gentoo-dev] Addressing split usage of USE=gles[123] Haelwenn (lanodan) Monnier
@ 2019-11-21 7:24 ` Dennis Schridde
2019-11-21 8:11 ` Mart Raudsepp
` (2 subsequent siblings)
3 siblings, 0 replies; 9+ messages in thread
From: Dennis Schridde @ 2019-11-21 7:24 UTC (permalink / raw
To: gentoo-dev; +Cc: Haelwenn (lanodan) Monnier
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-dev] Addressing split usage of USE=gles[123]
2019-11-21 3:32 [gentoo-dev] Addressing split usage of USE=gles[123] Haelwenn (lanodan) Monnier
2019-11-21 7:24 ` Dennis Schridde
@ 2019-11-21 8:11 ` Mart Raudsepp
2019-11-21 21:53 ` Dennis Schridde
2019-11-21 16:45 ` Michael Orlitzky
2019-11-21 19:26 ` Matt Turner
3 siblings, 1 reply; 9+ messages in thread
From: Mart Raudsepp @ 2019-11-21 8:11 UTC (permalink / raw
To: gentoo-dev
See also this related old thread:
https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09211
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-dev] Addressing split usage of USE=gles[123]
2019-11-21 8:11 ` Mart Raudsepp
@ 2019-11-21 21:53 ` Dennis Schridde
2019-11-21 22:05 ` Michael 'veremitz' Everitt
2019-11-21 22:09 ` Matt Turner
0 siblings, 2 replies; 9+ messages in thread
From: Dennis Schridde @ 2019-11-21 21:53 UTC (permalink / raw
To: gentoo-dev; +Cc: Mart Raudsepp
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-dev] Addressing split usage of USE=gles[123]
2019-11-21 21:53 ` Dennis Schridde
@ 2019-11-21 22:05 ` Michael 'veremitz' Everitt
2019-11-21 22:09 ` Matt Turner
1 sibling, 0 replies; 9+ messages in thread
From: Michael 'veremitz' Everitt @ 2019-11-21 22:05 UTC (permalink / raw
To: gentoo-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-dev] Addressing split usage of USE=gles[123]
2019-11-21 21:53 ` Dennis Schridde
2019-11-21 22:05 ` Michael 'veremitz' Everitt
@ 2019-11-21 22:09 ` Matt Turner
2019-11-24 17:30 ` Matt Turner
1 sibling, 1 reply; 9+ messages in thread
From: Matt Turner @ 2019-11-21 22:09 UTC (permalink / raw
To: gentoo development; +Cc: Mart Raudsepp
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-dev] Addressing split usage of USE=gles[123]
2019-11-21 22:09 ` Matt Turner
@ 2019-11-24 17:30 ` Matt Turner
0 siblings, 0 replies; 9+ messages in thread
From: Matt Turner @ 2019-11-24 17:30 UTC (permalink / raw
To: gentoo development; +Cc: Mart Raudsepp
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-dev] Addressing split usage of USE=gles[123]
2019-11-21 3:32 [gentoo-dev] Addressing split usage of USE=gles[123] Haelwenn (lanodan) Monnier
2019-11-21 7:24 ` Dennis Schridde
2019-11-21 8:11 ` Mart Raudsepp
@ 2019-11-21 16:45 ` Michael Orlitzky
2019-11-21 19:26 ` Matt Turner
3 siblings, 0 replies; 9+ messages in thread
From: Michael Orlitzky @ 2019-11-21 16:45 UTC (permalink / raw
To: gentoo-dev
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [gentoo-dev] Addressing split usage of USE=gles[123]
2019-11-21 3:32 [gentoo-dev] Addressing split usage of USE=gles[123] Haelwenn (lanodan) Monnier
` (2 preceding siblings ...)
2019-11-21 16:45 ` Michael Orlitzky
@ 2019-11-21 19:26 ` Matt Turner
3 siblings, 0 replies; 9+ messages in thread
From: Matt Turner @ 2019-11-21 19:26 UTC (permalink / raw
To: gentoo development
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-11-24 17:31 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-11-21 3:32 [gentoo-dev] Addressing split usage of USE=gles[123] Haelwenn (lanodan) Monnier
2019-11-21 7:24 ` Dennis Schridde
2019-11-21 8:11 ` Mart Raudsepp
2019-11-21 21:53 ` Dennis Schridde
2019-11-21 22:05 ` Michael 'veremitz' Everitt
2019-11-21 22:09 ` Matt Turner
2019-11-24 17:30 ` Matt Turner
2019-11-21 16:45 ` Michael Orlitzky
2019-11-21 19:26 ` Matt Turner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox