[RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?
ppaalanen at gmail.com
Thu Mar 2 11:42:08 UTC 2017
On Thu, 2 Mar 2017 05:47:10 -0500 (EST)
Olivier Fourdan <ofourdan at redhat.com> wrote:
> Hi Pekka,
> > I understand the attractiveness of adding an override, bypassing the
> > compositors like this. But, essentially it is just that: a
> > configuration bypass.
> > I would prefer leaning towards just making the compositors more
> > considerate about their Xwayland configuration. I believe the global
> > trend is to move towards the compositor having all the configurability
> > in itself, and all the other components having a single source of
> > configuration in the running system: the compositor. I would compare
> > Xwayland to libinput here.
> Yes, but that means that all compositors need to have this
> "configurability", even though it's actually Xwayland that uses it.
Indeed, the same arguments as with libinput.
> > Xwayland is not a program launched manually, but Xephyr is, isn't
> > it? That makes an env var very convenient with Xephyr, less so with
> > Xwayland.
> I have seen glamor issues with Xwayland that do not show up in
> Xephyr, we cannot always use Xephyr to investigate glamor issues (or
> the underlying layers),
> https://bugs.freedesktop.org/show_bug.cgi?id=99400 is one of them...
I meant that "Xephyr uses env vars, Xwayland should too" was not exactly
a good justification to add any env vars to Xwayland due to how
Xwayland vs. Xephyr get launched.
> > Are there already other env vars useful with Xwayland (debugging)?
> Not that I am aware, except GLAMOR_DEBUG.
That's a precedent, at least.
> > This is just food for thought, I don't want to NAK this patch just
> > by my own opinion.
> Yeap, I appreciate your views and share most of them, I am not a big
> fan of environment variables for such purpose either (that's why I
> sent this patch as an RFC), but I've felt many times that frustration
> of not being able to tell simply to a user to try Xwayland without
Yes, I understand.
I wonder if you'd like to have more toggles in your Wayland stack,
though, e.g. disable certain aspects of hw-accel or hw-accel completely
in the compositor too. Like Weston/DRM has --use-pixman which
consequently causes Xwayland to fall back from GLAMOR. But you probably
use LIBGL_ALWAYS_SOFTWARE or something for that, right?
What about GLAMOR with software-GL? Or forcing GLAMOR to use a GL
flavour it normally would not pick because another one more suitable is
available? I suppose those would be controlled via Mesa env vars, but
then how do you set them only for Xwayland so they don't affect your
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel