Re: Collaboration on standard Wayland protocol extensions

["Jasper St. Pierre" <jstpierre mecheye net>]

On Tue, Mar 29, 2016 at 5:24 AM, Drew DeVault <sir cmpwn com> wrote:
> > Thirdly, it's important to take a step back. 'Wayland doesn't support
> > middle-button primary selections' is a feature gap compared to X11;
> > 'Wayland doesn't have XRandR' is not. Sometimes it seems like you miss
> > the forest of user-visible behaviour for the trees of creating
> > protocol.
>
> I think you're missing what users are actually using. You'd be surprised
> at how many power users are comfortable working with tools like xrandr
> and scripting their environments.

I've removed myself from the protocol talk so far, but I have to call
this one out. XRandR might be one of the most unfortunate APIs I have
ever dealt with, on both sides of the equation.

* It deals with "outputs" by "index", implying that outputs are static
and ordered. This is not the case in today's equipment with laptop
lids and docks and tons of ports.

* There's *no* way to specify whether something is a temporary display
configuration or should be saved. I plug and unplug external monitors
on my laptop every day, but I don't want a second output to always
behave the same way. Projectors should be in mirror mode. So already
you have multiple configurations, keyed by EDIDs.

* The authors wanted to make hotplug work even when nothing was poking
XRandR, but this just meant that desktops that do store complex
configuration had to wait until XRandR auto-reconfigured before saying
"no, bad computer" and overwriting any configuration it wanted. Two
mode-sets for the price of one.

* The command-line tool made it easy for users to poke the X server
directly, bypassing the DE entirely, leading to cases where the
Settings panel showed bizarre, inconsistent results because the
intended configuration wasn't updated for the manual changes the user
made.

* In some cases, like touchscreens, you *need* input to be mapped to
screen rotation and orientation. Input mapping was half-bolted onto
XInput and XRandR as an after-thought.

* Games which wanted to change the resolution often did it through
XRandR. These rarely worked if users had a complex configuration that
used rotated outputs, etc., or even just had more than one monitor,
leaving users with broken configurations. If the game crashed, users
were stuck with a permanently small screen.

* Similarly to the above, applications which want to react to
resolution changes (e.g. a window manager which wants to resize
windows, or a desktop that wants to reorder desktop icons) is unaware
if such a change is temporary or permanent. The result is that all
your desktop icons got put in a 640x480 box after you launched a game.

* Not to mention that the only event you get out of XRandR is an
all-encompassing "quick! something changed!!" event, which doesn't
even tell if you if it was simply accepting that the configuration you
just made went through successfully, whether it was an auto-configure
from a hotplug, or whether it was some other program poking the API.

* A partial repeat of the above, XRandR was intended for a low-level
"mechanism, not policy" API, but quickly got policy bolted on
after-the-fact because users weren't running tools which actually
supplied the policy. I am very skeptical of users who try to
lego-brick their way through DEs because "it's all bloat, I don't
really need a window manager, I can just skirt along with raw X11"
(because we committed ourselves to making it half-work) and I don't
want to encourage this behavior in Wayland. Let's do it right and
mandate real policy.

(This also doesn't even touch the incredible unfortunate hacks [0] we
have had to do at Endless to support HDMI TVs that need underscan
support, which work by changing the mode-list at runtime based on a
configurable border... which is specified in the mode's XSkew field,
because we didn't have any better place to put it)

We can talk about independent protocols and APIs for each of these use
cases (with no guarantee that Wayland is the IPC mechanism at hand),
but let's not bolt on a "wl_randr" that doesn't even begin to solve
the basic problems at hand because users run xrandr today and we have
to support that use case

[0] https://github.com/endlessm/xf86-video-intel/commit/391771f1652477863ece6da90b81dddb3ecb148a

> --
> Drew DeVault
> _______________________________________________
> wayland-devel mailing list
> wayland-devel lists freedesktop org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel



-- 
  Jasper