Dodgy EDIDs (was: What does your OS look like?)

[Rusky]

For "faulty by design" hardware that failed to comply with even the most basic requirements (that probably doesn't exist and will probably never exist); the default expectation is "hardware shouldn't work at all". If the OS provides "works but is blurry" instead, then that's several orders of magnitude better than anyone can reasonably expect.

Not if someone can also reasonably expect "user specifies the native resolution and it works perfectly"...

[Brendan]

Hi,

The other case is installing the OS from network; but I'm planning to do this very differently - essentially, client downloads almost nothing (kernel and network card drivers), then sends the hardware's details (a list of PCI devices, CPUs and their features, memory map, etc) back to the server; and the server builds the boot image for the client, then tells client to "reboot via. kexec".

I really like this idea, mind if I borrow it?

I don't mind.

For "faulty by design" hardware that failed to comply with even the most basic requirements (that probably doesn't exist and will probably never exist); the default expectation is "hardware shouldn't work at all". If the OS provides "works but is blurry" instead, then that's several orders of magnitude better than anyone can reasonably expect.

Not if someone can also reasonably expect "user specifies the native resolution and it works perfectly"...

I'm not adding end-user hassle to work around a non-existent case (and creating problems in more likely cases, like systems with a monitor and no keyboard).


Cheers,

Brendan

[Octocontrabass]

non-existent

Tell that to my Olevia LT26HVE.

[Kazinsal]

I have a display that has a native resolution of 1920x1080 but reports having a native resolution of 1280x768.

The real world is full of strange things, and the perfect standards-adhering everything-works-as-it-should case is in fact the edge case.

[Rusky]

I'm not adding end-user hassle to work around a non-existent case (and creating problems in more likely cases, like systems with a monitor and no keyboard).

The question is which is more hassle - being stuck with a blurry screen that you have to modify the OS to fix, or having the option to enter the correct resolution and move on with your life?

[shmx]

I have a display that has a native resolution of 1920x1080 but reports having a native resolution of 1280x768.

Can you show EDID?

[Brendan]

Hi,

non-existent

Tell that to my Olevia LT26HVE.

Are you saying that its EDID reports the same "vendor ID" and "product ID" as a different display?

I have a display that has a native resolution of 1920x1080 but reports having a native resolution of 1280x768.

The real world is full of strange things, and the perfect standards-adhering everything-works-as-it-should case is in fact the edge case.

This is (part of) why I'm only using "vendor ID" and "product ID" to find my own file that (should, eventually) contain correct information, where the correct information is used and not the EDID.

I'm not adding end-user hassle to work around a non-existent case (and creating problems in more likely cases, like systems with a monitor and no keyboard).

The question is which is more hassle - being stuck with a blurry screen that you have to modify the OS to fix, or having the option to enter the correct resolution and move on with your life?

The question is which is more hassle:

• Me wasting time trying to deal with hardware problems that I doubt even exist when there's so much hardware that does exist that I could spend that time on instead; plus the hassle that a work-around would cause to the 100% of users that don't need it in the first place
• The hassle of "slightly more blurry" (given that VBE typically can't get the native resolution anyway) for the 0% of users that have hardware that doesn't exist; but only if the OSs "allow a user who may not be present to use an input device that may not exist" work-around can actually be used.

It seems like a very easy decision to me.


Cheers,

Brendan

[Owen]

I've seen a (1080p) TV where the VID & PID identified it as a IBM Thinkpad with a native resolution of 1280x1024. So there are definitely dreadful devices out there.

There are also lots of non-dreeadful cases where the VID & PID won't identify the display. For example, if probe one of the HDMI ports on my PC it will identify itself as a Yamaha DSP-AX763. From that you can identify nothing of the capabilities of my display - because it's not a display, there happens to be a display connected behind it!

[Rusky]

Letting the user specify a resolution is not a terribly time-consuming task, nor is its presence a "hassle" to people who don't use it. An unfixably blurry LCD screen, however, is a giant pain.

[Brendan]

Hi,

I've seen a (1080p) TV where the VID & PID identified it as a IBM Thinkpad with a native resolution of 1280x1024. So there are definitely dreadful devices out there.

How can any device (that uses the old EISA PnP IDs) be identified as a laptop, given that laptops don't have a VID & PID to begin with?

There are also lots of non-dreeadful cases where the VID & PID won't identify the display. For example, if probe one of the HDMI ports on my PC it will identify itself as a Yamaha DSP-AX763. From that you can identify nothing of the capabilities of my display - because it's not a display, there happens to be a display connected behind it!

Yes. One of my KVMs does strange things and lets some computers have the monitor's EDID while preventing other computers from doing the same.

For these problems my code does currently allow a user to provide (and/or override) the display's VID & PID; but it's a "boot script variable" that has to be set before the OS boots and requires admin permissions (rather than something a normal user can touch during boot), and it's something that isn't necessary for the intended use of the OS (and something that may be removed eventually).

Note 1: For the intended use of the OS (a distributed system) the OS determines which output device/s and forwards data (via. LAN) to a computer directly connected to the output device. There'd be no need for special hardware in the middle, like KVMs or AV receivers (although you might still want simple audio amplifiers).

Note 2: I have no intention of supporting "encrypted video+sound over the same cable" DRM schemes.


Cheers,

Brendan

[Brendan]

Hi,

Letting the user specify a resolution is not a terribly time-consuming task, nor is its presence a "hassle" to people who don't use it. An unfixably blurry LCD screen, however, is a giant pain.

For people with the corresponding hardware, "no support for Itanium CPUs" is also a giant pain (and likely to be far more important than this stupid "blurry screen" distraction that requires a very specific sequence of extremely unlikely events).

Let's do a basic estimate:

• The chance that 2 displays will have the same vendorID and product ID is probably about 0.01%
• If one of the displays is much more common than the other, you'd put the "less common" display on the OS's unsupported hardware list and forget about it. The chance of 2 displays being "roughly equally common" is maybe 10%.
• The chance that the native resolutions don't match anyway is maybe 25%
• The chance that OS and/or computers are able to support the native resolution is probably about 50%
• If there actually is a problem, the chance that the user knows their display is a cheap piece of crap and wanted to replace it anyway is about 50%.

By combining these probabilities we can estimate that there's a 0.0000625% chance that it'll actually be a problem in practice. This is lower than the chance of being hit by lighting.


Cheers,

Brendan

[Rusky]

I, too, can pull numbers out of a hat in direct contradiction to all the evidence.

[Brendan]

Hi,

Let's do a basic estimate:

• The chance that 2 displays will have the same vendorID and product ID is probably about 0.01%
• If one of the displays is much more common than the other, you'd put the "less common" display on the OS's unsupported hardware list and forget about it. The chance of 2 displays being "roughly equally common" is maybe 10%.
• The chance that the native resolutions don't match anyway is maybe 25%
• The chance that OS and/or computers are able to support the native resolution is probably about 50%
• If there actually is a problem, the chance that the user knows their display is a cheap piece of crap and wanted to replace it anyway is about 50%.

By combining these probabilities we can estimate that there's a 0.0000625% chance that it'll actually be a problem in practice. This is lower than the chance of being hit by lighting.

I'm and idiot.

The simple solution to the "non-problem" is to ensure there isn't any file for that vendorID and productID; which would force the OS's boot code to auto-generate a file from the monitor's EDID during boot.

Basically:

• Either:
  • The monitor's vendorID and product ID aren't unique and the monitor also provides dodgy video timings, etc in its EDID (that prevents the auto-generated file from being usable)
  • There are 2 or more monitor's with the same vendorID and product ID being used within the same cluster, where the auto-generated file/s from different computers conflicts
• And; the "same file for different monitors" approach can't work fine.

Cheers,

Brendan

[Brendan]

Hi,

I, too, can pull numbers out of a hat in direct contradiction to all the evidence.

What evidence?

There's been evidence of monitors providing dodgy EDID (Kazinsal's display, and Octocontrabass' Olevia LT26HVE - I googled it), which my "use vendorID and productID to find correct file" solves; but that is a completely different problem than the one we're talking about.

There's been evidence of systems that don't report EDID at all (my KVMs, Owen's Yamaha DSP-AX763); but that is a completely different problem than the one we're talking about.

Other than that, there's been "I've seen a TV identify itself as a laptop" (with no indication that the native resolution/s weren't the same and no indication that "blurry screen" would've been an otherwise avoidable result).


Cheers,

Brendan

[Rusky]

How are we not talking about the problems of incorrect and missing EDIDs? Everyone but you seems to be. The request for the ability to specify a resolution is satisfied by allowing the user to set up one of your definition files, which since the start of this thread you have stated is possible. So I don't know really know what you're arguing, at this point.