[Discussion] Support for creating, applying, and switching modes in Wayland

[syboxez]

This is a continuation of the discussion started here: libretro/RetroArch#17197

I was successfully able to implement a fully-agnostic method for switching modes in Linux, regardless of environment, so long as DRM is being used and edid_override and trigger_hotplug are both available as a proof of concept in BASH. This works quite well on my hardware, and switching is quite fast, but there's the obvious downside of requiring root access.

Currently, my setup includes a sudoers ruleset that automatically grants my user root access upon execution of specific scripts I wrote in /usr/local/bin, with the main meat of it being the script included in the PR linked above, and the other parts being specific to my setup (switching to custom EDIDs instead of resetting to default EDID provided by my displays along with scripts to enable/disable various displays before/after starting RetroArch).

IMO requiring the user to create a sudoers rule is a bit undesirable, not to mention requiring root access is a security concern. The issue here is that Wayland does not provide a standard to follow for compositors to allow for the use of custom modelines. There is an unstable, wlroots-exclusive protocol called wlr-output-management-unstable-v1 that allows for limited definitions of custom modelines (only allowing for HRes x VRes @ VFreq, or at least that's what wlr-randr allows for), but neither KDE (KWin) nor GNOME (Mutter) support that protocol, which limits use to less-popular desktops/WMs.

[syboxez]

Worth noting that backing up the EDID is unnecessary, as one could write the string reset to edid_override to reset the display's EDID to what the display provides. Some displays don't provide EDIDs (15KHz CRTs for instance), but my GPU or DAC (depending on which I'm using) seems to provide a default EDID. Alternatively, pin 12 on VGA can be grounded on the PC side and disconnected on the display side to use a legacy EDID mode intended for greyscale displays. This will force a default EDID of a generic 31KHz display with the only mode available being 640x480; I have not had luck with force-enabling the display output using the kernel, like what is recommended in the linux_kernel_15khz README.

[substring]

As I've already said but I'll say it again in a shorter yet clearer way: I'll never approve that.

Switchres is shipped as a library, which is linked to emulators. Having a side shell running as root goes against that rule. Abd it even totally breaks the idea switchres is built on.

Now even if the shell part was converted to C, it would still require root rights. And again, that's a big no. Even if you wanted to circumvent the root part, it would imply changing rights to some device folders, which goes against Linux standards.

Now note that we've already considered switching EDIDs on the fly. And to my experience, this hasn't worked reliably on AMDGPU.

All in all, although you've mentioned the Wayland thing and propose this as a way to modeswitch on wayland, it's not bullet proof, too hacky, and not a clean solution for the goal you wanna achieve. And I'm pretty sure the modeswitching times are terrific

[syboxez]

As I've already said but I'll say it again in a shorter yet clearer way: I'll never approve that.

Switchres is shipped as a library, which is linked to emulators. Having a side shell running as root goes against that rule. Abd it even totally breaks the idea switchres is built on.

Now even if the shell part was converted to C, it would still require root rights. And again, that's a big no. Even if you wanted to circumvent the root part, it would imply changing rights to some device folders, which goes against Linux standards.

Now note that we've already considered switching EDIDs on the fly. And to my experience, this hasn't worked reliably on AMDGPU.

All in all, although you've mentioned the Wayland thing and propose this as a way to modeswitch on wayland, it's not bullet proof, too hacky, and not a clean solution for the goal you wanna achieve. And I'm pretty sure the modeswitching times are terrific

Can you explain to me how the current DRM/KMS mode in switchres works, and if that can be adapted to Wayland? I haven't been able to get it to switch modes properly.

The ideal solution IMO is to propose either a Wayland protocol for the creation and addition of X11-style modelines or for every individual Wayland compositor to have their own methods of doing the same thing using compositor-specific tooling (ie: using gnome-randr, wlr-randr, kscreen-doctor, etc.). Not sure what the actual proper solution is, though.

It makes sense that you wouldn't want to merge something that requires root; I probably wouldn't merge it either.

[substring]

There are 2 ways to handle DRM modeswitching:

• the best way: when the app has a DRM backend and can set the CRTC itself, with a custom modeline. That's the way it's done in Retroarch since RA is pretty bare metal and hardly relies on any intermediate API
• the tricky way: it requires one of the 15kHz patch that allows custom modes to be added through an ioctl and stored in a user modes list (that feature as buried in Kernel 5.10-rc3 iirc because said "incomplete and not used", I had to resurrect it and make it work). This implies some cheating on the emulator side. Hopefully most apps run on SDL, but this requires a patched SDL2.

Wayland is yet another story, and what Linux did best once again: fragmentation armageddon -> Weston, wlroots etc...

wlroots supports custom modelines, Weston does, but it's too limited. Hyprland's aqua seems to have what it takes. But from the time I could spend inveestigating on it, nothing standard, just specific. Considering Wayland came and said "you don't need custom modes anymore", you get the idea: it's niche and not generic

[syboxez]

Issues opened here:
KDE/KWin: https://bugs.kde.org/show_bug.cgi?id=456697
GNOME/Mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/1816
Also GNOME/Mutter: https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/2027617

According to this comment from a GNOME maintainer, implementing a Wayland standard wouldn't make any sense since the Wayland protocol does not handle monitor configuration. This means that if we were to have custom modelines in Wayland sessions, it would need to be implemented in every single wl compositor using their own methods, and I just don't think that's the best way forward (fragmentation, as mentioned by substring above).

But whether or not I personally think custom crtc support should be a universal protocol in Wayland upstream doesn't make that much of a difference, as it's up to the Wayland guys how they want to handle that.