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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel