Hi Pekka, > I understand the attractiveness of adding an override, bypassing the > compositors like this. But, essentially it is just that: a > configuration bypass.
True. > 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. > I realize recognizing glamor issues is a pain at the moment as you > don't have a setting to disable glamor. However, the environment > variable you suggest needs to be already set when the compositor > starts. You suggest an /etc/profile.d/ script, which requires root to > set up. I might ask if adding that env var to avoid writing a script, > replacing the Xwayland binary, to exec the original Xwayland binary > with an additional command line argument is that much of an improvement? That's what I use myself, when I am debugging an issue, but but it's no so practical to tell users top write a wrapper script, rename the binary from their distro package and replace it with their own script... That's precisely why I am looking in other solutions. As glamor also depends on the drivers and thus the hardware, there are issues (including rendering issues) that I can never reproduce myself. > 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... > Are there already other env vars useful with Xwayland (debugging)? Not that I am aware, except GLAMOR_DEBUG. > Are there other features in Xwayland one might want to configure too? Not really, I was starting to write a man page for Xwayland and realized few options are actualy to any use for the reguilar user, as Xwayland is mostly useful when started by the compositor. > Should Xwayland get its own configuration file a la xorg.conf, or > should we go with just arguments passed from parent process (the > compositor)? I thought of that, but deemed it a overkill :) > Here's another thought: > > If the compositor detects that Xwayland crashed, maybe it could > automatically disable glamor when restarting Xwayland? Or show a dialog > saying what happened and let the user choose whether to try with or > without glamor the next time to help diagnose the issue? That's an ideal workld unfortunately, mutter requires Xwayland t orun and won;t survive a crash in Xwayland (unlike weston), so if Xwayland dies s does the entire gnome-shell Wayland session. Besides, that won't help much with rendering issues with glamor. > I suppose that's not an option for gnome-shell as gnome-shell crashes > with Xwayland, does it not? Maybe in the future it could though? Exactly. > 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 glamor... Cheers, Olivier _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel