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.
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).
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: panda-maverick- usb:~$ parse-edid /sys/devices/ omapdss/ display0/ edid
ubuntu@
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"
DotClock 148.500000
HTimings 1920 2003 2047 2200
VTimings 1080 1084 1089 1125
Flags "+HSync" "+VSync"
EndMode
Mode "1920x1080" # vfreq 60.000Hz, hfreq 67.500kHz
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/ 229d7dd3ff4447d 8. 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/ 5274e1527067d88 e/bd988bdaa65b7 d58, 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).