XWayland Lands RandR/Vidmode Emulation For Better Game Handling

[phoronix]

Phoronix: XWayland Lands RandR/Vidmode Emulation For Better Game Handling

There is yet another significant improvement found for XWayland in the latest X.Org Server code that will hopefully see a long overdue release soon...

http://www.phoronix.com/scan.php?page=news_item&px=XWayland-RandR-Emulation

[brent]

I'd rather like to see an *actual* RandR-like protocol that works cross-compositor and allows users to set up screens, resolutions and their properties. If you need specific screen setups or resolutions, Wayland still isn't practical to use, no matter what compositor is used.

[Guest]

So panning doesn't work under Wayland/XWayland? Long life to Xorg.

[ssokolow]

I'll have to try to find time to look into whether this fixes the problem with Dungeons of Dredmor where it'll only allow windowed resolutions that are valid fullscreen resolutions, so locking the desktop resolution at 4480x1080 (1280x1024 + 1920x1080 + 1280x1024) via MetaModes makes the game unusable.

(I've been meaning for years to find time to write an LD_PRELOAD hook which wraps SDL's calls for getting resolutions and creating windows to ensure that common resolutions are available and filter out the "fullscreen, please" flag if one of the synthesized resolutions is chosen.)

I'd rather like to see an *actual* RandR-like protocol that works cross-compositor and allows users to set up screens, resolutions and their properties. If you need specific screen setups or resolutions, Wayland still isn't practical to use, no matter what compositor is used.

The whole point is to make permanent resolution changes a privileged operation so that applications can't abuse them the way X11 games did XRandR. (Most infamously, "game crash leaves resolution at 640x480 or whatever")

What you actually need to be complaining about is that their proposal for a cross-compositor standard for authenticating privileged operations hasn't materialized.

[brent]

The whole point is to make permanent resolution changes a privileged operation so that applications can't abuse them the way X11 games did XRandR. (Most infamously, "game crash leaves resolution at 640x480 or whatever")

What you actually need to be complaining about is that their proposal for a cross-compositor standard for authenticating privileged operations hasn't materialized.

Correct. Of course you don't need any application be able to change this stuff. But it should be possible to do, with proper authentication. Isn't there a cross-compositor spec for safely grabbing the keyboard with user authentication nowadays, though? I remember that virt-manager triggered a prompt for that when I used it last time on GNOME. Might have been a GNOME-specific extension, though.

[ssokolow]

Correct. Of course you don't need any application be able to change this stuff. But it should be possible to do, with proper authentication. Isn't there a cross-compositor spec for safely grabbing the keyboard with user authentication nowadays, though? I remember that virt-manager triggered a prompt for that when I used it last time on GNOME. Might have been a GNOME-specific extension, though.

As I understand it, that has the same semantics as fullscreening. The effect is transient, bound to the lifetime of a Wayland surface (ie. window), and the request is not guaranteed to be satisfied. It's then up to compositors to implement any extra things they might want, such as an "Are you sure?" prompt or a "Press [Key] to forcibly release the grab" OSD message.

It's also apparently not a full de facto standard because the Sway/wlroots guys are being petulant and refusing to implement the standard versions everyone else agreed on in favour of their own in-house protocol called Input Inhibitor, which no applications or toolkits support. (Similar to how the GNOME guys are being petulant and insisting that things like SDL implement CSD if they want decorations, despite widget toolkits and the like being out-of-scope for SDL and SDL's reliance on SSD on every other platform.)

Is it ironic that Sway won't support nVidia because of EGLStreams, yet decided to act similarly when it comes to input grabbing or just Drew DeVault showing that he hates nVidia because they remind him of himself?

[Lycanthropist]

Much more important would be this:

https://gitlab.freedesktop.org/xorg/xserver/merge_requests/111

No more blurry Xwayland windows on my 4K displaY in sway.

[Britoid]

the like being out-of-scope and their reliance on SSD on every other platform.)

Sorry, that's a lie.

Both macOS and Windows both use client-side decoration and SDL uses these. On macOS via NSWindow (analog to a GtkWindow) and on Windows via some obscure Win32 APIs (which end up controlling a HWND). The display server on either isn't drawing any decorations. You can actually see the SDL code for creating a NSWindow (which is client-side) here https://github.com/spurious/SDL-mirr..._cocoawindow.m

Server-side decoration was an X thing because X had pluggable window managers, hence why it isn't part of Wayland. GNOMEs attitude is that if you want to make a window, you shouldn't talk to the display server directly, but instead talk via GTK/GDK. Things directly talking to X is one of the reasons why the Wayland transition has been difficult.

However, GTK kinda sucks at embedding other toolkits inside of it at the moment in a performant way, so whilst there is code to make SDL draw to a GtkWindow, it has pretty crappy performance.

[dos1]

Sorry, that's a lie.

Sorry, but no. From SDL perspective, whether Windows and macOS window decorations are implemented server- or client-side is just an implementation detail. No toolkit is required to develop their own window decoration support on those platforms. Under GNU/Linux, this isn't the case - there is no single system-wide window decoration implementation, so under compositors like Mutter that refuse to implement SSD, toolkits like SDL are required to provide their own decoration, which isn't the case on *any* other platform; just like ssokolow stated.

So while you're technically right, that point is irrelevant here.

I'd rather like to see an *actual* RandR-like protocol that works cross-compositor and allows users to set up screens, resolutions and their properties. If you need specific screen setups or resolutions, Wayland still isn't practical to use, no matter what compositor is used.

wlr-output-management

[brent]

wlr-output-management

That seems to be step into the right direction, thanks. But it still seems to be a bit limited (e.g. no key-value output properties).