On Mon, 27 Aug 2018 at 19:19, Keith Packard <kei...@keithp.com> wrote: > Daniel Stone <dan...@fooishbar.org> writes: > > It's the other way around. Wayland only has surface-relative > > co-ordinates, so we take those and then translate them back into the > > X11 global co-ordinate space. > > Oh, so if we know how XWayland is scaling the output to the screen, then > we can translate the coordinates back to the correct root > coordinates. That seems like it might be useful in supporting per-window > scaling.
Yeah, it would be handy to support per-window scaling for high-DPI environments with a mix of smart and dumb (wrt DPI) clients. It's been easier for us to support scaling in Wayland since we have fractional (±23.8) input co-ordinates. The window co-ordinate space is always the same, which is emulating non-HiDPI: fullscreen on my 3200x1800 laptop is a 1600x900 surface space. If we have a client which is aware of HiDPI and can render at full resolution, then it attaches a full-size buffer and tells the compositor it's rendering at native scale. But the input is handled as if it were 1600x900, and the transfrom is effectively only during presentation to the output. Cheers, Daniel _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel