xrandr bugs? (13.1)

I’ve just installed 13.1, and am experiencing what seem to be some fairly major bugs with xrandr. I’ve described one in a previous post here: http://forums.opensuse.org/showthread.php/495458-13-1-laptop-external-monitor-boots-to-low-resolution Far more serious is that running some xrandr commands will often (but not always) cause the user to be logged out - that is, every running user process is killed, and the display shows the xdm login. The commands include ‘xrandr --vervose --output LVDS1 --off’ (to turn the laptop display off), and even a simple ‘xrandr -v’.

System info: xrandr program 1.4.1, server 1.4. Laptop is Lenovo T61 with Intel graphics running in a dock, monitor is Dell 2001FP connected to the dock’s VGA output.

Any ideas on what to do about this, or even where to file a bug report? Xorg doesn’t seem to keep their info up to date - their Wiki on xrandr covers version 1.2,

You can search for and submit Xorg-related bugs here

https://bugs.freedesktop.org/

Do you have all updates installed?
There was a bug in the intel driver in 13.1 which caused X to crash when using xrandr, but this should be fixed already.

See here:
https://bugzilla.novell.com/show_bug.cgi?id=852025

Thanks. Installing the updates seems to have improved the situation considerably. (I don’t know why I assumed that doing a network install would get a system with all uptates/patches already applied…) Still some minor quirks: the system doesn’t boot to the correct 1600x1200 resolution, and doing an ‘xrandr --output VGA1…’ will several times return with “cannot find mode 1600x1200” before eventually setting it. That is, I change nothing in my system, just run the same command several times before it works.

PS: Perhaps off the thread, but why does the updater in yast2 install updates to things I didn’t install and don’t want, like Ruby and Samba?

Hm. Could you post the file /var/log/Xorg.0.log? (maybe upload it to http://susepaste.org or similar and post a link)
Maybe that would provide a clue why your screen’s resolution is not respected.

And which Desktop Environment are you using? (KDE, GNOME, …)
You could try to set the resolution in the Desktop’s settings, maybe it’s overridden there to a wrong one.

PS: Perhaps off the thread, but why does the updater in yast2 install updates to things I didn’t install and don’t want, like Ruby and Samba?

Those packages seem to be recommended by other packages you have installed.

If you don’t want them, just right-click on them and select “Taboo - Never install” in YaST.
Or uninstall them once they are installed, they shouldn’t be installed automatically anymore afterwards.

Although ruby is needed by YaST itself. (YaST’s modules have been translated to ruby for 13.1, they have been written in the proprietary YCP language before)

Here’s a link (I hope!): SUSE Paste

I see that around line 173 it’s setting VGA1 to 1024x768. It’s using default configuration: I’ve never learned to write new-style config files, and they’ve really not bee necessary.

And which Desktop Environment are you using? (KDE, GNOME, …)

I’m not. I’m using the fvwm2 window manager. (Honestly, if I wanted a Windoze-like ‘desktop’, I’d just do Windoze :-)) But the initial setting of resolution to 1024x768 happens well before the window manager is running - AFAIK it shouldn’t start until I log in, no? It’s not always going to low resolution on boot: once in a while it does pick up the 1600x1200 mode. (Just as in previous install, it would rarely boot to low res.) Which makes me wonder whether the new SSD is letting it boot too fast…

Do you think trying to write an Xorg screen config file would force it to the correct res?

I think X cannot read the EDID of the monitor then and therefore sets the default 1024x768.
Is it connected directly or via a KVM? If the latter, try to connect it directly as a test.

It happened to me once that my monitor suddenly provided invalid EDID data. Completely disconnecting it (including the power plug) fixed this.
So maybe try that.

You can still use an old-style xorg.conf file, although it’s recommended to use the new-style config files in /etc/X11/xorg.conf.d/.
Actually they are easier to use. You just put each section of the old config file in a separate file. And you only have to specify the sections you want/need to change, missing ones will be auto-configured.

I’m not. I’m using the fvwm2 window manager. (Honestly, if I wanted a Windoze-like ‘desktop’, I’d just do Windoze :-)) But the initial setting of resolution to 1024x768 happens well before the window manager is running - AFAIK it shouldn’t start until I log in, no? It’s not always going to low resolution on boot: once in a while it does pick up the 1600x1200 mode. (Just as in previous install, it would rarely boot to low res.)

I really think there’s a problem reading the monitor’s EDID data. Sometimes it seems to work though.

Do you think trying to write an Xorg screen config file would force it to the correct res?

Yes, if you do it right of course. :wink:
I guess you should add a modeline to 50-monitor.conf (or create a new file, 50-mymonitor.conf f.e., the name doesn’t really matter).
And then you would need a 50-screen.conf (again the name doesn’t really matter) that references your Monitor section.
But I’m not sure how you would do this with two monitors, so that the modelines only apply for VGA-1. Never had to do anything like this as I only ever used one monitor…

Another possibility would be to provide a file with the correct EDID data with the drm_kms_helper.edid_firmware kernel option.
See drm: allow loading an EDID as firmware to override broken monitor - kernel/git/torvalds/linux.git - Linux kernel source tree
The resolution should then be detected correctly all the time.
This would be the best solution I think.

Have you tried executing “xrandr --addmode VGA1 1600x1200” before the “xrandr --output VGA1 --mode 1600x1200” command?

Does this post solve your problem?

That seems to be it! At least it worked one time, and the boot screen info goes to both displays, instead of just the laptop. I should have thought of that myself, since I had to use the KVM switch as a KM switch: the other machine’s video never worked properly through the switch, so I just connected it to the display’s DVI port.

Another possibility would be to provide a file with the correct EDID data with the drm_kms_helper.edid_firmware kernel option.
See drm: allow loading an EDID as firmware to override broken monitor - kernel/git/torvalds/linux.git - Linux kernel source tree
The resolution should then be detected correctly all the time.
This would be the best solution I think.

Thanks, I’ll give that a look. Or maybe just buy a newer KVM switch…