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

[Brendan]

Hi,

One parameter that I *do* know is useful for end users is the one to override the automatic video mode setting, without which my dodgy CRT would have been unusable.

Without which, your dodgy CRT will still be perfectly usable (just with slightly more blur).

It *was* unusable. At that resolution, the pixels were smaller than the phosphor dots so apart from the text being too small to conformally read the letters were also not properly formed.

You're saying it failed to work on a OS that has none of the features intended to make faulty hardware bearable; and saying that my OS (with a "monitor description file" designed to work around the combination of "vendorID and productID not unique" and "EDID's timings are wrong" problems and give the "least worst possible" result) will be far superior to the OS you tried?

Note that if you actually cared about a little blur (other than for the purpose of whining) you would've replace your crappy "1366*768 native resolution only" display with something that has a better native resolution 5+ years ago when everyone else in the world was shifting to 1920*1200 (and wouldn't care now when people are shifting to 4K; and won't care when my OS is actually released, long after your piece of crud has suffered the same fate as all CRTs and becomes too dark even after you've set its brightness setting to maximum).

I don't remember mentioning anything about a 1366x768 display, but the CRT didn't need replacing because the monitor was fine once it was running at the correct resolution. Besides, it was my parents' old computer and that's all I had. A display is only "crappy" if your OS prevents the user from making proper use of it.

1366*768 is the highest resolution that the Olevia LT26HVE manual says it supports. Something is crappy if it fails to implement relevant industry standards correctly; and no work-around (including end user config and including "carefully designed monitor description file") changes that.

It's fundamentally wrong because:

• The minimum requirements are that software "just works" (ie. without any end user wankery).
• Providing end user configuration means that the end user will misconfigure it and screw everything up, and cause a whole pile of "PEBCAK" bug reports.
• Every single setting is a sign that the OS developer is an incompetent moron that failed to avoid the need for it.

First point: it's impossible to make software that "just works" to the event that no workarounds will ever be needed.

It's "possible in theory" to make almost all hardware "just work". Realistically, there's a limited amount of time to write suitable device drivers, so a lot of hardware that can "just work" won't be supported. This is a huge issue that effects all OSs (including Windows) that none of us can avoid.

In addition to the large number of devices that could "just work" but aren't supported, there will be a tiny number of devices that can't "just work" and also aren't supported.

The tiny number of devices that can't "just work" are nothing more than an irrelevant distraction.

Second point: users will only need to worry about the configuration if their monitor doesn't work, whence they can follow a simple instruction like "please enter the native resolution of your monitor".

To describe a video timing correctly its necessary to know horizontal/vertical resolution, horizontal/vertical sync polarity, horizontal/vertical front porch times, horizontal/vertical back porch times, horizontal/vertical sync width times, pixel clock frequency, and whether it's interlaced or not. Given that most OS developers seem to be too stupid to realise that horizontal/vertical resolution alone is completely inadequate (and that the majority of monitor manuals lack detailed information); what makes you think the average clueless user will be able to provide the necessary information?

Third point: it's not the OS developer's fault that some monitors report incorrect data.

If it's on the OS's supported hardware list but fails to work without end user hassle, then that is the OS developer's fault (either it should work or it shouldn't be on the list).

If it's not on the OS's supported hardware list, the OS developer is not responsible for something they don't support. In this case it's the user's fault for using unsupported hardware (they gambled, they lost).

Standards (e.g. EDID) make it easier for an OS to add devices to their supported hardware list (but only if the standards are implemented by the device correctly) - e.g. an OS developer can say "All monitors with correct EDID are on my supported hardware list".


Cheers,

Brendan

[Brendan]

Hi,

What makes you think it's not the truth?

Honestly? Because it contains the word "moron" and by historical inertia resorting to agression is reserved for people incapable of proper argument.

Which of the following statements do you think are true and which do you think are false:

• The world isn't flat, only morons think it's flat.
• True and false aren't effected by how an argument is worded.
• Poor excuses are for feeble minds

Cheers,

Brendan

[Rusky]

You're saying it failed to work on a OS that has none of the features intended to make faulty hardware bearable; and saying that my OS (with a "monitor description file" designed to work around the combination of "vendorID and productID not unique" and "EDID's timings are wrong" problems and give the "least worst possible" result) will be far superior to the OS you tried?

That's not what was said at all... what onlyonemac said was that your "work around" would produce a bad resolution, that it would not just be "slightly more blurry," but completely unusable, and that the way to make it usable was for the OS to allow its resolution to be specified by the user. This was, in fact, done, without (as far as I know) onlyonemac dealing with any other aspects of timings.

Your repeated refusal to give users the ability to fix the autoconfig (which you've already implemented) when it gets things wrong doesn't make you right; it makes you an idealist disconnected from reality, an old man yelling at a cloud, an incompetent designer.

Nobody would really question it if your reason were just that you didn't want to bother supporting those displays, or that you wanted to simplify the OS itself, or even that you just liked the idea and wanted to go with it (fantastic reasons, actually) but that's never been your goal. Instead, you go to great lengths to support old or strange hardware and talk about the commercial value of your OS, yet you've turned this into a crusade to remove all configuration and convince everyone else it's somehow better. End users won't get a "slightly less worse" (as you say) resolution and say "oh good, no configuration," they'll ask "how do I make this less blurry?"

You refuse to believe anybody else could have truly considered what you have and then come to a different conclusion- anyone who disagrees must just not have done your little "look at the linux kernel parameters" exercise, or else they're an "os developer" who is thus incapable of empathy with end users (but from which you are somehow exempt), or else they're a "moron" or something else from your grab bag of "I'm too mad to argue properly" words.

[Brendan]

Hi,

You're saying it failed to work on a OS that has none of the features intended to make faulty hardware bearable; and saying that my OS (with a "monitor description file" designed to work around the combination of "vendorID and productID not unique" and "EDID's timings are wrong" problems and give the "least worst possible" result) will be far superior to the OS you tried?

That's not what was said at all... what onlyonemac said was that your "work around" would produce a bad resolution, that it would not just be "slightly more blurry," but completely unusable, and that the way to make it usable was for the OS to allow its resolution to be specified by the user. This was, in fact, done, without (as far as I know) onlyonemac dealing with any other aspects of timings.

I know it's not what onlyonemac intended to say. I was using sarcasm to point out that how good/bad it worked on some completely different OS has nothing at all to do with how good/bad it would work on my OS.

Your repeated refusal to give users the ability to fix the autoconfig (which you've already implemented) when it gets things wrong doesn't make you right; it makes you an idealist disconnected from reality, an old man yelling at a cloud, an incompetent designer.

Your repeated refusal to listen to any of the perfectly valid reasons why this is both unacceptable and unnecessary; and the continually regurgitation of arguments that have been previously addressed/discounted doesn't help anyone (including you).

For about the fifth time; there is NOTHING ALREADY IMPLEMENTED for this (unless expecting the end user to download the "closed source" source code so they can tinker with the OS's boot script and file system permissions constitutes "end user visible configuration" in whatever fantasy land you exist within).

Nobody would really question it if your reason were just that you didn't want to bother supporting those displays, or that you wanted to simplify the OS itself, or even that you just liked the idea and wanted to go with it (fantastic reasons, actually) but that's never been your goal.

You think "I'm not adding end-user hassle to work around a non-existent case" (from my first post in this topic) is completely different to "I don't want to bother supporting those displays (because its not worth bothering with)"?

Instead, you go to great lengths to support old or strange hardware and talk about the commercial value of your OS, yet you've turned this into a crusade to remove all configuration and convince everyone else it's somehow better. End users won't get a "slightly less worse" (as you say) resolution and say "oh good, no configuration," they'll ask "how do I make this less blurry?"

0.0001% of users will say "how do I make this less blurry", and 99.999% of users will say "oh good, no configuration".

Trying to pretend that 99.999% of users will say "how do I make this less blurry" is extremely dishonest.

You refuse to believe anybody else could have truly considered what you have and then come to a different conclusion- anyone who disagrees must just not have done your little "look at the linux kernel parameters" exercise, or else they're an "os developer" who is thus incapable of empathy with end users (but from which you are somehow exempt), or else they're a "moron" or something else from your grab bag of "I'm too mad to argue properly" words.

You take an insignificant/irrelevant "problem" and try to pretend it's the only thing in the world that matters while discarding any and all perspective; then continually regurgitate the same nonsense for almost 2 entire weeks while ignoring every single thing I've said; then accuse me of "refusing to believe the One True Rusky" and wonder why I lose my patience?

Do you know what I've been doing for the last week? In between having my time wasted by you; I've been adding support for stereoscopic 3D. Do you know why? It's because recently several display manufacturers have released "glasses-free 3D screens" (autostereoscopic); and by the time my OS is actually released it's likely that people won't be saying "why is the screen blurry" but will be saying "why is there no 3D display support". With lots of luck, my OS will be the first OS to provide fully device independent 3D for all GUIs, apps, etc in the entire OS (starting from very early during boot); and will do it with complete auto-configuration, perfect antialiasing, colour space conversion/correction, dithering, focal blur for "legacy" 2D displays, etc. Of course by this time you will probably be busy dealing with end users complaining that your "OS installation" CD causes the monitor to display "Unsupported video mode timing" and nothing else, and wondering why these users laugh at you when you tell them to adjust a setting that they can't see.


Cheers,

Brendan

[Combuster]

0.0001% of users

There are too many counterexamples in this thread compared to the amount of regulars to these forums that such a statistic is even remotely believable. 0.1% would be a more accurate guess (and even then I believe it's optimistic).

Trying to pretend that 99.999% of users will say "how do I make this less blurry" is extremely dishonest.

Misrepresenting someone else is just as much bad faith on your end.

[onlyonemac]

The tiny number of devices that can't "just work" are nothing more than an irrelevant distraction.

They're only irrelevant until you have to deal with one.

Second point: users will only need to worry about the configuration if their monitor doesn't work, whence they can follow a simple instruction like "please enter the native resolution of your monitor".

To describe a video timing correctly its necessary to know horizontal/vertical resolution, horizontal/vertical sync polarity, horizontal/vertical front porch times, horizontal/vertical back porch times, horizontal/vertical sync width times, pixel clock frequency, and whether it's interlaced or not. Given that most OS developers seem to be too stupid to realise that horizontal/vertical resolution alone is completely inadequate (and that the majority of monitor manuals lack detailed information); what makes you think the average clueless user will be able to provide the necessary information?

I had only to enter the correct monitor resolution into the GRUB configuration file and it was fixed. Native resolutions aren't particularly hard to find out, especially for the average IT department in your hypothetical company where everyone uses your operating system.

If it's on the OS's supported hardware list but fails to work without end user hassle, then that is the OS developer's fault (either it should work or it shouldn't be on the list).

If it's not on the OS's supported hardware list, the OS developer is not responsible for something they don't support. In this case it's the user's fault for using unsupported hardware (they gambled, they lost).

Supported hardware lists generally go "if it's not on the list then don't assume that it will work, but here's the documentation and configuration files for if you want to try to fix it yourself" not "if it's not on the list then it probably won't work, and I didn't give you a configuration file to let you fix it even though I had that functionality until the first release".

You're saying it failed to work on a OS that has none of the features intended to make faulty hardware bearable; and saying that my OS (with a "monitor description file" designed to work around the combination of "vendorID and productID not unique" and "EDID's timings are wrong" problems and give the "least worst possible" result) will be far superior to the OS you tried?

That's not what was said at all... what onlyonemac said was that your "work around" would produce a bad resolution, that it would not just be "slightly more blurry," but completely unusable, and that the way to make it usable was for the OS to allow its resolution to be specified by the user. This was, in fact, done, without (as far as I know) onlyonemac dealing with any other aspects of timings.

I know it's not what onlyonemac intended to say. I was using sarcasm to point out that how good/bad it worked on some completely different OS has nothing at all to do with how good/bad it would work on my OS.

How well it works on another OS is not that irrelevant when both OSes are getting the data for their autoconfiguration from the same place.

0.0001% of users will say "how do I make this less blurry", and 99.999% of users will say "oh good, no configuration".

Trying to pretend that 99.999% of users will say "how do I make this less blurry" is extremely dishonest.

Ultimately I think that is your problem here: you're trying to make out like this is an insignificant issue and are failing to recognise how much of a problem this is to those who experience it. Maybe you've got a quad-HD display which probably doesn't look too bad at a 1920x1080 resolution, but then you haven't truly experienced the problem. Since I went blind I've become incredibly frustrated at sighted people's apparent obsession with crystal-clear ultra-high-resolution, but my experience with blurry monitors has been bad enough for me to care even today.

Ultimately, the biggest turn-off for me has always been auto-configuration that I can't override when it fails, and trust me auto-configuration will always fail some time or another no matter how much more "superior" than Linux you think it is.

[Brendan]

Hi,

0.0001% of users

There are too many counterexamples in this thread compared to the amount of regulars to these forums that such a statistic is even remotely believable. 0.1% would be a more accurate guess (and even then I believe it's optimistic).

Please try to keep up. There is one and only one example; which is an Olevia LT26HVE television and not a monitor, with CRT that has a max. resolution of 1366*768, that was made in 2005 by a company that went bankrupt after federal fraud charges; which will be 20+ years old before my OS is released.

Feel free to provide your own estimate for how many people will be using this one TV (as a monitor) in ~2026 (while taking into account that most people would've shifted to 4k+ displays and/or 3D displays by then, and that CRTs rarely last that long due to ghosting and/or "brightness loss" and/or leaky electrolytic capacitors, and that some people wouldn't even notice and/or care if a CRT isn't running in it's max. resolution anyway).


Cheers,

Brendan

[Octocontrabass]

Please try to keep up. There is one and only one example; which is an Olevia LT26HVE television and not a monitor, with CRT that has a max. resolution of 1366*768, that was made in 2005 by a company that went bankrupt after federal fraud charges; which will be 20+ years old before my OS is released.

My Olevia LT26HVE is a LCD, not CRT. It has incorrect information in its EDID, and shares this information with several other models (including ones that operate at different native resolutions). Its max resolution is somewhere around 1280x1024, since it runs correctly (although too blurry to be useful) at that resolution. Its native resolution is 1280x768, and the native resolution of some models that share the EDID is 1366x768.

Onlyonemac's CRT is... a CRT. Its max resolution is also somewhere around 1280x1024. At this resolution, pixels are smaller than the phosphor dots, resulting in a blurry image. Additionally, the refresh rate will be limited to 60Hz, which causes flicker that will be visible to some users.


And since I'm responding to this thread anyway...

To describe a video timing correctly its necessary to know horizontal/vertical resolution, horizontal/vertical sync polarity, horizontal/vertical front porch times, horizontal/vertical back porch times, horizontal/vertical sync width times, pixel clock frequency, and whether it's interlaced or not. Given that most OS developers seem to be too stupid to realise that horizontal/vertical resolution alone is completely inadequate (and that the majority of monitor manuals lack detailed information); what makes you think the average clueless user will be able to provide the necessary information?

To describe a video timing correctly, it's necessary to know horizontal/vertical resolution, target refresh rate, whether it's a TV mode with an "i" at the end, and VESA's display resolution standards. Do you have any examples where this isn't sufficient to derive the remaining information?

[Combuster]

...

Last post:
Factual inaccuracies: 3
Reiterations of irrelevant facts: 2
Distractions: 1
Useful arguments: 0

Post before that:
Insults: 1
Reiterations of irrelevant facts: 1
New but irrelevant facts: 1
Distractions: 1
Factual inaccuracies: 2
Misrepresentations: 2
Useful arguments: 0

Post before that:
False dichotomys: 3
Distractions: 1
Useful arguments: 0

It's probably the primary reason why I avoid discussions with you in the first place because the result is almost always dishonourable.

I think very well demonstrates this particular (though off-topic) point I made earlier.

tl;dr: Brendan, I can't moderate you - you'd just overrule me, sou you should instead learn to shut up on your own accord when it's the time to do so.

[Brendan]

Hi,

The tiny number of devices that can't "just work" are nothing more than an irrelevant distraction.

They're only irrelevant until you have to deal with one.

..which will be exactly never.

Second point: users will only need to worry about the configuration if their monitor doesn't work, whence they can follow a simple instruction like "please enter the native resolution of your monitor".

To describe a video timing correctly its necessary to know horizontal/vertical resolution, horizontal/vertical sync polarity, horizontal/vertical front porch times, horizontal/vertical back porch times, horizontal/vertical sync width times, pixel clock frequency, and whether it's interlaced or not. Given that most OS developers seem to be too stupid to realise that horizontal/vertical resolution alone is completely inadequate (and that the majority of monitor manuals lack detailed information); what makes you think the average clueless user will be able to provide the necessary information?

I had only to enter the correct monitor resolution into the GRUB configuration file and it was fixed.

Then you were lucky and "whatever random timing" the video card's VBE ROM happened to use was close enough. For most computers VBE doesn't support the native resolution.

Supported hardware lists generally go "if it's not on the list then don't assume that it will work, but here's the documentation and configuration files for if you want to try to fix it yourself" not "if it's not on the list then it probably won't work, and I didn't give you a configuration file to let you fix it even though I had that functionality until the first release".

Which settings do I play with to get the GPU working on my ATI cards in Linux; or my USB 3.0 controllers working under Windows 98, or my old SoundBlaster card working under Windows 8.1? For most hardware you get documentation for how to write a device driver.

You're saying it failed to work on a OS that has none of the features intended to make faulty hardware bearable; and saying that my OS (with a "monitor description file" designed to work around the combination of "vendorID and productID not unique" and "EDID's timings are wrong" problems and give the "least worst possible" result) will be far superior to the OS you tried?

That's not what was said at all... what onlyonemac said was that your "work around" would produce a bad resolution, that it would not just be "slightly more blurry," but completely unusable, and that the way to make it usable was for the OS to allow its resolution to be specified by the user. This was, in fact, done, without (as far as I know) onlyonemac dealing with any other aspects of timings.

As far as I can tell:

• The monitor (Olevia LT26HVE) reports its max. resolution (and not it's native resolution). Note: This is most likely perfectly fine and does comply with VESA's EDID specs (assuming it doesn't set the "first detailed timing descriptor is the native resolution" flag).
• Almost all software assumes that the max. resolution is the "best" resolution
• For this monitor the max. resolution is 1028 lines but the native resolution is 768 lines; which results a video timing that is higher resolution than "ideal" and scaled down (and not lower resolution and scaled up).
• If the vendorID and productID were unique; this problem would be trivial to fix with my "monitor info data" files, not because the video mode timings would be any different, but because I have a "preference" for each video timing that more accurately indicates how well each timing works (unlike EDID's crude "search order" scheme).
• The PnP ID reported by this display is the same as other/different displays; where some of the displays are 1366*768 and some are 1280*768. Note: VESA (for no logical reason I can think of) expect video modes to be a multiple of an arbitrary "character width of 8 pixels"; and a lot of displays that have a horizontal resolution of 1366 pixels end up deliberately misreporting their native resolution because of this.
• By creating a "monitor info data" file that only says "1280*768", it'd would be using the native resolution on half of the TVs (including Olevia LT26HVE); and end up with horizontal but not vertical scaling ("1280*768 scaled up to 1366*768") for the other half.
• Because it's a relatively large (26 inch) screen with a relatively low resolution (and because the OS's graphics API is 100% resolution independent and 100% 3D, and nothing ends up on exact pixel boundaries and everything ends up anti-aliased); for the "1280*768" TVs where the native resolution is used the picture will be blurry (compared to a modern display) because the native resolution is too low for the user's field of view; and for the TVs where the native resolution is 1366*768 the picture won't be noticeably worse than the "only slightly less blurry" 1280*768 TVs.

Trying to pretend that 99.999% of users will say "how do I make this less blurry" is extremely dishonest.

Ultimately I think that is your problem here: you're trying to make out like this is an insignificant issue and are failing to recognise how much of a problem this is to those who experience it.

No. Even though I've repeatedly pointed it out; you still fail to understand that I'm primarily designing an OS for the hardware people will be using in 10+ years time (when the OS will hopefully be released); and I couldn't give a crap about hardware that is already obsolete now because it's not going to become "less obsolete" in the next 10 years. Note (because I can predict Rusky will attempt to use this as an opportunity to whine); 80486SX compatible systems are still being sold as small/embedded systems and are therefore not obsolete now).

Ultimately, the biggest turn-off for me has always been auto-configuration that I can't override when it fails, and trust me auto-configuration will always fail some time or another no matter how much more "superior" than Linux you think it is.

The biggest turn-off for me is when auto-configuration fails. If it's the OS's fault then the OS is buggy and I want my money and time back. If it's the hardware's fault then the product is not fit for its intended purpose and I want my money and time back.


Cheers,

Brendan

[Brendan]

Hi,

Please try to keep up. There is one and only one example; which is an Olevia LT26HVE television and not a monitor, with CRT that has a max. resolution of 1366*768, that was made in 2005 by a company that went bankrupt after federal fraud charges; which will be 20+ years old before my OS is released.

My Olevia LT26HVE is a LCD, not CRT. It has incorrect information in its EDID, and shares this information with several other models (including ones that operate at different native resolutions). Its max resolution is somewhere around 1280x1024, since it runs correctly (although too blurry to be useful) at that resolution. Its native resolution is 1280x768, and the native resolution of some models that share the EDID is 1366x768.

You're right - it's onlyonemac's "unknown monitor with unknown problem" that was CRT.

To describe a video timing correctly its necessary to know horizontal/vertical resolution, horizontal/vertical sync polarity, horizontal/vertical front porch times, horizontal/vertical back porch times, horizontal/vertical sync width times, pixel clock frequency, and whether it's interlaced or not. Given that most OS developers seem to be too stupid to realise that horizontal/vertical resolution alone is completely inadequate (and that the majority of monitor manuals lack detailed information); what makes you think the average clueless user will be able to provide the necessary information?

To describe a video timing correctly, it's necessary to know horizontal/vertical resolution, target refresh rate, whether it's a TV mode with an "i" at the end, and VESA's display resolution standards. Do you have any examples where this isn't sufficient to derive the remaining information?

That information isn't enough to uniquely identify any specific timing; and is only enough for hueristical purposes - basically; enough to estimate the probability that it might match a specific timing from some other source (e.g. one of VESA's "safe mode timings", an established timing, a timing that's in VESA's "Display Monitor Timing" list, a timing that fits with GTF with default parameters (but not secondary parameters), a timing that fits with default CVT formulas without reduce blanking, and/or a timing that fits with CVT "reduce blanking" formulas).

For example; something like "640*480 @ 60Hz, not interlaced" matches 5 different timings - one legacy VGA/established timing, one safe mode timing (that is more like a sliding scale from 400 lines to 480 lines and ends up almost the same as legacy VGA with different margins and blanking), one timing in the DMT list (that has a higher pixel clock and less blanking than both legacy VGA and safe mode timing), etc. Of course everything matches GTF and CVT in multiple ways.


Cheers,

Brendan

[onlyonemac]

Please try to keep up. There is one and only one example; which is an Olevia LT26HVE television and not a monitor, with CRT that has a max. resolution of 1366*768, that was made in 2005 by a company that went bankrupt after federal fraud charges; which will be 20+ years old before my OS is released.

The tiny number of devices that can't "just work" are nothing more than an irrelevant distraction.

They're only irrelevant until you have to deal with one.

..which will be exactly never.

Did you just *completely* ignore my posts discussing my CRT? That's TWO examples, not ONE, and you can't say that it is "exactly never" that one will have to deal with such hardware when I've just given you an example )my aforementioned CRT) of such hardware.

[Octocontrabass]

For example; something like "640*480 @ 60Hz, not interlaced" matches 5 different timings

The "legacy based on NTSC", safe mode, and DMT timings are identical when the border color is black. Other timings are irrelevant, because all displays usable with a PC support the "legacy based on NTSC" timing.

[onlyonemac]

Ultimately, the biggest turn-off for me has always been auto-configuration that I can't override when it fails, and trust me auto-configuration will always fail some time or another no matter how much more "superior" than Linux you think it is.

The biggest turn-off for me is when auto-configuration fails. If it's the OS's fault then the OS is buggy and I want my money and time back. If it's the hardware's fault then the product is not fit for its intended purpose and I want my money and time back.

You simply cannot expect to be able to write auto-configuration that will always work. You can try your best, but as you quite rightly pointed out sometimes (usually) it's the hardware's fault - your mistake here is that not everyone has specifically *bought* "crappy" monitors and feels like wasting their own time trying to get a refund because it didn't work with some obscure OS that doesn't let you change the monitor resolution; some people already have those monitors and if your OS doesn't work with the monitor then it's going to be the OS that they'll demand a refund for (I know I would - having just spent money on a new OS I wouldn't want to then be told that I had to spend more money on a new monitor when I'm quite happy with my old one). I really don't know why you stubbornly refuse to offer a configuration file with a big warning at the top saying "I DO NOT AND WILL NOT OFFER ANY SUPPORT WHATSOEVER BEYOND THE AVAILABLE DOCUMENTATION FOR THE FOLLOWING CONFIGURATION OPTIONS OR ANY PROBLEMS THAT ARISE FROM THEIR USE, BUT THEY ARE AVAILABLE SHOULD YOU WISH TO ATTEMPT TO RESOLVE HARDWARE COMPATIBILITY ISSUES YOURSELF. PROCEED AT YOUR OWN RISK." and supply a small booklet explaining each option and it's intended use (e.g. "The 'resolution' parameter can be used to override the automatic detection of monitor resolution should your monitor be incompatible with the auto-configuration routine, and requires three parameters giving the desired horizontal resolution, vertical resolution, and refresh rate of the monitor.") which wouldn't take more than a few hours to write (hardly a big deal for an OS with a 10-year development timescale).

The bottom line is: while we all wish that manufacturers would follow industry standards and make their products compatible with each other, the fact is that there are always going to be one or two that aren't and usually there's nothing that the end user can do about that.

You're right - it's onlyonemac's "unknown monitor with unknown problem" that was CRT.

They're only "unknown problems" because when I offered to collect some data from the monitor for you you quite blatantly ignored me.

[iansjack]

It's impressive that you guys have managed to keep an argument about absolutely nothing going for 8 pages. But surely by now you have said it all (several times).

For goodness sake, let this thread rest in peace.