Bug 98145

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.