udev support doesn't work on all systems about autorandr HOT 19 CLOSED

Just to clarify: What exactly does not work? Is it just the udev rule, i.e. running autorandr automatically, or do you also have problems with running autorandr.py itself?

We currently have two options to gather the current setup:

• xrandr -v - that is what autorandr.py uses, and also what Stefan's upstream autorandr prefers
• edid files in /sys/class/drm/card*-*/ - that is what the legacy version here perfers

And three options to get notified when the configuration changes:

• An udev rule
• srandrd
• Polling the setup regularly

Which of those work, and which don't?

Maybe a fourth method to get notified is to poll/select the /dev/dri interface. Does this work for you? The following Python script should wait until the display configuration changes (or some other event occurs):

import select
poll = select.poll()
poll.register(open("/dev/dri/card0", "r+"))
poll.poll()

from autorandr.

What doesn't work

1. udev rule - when monitoring with udevadm --monitor there is rarely an event to trigger the udev rule, so in turn the rule will not work.
2. running autorandr automatically - it is my understanding that autorandr does not get ran automatically because of the udev rule not getting fired.
3. running autorandr.py itself - if I run autorandr (from this project) like say autorandr --change then it many times does not detect my connected hardware, however when using the original bash project it detects it fine and loads my saved configuration. This project detects the same configuration and claims it is already loaded.

Options for notification

1. An udev rule - doesn't work on my system
2. srandrd - also doesn't work on my system, possibly due to reliance on udev?
3. Polling - works fine and the reason I created the project http://github.com/nalipaz/poll-xrandr

Thanks for looking into this, I would rather use the updated python version than the old bash version if possible.

from autorandr.

If I get you right, the only thing that prevents you from using your polling ansatz with the Python version is that it claims that the configuration was already loaded. Let's try to resolve that first. Could you please post

• the output of xrandr -q --verbose
• the output of autorandr --config (using the Python version)
• the contents of the configuration file (in ~/.autorandr/PROFILE NAME/config)

from a situation where the Python version claims that the configuration was already loaded though it actually is not?

from autorandr.

All of the following commands were done while my autorandr claimed:

docked
mobile (detected)

Yet, the xrandr layout that was actually loaded was docked despite any output from the commands.
xrandr -q --verbose
autorandr --config
cat ~/.autorandr/docked/config
cat ~/.autorandr/mobile/config

For a little more background. Here is the output of xrandr -q

While using autorandr python library and in mobile state (however, the external monitor is still part of layout):

$ xrandr -q
Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 308mm x 173mm
   1920x1080     60.00*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
HDMI1 disconnected 1920x1200+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm
  1920x1200 (0x55) 154.000MHz
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock  74.04KHz
        v: height 1200 start 1203 end 1209 total 1235           clock  59.95Hz

While using autorandr bash library and in mobile state (correctly loaded):

$ xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 308mm x 173mm
   1920x1080     60.00*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
HDMI1 disconnected (normal left inverted right x axis y axis)

It seems to me that maybe the layout is applied but the output is not turned off properly.

from autorandr.

Are you able to manually enable and disable HDMI1, using

xrandr --output HDMI1 --off
xrandr --output HDMI1 --mode 1920x1200 --pos 1920x0 

and does the output of xrandr -q for HDMI1 change when you do?

from autorandr.

The commands you gave work fine, but looks like the output of xrandr -q is not updated.

$ xrandr --output HDMI1 --off
$ xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 308mm x 173mm
   1920x1080     60.00*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
HDMI1 connected (normal left inverted right x axis y axis)
   1920x1200     59.95 +
   1920x1080     60.00    50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1440x576i     50.00    50.00  
   1024x768      75.08    70.07    60.00  
   1440x480i     60.00    59.94  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08

$ xrandr --output HDMI1 --mode 1920x1200 --pos 1920x0
$ xrandr -q
Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 308mm x 173mm
   1920x1080     60.00*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
HDMI1 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 550mm x 340mm
   1920x1200     59.95*+
   1920x1080     60.00    50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1440x576i     50.00    50.00  
   1024x768      75.08    70.07    60.00  
   1440x480i     60.00    59.94  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08

What is being done differently in the bash implementation I am not sure. Perhaps xrandr -q is unreliable? However, I doubt it because I use xrandr -q | grep " connected"|cut -d ' ' -f1|xargs to detected (dis)connects in my poll-xrandr project.

from autorandr.

from autorandr.

Oh, wait, I screwed up the above output because I forgot to unplug the display between running the command XD sorry...

Here is corrected output which looks normal to me:

Disconnect HDMI1 then run:

$ xrandr --output HDMI1 --off
$ xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 308mm x 173mm
   1920x1080     60.00*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
HDMI1 disconnected (normal left inverted right x axis y axis)

Reconnect HDMI1, then run:

$ xrandr --output HDMI1 --mode 1920x1200 --pos 1920x0
$ xrandr -q
Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 8192 x 8192
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 308mm x 173mm
   1920x1080     60.00*+  59.93  
   1680x1050     59.95    59.88  
   1600x1024     60.17  
   1400x1050     59.98  
   1280x1024     60.02  
   1440x900      59.89  
   1280x960      60.00  
   1360x768      59.80    59.96  
   1152x864      60.00  
   1024x768      60.00  
   800x600       60.32    56.25  
   640x480       59.94  
HDMI1 connected 1920x1200+1920+0 (normal left inverted right x axis y axis) 550mm x 340mm
   1920x1200     59.95*+
   1920x1080     60.00    50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1440x576i     50.00    50.00  
   1024x768      75.08    70.07    60.00  
   1440x480i     60.00    59.94  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08

from autorandr.

Just to reiterate my explanation from earlier as well. It looks like the output from xrandr -q doesn't look right for my HDMI1 under the conditions:

• the python library
• the docked profile is detected/loaded
• the HDMI cable is disconnected

HDMI1 disconnected 1920x1200+1920+0 (normal left inverted right x axis y axis) 0mm x 0mm
  1920x1200 (0x55) 154.000MHz
        h: width  1920 start 1968 end 2000 total 2080 skew    0 clock  74.04KHz
        v: height 1200 start 1203 end 1209 total 1235           clock  59.95Hz

versus the output from xrandr -q when using the bash library or just disabling the display directly with xrandr --output HDMI1 --off:

HDMI1 disconnected (normal left inverted right x axis y axis)

from autorandr.

Whether you use the Python or Bash version doesn't make a difference for xrandr's output - both programs run xrandr --verbose -q to check which configuration is active and do nothing else until they apply a configuration. Whether there is a resolution in xrandr's output after "disconnected" or not doesn't make a difference either, both versions of autorandr detect this as a disconnected output.

There's one important test missing above: If you run xrandr --output HDMI1 --off with a disconnected HDMI1, and then connect it, what's the output of xrandr --verbose -q (before performing any configuration changes)?

Also, ~/.autorandr/docked/setup and ~/.autorandr/mobile/setup could be useful.

from autorandr.

I am going to run the commands here shortly.

What might be the reason for the different output of HDMI1 in xrandr -q if both libraries apply the layout using the same method?

from autorandr.

They don't apply the layout using the same method. But that's one step too far ahead: You've said that autorandr.py cancels with a message claiming that the configuration was already loaded. That means it doesn't apply the layout at all, because it assumes it doesn't need to. We need to find out why it thinks that.

I think I have an idea what the issue is; I might have misunderstood the

HDMI1 disconnected 1920x1200+1920+0

line. Do I get this right: The screen is disconnected, but there still is a - now invisible - 1920x1200 area right of your screen. And autorandr.py doesn't remove that invisible area, while bash autorandr does?

from autorandr.

If this is the problem, the changes https://github.com/phillipberndt/autorandr/tree/connection-ne-usage might resolve this!?

from autorandr.

Yes you are right, I did initially say that, however I restated that, "It seems to me that maybe the layout is applied but the output is not turned off properly."

And yes, the layout that is loaded is a layout where the screen is disconnected, but the canvas (for lack of a better word) of the outputs still extends 1920x1200 to the right of the primary output. This means my mouse and windows can still make their way over there I can't see them.

from autorandr.

$ git fetch
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From github.com:phillipberndt/autorandr
 * [new branch]      connection-ne-usage -> origin/connection-ne-usage
nicholas@alipaz-y40:~/.scripts/autorandr$ git checkout connection-ne-usage
Branch connection-ne-usage set up to track remote branch connection-ne-usage from origin.
Switched to a new branch 'connection-ne-usage'
nicholas@alipaz-y40:~/.scripts/autorandr$ sudo ln -f -s /home/nicholas/.scripts/autorandr/autorandr.py /usr/bin/autorandr

Yep, it now seems to work as expected! Nice work. Let me know if you merge that into master. Now back to the detection of hotplugs via udev

Options for notification

1. An udev rule - doesn't work on my system
2. srandrd - also doesn't work on my system, possibly due to reliance on udev?
3. Polling - works fine and the reason I created the project http://github.com/nalipaz/poll-xrandr

Unfortunately on my system the only thing that works is polling. Not sure how you want to incorporate detection in your project or at what point detection might just be deemed edge-case (won't fix).

from autorandr.

I still hope that polling can be avoided. Which graphics driver do you use - both on Xorg's and the kernel's side? (Maybe we can find out why RRScreenChange, the event that RandR uses to notify srandrd of changes, isn't fired, or/and find a workaround.) Is there any dmesg output upon changes that we could use?

from autorandr.

connected
disconnected

from autorandr.

I merged the change into master now.

The dmesg looks disappointing. Also, the radeon driver is closed source (at least the part of the code that is available doesn't contain any udev references). Which leaves polling as the best option. Integrating this into autorandr wouldn't bring any benefits over your poll-xrandr, so I'd tend to leave things as they are. If you, however, want to add your script to the contrib/ folder or just a link to your project to the readme (in a new section for known issues & workarounds, maybe?), go ahead, I'll happily merge a corresponding pull request!

from autorandr.

Thanks for all the help and discussion. I will review the options and finish some stuff up on my script (I may actually rewrite in python too). Then I will let you know how I think I want to proceed with the poll-xrandr project. Best!

from autorandr.