Any way to ignore/suppress monitor hotplug events?

[MaxMotovilov]

After upgrading to a dual-4K monitor setup, I found myself suffering from the infamous "false hotplug event" when monitors go to standby mode. As far as I can tell, my particular monitors (Samsung U28E510) do drop the HPD pin of the DisplayPort when in standby which is interpreted by the nvidia driver as monitor disconnect. They do reconnect properly when coming back from standby, however I am encountering an intermittent issue with Cinnamon (on about 50% of standby re-awakenings):

• all windows are piled up in one of the monitors (usually, but not necessarily, the primary aka "left" one)
• the Cinnamon applets reset their configurations (they don't load the ones from .cinnamon/configs/* but overwrite them with the default versions from applets' source code in .local/share/cinnamon/applets)

It appears that there's presently no way to tell the nvidia driver to ignore hotplug events, or at least I didn't manage to find one. For my purposes, it would be quite sufficient to suppress the monitor disconnect/connect events at Cinnamon level so that it doesn't attempt to re-arrange or reset anything. Any advice on how to approach this? I don't imagine there's a setting per se, but perhaps I can patch the JS code to have a dummy event handler at desktop level? Or are [some of] those things happening way before JS level, say in mdm?

Any suggestions are heartily appreciated.

My setup:
Mint 17.3 / Cinnamon 2.8.8
Nvidia GTX 960 (EVGA), driver version 367.44 (official nvidia)
2xSamsung U28E510 connected via DisplayPort 1.2, 4K @ 60Hz

Edit: looks like I was able to do that by
gsettings set org.cinnamon.settings-daemon.plugins.xrandr active false

Will try to live with it and see what else this setting might break...

[drmoose]

This workaround saved my sanity for many months but seems to have been broken when my system updated to Cinnamon 3.4.1. It looks like the active key has been removed from org.cinnamon.settings-daemon.plugins.xrandr.

As a new workaround, renaming the csd-xrandr binary so cinnamon can't find it solved the problem for me.

[mikebutash]

Thanks for noting the issue to me @drmoose, this is indeed the same problem from a different issue. I'm on 3.2.8 cinnamon still on arch with 3 samsung displays, so going to try the plugins.xrandr disable and see. I don't have the csd-xrandr binary on here, so that's good I think, but not sure if that's a byproduct of 3.4 cinnamon either.

This is a really terrible issue that basically affects every linux desktop I've used so far. It would drive KDE to be entirely unusable, I moved to Cinnamon as a result, and while annoying, it doesn't normally break the OS entirely.

I do notice that when shutting my displays off and on, over time the desktop destabilizes the point I have to restart the desktop. It manifests itself as taking long and longer to render the login screen after starting the displays in the morning for a work day, and eventually I'll log in, and not be able to interact or move any windows on the desktop, like the compositor is broken and I'm touching against a piece of glass, but can't grab the window handler. I end up having to drop to a console and restart the ui.

Do you guys happen to see this as well since your monitors hotplug away and back like mine? I usually have to restart cinnamon every 5-7 days as a result.

[MaxMotovilov]

over time the desktop destabilizes the point I have to restart the desktop

I have always found Cinnamon to be somewhat unstable; fortunately its ability to restart preserving all windows forecloses most of my complaints. The two things I do observe on a more or less constant basis is excessive flicker of the desktop background and window decorations when the wallpapers are switched (I have couple astronomic images of extremely high resolution in a "slide show" as wallpapers) and neverending glitches with the screen saver (half of my bash history is now xset dpms force off). Of course I'm still on 2.8.8 so my experiences might not be at all typical.

[mikebutash]

The two things I do observe on a more or less constant basis is...

Ah yes, that flickering is another smaller annoyance of mine too, and I'm on 3.2.8, so still here. Same all around it sounds like, I have an archive of 11520x2160 DigitalBlasphemy images I cycle through as well across the 3 displays, and get the random flickering in different parts of the displays, not even when just switching. It becomes more pronounced as it builds up to unstable as described above, where the compositor just seems to be coming unglued over time with resource leaks.

I'm not epileptic, so the flickering is nothing that has become too annoying/life-threatening for me at least, but another "todo" item that needs some fixing.

I only use the basic cinnamon screensaver and locker, so haven't noticed anything with that. I was considering moving to another screensaver to get the cool glmatrix back recently, but something tells me it'd just make things worse.

[MaxMotovilov]

I only use the basic cinnamon screensaver and locker

Heh -- all I want is monitor standby (and here we have just drifted back to the original topic!).

[mikebutash]

From what I've found, normal monitor dpms style standby just isn't possible with the hdmi displays that are more TV's than monitors. I also have to use displayport to hdmi adapters for the 3x tv's off my gtx1070 card, but doesn't seem to work any different if using the native hdmi port either.

I blame samsung mostly for omitting standby features, but something linux video and UI folks need to take into account tv/monitors do this now too, where the graphics end up with no displays temporarily when the displays power off.

I'd thought about getting hdmi port edid ghosters to trick the computer into keeping the displays "there", but it's a big expense for such a stupid thing. Here's to hoping desktop environments get smarter than the displays.

[MaxMotovilov]

My monitors have DP connectors so HDMI is not involved at all. Nevertheless, as I understand, the spec for DP has a leeway (or possibly a rule that is summarily ignored by the likes of Samsung) in that HPD pin may or may not be powered down during standby. Personally, I have no more use for this "hot plug" functionality than rabbit has for a brake light but the nvidia driver does not seem to treat it as optional...

[DemonTPx]

@drmoose Renaming csd-xrandr (and killing the running process) fixes my problem, so thanks for that workaround. It should be noted that I'm not able to access windows which are on a screen which is turned off, but I can live with that for now.

@mikebutash You said you don't have the csd-xrandr binary on there. Have you checked this folder: /usr/lib/x86_64-linux-gnu/cinnamon-settings-daemon and have you checked if it is running? (for example using ps aux | grep csd-xrandr)

[drmoose]

@DemonTPx I find that the "Move to other monitor" option in the context menu on the window-list applet still works for me, although I occasionally had to remove and re-add the window-list applet to get it to show windows from all displays. My branch here adds a show windows from all displays switch to the window-list's configuration, but I haven't tried to PR it because it's only necessary when xrandr is getting bogus hotplug events. Otherwise, the existing monitor-watching code seems to correctly detect windows on other screens. I'd rather try to figure out precisely what's going wrong with cinnamon-settings-daemon and open an issue or PR there

[drmoose]

@mikebutash I'm on Arch as well. It seems to have been quite a while since your last -Syu, but you're right about the version number. When you upgrade cinnamon to 3.4.x the dconf option will stop working and csd-xrandr will appear in /usr/lib/cinnamon-settings-daemon

[jaszhix]

This is more of a dirty workaround, but I created a window position saving utility applet for restoring window positions for this purpose.

[nalldrin]

FYI, I encountered the same problem and found a cleaner workaround than moving the csd-xrandr binary. Instead you can go to Settings->Startup Applications, edit the "Cinnamon Settings Daemon - xrandr" and add the flag --exit-time=5 to the command line. This causes the csd-xrandr binary to exit after 5 seconds, meaning it will apply screen settings (like rotation of secondary display) on startup but ignores hotplug events afterward.

[GregBrannon]

@nalldrin: I'm late to the party, but your fix has solved the problem for me - so far. Window rearranging was a Cinnamon killer for me, even though the DE otherwise fit my needs better than any other. I'd gone back to Gnome in order to use an HDMI/USB switch to share a single monitor, mouse, and keyboard between my home desktop and a Raspberry Pi to reduce the hardware on my desk. A previously tried fix, turning xrandr off completely, worked for awhile but eventually went unstable, refusing to reconnect USB. Thank you!

Update on my experience with the fix and discovered unintended consequences: The fix still works, but I learned that with the fix, monitor settings (all?), like changing monitor positions cannot be made. No biggee. Remove the fix, restart the PC, change the desired monitor settings, reapply the fix, and restart. Another unplanned behavior involves screen blanking, especially if blanking results in a locked. system. After switching back to the blanked/locked system, one screen may behave as though it is available to user input, but selecting apps, trying to make inputs, etc. are ignored. This behavior can be overcome by mousing to the other screen (always the shared screen on my system) and getting past the login dialog. I don't remember why this isn't immediately obvious, but the screen with the login dialog may stay blanked longer than the other.

[codexp]

Described bugs are still present in

➜  ~ uname -a
Linux L-X1-9 5.14.0-1042-oem #47-Ubuntu SMP Fri Jun 3 18:17:11 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
➜  ~ cinnamon --version
Cinnamon 5.2.7

Very annoying for me, as I use a lockscreen setting after 5 minutes inactivity.
So every time after a lockscreen I have to rearrange all my windows.
Disabling lockscreen is not an option.

Is there a way to fix xrandr so it works as expected?

The blanked/locked system bug seems often to appear after switching the accounts.