Nice that you got this working. Regarding the subject, maybe this is not the correct place to discuss, but the main problem I believe is to know what should be the best and more standard way to use the EDID information and set the correct monitor output.
Currently for Omap 4 the EDID parsing happens inside the display driver, and it tries to set up everything so you don't need to specify any display argument at the boot cmd line. Even with all this logic, robclark created an entry at the sysfs so you could probe it: ubu...@panda-maverick-usb:~$ parse-edid /sys/devices/omapdss/display0/edid parse-edid: parse-edid version 2.0.0 parse-edid: EDID checksum passed. # EDID version 1 revision 3 Section "Monitor" # Block type: 2:0 3:fd # Block type: 2:0 3:fc Identifier "W2253" VendorName "GSM" ModelName "W2253" # Block type: 2:0 3:fd HorizSync 30-83 VertRefresh 56-61 # Max dot clock (video bandwidth) 150 MHz # Block type: 2:0 3:fc # DPMS capabilities: Active off:no Suspend:no Standby:no Mode "1920x1080" # vfreq 59.934Hz, hfreq 66.587kHz DotClock 138.500000 HTimings 1920 1968 2000 2080 VTimings 1080 1083 1088 1111 Flags "+HSync" "+VSync" EndMode Mode "1920x1080" # vfreq 60.000Hz, hfreq 67.500kHz DotClock 148.500000 HTimings 1920 2003 2047 2200 VTimings 1080 1084 1089 1125 Flags "+HSync" "+VSync" EndMode # Block type: 2:0 3:fd # Block type: 2:0 3:fc EndSection This week we had one thread about what should be the default resolution for BeagleBoard xM validation, that you can find at http://groups.google.com/group/beagleboard/browse_thread/thread/229d7dd3ff4447d8. For them there could be two options, one is to probe i2c and parse the edid at the boot loader and the other is to change the kernel code in order to probe and detect it correctly, like what we have for Omap 4. For the second option there is a quite old patch at http://groups.google.com/group/beagleboard/browse_thread/thread/5274e1527067d88e/bd988bdaa65b7d58, that was sent last year. As you demonstrated, changing the kernel to probe the EDID from eeprom works, and it would fit our blueprint (that sets up the correct resolution just after the second boot), but looking forward, what should be the best way to implement this? Doing like Omap 4 sounds more correct, but needs a lot of work. Another solution would move this to u-boot, as it'd help us from the first boot and affect a wider audience (beagle, OE, etc). -- i2c support for edid on armel https://bugs.launchpad.net/bugs/608279 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs