(In reply to comment #0)
> For full details kindly see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750605

There are no details there or here...

Please start with an Xorg.0.log and a description of what you mean by beserk, and since you are filing upstream testing with the latest upstream version would be sensible.

OK I will post the logs soon.
By berserk I mean diagonal lines racing across the screen.
I think I am using the latest version according to 
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/
Installed: 2:2.99.914-1~exp1
Anyway I can only use .debs.

OK I am sorry. It turns out all the weirdness occurs on my attached
BenQ FP747 monitor!

I found the fix was to change
xrandr --output VGA1 --auto --brightness 0.6 #to
xrandr --output VGA1        --brightness 0.6

And now everything is fine.

Then I don't need this in
/usr/share/X11/xorg.conf.d/67-jidanni.conf
anymore:

Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "AccelMethod"  "uxa"
EndSection

nor do I need to resort to holding back post May 2014 versions of the
package either.

I'm not sure why I used --auto in the first place. But now that it
broke starting May 2014, I'll stay away from it.

Created attachment 103968 [details]
xorg log

I wonder what the difference is. Can you please attach the output of

xrandr --output VGA1 --auto; xrandr --verbose; xrandr --output VGA1; xrandr --verbose

Created attachment 103987 [details]
after --auto

Well doing
xrandr --output VGA1 --auto; xrandr --verbose; xrandr --output VGA1; xrandr --verbose
caused my screen to go berserk, and made to identical copies of output "BAD".
The second call didn't fix anything. All I could do was
switch to a tty and do systemctl stop nodm.service; systemctl start nodm.service .
Then I did xrandr --output VGA1; xrandr --verbose, saving into "GOOD".
The primary difference is 48(GOOD) vs. 94(BAD):
$ sort BAD GOOD|uniq -u
  1280x1024 (0x48) 135.000MHz +HSync +VSync *current +preferred
  1280x1024 (0x48) 135.000MHz +HSync +VSync +preferred
  1280x1024 (0x94) 141.813MHz -HSync +VSync *current
  1280x1024 (0x94) 141.813MHz -HSync +VSync +preferred
VGA1 connected 1280x1024+0+0 (0x48) normal (normal left inverted right x axis y axis) 338mm x 270mm
VGA1 connected 1280x1024+0+0 (0x94) normal (normal left inverted right x axis y axis) 338mm x 270mm

Created attachment 103988 [details]
GOOD after restarting nodm

Files:
BAD after --auto
GOOD after restarting nodm

Ok, it just looks like you monitor doesn't handle "1280x1024@76Hz". This would not be an issue except that since it is the highest dotclock mode it is the one selected by auto. xrandr --output VGA1 --preferred should do the right thing.

Ho ho ho
xrandr --output VGA1 --preferred
causes my monitor to become totally white.

So then on the tiny EEEPC window I restarted nodm.
Still totally white.
Only antidote: reboot.

Anyway I am happy with my
xrandr --output VGA1 --brightness 0.6

If for some reason I want to use --auto
I must load the
Option      "AccelMethod"  "uxa"
above.

Created attachment 104002 [details] [review]
Add the current CRTC mode last.

The only difference is that SNA queries the current mode in case it is not in the EDID and adds that to the mode list. This can reorder the modes wrt UXA. The attached patch should prevent that reordering.

Glad you found the problem!
I'll test it when the .deb hits Debian and will report back here.

(In reply to comment #11)
> Glad you found the problem!

Only presume that is causing the problem, since the auto mode selection code is elsewhere... Oh well, let's push and find out.

commit ab3f1526f19ec405dca8ab3094a626096dc30358
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Mon Aug 4 16:23:00 2014 +0100

    sna: Add the current CRTC mode last
    
    We only want to add the current mode to the modelist if it is not
    already present in the EDID. At the moment, we always add the current
    mode first which causes the list to be reordered. If we add it after
    checking the EDID, then we will not perturb the list.
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82068


Presuming the issue is now worked around.