On Mon, Sep 11, 2017 at 3:44 PM, Adam Jackson <[email protected]> wrote: > On Sun, 2017-09-10 at 22:25 +0200, Joseph Burt wrote: > >> What about always running the X server at hardware resolution, > > This isn't a fixed number. Outputs can be hotplugged.
Oh yeah, and they can have distinct DPIs. That means downscaling or upscaling even DPI-aware clients for some outputs. Maintaining the whole X space scaled in 96 DPI logical pixels is looking better and better. Xwayland is for legacy support after all... On Thu, Sep 7, 2017 at 10:15 PM, Adam Jackson <[email protected]> wrote: > On Thu, 2017-09-07 at 12:17 -0400, Olivier Fourdan wrote: > >> 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. Could this be done with one server listening on two sockets? This could work for X servers in general, has it been discussed in that context? Cheers, Joseph _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
