public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Matt Turner <mattst88@gentoo.org>
To: gentoo development <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Addressing split usage of USE=gles[123]
Date: Thu, 21 Nov 2019 14:26:27 -0500	[thread overview]
Message-ID: <CAEdQ38Hd=1X_kN2mgZhBxDCrvsS=AHTOHTmpZFA6V8oSWOOY1w@mail.gmail.com> (raw)
In-Reply-To: <20191121033234.GE8235@cloudsdale.the-delta.net.eu.org>

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.


      parent reply	other threads:[~2019-11-21 19:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEdQ38Hd=1X_kN2mgZhBxDCrvsS=AHTOHTmpZFA6V8oSWOOY1w@mail.gmail.com' \
    --to=mattst88@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox