Udev rule not firing always

[Kaysera]

Hello.

I open this issue because the udev rule does not always fire. When I use udevadm trigger, it does fire and the program executes. But when I plug or unplug the screen, it sometimes does not execute. I'm connecting the screen via HDMI to USB-C adapter.

Cheers.

[fogine]

Does that happen on system startup or randomly?
Only limitation of the current implementation is that Xorg server must be running at the time of udev rule triggering. So in order for the utility to work on system startup, the i3-workscreen executable must be explicitly triggered after Xorg server is running eg. in .xinitrc or your window manager configuration file.

Other than that it will be likely issue with hardware system drivers. You can try to monitor udev events by :

sudo udevadm monitor -u

and see if the system registers the change when you connect/disconnect another display.
You can also check out system log (journalctl) to see any unexpected issues

ps. I also use HDMI to USB-C adapter on my dell laptop which fortunately has excellent firmware for linux systems.

[Kaysera]

It happens mostly randomly. Just after boot it works fine, but after I do several plug-unplug tries, it starts working randomly.

udevadm can indeed monitor the changes, so that is not the problem.

The most uncommon thing is that the system log registers
jun 03 16:27:36 KYSR kernel: usb usb4-port1: Cannot enable. Maybe the USB cable is bad? jun 03 16:27:36 KYSR kernel: usb usb4-port1: attempt power cycle

Regarding the system drivers, I also have a dell laptop. Do I need to install some particular drivers? Currently using Arch Linux, I thought it worked out of the box.

Edit:

I installed the package as non-root (with the --user option of pip), and it is installed in ~/.local/bin. It is the only thing I did different. Does that suppose a problem?

Cheers.

[fogine]

The most uncommon thing is that the system log registers
jun 03 16:27:36 KYSR kernel: usb usb4-port1: Cannot enable. Maybe the USB cable is bad? jun 03 16:27:36 KYSR kernel: usb usb4-port1: attempt power cycle

Well, that sounds like an issue with the adapter. USB-C to HDMI support in linux kernel is relatively new thing, so make sure your kernel is recent enough. You shouldnt be required to install additional drivers, especially if it works sometimes. Also could be issue with power management, you can try to disable related options to powering down usb ports in BIOS.

udevadm can indeed monitor the changes, so that is not the problem.

Indeed it can.However does it report related events being triggered at the times when you (dis)connect display cabel and i3-workscreen doesnt work? (I dont think so)

I installed the package as non-root (with the --user option of pip), and it is installed in ~/.local/bin. It is the only thing I did different. Does that suppose a problem?

No, it shouldn't be a problem. Anyways it wouldnt work at all if it were a problem.

Other debug stuff you can try:

dmesg -w

You would have to run the command in background and wait until the udev rule stops triggering.

When the udev rule doesnt trigger, have you tried to manually execute i3-workscreen from console? Or directly execute xrandr commands? Does that always work?

ps: I bought this adapter a year ago.. works like charm.
I'm also on arch.

[Kaysera]

USB-C to HDMI support in linux kernel is relatively new thing, so make sure your kernel is recent enough.
Updated to Kernel 5.1, same result

However does it report related events being triggered at the times when you (dis)connect display cabel and i3-workscreen doesnt work?

Sorry, I did not express myself correctly. I meant that indeed it report the related events triggered. This happens every time I plug or unplug the screen:

UDEV [364.586327] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)

Other debug stuff you can try:

dmesg -w

That displays the same I wrote before.

When the udev rule doesnt trigger, have you tried to manually execute i3-workscreen from console? Or directly execute xrandr commands? Does that always work?

Indeed, that always work, both options.

I'm at a loss here, because it seems that everything is working when executing the things manually and when logging, the events are fired, so I don't know what else.

Cheers.