Re: How to support mixed DPI in Xwayland?

[Joseph Burt]

On Mon, Sep 11, 2017 at 3:44 PM, Adam Jackson  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  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
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How to support mixed DPI in Xwayland?

[Adam Jackson]

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.

- ajax
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How to support mixed DPI in Xwayland?

[Joseph Burt]

On Mon, Sep 11, 2017 at 9:08 AM, Olivier Fourdan  wrote:
> Hi
>
> On 10 September 2017 at 22:25, Joseph Burt  wrote:
>>
>>
>> I'm now up to date on the relevant bug reports. Sorry for the spam.
>>
>> What about always running the X server at hardware resolution,
>> limiting the size of lodpi clients on the XWM side, and letting the
>> compositor scale them?
>
>
> That's pretty much what we do already in mutter 3.26 with
> 'frame-monitor-framebuffer' enabled (and weston and kwin already do this as
> well -or so I heard-), but the problem is the X11 clients that can take
> advantage of hiDPI, you don't want to scale them...
>
> When scaling up the LoDPI X11 clients, you need to adjust the advertised
> screen size accordingly, because a LoDPI client configuring its X11 window
> to be, say 300x200 will end up with a surface of size 600x400 once scaled by
> 2 by the compositor when mapped on screen, so in that case the X server
> needs to adjust, i.e. downscale, the screen size advertised to the LoDPI
> clients by the same factor so that a client basing its window size/location
> on the screen size ends up with the expected size/location when mapped on
> the output, that's https://patchwork.freedesktop.org/patch/175578/
>
> But when dealing with HiDPI aware X11 clients, you don't want to scale those
> because they already know better how to render their contents without
> additional scaling, so eventually, these clients need to have access to the
> actual un-scaled screen size, meaning that the screen size as advertised to
> X11 clients actually depends on the client being capable of taking advantage
> of HiDPI...

I'm talking about just setting a different buffer_scale for each X
client's surfaces. As in, for a scale factor of two (ignoring the
fractional scaling issue for the time being, but it would work the
same), that the XWM only allows HiDPI clients to use more than a
quarter of the screen, HiDPI surfaces get a buffer_scale of 2, LoDPI
1. Any fullscreen or modesetting could be handled a little
differently, that might require some lies.
As Ajax pointed out, X clients might not react to root window
reconfiguration, but they do react to the XWM. The XWM has a huge
amount of power over X clients to enforce just about any policy.

Cheers,
Joseph
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How to support mixed DPI in Xwayland?

[Joseph Burt]

On Sun, Sep 10, 2017 at 5:01 PM, Joseph Burt  wrote:
> Hi Olivier,
>
> On Thu, Sep 7, 2017 at 6:17 PM, 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.
>
> I'm not aware of a facility for X clients to advertise DPI awareness
> to the X server. What would the heuristic be? Or just user-specified
> scaling for a specific X client?
>
> On scaling: DPI awareness isn't really possible in Wayland at the
> moment. The client needs to be told what DPI the compositor would like
> it to render, and must be able to acknowledge that. Pretty close to
> the current spec would be to have wl_output::scale and buffer_scale
> non-integers with an explicitly defined pixel size corresponding with
> 1 (96, 72 or 75 DPI, 0.25mm/pixel, whatever), but there are so many
> possibilities. Even just the client attaching a differently-sized
> buffer than it's surface "size" in such normed pixels would be
> acknowledgment enough.
>
> What's the current state of that conversation?

I'm now up to date on the relevant bug reports. Sorry for the spam.

What about always running the X server at hardware resolution,
limiting the size of lodpi clients on the XWM side, and letting the
compositor scale them?

Cheers,
Joseph
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How to support mixed DPI in Xwayland?

[Joseph Burt]

Hi Olivier,

On Thu, Sep 7, 2017 at 6:17 PM, 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.

I'm not aware of a facility for X clients to advertise DPI awareness
to the X server. What would the heuristic be? Or just user-specified
scaling for a specific X client?

On scaling: DPI awareness isn't really possible in Wayland at the
moment. The client needs to be told what DPI the compositor would like
it to render, and must be able to acknowledge that. Pretty close to
the current spec would be to have wl_output::scale and buffer_scale
non-integers with an explicitly defined pixel size corresponding with
1 (96, 72 or 75 DPI, 0.25mm/pixel, whatever), but there are so many
possibilities. Even just the client attaching a differently-sized
buffer than it's surface "size" in such normed pixels would be
acknowledgment enough.

What's the current state of that conversation?

Cheers,
Joseph
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

How to support mixed DPI in Xwayland?

[Olivier Fourdan]

Hi all,

For quite some time now [1] we've been trying to figure out a way to have
mixed DPI, both non-HiDPI capable X11 clients (e.g. xterm) and HiDPI aware
X11 clients coexists on Xwayland.

Typically, the compositor would scale the surface for xterm when on a HiDPI
monitor, but would leave another HiDPI aware client's surface unscaled to
achieve best results (as the client is HiDPI aware).

Problem, when scaling up the client buffer, the Xwayland screen size needs
to be scaled down accordingly, so that a client wishing to size or locate
its toplevel window based on the output size gets the correct size and
location once the surface is mapped on screen by the compositor.

So, we need to advertise different screen sizes (via Width//HeightOfScreen(),
Xrandr, Xvidmode, whatever) to different clients, depending on whether or
not those clients are HiDPI capable.

During GUADEC, we had some discussions with Jonas and Carlos, involving
Peter as well trying to evaluate the level of insanity of the various
solutions being considered.

One solution was to have two different "Screens" (in X11 terms) coexisting,
with a new X11 extension in place so that HiDPI aware clients would connect
to a screen that advertise the HiDPI "version" of the screen whereas the
no-HiDPI aware would connect to a different screen of the same display.

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...

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.

Ajax, Keith, what's your take on such an approach, is that even doable based
on your knowledge of the Xserver internals? Or do you see any better/simpler
idea?

Cheers,
Olivier

[1] https://bugs.freedesktop.org/show_bug.cgi?id=93315
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel