Does X regenerate it's list of modes when a monitor is hot plugged? We're using the 3.0.35 kernel, xorg 1.14.4, and the vivante X driver. Currently it seems to obtain the list of valid modes from the framebuffer at X start, but if I swap out a new monitor it does not create a new mode list. Should it?
One catch, the EDID is being provided by a aux channel, not over the standard i2c bus. I've already written a new framebuffer driver similar to mxc_dvi.c but reading the EDID using our custom channel. I can see the proper modes display in /sys/class/graphics/fb0/modes. Is the vivante X driver expecting to read the EDID itself and generate its own mode list?
One thought I had was to use a udev rule to execute a script that would use xrandr to clear the modes and add the correct ones back. But I'd rather do it the "correct" way if there is one.
A followup, it appears the 3.10.17 vivante xorg driver reads the mode list from a sysfs attribute exposed by the framebuffer driver and uses a utility, autohdmi, to receive kernel udev events in response the monitor plug actions and trigger a refresh of the available modes from the framebuffer driver.
It's still work in progress but I've been able to patch the util and driver to work with my new display output and framebuffer driver. This is much cleaner than using xrandr to manage the mode list.
The HDMI video driver receives a hotplug interrupt and reads the EDID from the HDMI sink device constructing a list of video modes from the retrieved EDID
Information. the HDMI driver selects a video mode from the mode list that is the closest match.
To add different modes you have to modify the xorg.conf, and add Modeline in the monitor section. Restart X and xrandr shows these new mode in addition to the default.
Identifier "Builtin Default Monitor"
Option "DPMS" "false"
Modeline "1024x600_60.00" 49.00 1024 1072 1168 1312 600 603 613 624 -hsync +vsync
Modeline "640x480_60.00" 23.75 640 664 720 800 480 483 487 500 -hsync +vsync
hope this helps
Unfortunately this won't work. This is a closed system, and we do not control what monitor may be connected by a customer at runtime.
We're not using the HDMI interface, we're using the parallel output with a custom converter. What I've done is trigger a kernel uevent on monitor hotplug and use a udev script plus cvt and xrandr to generate the mode timings and add them to the current output. It's not the most elegant solution but appears to work. I had hoped to have X pick up the new modes from the framebuffer driver directly.