On Tue, Mar 29, 2016 at 5:24 AM, Drew DeVault <s...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel