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

[Brendan]

Hi,

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.

For a (paraphrased) commentary of (this part of) the conversion so far:

• Octocontrabass: "what do you do when several different displays share the same vendor and product ID?"
  Brendan: "depending on how different the monitors are people might be able to find some common ground - e.g. if one supports a 1280*1024 timing, one supports a 1920*1600 timing and they both support the same 800*600 timing; then you'd be able to create a file that only mentions the 800*600 timing"
  Octocontrabass: "Unfortunately, these are LCDs, so any compromise will end up with a very blurry picture on at least one display model."
  Brendan: "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."
  Rusky: "Not if someone can also reasonably expect "user specifies the native resolution and it works perfectly"..."
  Brendan: "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)."
  Rusky: "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?"
  Brendan: "A waste of time for 0% of users? It seems like a very easy decision to me."
  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: "we can estimate that there's a 0.0000625% chance that it'll actually be a problem"

We were talking about blurred screen caused by a suggested fix for the "vendor ID and product ID not unique" problem. Other people were talking about other things (incorrect EDID with correct VID & PID, and missing EDID) but not you.


Cheers,

Brendan

[Rusky]

Just because I didn't bring my own example of a broken display doesn't mean the other examples don't support my argument. But its strongest support is that you have already implemented a way to override the VID/PID of a display, so again, what is your point?

[Brendan]

Hi,

Just because I didn't bring my own example of a broken display doesn't mean the other examples don't support my argument. But its strongest support is that you have already implemented a way to override the VID/PID of a display, so again, what is your point?

I'm only responding to concerns expressed by others. Originally I only really wanted to show screenshots of "device independent to device dependent conversion (complete with dithering) done by run-time generated code"; as it's the first half of research I started about 6 months ago (the other half dealing with monitor size and shape is still coming).

If I have a point, it's that the "incorrect EDID but correct VID & PID" problem (that you weren't complaining about) was fixed/avoided during the research phase; the "no EDID" problem (that you weren't complaining about) was solved ages ago (that dates back several years to prior versions of my OS); and the only other issue (which is the issue you were complaining about and are now attempting to pretend you weren't complaining about, I assume because you realised your argument was seriously flawed), never was a significant problem.


Cheers,

Brendan

[Rusky]

Nope. Owen already mentioned a display with a VID and PID that referred to a different device with a different resolution, and you already implemented a way to override a display's VID and PID, so the initial problem has been shown both to be real and solvable in a way you're okay with.

[Brendan]

Hi,

Nope. Owen already mentioned a display with a VID and PID that referred to a different device with a different resolution, and you already implemented a way to override a display's VID and PID, so the initial problem has been shown both to be real and solvable in a way you're okay with.

I think you need to learn how to read - it's a valuable skill.

What Owen did say is:

• "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."

He didn't say the TV had a different resolution to the laptop. For all we know they both have a native resolution of 1280x1024.

He also didn't say the TV's EDID referred to a fundamentally different device. For all we know the same company used the exact same display panel and driver circuitry (and EDID) for both a TV (with a tuner bolted on front) and to sell to IBM for one of their Thinkpads; and the reported EDID is 100% correct in every possible way in both cases (in the laptop and in the TV).

What I've said is that I currently have a way to provide/override a display's VID and PID for the "no EDID" problem (and not the "VID & PID not unique" problem), which isn't usable for normal users, doesn't work for the normal "put CD in drive and boot it" scenario, isn't needed at all for the intended use of the OS, and may be removed in future. The fact is that it's just a temporary hack so I can keep using my KVMs, where (eventually, when I get networking done) I won't want or need the KVMs (or the hack). Trying to pretend this is intended as a solution to the "VID & PID not unique" problem is laughably retarded.

Nowhere has the initial "VID & PID not unique" problem been shown to actually exist (yet - Owen may or may not provide further details).

Nowhere has the initial "VID & PID not unique" problem been solved in a way I'm okay with. Essentially, I'm not solving it at all because I doubt the problem needs to be solved in the first place (and I've only suggested ways to "creatively use" existing functionality designed to solve completely different problems as a work-around in lieu of an actual solution).


Cheers,

Brendan

[Rusky]

Explain to me again how a 1080p TV has the same native resolution as a 1280x1024 Thinkpad?

[MDenham]

What Owen did say is:

• "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."

He didn't say the TV had a different resolution to the laptop. For all we know they both have a native resolution of 1280x1024.

FWIW, 1080p is automatically 1920x1080, so while he's not explicitly stating it, he is at least strongly implying that the device is identifying its native resolution incorrectly.

(That having been said, why isn't the natural default on devices to just center images of lower resolution on the screen? I mean, yes, you're looking at a bunch of excess black space around the image... but at least you're not trying to scale something badly if not nonuniformly.)

[Brendan]

Hi,

What Owen did say is:

• "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."

He didn't say the TV had a different resolution to the laptop. For all we know they both have a native resolution of 1280x1024.

FWIW, 1080p is automatically 1920x1080, so while he's not explicitly stating it, he is at least strongly implying that the device is identifying its native resolution incorrectly.

As far as I understand it, "1080p" only means "1080 vertical lines with progressive scanning". When given signals from a computer you might just have a 28-line margin (which could be hidden under a laptop display's bezel).

The 16.9 aspect ratio (and therefore the 1920 horizontal resolution) is only an assumption, and not a requirement, and (as far as I can tell) displays that actually do have 1920 horizontal resolution are typically marketed as "Full HD" and not "1080p", which implies the TV is not 1920*1080.

(That having been said, why isn't the natural default on devices to just center images of lower resolution on the screen? I mean, yes, you're looking at a bunch of excess black space around the image... but at least you're not trying to scale something badly if not nonuniformly.)

Something like 640*480 looks tiny on a 1920*1600 screen.

Note that the "blur" caused by scaling is massively exaggerated by most people. When scaling down to a lower resolution there's no sane choice. When scaling up by an integer factor (e.g. 640 up to 1280 or 1920) there should be no blur (pixels are just replicated).

In addition, for natural images (rather than artificial computer generated images containing perfectly straight lines/edges) things don't end up perfectly aligned on pixel boundaries in the first place, causing natural blur in the source image that tends to make any blur caused by scaling far less noticeable.

The only real problem is when you do have unnatural computer generated images combined with a display that has low native DPI to begin with.


Cheers,

Brendan

[Octocontrabass]

Nowhere has the initial "VID & PID not unique" problem been shown to actually exist

DMI0000 is the PnP ID of several Olevia displays (including mine), of which some are 1366x768 and others are 1280x768. Google can find the EDID for a few different models.

[Brendan]

Hi,

Nowhere has the initial "VID & PID not unique" problem been shown to actually exist

DMI0000 is the PnP ID of several Olevia displays (including mine), of which some are 1366x768 and others are 1280x768. Google can find the EDID for a few different models.

I tried to find information online. What I found is:

• The official Plug and Play Vendor ID list, that says DMI isn't even a register vendor ID in the first place.
• This wikipedia page about Syntax-Brillian Corporation (the manufacturer of Olevia displays), where most of the information is about bankruptcy, investigations and federal fraud charges.

As far as I can tell, Olevia displays (including yours) are trash manufactured by scam artists.

Now, I'm more interested in adding official "support" for these monitors in the form of code to detect DMI0000 that displays a suitable "Your monitor is unsupportable trash" warning.


Cheers,

Brendan

[onlyonemac]

Giving the user a workaround for their "trash" monitor is still a good idea though, as a lot of users of "trash" monitors are probably unaware that their monitors are trash. I for one have an old CRT that presumably reports some incorrect data as I've yet to find a Linux system that correctly identifies the monitor's native resolution (and Haiku had the same problem) - if there's any code I can run with said monitor to help with the present troubleshooting issue then I am willing to do so, but remember that I'm blind now.

[Octocontrabass]

As far as I can tell, Olevia displays (including yours) are trash manufactured by scam artists.

This should be no surprise. Reputable manufacturers usually put more effort into their products.

Now, I'm more interested in adding official "support" for these monitors in the form of code to detect DMI0000 that displays a suitable "Your monitor is unsupportable trash" warning.

The user sees this message, wonders why Windows/Linux/whatever has no trouble, and decides your OS must be trash.

[Rusky]

The term 1080p "usually assumes a widescreen aspect ratio of 16:9, implying a resolution of 1920x1080 often marketed as Full HD." And in any case, "1080 lines of non-interlaced vertical resolution" is still incompatible with 1280x1024, no matter what its horizontal resolution is (and you are much less likely to find a non-16:9 display that someone is willing to call "1080p" as shorthand than you are to find one with an unusable VID/PID - the only other resolution I can find is 2560x1080, where someone would more likely brag about its size).

[Brendan]

Hi,

Giving the user a workaround for their "trash" monitor is still a good idea though, as a lot of users of "trash" monitors are probably unaware that their monitors are trash. I for one have an old CRT that presumably reports some incorrect data as I've yet to find a Linux system that correctly identifies the monitor's native resolution (and Haiku had the same problem) - if there's any code I can run with said monitor to help with the present troubleshooting issue then I am willing to do so, but remember that I'm blind now.

I'm not sure that CRTs actually have a native resolution like LCD - they do horizontal lines of analogue signals without caring about where one pixel ends and another starts; and tend to have max. horizontal and vertical frequencies only. They would have a "size of phosphorous dots and electron mask holes" but the arrangement of these is likely overlapping (like a brick wall where a green brick in one row is centered above the boundary between the red and blue bricks in the row below); and even if you knew the exact details of the dots (and where doing sub-pixel rendering) you'd never hit them precisely (due to "not enough accuracy" of analogue signals and linear amplifiers), and even if you could hit them precisely the amount of "colour bleed" caused by the light of one dot of glowing phosphor reflecting off neighbouring dots would destroy the point.


Cheers,

Brendan

[Brendan]

Hi,

Now, I'm more interested in adding official "support" for these monitors in the form of code to detect DMI0000 that displays a suitable "Your monitor is unsupportable trash" warning.

The user sees this message, wonders why Windows/Linux/whatever has no trouble, and decides your OS must be trash.

These monitors don't work properly (for auto-detection) for Windows/Linux/whatever either. Mostly, these monitors have 2 problems:

• They don't have a unique VID and PID; which causes problems for my OS (but not Windows/Linux/whatever)
• They don't report their native resolution correctly; which causes problems Windows/Linux/whatever (but not my OS)

The only way to work around both problems at the same time is to ask the user (and bypass/destroy auto-detection).

I refuse to ask the user.

Think of it like this... You've got 250 computers on a LAN. There are 200 normal users that are all considered "potentially malicious" and therefore prevented from messing with hardware details or OS configuration. You are the only administrator. You spend most of your time creating user accounts (and resetting user's passwords because people forgot it) and replacing hardware that the OS tells you has failed. As the administrator you also have the ability to tell the OS it is allowed to use a disk drive (but can't/don't tell the OS what to use the disk space for). You are a 17 year-old that did a 3 week training course who has no other qualifications and no other knowledge of computers; who is a part time employee that works 8 hours a week, and for half of that you work from home because you don't need physical access.

When a new computer is added to the LAN you plug things in, tell the firmware to boot from network, boot it and walk away. Optionally (later, from home) you might tell the OS it can use disk space on the new computer (if it has any). There is nothing else.

After you've been administering a LAN of 250 computers for 4 years, you decide to get a second job. You apply for a job administering another LAN of about 250 computers, thinking that it will just be another 8 hours per week. You get the job. On your first day of the new job they tell you the OS is Windows/Linux. On the second day you spend 16 hours trying to figure out all the configuration bullshit. On the third day you quit - life's too short for insane crapware.


Cheers,

Brendan