How to support mixed DPI in Xwayland?
caseorum at gmail.com
Tue Sep 12 17:34:22 UTC 2017
On Mon, Sep 11, 2017 at 3:44 PM, Adam Jackson <ajax at nwnk.net> 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 <ajax at nwnk.net> 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 . 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  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
More information about the wayland-devel