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

[Pekka Paalanen]

On Thu, 30 Nov 2017 04:14:08 -0500 (EST)
Olivier Fourdan <ofourdan at redhat.com> wrote:

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

That's a reasonable justification.

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

That somewhat depends on whether the compositor actually has to deal
with anything. But, getting the mode list from the compositor is safer.

If a game needs a specific mode, the Wayland compositor should arrange
it.

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

Just asked this in IRC as well: why is the input fixup patch to
Xwayland necessary at all?

If mutter decides to scale up something on its own, it should not
change how the Wayland client sees input, because input is defined in
surface-local coordinates. Is it a mutter bug?

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

While having lunch, I remembered something that makes it non-ideal:
there can be multiple RandR outputs, but the mode switch is per RandR
output, not global.


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/ed4b1448/attachment.sig>