[PATCH RFC xserver] xwayland: List all wl_output::mode(s) in xrandr

[Pekka Paalanen]

On Wed, 29 Nov 2017 10:18:47 -0500 (EST)
Olivier Fourdan <ofourdan at redhat.com> wrote:

> Hi Pekka,
> 
> > do you also plan to let Xwayland change the mode? If not, what's the
> > benefit of this?  
> 
> Yeah, sorry, I didn't give all the details on why this RFC patch, my bad.
> 
> Basically, in downstream RH bug 1289714 [1], Robert Mader (cc'ed) is
> running some proof of concept to see how he can improve the support
> for older games in Xwayland.

Ooh, exciting! I had a quick glimpse through the thread.

> So this patch here is mostly a follow-up on my comment 15 in that bug
> [2], where I was arguing that Xwayland should not add fake modes by
> itself but use whatever the Wayland compositor advertises.

Right, however, I would ask this: if Xwayland will not be able to
actually set the modes, does it make a difference if the modes listed
are real or artificial?

I'm more curious than trying to argue against the patch, mind.

> > My naive guess is that if apps or users don't see multiple modes in
> > the list, they are less likely to attempt to change it via RandR.  
> 
> No, I don't plan to let users change the modes via xrandr, but from
> bug 1289714 it seems that listing available modes helps some games
> (not sure why, I don't play games), even though input transformation
> is broken.

Does it actually break the input transformation? Well, depends on how
you handle the RandR mode change, I suppose.

> There is a lot more for this, this patch here is just a first (small)
> step (thus the RFC) to use the available modes listed by the Wayland
> compositor rather than faking arbitrary modes in Xwayland, and since
> I didn't reckon this patch would break anything, I posted that to the
> ML for more feedback.

Yes, letting Xwayland pretend successful mode switches is an
interesting topic.

I saw the input transformation fixup patch that seems special-case the
fullscreen window. If there is a X11 window on top of the fullscreen
window, that would still get wrong input coordinates, would it not?

An idea comes to mind: what if you'd make RandR mode changes change the
scaling of *all* Xwayland wl_surfaces?

Say, xwl_screen size is 1600x1200, RandR "sets" 800x600, and suddenly
all Xwayland wl_surfaces start using wp_viewport to set 2x up-scaling?
I.e. X11 window size that is 800x600 will produce a 800x600 wl_buffer,
but wp_viewport makes the wl_surface 1600x1200. I think visually that
should match pretty close what an actual mode change would have done,
for all X11 windows on the Wayland desktop.

Obviously now X11 and Wayland windows are at different scale, but since
for X11 the scaling by video mode is global (per Xwayland instance)
anyway, it kind of... fits?

To a Wayland compositor this would look like a small buffer upscaled to
fill the screen, which, if implemented in a compositor, could even
trigger a real video mode switch automatically based on which window is
active and on top.

Fixing up the input should be a little easier I imagine, because all
X11 windows have the same scaling factor, which means the X11
coordinate space can stay consistent for all X11 objects... right?

One thing I didn't think is how the XWM could cope with this scaling,
does it mess up some window relative to window positioning.

Crazy? I'll let you decide. :-)

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1289714
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1289714#c15


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20171130/64c88131/attachment-0001.sig>