EDID

Is EDID reliable under RISC OS?

Over the past week I’ve been testing EDID on a Pi1 and Pi3 across various HDMI TV’s/Monitor I have here, without much success.

The firmware appears to detect the display correctly and Linux selects a suitable resolution, but in RISC OS it either results in no display (and possibly a hard-lock – it’s hard to tell) or a list of modes that don’t appear to be coming from the device and usually 640×256×8 as the default mode. I assume RISC OS falls back to a known list of legacy VGA modes.

I’ve been testing with the latest HardDisc4 image and Nightly RISC OS build as of time of writing. CONFIG/TXT is using hdmi_group=0, CMDLINE/TXT only contains disable_gamma, MonitorType is set to EDID and Configure\Screen is the default of Auto.

Is there something I’m missing?

EDIT: If its relevant, here’s the EDID info from two devices:

0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x4C 0x2D 0xB0 0x05 0x00 0x00 0x00 0x00 0x0D 0x13 0x01 0x03 0x80 0x10 0x09 0x78 0x0A 0xEE 0x91 0xA3 0x54 0x4C 0x99 0x26 0x0F 0x50 0x54 0xBF 0xEF 0x80 0x71 0x4F 0x81 0x00 0x81 0x40 0x81 0x80 0x95 0x00 0x95 0x0F 0xA9 0x40 0xB3 0x00 0x02 0x3A 0x80 0x18 0x71 0x38 0x2D 0x40 0x58 0x2C 0x45 0x00 0xA0 0x5A 0x00 0x00 0x00 0x1E 0x01 0x1D 0x00 0xBC 0x52 0xD0 0x1E 0x20 0xB8 0x28 0x55 0x40 0xA0 0x5A 0x00 0x00 0x00 0x1E 0x00 0x00 0x00 0xFD 0x00 0x18 0x4B 0x1A 0x51 0x17 0x00 0x0A 0x20 0x20 0x20 0x20 0x20 0x20 0x00 0x00 0x00 0xFC 0x00 0x53 0x79 0x6E 0x63 0x4D 0x61 0x73 0x74 0x65 0x72 0x0A 0x20 0x20 0x01 0xD1

Which decodes to:

Timing bitmap:

720x400 @ 70
640x480 @ 60
640x480 @ 67
640x480 @ 72
640x480 @ 75
800x600 @ 56
800x600 @ 60
800x600 @ 72
800x600 @ 75
832x624 @ 75
1024x768 @ 60
1024x768 @ 72
1024x768 @ 75
1280x1024 @ 75
1152x870 @ 75

Standard Display Modes
X Resolution: 1152
X:Y Pixel Ratio: 4:3
Vertical Frequency: 75
X Resolution: 1280
X:Y Pixel Ratio: 16:10
Vertical Frequency: 60
X Resolution: 1280
X:Y Pixel Ratio: 4:3
Vertical Frequency: 60
X Resolution: 1280
X:Y Pixel Ratio: 5:4
Vertical Frequency: 60
X Resolution: 1440
X:Y Pixel Ratio: 16:10
Vertical Frequency: 60
X Resolution: 1440
X:Y Pixel Ratio: 16:10
Vertical Frequency: 75
X Resolution: 1600
X:Y Pixel Ratio: 4:3
Vertical Frequency: 60
X Resolution: 1680
X:Y Pixel Ratio: 16:10
Vertical Frequency: 60

Descriptor 1: 1920x1080

Detailed Timing Descriptor
Pixel Clock: 148.5MHz
Horizontal Active: 1920
Horizontal Blanking: 280
Vertical Active: 1080
Vertical Blanking: 45
Horizontal Sync Offset: 88
Horizontal Sync Pulse: 44
Vertical Sync Offset: 4
Vertical Sync Pulse: 5
Horizontal Display Size: 160
Vertical Display Size: 90
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3

Descriptor 2: 1280x700

Detailed Timing Descriptor
Pixel Clock: 74.25MHz
Horizontal Active: 1280
Horizontal Blanking: 700
Vertical Active: 720
Vertical Blanking: 30
Horizontal Sync Offset: 440
Horizontal Sync Pulse: 40
Vertical Sync Offset: 5
Vertical Sync Pulse: 5
Horizontal Display Size: 160
Vertical Display Size: 90
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3

Resulting ModeFile:

Can't capture as there's no screen

And an LG TV:

0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0x00 0x1E 0x6D 0xC8 0xC0 0x01 0x01 0x01 0x01 0x01 0x1E 0x01 0x03 0x80 0xA0 0x5A 0x78 0x0A 0xEE 0x91 0xA3 0x54 0x4C 0x99 0x26 0x0F 0x50 0x54 0xA1 0x08 0x00 0x31 0x40 0x45 0x40 0x61 0x40 0x71 0x40 0x81 0x80 0xD1 0xC0 0x01 0x01 0x01 0x01 0x08 0xE8 0x00 0x30 0xF2 0x70 0x5A 0x80 0xB0 0x58 0x8A 0x00 0x40 0x84 0x63 0x00 0x00 0x1E 0x6F 0xC2 0x00 0xA0 0xA0 0xA0 0x55 0x50 0x30 0x20 0x35 0x00 0x40 0x84 0x63 0x00 0x00 0x1E 0x00 0x00 0x00 0xFD 0x00 0x18 0x78 0x1E 0xFF 0x77 0x00 0x0A 0x20 0x20 0x20 0x20 0x20 0x20 0x00 0x00 0x00 0xFC 0x00 0x4C 0x47 0x20 0x54 0x56 0x20 0x53 0x53 0x43 0x52 0x32 0x0A 0x20 0x01 0x66

Which decodes to:

Timing bitmap:
720x400 @ 70
640x480 @ 60
800x600 @ 60
1024x768 @ 60

Standard Display Modes:
X Resolution: 640
X:Y Pixel Ratio: 4:3
Vertical Frequency: 60
X Resolution: 800
X:Y Pixel Ratio: 4:3
Vertical Frequency: 60
X Resolution: 1024
X:Y Pixel Ratio: 4:3
Vertical Frequency: 60
X Resolution: 1152
X:Y Pixel Ratio: 4:3
Vertical Frequency: 60
X Resolution: 1280
X:Y Pixel Ratio: 5:4
Vertical Frequency: 60
X Resolution: 1920
X:Y Pixel Ratio: 16:9
Vertical Frequency: 60

Descriptor 1: 3840x2160

Detailed Timing Descriptor
Pixel Clock: 594MHz
Horizontal Active: 3840
Horizontal Blanking: 560
Vertical Active: 2160
Vertical Blanking: 90
Horizontal Sync Offset: 176
Horizontal Sync Pulse: 88
Vertical Sync Offset: 8
Vertical Sync Pulse: 10
Horizontal Display Size: 1600
Vertical Display Size: 900
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3

Descriptor 2: 2560x1440

Detailed Timing Descriptor
Pixel Clock: 497.75MHz
Horizontal Active: 2560
Horizontal Blanking: 160
Vertical Active: 1440
Vertical Blanking: 85
Horizontal Sync Offset: 48
Horizontal Sync Pulse: 32
Vertical Sync Offset: 3
Vertical Sync Pulse: 5
Horizontal Display Size: 1600
Vertical Display Size: 900
Horizontal Border: 0
Vertical Border: 0
Interlaced: false
Stereo Mode: 0
Sync Type: 3

It’s resulting ModeFile:

# Exported from ScrModes 0.74
file_format:1
monitor_title:LG TV SSCR2
DPMS_state:0

# Mode: 640 x 480 @ 60Hz
startmode
 mode_name:640 x 480
 x_res:640
 y_res:480
 pixel_rate:25175
 h_timings:96,40,8,640,8,8
 v_timings:2,25,8,480,8,2
 sync_pol:3
endmode

# Mode: 640 x 480 @ 60Hz
startmode
 mode_name:640 x 480
 x_res:640
 y_res:480
 pixel_rate:25175
 h_timings:96,40,8,640,8,8
 v_timings:2,25,8,480,8,2
 sync_pol:3
endmode

# Mode: 720 x 400 @ 70Hz
startmode
 mode_name:720 x 400
 x_res:720
 y_res:400
 pixel_rate:28322
 h_timings:108,54,0,720,0,18
 v_timings:2,34,0,400,0,13
 sync_pol:1
endmode

# Mode: 800 x 600 @ 60Hz
startmode
 mode_name:800 x 600
 x_res:800
 y_res:600
 pixel_rate:40000
 h_timings:128,88,0,800,0,40
 v_timings:4,23,0,600,0,1
 sync_pol:0
endmode

# Mode: 800 x 600 @ 60Hz
startmode
 mode_name:800 x 600
 x_res:800
 y_res:600
 pixel_rate:40000
 h_timings:128,88,0,800,0,40
 v_timings:4,23,0,600,0,1
 sync_pol:0
endmode

# Mode: 1024 x 768 @ 60Hz
startmode
 mode_name:1024 x 768
 x_res:1024
 y_res:768
 pixel_rate:65000
 h_timings:136,160,0,1024,0,24
 v_timings:6,29,0,768,0,3
 sync_pol:3
endmode

# Mode: 1024 x 768 @ 60Hz
startmode
 mode_name:1024 x 768
 x_res:1024
 y_res:768
 pixel_rate:65000
 h_timings:136,160,0,1024,0,24
 v_timings:6,29,0,768,0,3
 sync_pol:3
endmode

# Mode: 1152 x 864 @ 60Hz
startmode
 mode_name:1152 x 864
 x_res:1152
 y_res:864
 pixel_rate:81624
 h_timings:120,184,0,1152,0,64
 v_timings:3,27,0,864,0,1
 sync_pol:1
endmode

# Mode: 1280 x 1024 @ 60Hz
startmode
 mode_name:1280 x 1024
 x_res:1280
 y_res:1024
 pixel_rate:108000
 h_timings:112,248,0,1280,0,48
 v_timings:3,38,0,1024,0,1
 sync_pol:0
endmode

# Mode: 1920 x 1080 @ 60Hz
startmode
 mode_name:1920 x 1080
 x_res:1920
 y_res:1080
 pixel_rate:172798
 h_timings:208,328,0,1920,0,120
 v_timings:3,34,0,1080,0,1
 sync_pol:1
endmode

# Mode: 2560 x 1440 @ 120Hz
startmode
 mode_name:2560 x 1440
 x_res:2560
 y_res:1440
 pixel_rate:497750
 h_timings:32,80,0,2560,0,48
 v_timings:5,77,0,1440,0,3
 sync_pol:0
endmode

# Mode: 3840 x 2160 @ 60Hz
startmode
 mode_name:3840 x 2160
 x_res:3840
 y_res:2160
 pixel_rate:594000
 h_timings:88,296,0,3840,0,176
 v_timings:10,72,0,2160,0,8
 sync_pol:0
endmode

Configure/Screen listed resolutions:

640x480
720x400
800x600
1024x768
1152x864
1280x1024

I’ve got an LG TV and found that I have issues depending on what HDMI cable I use.

I have found that two cables I have that state High Speed with Ethernet totally lock up the Pi4B which has the latest ROM/Firmware and Hard Disc image on it.

Of two other cables I tested only one reliably gives a correct resolution on start up of 1920 × 1080, whilst the other starts up in a low resolution /256 colour mode but on selecting 1920x 1080 works ok from then on.

So could the HDMI type of cable, i.e 1.3/4, 2/2.1 etc, also be adding to the issues?

I might get out a Samsung and try the different cables on that just to eliminate the LG effect.

It might be interesting to compare the output from *SaveModeFile when using the monitors in question with (a) the EDID data given upthread, and (b) the screen modes actually offered by Display Manager and/or “Configure>Screen”.

It might be interesting to compare the output from *SaveModeFile when using the monitors in question with (a) the EDID data given upthread

Good question. I’ve updated the OP and it appears the ModeFile is correct on the LG, I can’t tell on the pi-top as there’s no image. I’ll test some more displays at some point and grab their data.

Why would Configure/Screen not list all the resolutions from the Mode File? How is it coming by the displayed list?

Why would Configure/Screen not list all the resolutions from the Mode File? How is it coming by the displayed list?

It lists all of the entries that it regards as valid. For example, many monitors will offer 1366×768, but as RISC OS cannot use that (the X-value isn’t divisible by 8) it won’t appear on the list.

Under certain circumstances, additional entries may appear. I have witnessed legacy VGA resolutions (e.g. 640×200) sneaking onto the list. These won’t actually work (attempting to select them will give the error “This screen mode is unsuitable for displaying the desktop”) and IIRC you are most likely to see these if you have selected the “Auto” monitor rather than “Auto(your-monitor-here)”.

“Auto” monitor rather than “Auto(your-monitor-here)”

It’s somewhat ironic that “Auto” isn’t actually auto…why doesn’t it default to the attached display.

I’ve tested a few more screens. A Dell 4K Monitor and a Samsung TV – they both defaulted to 1080p and listed all the expected resolutions. So perhaps I’ve just been unlucky in that the displays I actually want working with EDID don’t work under RISC OS.

I know the EDID data in the pi-top isn’t reflective of the display – fine, but RISC OS going to a screen that fades to grey and appearing to hard-lock isn’t ideal.

The LG’s odd behaviour I can’t explain. Yes the Pi1/3 do not support native 4K, but I would hope BCMVideo would handle that and reject 4K based on the Pixel rate/Pi model. As 1080p isn’t shown in Configure/Screen, clearly something is blocking the higher resolution modes – I’m just not sure what or how to override it.

The Dell 4K works, I believe, due to it being an older HDMI standard that maxes out at 1080p – which is also reflected in the EDID data.

Is the monitor already turned on before the Pi? There’s a config.txt option to delay the boot a few seconds to give a monitor a chance to start up. IIRC

Is the monitor already turned on before the Pi?

Yes, all testing was done with the display on, correct input active and the screen awake.

Is EDID reliable under RISC OS?

Yes, no, maybe. It depends upon the device. Some monitors… return information that doesn’t match the monitor.

And, as people have noted, the cable used might also have an influence.

I have witnessed legacy VGA resolutions (e.g. 640×200) sneaking onto the list.

Are you sure it was 640×200? There’s no possible way that would work. That’s CGA which used TTL video (like a BBC Micro) with an extra “Intensity” signal, and a 15kHz horizontal rate not unlike a progressively-scanned TV signal in timing.

Is the monitor already turned on before the Pi?

I thought the HDMI cable was supposed to power up and read a serial EPROM inside the device, so the monitor didn’t actually need to be on in order for this to work.

It’s worth saying that, for me, when I’m connecting a new monitor I reboot and hit Esc to abort the boot sequence.
I then *SaveModeFile to capture what the monitor is telling me.
I then go to the Desktop and look at it in Edit, to check it makes sense. It usually does. However often the Desktop is something dumb like 640×480.
So I then copy the file it to BootResources:Configure.Monitors.Other.
Then I reboot. RISC OS is set to Auto mode and MonitorType EDID, but as I mentioned it seems rather prone to wanting to revert to generic defaults.
So I go into Configure, choose the mode file that I previously saved as the monitor, and I set that and the desired resolution.
Then I lock Choices:Boot.PreDesk.Configure.Monitor in order that it cannot be fiddled with by the OS (ScreenModes?).

I don’t know what it is that buggers around with the monitor settings, or why it is so obsessed with reverting to thinking you have a bog standard VGA connected, but it is annoying.

One shouldn’t have to lock files so that the OS leaves them in peace!

the monitor didn’t actually need to be on in order for this to work

The Pi Firmware does funny things if the monitor isn’t on when you power the Pi up – that’s a known issue.

As for the rest of what you’ve said – that’s the kind of nonsense EDID is supposed to avoid. I alluded to it in the OP, but Windows/Linux (on the Pi) work as expected – I can’t recall the last time a monitor/TV didn’t go to its native resolution with Windows for example. It’s possible RISC OS just needs some tweaks to its EDID handler.

One shouldn’t have to lock files so that the OS leaves them in peace!

It looks like it is ClrMonitor (DesktopBoot → Source → ClrMonitor) that does this if it reads that the CMOS RAM has been reset. Which is fair enough.

So I guess the next question is what is flagging the “reset” bit when it hasn’t, in fact, been reset?

I can’t recall the last time a monitor/TV didn’t go to its native resolution with Windows for example.

I can. ;)

https://heyrick.eu/blog/index.php?diary=20231020

Four entries down, “Shonky VGA cable” (yes, VGA not HDMI as I’m old-tech here, but if an EDID cable was wired the same sort of way it would probably have the same effect).

Even worse, my monitor’s native resolution (something like 1440×900) isn’t one in the video defaults list, so I couldn’t just “make do”. I literally could not use that cable with Windows.

I can. ;)

I was referring specifically to where EDID is being used to choose the default resolution.

Are you sure it was 640×200? There’s no possible way that would work. That’s CGA

It’s a CGA mode that VGA monitors were required to support for backward compatibility. I can only suppose it was lurking in the kernel mode definitions for monitor type 3.

Shonky VGA cable

Nobody would omit the DDC wiring on a VGA or HDMI cable? Oh, sorry, China.