X11/Nvidia fails to use correct EDID on Onkyo receiver reconnect/plugin

Graphics / Linux Linux
1

Hi,

Setup is Ubuntu 14.04 with latest updates installed, Nvidia 610 graphic card with HDMI connected to an Onkyo PR-SC5507 receiver. The receiver is connected via HDMI to a Panasonic plasma TV. Main use is Kodi.

/proc/version is ‘Linux version 3.13.0-57-generic (buildd@brownie) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015’. Current Nvidia driver, installed from 352.21-0ubuntu0~xedgers14.04.1, is v 352. Also tried drivers 331 ‘on up’ to 352.

System has been behaving itself for months until after an ubuntu upgrade which, I believe, included a new kernel. System boots fine and the display is excellently set to 1920x1080 60Hz progressive (mode “1920x1080_60”). Problem comes in when the receiver (and TV) are turned OFF and then back ON. The display is now interlaced resulting in two pictures offset vertically by about a pixel. It looks fuzzy. It seems to be either an X11 or Nvidia driver problem, hence the use of X11/Nvidia.

I can issue command:
xrandr --output HDMI-0 --mode 1920x1080 --rate 60.0
and the TV picture is back to its progressive self.

I have tried changing the xorg.conf (in /etc/X11) file to force mode “1920x1080_60”, which is the 60Hz progressive mode obtained from the EDID by:

  1. Adding ‘Option “PreferredMode” “1920x1080_60”’ to the “Monitor” section

  2. Using nvidia-settings to output the EDID in binary and including a ‘Option “CustomEDID” “GPU-0:DFP-1:/etc/X11/onkyoHdmiEdid.bin”’ in the “Screen” section

  3. Added a Modeline as ‘Modeline “1920x1080w60.00” 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +HSync +Vsync’ (based on Xorg.0.log) to the “Monitor” section along with “ModeValidation” options to not use the EDID or not use EDID modes, etc.

Number 3 I could not get working, Nvidia or X11 just ignored the modeline and choose a muddy producing one instead. I gave up on this one. At least it was consistently bad across the OFF/ON boundary.

Numbers 1 and 2 produced exactly the same results. The Xorg.0.log is from number 2. When the receiver turns OFF, udef triggers and X11/Nvidia writes to the log file “NVIDIA(0): ACPI: received event: jack/lineout LINEOUT plug”. Turning the receiver ON produces the 8,995 lines below this marker. X11/Nvidia then tries to read the EDID file (ignoring the binary file) which has the pixel clock halved. It does this a whopping 11 times.

This wouldn’t be too bad if it choose the right EDID. After the ON event, it reads the correct EDID five times, the sixth is “wrong” and that’s the one (perhaps) it uses to set the mode (search for “Setting mode”).

My fix will be to write a udev rule. But something is just not right with the Linux box handshakes over HDMI with the receiver. Probably something stuip I’ve done.

Any suggestions (other than a udev rule?) for fixing this?

thanks!

mark

nvidia-bug-report.log.gz (251 KB)
xorg.conf.zip (735 Bytes)

2

There are two things to note here:

  1. There's no "right EDID" or "wrong EDID" for the driver to read. If the driver is printing incorrect information, then it's because the Onkyo receiver is sending wrong information. This is a typical problem with receivers; many of them are just terrible when it comes to providing a correct EDID to the HDMI source device.
  2. The driver doesn't change the mode configuration on its own. Even across hotplugs, if an X client doesn't send a request, the driver won't change the mode. So the Ubuntu update that broke this for you probably included an updated desktop environment that responds to the hotplug events and incorrect modes generated by your receiver by sending modeset requests to the driver.

One option might be to try to disable whatever your desktop environment is doing, but probably the easiest option, if you always have the same TV plugged in, is to use nvidia-settings to capture the correct EDID information to a file, and then use the CustomEDID option to override the EDID provided by the receiver. That option is designed for exactly this sort of scenario.

3

Hi Aaron,

  1. My bad attributing human characteristics to machines. More appropriate to say “EDID producing desirable results” than “right EDID”.

  2. Really hard for us non-driver folks (even one who has written, ah, Unix drivers in the early '80s), to figure out what is responding to the (udev?) events. It might be interesting to switch from Gnome to KDE and see if that did the trick… BUT

I am typically my own worse enemy. The xorg.conf using CustomeEDID (see my Num. 2 above) specified the graphic card with a “GPU-0:” . Taking that out caused the EDID binary file to be applied to the hdmi display device. In my defense, I had no clue that the file was read correctly or if it was applied to the correct device (I suspect it read in OK, but there was no “GPU-0:DFP-1” display device.

Still holding my breath, but the X11 log now has only one “Setting mode” generated at X11 startup and the screen looks great.

mark