X modesetting problem on dell laptop
Submitted by Klaus Kusche
Assigned to Xorg Project Team
Description
When I returned to our university after my summer holidays, I noticed that all our VGA beamers in the lecture halls no longer synced to my laptop (they did with no problem several months ago).
In detail:
-
All the beamers are 1024x768@60, no more. Some of them send broken EDID data, some of them do not send EDID at all (I'm not sure if any beamer sends valid EDID data). Doesn't make any visible difference for my problem.
-
The linux kernel configures them correctly in framebuffer text mode.
-
After starting X, they are out of sync.
-
Setting the VGA mode with xrandr takes 10-20 seconds (laptop completely blocked) and results in the wrong mode:
No matter if I specify the mode as 1024x768, or as 1024x768 at 60, or by hex (0x59), or if I define my own 1024x768@60 mode and use that (as I did for the log files attached: Added a VESA-compatible 1024x768 mode and set the VGA output to that), in most cases the VGA output is (again?) set to a 1024x768 @ 120 mode (hex 0x58, 1024x768 @ 60 double scan, detected by the beamers as 2048x1536 or 1024x768@120, not syncable), and in rare cases it is set to some seemingly random mode (also too fast for the beamers).
- Turning the VGA output off with xrandr and setting it again in many cases results in the correct 1024x768@60 after many seconds, the beamers sync. Sometimes, this results in the same unuseable 1024x768 doublescan mode as before.
Strange observations:
-
The evil 0x58 double scan mode cannot be removed from the VGA output or the mode table by xrandr. It seems to be hardcoded (and it seems to be a valid mode for the builtin laptop display).
-
In some rare cases, xrandr --verbose shows the output in the desired 0x59 mode (1024x768@60), but the VGA output is actually still running at 0x58 1024x768 doublescan (i.e. what xrandr thinks is not what the hardware does)!
-
Even setting the VGA output to 1024x768@60 the hard way (using a "video" kernel boot parameter) does not keep X from setting it to 1024x768 double scan.
Hardware and software:
- Dell precision M6700 laptop with ATI "cap verde" graphics: [drm] initializing kernel modesetting (VERDE 0x1002:0x6825 0x1028:0x053F 0x00)
Of course, dell configures it as a professional "fire" graphics card...
- Recent Dell BIOS, which causes an error message in the kernel: radeon 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff ATOM BIOS: Heathrow
Tried several BIOS versions, reflashed several times, error persists.
-
Gentoo linux, locally compiled kernel, up to date (currently 4.7.6), up-to-date radeon microcode (loads without errors).
-
Kernel modesetting & drm, X started after login in existing framebuffer vt and login session (not opening a new vt), in non-root (non-suid) mode.
-
Xorg server version 1.18.4, running builtin modesetting driver ( not radeon driver, but the last time I tried the radeon driver some months ago, modesetting behaviour was identical in both drivers).
Problems (I think these are really two distinct and independent problems?!):
1.) Where does that evil 0x58 1024x768 doublescan mode listed by xrandr as a valid mode for the VGA output (!) come from? (definitely not from any beamer's EDID !)
And why does X choose that mode as the default mode for VGA on startup? Especially if the beamer is not sending EDID (or a broken EDID), 1024x768@120 is not a reasonable default VGA mode (by far too fast for all common VGA devices)!
The kernel knows that 1024x768@60 is the mode to use and sets it correctly without even trying 1024x768@120. Why is X pretending to know better than the kernel? There is a correct builtin 1024x768@60 mode listed in xrandr, it should be used by default at startup (especially if the kernel was started with video=VGA-1:1024x768M@60 !)
And why is the hardware set to this mode 0x58 by xrandr even if a completely different 1024x768 mode (0x59 or user-defined) is specified in xrandr? (and why does the mode shown in xrandr in rare cases not correspond to the mode the hardware uses)?
2.) Why is any mode change taking ages (many seconds), with the laptop being blocked and the displays (both internal and external) being all black or randomly flashing or out of sync or showing only part of the screen?
There are some ATOMbios errors related to that (see dmesg), but I think only for xrandr mode changes. As for as I can tell, there are no errors for the initial modeset.
Unfortunately, I can't bisect. Last known good is not known and at least 6-12 months in the past, and I use Gentoo (rolling upgrades) and update every week...
I'll attach Xorg.log and dmesg.