From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-89330-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by finch.gentoo.org (Postfix) with ESMTPS id D2946138334
for <garchives@archives.gentoo.org>; Thu, 21 Nov 2019 19:26:46 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 94457E08BF;
Thu, 21 Nov 2019 19:26:42 +0000 (UTC)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 3A19EE07F6
for <gentoo-dev@lists.gentoo.org>; Thu, 21 Nov 2019 19:26:42 +0000 (UTC)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
(Authenticated sender: mattst88)
by smtp.gentoo.org (Postfix) with ESMTPSA id 586C834D18D
for <gentoo-dev@lists.gentoo.org>; Thu, 21 Nov 2019 19:26:41 +0000 (UTC)
Received: by mail-io1-f54.google.com with SMTP id x21so4863257ior.2
for <gentoo-dev@lists.gentoo.org>; Thu, 21 Nov 2019 11:26:41 -0800 (PST)
X-Gm-Message-State: APjAAAUsP6EMBdUy39xJKOre4cJ5kTGOBhKoYuxiWvAMjSUr2LZqIP8S
eZPxPioYkXLLRVft1pT+MAnOxY9l8473CEtsRS0=
X-Google-Smtp-Source: APXvYqxOk2BiViPXOVSOIy8zU6DW9bFRjDNAFf3gFqYITekThaNqoqXhlz1u5yrOyRFthoQpUlPlfNdnSAWhFf4YmP4=
X-Received: by 2002:a05:6602:2246:: with SMTP id o6mr9409168ioo.225.1574364399364;
Thu, 21 Nov 2019 11:26:39 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <20191121033234.GE8235@cloudsdale.the-delta.net.eu.org>
In-Reply-To: <20191121033234.GE8235@cloudsdale.the-delta.net.eu.org>
From: Matt Turner <mattst88@gentoo.org>
Date: Thu, 21 Nov 2019 14:26:27 -0500
X-Gmail-Original-Message-ID: <CAEdQ38Hd=1X_kN2mgZhBxDCrvsS=AHTOHTmpZFA6V8oSWOOY1w@mail.gmail.com>
Message-ID: <CAEdQ38Hd=1X_kN2mgZhBxDCrvsS=AHTOHTmpZFA6V8oSWOOY1w@mail.gmail.com>
Subject: Re: [gentoo-dev] Addressing split usage of USE=gles[123]
To: gentoo development <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset="UTF-8"
X-Archives-Salt: 9bc7b248-cb06-4754-8f55-d41c12a12890
X-Archives-Hash: 2390da57eb96e8fc443fe71fcf4e3e51
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.