Comment 6 for bug 608279

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:
ubuntu@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).