Please attach your Xorg.0.log.

Created attachment 110587 [details]
Xorg.0.log

Hmm, maybe Xorg.0.log.old? The important bit is to try the xrandr setup of the 24/1001 mode so that I can see if it is any failure message.

This was the Xorg.0.log.old, the new is only using the internal LVDS. I did several xrandr commands when the PJ was hooked up, so it apparently did not produce an error.

Not only did it not produce an error, but it also never tried to set any mode. The xrandr request didn't make it through to the driver.

Could you capture the xrandr traffic using xtrace?

I'll do another test later on with xtrace (currently without physical access to perform a new test)

I wish I had a monitor with 24Hz support (vs. PJ), as this would be a lot easier to diagnose...

Created attachment 110597 [details]
Xorg.0.log

Xorg.0.log which shows the attempted switch to 24Hz, and then the immediate switch back to 60Hz. (The old log file must have been overwritten during my tests.)

Created attachment 110598 [details]
xtrace xrandr --output HDMI2 --mode 1920x1080@23.97610

xtrace of xrandr trying to switch to 23.976Hz on HDMI2

Yes, xrandr switches mode correctly. Then something tells to switch back. Do you have a display manager running in the background responding to RandR notifications?

What you might like to try is gdb Xorg and "b __sna_crtc_set_mode" to see where the mode resets are originating from (i.e. whether they are due to client requests or internal). I suspect external requests, like a display manager applying its configuration everytime it notices a change.

Do you mean window manager, or display manager?

I am obviously running a display manager (like most other people). The same display manager which worked properly in 13.04 (mdm).

As for window manager, I've verified this behaviour across several, which include:

- Cinnamon
- XFCE
- Unity
- IceWM
- Gnome (classic/flashback)

So it does not appear to be related to a specific WM.

Just out of curiosity; are you able to set a 24Hz mode on an external screen with any of your test setups, assuming you have a 24Hz-cable external screen? (if so, on which DM & WM?)

If there really is some obscure component causing this, I would naturally like to get it identified.

I might not have time to run a full gdb trace for Xorg while testing this week, but if I do I'll post it. Hopefully I can attach gdb to the running process and do a thread apply all bt.

I mean something like gnome-display-manager (or something like that). There's a little daemon which stores user configuration for different display setups and listens for RandR events to match up with earlier configs and reapply them. (It is an issue that crops up from time to time.)

Current -intel and -nightly:

Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
   1920x1080     60.00 +  60.00    50.00    59.94    24.00    23.98* 
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     75.02    60.02  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.08    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x576i      50.00  
   720x480       60.00    59.94  
   720x480i      60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
HDMI3 disconnected (normal left inverted right x axis y axis)
VGA1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

that's using a bare X.

I can try starting X without a display manager (i.e, with 'startx' or similar) to rule out any issues. I am currently running MDM (a derivative of GDM).

At least it is reassuring that it works on your test setup.

Any news or further info?

First off, sorry for the late reply.

The issue was not related to the display manager; it behaved the same when launching the session via startx & .xinitrc (although this had to be done as root/sudo due to access issues with direct rendering)

However, it also does not appear to be strictly driver-/kernel related either.

I was able to switch to a 24Hz mode when running in a MATE session. This was on a secondary test system running on Haswell (not my primary Ivy Bridge one). Interestingly, I was not able to launch any session via startx other than the failing Cinnamon session.

What is curious is that I made several tests, using the WMs listed further up, and they all behaved the same wrt. not being able to set the 24Hz mode. Those tests were time consuming, and done a few months back using slightly older version of the drivers and were run on IVB. 

So it appears that the bug report was somewhat misidentifying the issue. I'll hopefully be able to perform some more tests this weekend and can close it unless the behavior is inconsistent.

Tests were done on 3.13.5, btw. (didn't upgrade in order to get a better idea of where the fault, if any, might have been.)

Ok, no worries - thanks for trying to nail it down.

One relatively quick task you could do for me is compile xf86-video-intel with --enable-debug=full and attach the debug Xorg.0.log for the non-persistent 23.96Hz modeset. I am not sure if it will shed more light, but it might.

My primary suspect for this ill-behaviour is currently "Cinnamon" (which actually was the one DE that worked properly before). "Before"=Ubuntu 13.04.

If I have time I can compile the X driver to produce some debug output, but the issue as it stands now at least appears to be tied to the DE. (Unless there are other aspects impacting this as well, which could also be the case considering all the directions this bug has taken.)

Not sure if you have Cinnamon available, but if so it could be quickly confirmed or denied if it indeed is the culprit (and escaped detection before). I've actually done three upgrades (with subsequent rollbacks) on my HTPC as a result of this due to what was thought to be a glitch with the drivers.

Oh boy is my reply late..! (I was sure this bugreport had already been closed; I never had time to follow this up properly last year around the time it was logged - my sincerest apologies for that!)

Nevertheless (and in case it might still be of interest), I believe I narrowed this nasty little bug down to the pre-2.99.917 versions of xf86-video-intel. (Or perhaps, the 2.99.911 version itself as that is, i think, the only prior version tested.)

I did numerous tests today on a Haswell system, running a 3.13.5-031305-generic kernel, and was able to consistently reproduce the error with xf86-video-intel-2.99.911 and eliminate it with xf86-video-intel-2.99.917.

I have provided a log with debug information from xf86-video-intel-2.99.917, for the sake of completion. This is running the MATE desktop, btw. (which does not use any compositing)

However (and despite this good news), the dual-output issue appears to have been reincarnated in that it does not work - at all (i.e, no output) - with the newer 4.0.x kernels (tested the kernel.ubuntu.com provided wily builds for 4.0.2, 4.0.4 & 4.0.9) in any 24Hz or 23.976Hz modes–only 50Hz & 60Hz modes worked correctly on the secondary display (an Epson Projector–using the same drivers and X config as the one which worked on 3.13.5). I consistently reproduced this issue as well (and will open a separate bug report, if needed, for it as I did also capture a debug log from the 2.99.917 driver.)

If not I'll provide it here, since there is some prior history for much of the same issue.

Created attachment 117301 [details]
debug output from correctly-working xf86-video-intel driver (2.99.917) running on 3.13.5

(Submitted a new bug report for the most recent issue, https://bugs.freedesktop.org/show_bug.cgi?id=91434)

Apparently the bug is actually still present, at least on Ivy Bridge. It still fails to switch to the 23.976Hz mode, outputting everything in 24.00Hz. The 23.976Hz mode is added manually as a ModeLine for this gpu (Integrated Graphics Chipset: Intel(R) Ivybridge Desktop (GT2)):

[  1901.437] (II) intel(0): Modeline "1920x1080@23.97610"x24.0   74.23  1920 2560 2604 2752  1080 1084 1089 1125 +hsync +vsync (27.0 kHz)

Kernel and X is the same, the only changes being replaced versions of –

- libdrm (2.4.64) 
- libdrm-intel1 (2.4.64)
- libva / libva-{glx1,drm1,egl1,x11-1} (1.6.0)
- libva-intel-driver (1.6.0)
- xserver-xorg-video-intel (2.99.917)

2.99.917 was indeed a step up from 2.99.911, which did not want to output in either 23.976 or 24.00Hz. So it's a matter of "Close, but no cigar." ;)

Did several further tests today with the most recent 4.8.4 kernel on Ivy Bridge.

The bug appears consistently, and produces no output on HDMI2 whatsoever using any recent kernel versions, even when reverting to a blank xorg.conf (to avoid issues with user-provided modelines) as well as downgrading the xf86-video-intel driver (to 2.21.9-the last "known-good" version for dual-display IVB)

According to the debug output, and output from xrandr, the system/drivers do _think_ that the modes have been successfully switched, but again, there is not output for either 60Hz, 50Hz, 24Hz & 23.976Hz on the secondary display. The regular LCD panel is unaffected and -always- produces output.

See the provided drm.debug=0xe attachments, for 4.8.4/nonworking and 3.18.5/working - and *please* let me know whether any additional output would be needed as I really want to solve this issue; it has prevented me from upgrading this system for quite some time.

Created attachment 127500 [details]
drm.debug=0xe from nonworking 4.8.4 kernel

Created attachment 127501 [details]
drm.debug=0xe from working 3.18.5 kernel

Created attachment 127502 [details]
xrandr -q --verbose on 3.18.5 working perfectly with 23.976Hz using xf86-video-intel driver 2.21.9 (2.99.917 also tested, but only provides 24Hz + 50/60Hz)

Created attachment 127503 [details]
xrandr -q --verbose on 4.8.4 (detecting+setting modes, but producing no output whatsoever on either 50/60Hz or 24.000/23.976Hz))

I noticed this bug is still open, with no activity since 2016 after my latest info was provided. However, it is a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=91434

The latter still remains to be solved in an amicable manner. The xrandr fix proposed in this bug report, which limits the BPC once the system is up and a user has logged in, is not a workable solution for systems which rely on a single HDMI output -- which is left blank, and thus requires a user to log in simply to revert to the previous kernel behavior (pre-4.x) branch.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/37.