How to support mixed DPI in Xwayland?

[Adam Jackson]

On Thu, 2017-09-07 at 12:17 -0400, Olivier Fourdan wrote:

> But we dismissed that solution, having different X11 screens is not very
> practical, mutter does not support multiple screens for a start, and 
> things like drag'n drop, copy/paste, root properties, etc. all would
> become quite complicated very quickly when dealing with multiple screens...

metacity certainly used to support multiple screens, so having taken a
feature out and then thinking it too hard to put back in is perhaps a
self-inflicted injury.

One possibility could be to expose the hi- and lo-dpi root windows as
different _displays_, listening on different sockets, and rewriting
geometry depending which one you're on (while otherwise having the same
set of windows, properties, devices...). Keith wrote a pseudo-root
extension along similar lines long ago [1], though that didn't make any
effort at rescaling, just subsetting.

One other problem with rescaling is what to do if graphics commands
cross logical displays. If I GetImage from a hidpi window on a lodpi
client, who's going to do the downscaling?

Another possibility could be just running more than one Xwayland
server, each with different DPI configurations; the compositor is going
to handle final presentation anyway, so this requires many fewer server
changes. But, a window manager that can't even deal with multiple
screens is probably also going to have problems with multiple displays,
and the wayland half of its brain would need to handle proxying
clipboard and friends between both servers.

> The other solution would be to have the same screen, but have Xwayland to
> give different scaling conversions for root window size, screen size, events
> coordinates, etc. depending on the client, if it's HiDPI aware or not,
> some sort of a "hidden" screen.

Root window size is only ever sent during the initial connection
handshake, and the client extension libraries don't update it when the
root window is reconfigured [2]. So we have a bootstrapping problem:
how is the X server supposed to know which set of lies to give the
client when it connects? If you have multiple displays (either logical
views or whole processes) then you decide this when you connect, and
remote X apps [3] have an obvious way to pick the right one.

One more possibility would be bumping the X protocol itself so the
client can express this kind of preference in the connection handshake
[4]. Doing that requires that you upgrade your clients (or at least
your toolkits) to do additional setup before connecting, or use an API
other than XOpenDisplay.

It'll be a decent amount of work any way you slice it, tbh.

One thing I've never really been thrilled with about the Xwayland
design is that the wayland compositor wants also to be the X window
manager, and that all the related state about window position and
whatnot is just internal to the compositor. xwin and xquartz don't have
this problem, you can run twm as your window manager and still move
windows, but in xwayland that doesn't work because wayland refuses to
allow you to position your own window for (what I consider) essentially
religious reasons [5]. And as a result the compositor gets a lot more
complicated and you _still_ need to change the X server to get things
to work. What I'd have preferred is a wl_x11_interop protocol that
Xwayland could use to send this kind of advisory state, which mutter
could optionally only expose to Xwayland if it really wanted to be less
functional than X.

[1] - https://keithp.com/~keithp/talks/proot.tar.gz

[2] - Even if they did, because libX11 is some of 1988's finest
engineering, things like DisplayWidth() are just macros that
dereference fields in the Display*, so updating them dynamically would
be hoping that the compiler didn't optimize away multiple loads of the
same field, and that the toolkit/app haven't cached them anywhere. We
could try anyway, and maybe that'd be good enough for xterm...

[3] - Still a thing! But even neglecting that, you have to set $DISPLAY
to something to get apps to launch from the command line; gnome-shell
is not going to be the only thing that starts clients, so inspecting
.desktop files or the link map of the binary is not going to be
sufficient in general.

[4] - I think you could get away with simply adding more authentication
class data before you get to the MIT-MAGIC-COOKIE bit, and have that
class always succeed and just record client capabilities, rather than
trying to define version 11.1 of the protocol. Which is good, because
11.1 would require you to update libX11/libxcb to make it work, and
that'd make it tough to upscale that old copy of Netscape running on
your IRIX machine.

[5] - They'd be hints in any case, the wayland server is entirely free
to ignore them. They're already hints in X because windows are managed,
so that's not actually different.

- ajax