You could also try using KDE Plasma instead of Gnome, which survives GPU resets.

Okay, then the driver doesn’t allow Plasma to turn it on for some reason. You can report that at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues, maybe someone from Intel can help.

No I can’t move my mouse to the external monitor.

Do you mean that it stays on the internal display, or that it doesn’t show up on the external one?

Or to ask it differently, can you move a window where the monitor should be?

My laptop detects the monitor correctly so it shows up in the KDE plasma display configuration but the monitor is not getting any input.

So the system thinks it’s enabled? Can you move the mouse cursor to it?

Screen mirroring is kinda shitty rn, this might get fixed with future changes for Plasma 6.4 (which make it less shitty in general). It’s probably worth fixing this as a separate thing for 6.3 though, so please make a bug report about this for KWin at bugs.kde.org

It’s an Electron problem, yes. The API is there, just waiting to be used.

Ah, you’re on Xorg. This feature is only available in the Wayland session

Go into system settings > mouse > select your mouse > rebind buttons

NVidia still hasn’t implemented support for adaptive sync with multiple monitors in their driver. If you can connect the second screen to the integrated GPU, that would work though

KWin had the shortcut built in and enabled by default at some point, but I removed it, for Plasma 6 IIRC. If shortcuts still work, you can switch to a different tty and execute kwin_wayland --replace for a similar effect - which you can’t hit accidentally and which might not crash all the apps with it.

fully up to date Debian Stable

Now that’s quite the oxymoron… Debian stable is on Plasma 5.27.5, that’s 6 bugfix-only releases behind the upstream 5.27 branch, which itself is very old by now and has seen its last release almost a year ago.

That all is to say, if you want to avoid crashes, avoid Debian stable.

It’s not a shortcut configured by us, but a thing Xorg does specifically. Be grateful it doesn’t require editing Xorg configs…

Please make a bug report to KWin about that issue then, and attach one of the ICC profiles you tried to the bug report. Maybe something’s wrong in KWin’s profile parsing and it gets silently ignored.

regardless, the whole point of my og comment was color management protocol isn’t only hdr stuff

Yes, nothing wrong with that.

like how color profiles are under ‘color management’ in the system settings you’re telling me to use

No, I’m telling you to use the display settings. The color management page is hidden on Wayland starting with Plasma 6.3, because it’s misleading and confusing.

the wiki says

The wiki is very outdated, it’s about Plasma 5.

It’s in the display settings

If you’re on Plasma, setting the color profile to “built-in” might be all you need to make them reasonably match

No, colord does not handle color profiles on Wayland. You need to set the profile in the display settings.

If you have an ICC profile that doesn’t work, please make a bug report about it for KWin.

This protocol isn’t relevant for your compositor to apply an ICC profile. If you’re using KDE Plasma, you can just select it in the settings. I think Sway allows that now too. If you’re on Gnome, you’ll need to wait.

You don’t need a protocol for profiling, it’s merely a nicer user experience if you have one.

Chromium had it for qhite a while, but it isn’t really relevant… Discord’s implementation of screen sharing was custom on X11, if they had used the one that comes with Electron, this would’ve worked far earlier.

operating systems may not have implemented it umtil more recently

DEs that had a Wayland session (aka Gnome and Plasma) supported it very soon after the portal was made.

The real reason won’t be anything external, but something in the company. Usually it’s just that Linux isn’t a priority for a given company, so even if there’s a motivated engineer that wants to take care of it, it’s hard justifying to their managers why they need to spend a lot of time on it.

This isn’t exclusive to Discord, to use a very similar example, Zoom is kinda worse. In the past, Zoom misused a Gnome screenshot API to do screen casting very badly, and recently they ported to the desktop portal - not because they had a choice, but because Gnome locked down the API they were using. Screen casting still only works on Gnome though, because they still check for the desktop name. If you set it to Gnome, it works perfectly fine everywhere else too!

All it would take to fix that problem is removing an if statement, yet, despite many complaints, it hasn’t happened… because no big customer has complained, so it’s just one of the unimportant Linux bugs.

The screen casting portal is 6 years old. 6 years is not recent…