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

[Olivier Fourdan]

Hi Pekka,

> > [...]
> > 
> > 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?

No difference, I reckon, fake or real doesn't matter, but I'd rather let the compositor decide.

My point being solely that Xwayland should not decide to come up with and force fake modes all by itself if the compositor doesn't know how to deal with those.

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

Yeah that's one of the corner case, I'm sure there are a lot more.

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

Now, I think this is a very interesting idea, also because randr isn't per client, even less per window (thus matching a surface to the X11 client issuing the randr request might not be trivial in xwl_randr_set_config()).

So making the scaling global would solve that problem.

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

If you ask me, probably one of the less crazy ideas I've heard around the topic to be honest, and definitely worth pursuing :)

Copying Jonas and Carlos as they were looking into Robert's approach.

Cheers,
Olivier