OSDev.org

Nobody's suggesting that you remove auto-detection. Getting a blurry resolution during install or initial setup is fine. The problem is when the OS arbitrarily refuses to let the user set the resolution.

Hi,



Our perspectives are fundamentally different...

I'm not refusing to let the user set the resolution; I'm refusing to allow the user, applications, GUI and all other software (except video driver) set the resolution.

The video driver alone is the only piece that knows/cares what the resolution is, and may change video modes whenever it feels like - e.g. due to "hot-plug"/monitor replacement, or to get a better compromise between performance and quality (e.g. if it's spent the last 2 hours struggling to render graphics quickly enough and there's been no user activity for 5+ minutes it can decide to switch to a lower resolution; and if it believes it can handle the extra processing of a higher resolution then...). If/when video driver changes video modes, it has no reason to get permission beforehand, or inform any other software afterwards.


Cheers,

Brendan

That's irrelevant to the problem we're discussing. The user still needs to be able to specify is the display's native resolution (however indirectly that may be accomplished)- your video driver is of course then free to do what it likes with the information, but if it doesn't have it in the first place it has no chance of using the native resolution when that's appropriate.

Hi,



The video driver needs to know all of the video timings that the display supports. For each of them, just knowing (e.g.) "800*600" is completely worthless without knowing pixel clock, front porch and back porch times, horizontal and vertical sync polarities, etc (essentially, it needs something like X's "mode lines").

Expecting a typical end user to provide this information may (very arguably) have been acceptable in 1990. It is not acceptable now.


Cheers,

Brendan

They don't have a "native resolution" as such in terms of how many physical pixels they have, but they still have an "optimum/preferred resolution" based on the dot pitch and for this display that was 1024x768 but Linux always tried to run it at 1280x1024 which led to everything appearing very blurry.

That's what GTF, DMT, and CVT are for.

Hi,



Sadly, most monitors (none I've tested) support GTF or CVT.

DMT only helps to decode EDID and doesn't help for anything else (e.g. if the user says "I want 800*600"; then there's 6 different "800*600" video modes listed in DMT and you have no idea which one user meant or if the monitor supports any or none of them or something that isn't listed in DMT at all).


Cheers,

Brendan

Certainly, the effort to support an override mechanism - one which allows the administrator to provide an alternate or custom details file, something you have already stated you would provide - would be minimal, would it not? The major change, in this case, would be allowing the administrator to provide a custom (or even gensymmed/GUIDed) device ID for the non-conformant device. Even if your design would require you to use a separate table for non-conformant devices (which is an issue that goes well beyond monitors), the effort would not be especially great, I imagine. Am I wrong in this?

Note that none of this would require you (or your support team) to support the non-conformant hardware; the system should make it clear that if the administrator chooses to pursue using hardware not supported by the system, then they are on their own in doing so. Not a good solution, by any means, but still one more likely to avoid irate administrators and users, I would expect.

...which is why nobody is suggesting that be the normal mode of operation, but rather an override for the relatively uncommon case of an uncooperative device. In fact, you already need a way for someone to provide that information for displays with missing EDIDs, in order to build your database of description files. This is not going very much further.

Hi,



As far as the end user knows, they turn the computer on and it works by "magic", the first time, and every time (unless the hardware is faulty).

They don't know about "the man (people) behind the curtain" who created the device drivers and "display info data" files that make the magic happen. As soon as you start getting "people in front of the curtain" and "people behind the curtain" mixed up, you end up with a tragic disaster where only trained professionals are able to use a toaster (and where most users would rather pay $$$ to Microsoft or Apple just to avoid the OS you're trying to give away for free).


Cheers,

Brendan

Since said users are usually unaware that they pay anything for the Microsoft or Apple software that came bundled with their PC - it just came with it, must be free, right? - the chances of anyone getting them to use a different OS, free or not, is zero, no matter how much better it might be, how easy the installation is, or how low the barriers to entry are. As far as the users know, the barriers to entry of what they already have is zero (feel free to chuckle bitterly at this), and the chances of them even understanding what you are offering is miniscule.

We are talking about people who don't know the difference between the dektop and the applications, who have never heard of Linux (or if they have, think it is either a version of Windows, a 'hacking tool', or an obscure application), and think that a web browser is an operating system. And you know what? Their ignorance is entirely justified. They have no reason at all to know anything more, or wouldn't if the software actually worked and did what they needed it to. I know that this is exactly what you are aiming at, but doing so with a new OS is self-defeating, because it would require them to break out of exactly that ignorance in order to understand the issues at hand.

Seriously, Brendan, you aren't actually thinking that someone is going to use any of our operating systems, are you? Yes, it makes sense to design and code them as if someone will, but you of all people know better than to expect it will actually happen.

The end user is free to leave the configuration in its sub-optimal state. The essential thing is that they are allowed to become a "person behind the curtain," even if only in the sense that they can add a config file to an already-existing system so they can use their own hardware correctly.

Your hypothetical 8 hr/wk IT intern or typical power user can handle reading the instructions on how to fill out a form based on device specs, and your typical end user can handle an optional mechanism they don't see unless they look for it.

To put it in your terms: "Our perspectives are fundamentally different..." The user should be able to use their hardware as they see fit, and the OS should not be a "take it or leave it" model.

Hi,



It's important to know who your customer is.

If users think of it as a single package (e.g. "Windows PC", "Apple Mac") and not as separate pieces ("white box PC + Windows OS", "beige box PC + OS X"), then your customer is OEMs and not end users. It's people like Dell and HP (and thousands of others ranging in size from from local computer shops that custom build all the way up).

It doesn't change the fact that you need to convince the customer; and doesn't change the fact that convincing the customer requires an OS that is attractive to the end user.



Do people who purchase a lottery ticket seriously think they will win? I do what I do not because I think I will succeed, but because I know there's a very tiny chance that I might succeed if I try. Otherwise, there's no reason for me to be here, and I would've given up 10 years ago (after my first few "hobby" OSs).

Eventually all OS developers either try to succeed, or give up, or die. These are only 3 possible outcomes, and I don't like 2 of them.


Cheers,

Brendan

Hi,



If there is configuration, then:

• The people behind the curtain (including hardware manufacturers) failed to do their job
• The people behind the curtain know that they failed (otherwise they wouldn't have had a reason to provide configuration)
• The people behind the curtain did not fix their failure (otherwise they wouldn't have had a reason to provide configuration)
• The product is not fit for its intended purpose
• The product should never have been made available to end users

If you think that (as a developer) you are a failure and therefore need to provide configuration, then that's fine for *your* project. For my project it's not acceptable.



If an intern or power user has to spend 2 minutes reading instructions then they deserve a personal apology and compensation for the time your crapware has cost them.



A distributed OS doesn't make sense without 3 or more computers. 3+ computers rarely makes sense without multiple users. With multiple users you end up with roles.

For my project there are 4 distinct roles. The hardware owner (e.g. a company), the admin and maybe maintenance people (who are not the hardware owner and not "all powerful super user" but are just disposable peripherals able to do things the OS can't automate), and normal users. These are all "in front of the curtain". The fourth role is developers - the people behind the curtain.

The users are employees, paid to do things like accountancy, and creating artwork, and re-ordering feed for livestock. The computer is only a tool. They needn't know anything about the machinery.


Cheers,

Brendan

Certainly! That's the whole point here- the hardware manufacturers failed, but shipped the display anyway, and now the end user has it. The question is not what to do in your mythical unicorn world where no hardware manufacturer ever fails, but what to do in the real world where just about every hardware manufacturer fails in some way or another.

And the fact is, you already have configuration files for displays with missing or incorrect EDIDs, so the only change anybody here wants is the ability to override which config file to use for a particular display. This is not a failure of the developer, it's a success of the developer in mitigating the failure of the hardware manufacturer.

What's unacceptable is the developer not letting the end user (or administrator, if you prefer) use their hardware properly, even if that involves reading the labels on a form. You can't expect everything about operating a computer to be intuitive to everyone without reading instructions.