Is there a way to prevent Mint from responding to display configuration changes?

[jwatts1980]

TLDR; a Windows service is triggering a phantom monitor disconnect event which is messing with my screen config in Linux Mint running in VMWare Workstation.

I have only been using Linux for a couple of months, but I've run into a interesting issue which has nothing to do with Linux, but maybe there is a Linux based solution. I have a Windows 10 laptop running Linux Mint 20.1 in VMWare Workstation 16 Pro. I have 3 monitors and I have VMWare configured to use 2 of my monitors at a time.

The problem is that there is some service on my laptop that is causing a display configuration change multiple times a day (~15 times). I was able to catch it happening by writing a little Windows forms .NET C# logging program based on this MS article: https://docs.microsoft.com/en-us/dotnet ... ew=net-5.0

Every time the phantom service triggers a config change:
- the logging program logs a trigger to the SystemEvents_UserPreferenceChanging event
- nothing happens in Windows - no screen flashes or windows moving, no indication that an event occurred.
- but VMWare is picking up that change, dropping out of multi-monitor mode, then sends the display config change to the Linux VM
- and Linux is reading it as a monitor 2 disconnected event.


So my second monitor disconnects from Linux and Mint moves all of my windows over to monitor 1. About 10 times during the work day I then have to hit the multi-monitor mode button in VMWare to reconnect the second monitor, and then manually move all my Linux programs back over. I have not been able to track the source. Could be a Windows service, something from Dell, an Nvidia drivers, or a service related to my docking station (<- this is the one I think it is).


On the Linux side, I'm hoping to find a way to have Linux ignore window configuration changes. I've found that the service responsible for handling this in Mint is csd-xrandr. It is the first service listed in Startup Applications.

As I see it, I have a couple of options.

**Option 1:** kill the csd-xrandr service.

I'm not sure how to do this, and I have a feeling this service handles more than just monitor inputs. I would be willing to try it, but I think I'd have to kill it after the desktop loads.


**Option 2:** Somehow capture those config change events and ignore them, or prevent them from being caught in the first place.

In chasing this issue, I found the C code for the csd-xrandr manager here: https://github.com/linuxmint/cinnamon-s ... er.c#L1850 .

Around line 1850 there is an "on_randr_event" that takes some monitor related inputs. My C skills are very poor, and I do not know how to follow that method call back up the stack to see what is calling that event and figure out how to capture or ignore it.


**Option 3:** something I haven't thought of yet.

[vimes666]

Option 3 suggestion:
Have you tried using virtualbox instead of vmware?

[jwatts1980]

I have not tried VirtualBox. There are a few business reasons why I'm using VMWare Workstation. If VB has the ability to import and run VMW images, that might be something I can try... but I'm not going to be able to use VB long term.

[rene]

Lame answer, but your issue is involved enough that I'd say chances of anyone here knowing are very, very slim; that you'd need to retreat to a VMWare forum with this question.

[jwatts1980]

Lame answer, but your issue is involved enough that I'd say chances of anyone here knowing are very, very slim; that you'd need to retreat to a VMWare forum with this question.

I have a VMWare support ticket in progress with this issue. Once I figured out that it was a Windows service triggering the change, I updated the ticket. I was asking if there was a way in VMW to disable monitor change events from passing into the guest OS. My last response from them this morning was "Thank you for your response and update. We are further checking on your response and will update you at the earliest. Thank you for choosing VMware." So, how knows there that is going.

I also have a Stack Overflow question posted to see if there is a way to figure out which Windows service is triggering the display change. But no traction there as of yet. Likely for the same reasons you suggest, I'll end up having to put a bounty on the question.

I was going to post in AskUbuntu, but this is really more of a Mint question. Maybe SuperUser. IDK, this seemed like the natural place for it, but I'm new to the OS and this forum so I don't have the context you do

[SMG]

Every time the phantom service triggers a config change:
- the logging program logs a trigger to the SystemEvents_UserPreferenceChanging event
- nothing happens in Windows - no screen flashes or windows moving, no indication that an event occurred.
- but VMWare is picking up that change, dropping out of multi-monitor mode, then sends the display config change to the Linux VM
- and Linux is reading it as a monitor 2 disconnected event.

Linux Mint has hot-plugging capability so if a monitor is connected or disconnected then it will react appropriately. Because your system is passing through a VM layer, there are additional places where a "disconnect" might happen even if the hardware disconnect does not happen. Mint can only react to what it sees.

I was going to post in AskUbuntu, but this is really more of a Mint question. Maybe SuperUser. IDK, this seemed like the natural place for it, but I'm new to the OS and this forum so I don't have the context you do

I am not aware of there being a way to turn off the hot-plug capability.

As I read this description, to me the problem seems to be upstream of Mint.

[jwatts1980]

Mint can only react to what it sees. As I read this description, to me the problem seems to be upstream of Mint.

Oh yeah. 100%. Definitely not a problem with Mint. This post was to see if there was a way to handle the issue in Mint. Being new to the OS and Linux in general, I was hoping someone here might be able to suggest a high level or low level way to keep the Mint screen resolution "locked" so that it ignores display change events. (Ideally without sacrificing other system services/events.)

[rene]

Actually, there probably is. Just came from a different thread involving a so-called udev rule. If you open a terminal in Mint and run

Code: Select all

sudo udevadm monitor -p

and trigger the event, you may in the output in said terminal notice a kernel-level event that corresponds to that display change. If detailed enough we can then write a udev rule to tell udev to ignore it; to not distribute it further up into userspace, that is.

One issue with -p is that it tends to be rather verbose. Perhaps first try without -p and, after having identified the correct event, do it again with and only paste back the correct event/events in the kind of full detail that -p provides for.

[jwatts1980]

Actually, there probably is...

Code: Select all

sudo udevadm monitor -p

and trigger the event, you may in the output in said terminal notice a kernel-level event that corresponds to that display change. If detailed enough we can then write a udev rule to tell udev to ignore it; to not distribute it further up into userspace, that is.

Very interesting. Okay, so, the process is that VMWare is normally running in multi-monitor mode with 2 displays configured. In the menu in VMW I can manually enable or disable multi-monitor mode. When I enable it, VMWare basically artificially triggers a hot-plug event to the guest OS. Right, because the number of monitors on my host system didn't actually change, but VMWare is telling Mint that it did, so Mint responds accordingly.

With this issue I am having, VMW is picking up this random Windows change and thinks it is a real monitor disconnect event. So, it automatically drops out of multi-montior mode.

Using your suggestion and the information above, I ran the udev command with -p, and manually disabled multi-monitor mode, same as if VMW had done it automatically because of the errant event. Here is the result:

Code: Select all

$ sudo udevadm monitor -p
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1155506.495537] change   /devices/pci0000:00/0000:00:0f.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:0f.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=126750
MAJOR=226
MINOR=0

UDEV  [1155506.499210] change   /devices/pci0000:00/0000:00:0f.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:0f.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=126750
USEC_INITIALIZED=4273741
ID_PATH=pci-0000:00:0f.0
ID_PATH_TAG=pci-0000_00_0f_0
ID_FOR_SEAT=drm-pci-0000_00_0f_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-0000:00:0f.0-card
TAGS=:master-of-seat:uaccess:seat:

When I enable multi-monitor mode, it looks like this:

Code: Select all

$ sudo udevadm monitor -p  
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1156557.196421] change   /devices/pci0000:00/0000:00:0f.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:0f.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=126983
MAJOR=226
MINOR=0

UDEV  [1156557.199095] change   /devices/pci0000:00/0000:00:0f.0/drm/card0 (drm)
ACTION=change
DEVPATH=/devices/pci0000:00/0000:00:0f.0/drm/card0
SUBSYSTEM=drm
HOTPLUG=1
DEVNAME=/dev/dri/card0
DEVTYPE=drm_minor
SEQNUM=126983
USEC_INITIALIZED=4273741
ID_PATH=pci-0000:00:0f.0
ID_PATH_TAG=pci-0000_00_0f_0
ID_FOR_SEAT=drm-pci-0000_00_0f_0
MAJOR=226
MINOR=0
DEVLINKS=/dev/dri/by-path/pci-0000:00:0f.0-card
TAGS=:uaccess:seat:master-of-seat:

KERNEL[1156557.773077] remove   /buffer_head(32061:NetworkManager-dispatcher.service) (cgroup)
ACTION=remove
DEVPATH=/buffer_head(32061:NetworkManager-dispatcher.service)
SUBSYSTEM=cgroup
SEQNUM=126984

UDEV  [1156557.774091] remove   /buffer_head(32061:NetworkManager-dispatcher.service) (cgroup)
ACTION=remove
DEVPATH=/buffer_head(32061:NetworkManager-dispatcher.service)
SUBSYSTEM=cgroup
SEQNUM=126984
USEC_INITIALIZED=1156557773148

KERNEL[1156557.782697] remove   /dentry(32061:NetworkManager-dispatcher.service) (cgroup)
ACTION=remove
DEVPATH=/dentry(32061:NetworkManager-dispatcher.service)
SUBSYSTEM=cgroup
SEQNUM=126985

UDEV  [1156557.784149] remove   /dentry(32061:NetworkManager-dispatcher.service) (cgroup)
ACTION=remove
DEVPATH=/dentry(32061:NetworkManager-dispatcher.service)
SUBSYSTEM=cgroup
SEQNUM=126985
USEC_INITIALIZED=1156557782817

[jwatts1980]

PS
I did let it catch the event one time with the automatic route, but I didn't have -p on that one. The result was the same change lines without all the details.

Code: Select all

KERNEL[1155107.154477] change   /devices/pci0000:00/0000:00:0f.0/drm/card0 (drm)
UDEV  [1155107.157371] change   /devices/pci0000:00/0000:00:0f.0/drm/card0 (drm)

[ivar]

So my second monitor disconnects from Linux and Mint moves all of my windows over to monitor 1. About 10 times during the work day I then have to hit the multi-monitor mode button in VMWare to reconnect the second monitor, and then manually move all my Linux programs back over. I have not been able to track the source. Could be a Windows service, something from Dell, an Nvidia drivers, or a service related to my docking station (<- this is the one I think it is).

Docking stations are able to do all kinds of weird stuff in multi-monitor setups in my experience

First thing I'd do is make sure Bios / firmware is up to date on both pc and docking stations + the Nvidia drivers. Then, what kind of connections are used for the monitors?
I've found HDMI cables to me more vulnerable than, say Displayport.

Is there any pattern to the disconnects or are they pretty much random?
I'd take a look in Task scheduler on the host to see if there's any triggered events being run when it happens.

Also, if its always "monitor 2" that craps out, maybe try to swap monitor 2 and 3 as a test to see if the problem stays or disappears

[rene]

Code: Select all

KERNEL [1155107.154477] change   /devices/pci0000:00/0000:00:0f.0/drm/card0 (drm)
UDEV  [1155107.157371] change   /devices/pci0000:00/0000:00:0f.0/drm/card0 (drm)

Mmm. yes, also with -p we didn't get much more to select on; I was hoping for ADD/REMOVE events but it seems you are getting only a CHANGE event both for enable and disable. That's to say that on this level we would only get to ignore that and doing that fully might be too much; I'm not sure what else generates a CHANGE event.

And to be frank I'm also noticing it does not in fact seem obvious how to fully drop some given event which was my idea, so let's just test; it seems you can reproduce at will, so...

In Mint and as root, create a file /etc/udev/rules.d/ignore-monitor-connect-disconnect.rules (name is free; extension must be .rules) with

Code: Select all

SUBSYSTEM=="drm", ACTION=="change", OPTIONS="ignore_device"

Copy-paste that, or at least note that the last key has a single = whereas the earlier ones have double ==.

Although it shouldn't be necessary use sudo udevadm control --reload if it doesn't seem to work immediately after dumping that file into that given directory or even reboot the Mint VM to be even more sure it doesn't work if indeed it doesn't...

If this doesn't work: the missing event granularity implies that X.org in fact largely handles this itself, using the event only as a wake-up. That's then to say further attempts would want to live at the level of X itself and I sort of really, really do not so we may be done quickly again here.

[rene]

Damn it; "ignore_device" was removed:

https://cgit.freedesktop.org/systemd/sy ... cfa2da9cb0

Seems there's no way to just outright drop the event then; so much for that idea.

[ivar]

Also, if its always "monitor 2" that craps out, maybe try to swap monitor 2 and 3 as a test to see if the problem stays or disappears

I've had monitors that fo no reason, just go into powersave , maybe a thng to check out?

[vimes666]

Have a look at this topic, it seems to offer a solution for xfce, cinnamon and mate:
https://askubuntu.com/questions/743473/ ... figuration

[jwatts1980]

Damn it; "ignore_device" was removed:

https://cgit.freedesktop.org/systemd/sy ... cfa2da9cb0

Seems there's no way to just outright drop the event then; so much for that idea.

Are you saying the udev option is a bust? Or still something worth trying?

[jwatts1980]

I've had monitors that fo no reason, just go into powersave , maybe a thng to check out?

I didn't occur to me that it could just be one specific monitor. But I'm not sure it is relevant? The interesting thing is that in the Windows host.. like visually to me sitting at the desk.. there is nothing that indicates the monitor is having an issue. No lights blink. If I'm using just windows with the VM turned off, no windows move around or flash. There's no indication that anything has happened.

I've had the laptop and the dock for about 8 months. And I've been running Mint in the VM for only about 2 months. This was a problem I was having from the beginning of using the VM. So I can only assume Windows was already doing this thing before and I never noticed until VMWare started picking it up.

[rene]

Are you saying the udev option is a bust?

Yes. I already had trouble locally trying to get udev to simply outright drop on the floor a given event, as was my notion originally, and then later found that commit to udev that explicitly removed the (shadow of a...) possibility to do so. A commit from 2009 already I also later saw so hurray for the internet as documentation for Linux; I found the ignore_device option from seemingly current Debian documentation (specifically from http://reactivated.net/writing_udev_rules.html as linked by https://wiki.debian.org/udev).

Anycase then, yes, that's a bust. Also in the earlier mentioned sense of you getting very sparingly specified events in the first place; how this implies that X basically handles this largely itself --- and in that sense the post just above from vimes666 looks quite interesting; it details disabling xrandr outright, i.e., disable the thing that would listen to any such event or at least, do something in response. Also a 5+ year old link so YMMV I suppose; you'd need to test.

[jwatts1980]

Have a look at this topic, it seems to offer a solution for xfce, cinnamon and mate:
https://askubuntu.com/questions/743473/ ... figuration

I have read through the linked post. I will give some of that a try this weekend. Thank you