xrandr block bug

[evanrichter]

this frustrating bug took me a while to track down but I'm pretty sure it's this exact module. intermittently, if this module is enabled in my barconfig.toml, the entire screen will go black with no recovery possible. If I'm lucky, it will happen when I'm at a terminal and I can ^C then issue a reboot. I cannot switch to other TTYs to bring the screen back. My configuration looks like this for xrandr:

[[block]]
block = "xrandr"

Let me know if you need any more info to look into this. For now, I've removed the block and everything seems to be working

[atheriel]

Yikes. Do the xrandr commands otherwise function normally on your system?

[evanrichter]

all the commands found in xrandr.rs work as intended when run from a terminal. I also ruled out that redshift (it warms the display color) is not interfering here. I think whats happening is the module is setting the display brightness to 0.0 without user's intent.

[x123]

the xrandr block caused issues on my system, each time it ran it probed for new Modeline. I did not get any black screen, but it did hard lag my X windows every single time it updated. I'd recommend at least putting a warning or disclaimer on the xrandr block documentation, it's simply unusable for me due to the lag it introduces on each update interval.

The constant and repeated modeline spam it produced in X.log upon each interval refresh:

[   829.251] (II) modeset(0): EDID vendor "LGD", prod id 1313
[   829.251] (II) modeset(0): Printing DDC gathered Modelines:
[   829.251] (II) modeset(0): Modeline "1920x1080"x0.0  138.70  1920 1968 2000 2080  1080 1083 1088 1111 +hsync -vsync (66.7 kHz eP)
[   829.251] (II) modeset(0): Modeline "1920x1080"x0.0  110.92  1920 1968 2000 2080  1080 1083 1088 1111 +hsync -vsync (53.3 kHz e)

[atheriel]

@x123 I'm not sure your comment is relevant to this specific issue. If the default interval settings for the block are causing lag, it would probably be better to open a new one.

[ammgws]

@evanrichter Does this still happen?

[evanrichter]

I don't know, sorry!

[timokratia]

I'm in a similar situation: enabling the xrandr block causes my computer to reboot after 2 to 10 minutes, while brightness control via scrolling works fine, as well as using xrandr to set brightness on the command line.

I'm using Solus on a ThinkPad X220, and xrandr --version gives me

xrandr program version       1.5.1
Server reports RandR version 1.6

Please let me know where to look for the related system log so I can provide more information, since I'm not very familiar with it. Thanks!

[ammgws]

From a quick look at the source, this is what the block does every update interval:

1. Gets a list of monitors: xrandr --listactivemonitors | grep \\/
2. Then runs this command for each monitor: xrandr --verbose | grep -w '{} connected\\|Brightness' (replace {} with monitor name from first command)

If you make a bash script that loops those commands every xx seconds do you experience the same symptoms?

[timokratia]

Thanks for the reply! I do experience the same symptom.

The first time I ran xrandr --verbose | grep -w '{} connected\\|Brightness', it rebooted immediately. Then I put the commands in a script and use watch to run them every 5 seconds. I tried 2 times, and my computer rebooted after 10 and 2 minutes.

It might also has something to do with my ThinkPad I'm not sure, because I had it modded for a better screen. xrandr recognizes the modded ThinkPad screen as DP3 and my external monitor connected via VGA as VGA1. But this could also be unrelated.

Would it be helpful to look for system logs related to the reboot? If yes, where should I look at? Thank you!

[ammgws]

Would it be helpful to look for system logs related to the reboot?

I suppose so but at this point it's not a bug with i3status-rust, but rather with xrandr/your system, and I use a Wayland system so not sure how much actual help I can provide.

Maybe check dmesg output and X logs (probably in /var/ somewhere)?

Also what distro you're running and your graphics info might be helpful too.

[timokratia]

I suppose so but at this point it's not a bug with i3status-rust, but rather with xrandr/your system,

You're right, I'll look for related xrandr bug reports as well as dmesg and X logs as you pointed out.

Also what distro you're running and your graphics info might be helpful too.

I'm using Solus, and neofetch says the graphic is Intel 2nd Generation Core Processor Family.

Thank you for your help, I'll come back to report more info if I find anything useful. Cheers.

[ammgws]

I'll add a note to the block documentation as well. If anyone finds out the cause of this issue then please re-open.