OSDev.org

tjmonk15 wrote:And Brendan has already addressed this in his port where he listed resolutions and sizes of characters and monitors. Just because "some" blurring has happened does not mean the characters will be illegible. They CAN become illegible unles you take some precautions (such as picking a font-size where even when blurred the text is still legible, which brendan has already stated he is looking into.)

Perhaps it would be better to allow the user to configure the monitor resolution rather than being restricted to a particular set of font sizes working on the assumption that only certain resolutions will be used.

I don't get what the big deal is with avoiding manual configuration. So far we've had to:

• Run some monitors at non-native resolutions, which is by definition a "wrong" resolution in that it is not the intended resolution but is designed merely as a fallback/stopgap for if the video card outputs the wrong resolution; trying to claim that non-native resolutions are equally "correct" as native resolutions are is very naive
• Sacrifice image quality and pretend that it's insignificant due to some "innovative" rendering which apparently isn't affected by blur
• Restrict our choice of font sizes and styles (which will affect far more users than any manual monitor configuration ever would) to avoid illegible text on certain random combinations of video card resolution and monitor resolution

just to avoid one little configuration file which no users and most administrators won't even know, or need to know, exists.

Brendan wrote:But enough about me... Let's talk about your OS.

How does your OS currently handle video mode auto-selection (and ensure that the chosen video mode is actually visible/supported by the monitor)? How does your OS avoid the "user has to change a setting to get video to work but user can't see anything because video doesn't work" problem? How long did it take you to write all of the native video drivers so that you could avoid "not-native resolution" on all computers?

I missed this earlier because I accidentally interrupted my screenreader halfway through your post and didn't feel like listening to the whole thing again, but currently my OS doesn't support video output due to being early in development and when it gets more mature it probably still won't due to difficulty in testing such output (if I have to explain why then clearly you haven't been paying attention to the thread), and if it ever does it'll boot up in a text mode and then allow the user to start a graphical session with either a manually-configured resolution or perhaps later an auto-configured resolution, with the ability to fall back to a text mode (note that ultimately the starting of the graphical session may be automated/scripted by a startup script, but the user will still have a way to escape to a text mode via a key combination or bootloader parameter or something if it fails).

Brendan wrote:Basically you could summarise my position as:

• The "slightly more blurry graphics on faulty hardware" problem won't exist by the time my OS is released (and is already extremely rare)
• If it did exist; "slightly more blurry graphics" would be a minor issue anyway
• If it did exist and wasn't a minor issue; adding end-user configuration/work-arounds won't make any real difference to the number of people willing/not willing to use my OS
• If it did exist, wasn't a minor issue and did effect the number of people willing to use my OS; "end user work-around for faulty hardware" only cures short term symptoms and makes the problem worse in the long term; so I'd still refuse.

People can argue about one of these things in isolation (and have been); but even if I'm wrong for 3 of these things it makes no difference and "end user configuration as work-around for slightly more blurry graphics on faulty hardware" is still a bad idea.

OK, well, I won't argue this point any more; I was more concerned about your apparent view that users and administrators could be expected to behave rationally than by the actual technical problems. If you are prepared to deal with the backlash it could lead to, that's your choice.

For what it is worth, I think you are right, I just wanted to be certain you were aware of the consequences of the decision (mainly, potential bad word-of-mouth on technical review sites and a lot of complaining nincompoops clogging up your technical support channels with 'known but won't fix' problems). It sounds like you are, so proceed as you will.

Hi,

onlyonemac wrote:I don't get what the big deal is with avoiding manual configuration. So far we've had to:

• Run some monitors at non-native resolutions, which is by definition a "wrong" resolution in that it is not the intended resolution but is designed merely as a fallback/stopgap for if the video card outputs the wrong resolution; trying to claim that non-native resolutions are equally "correct" as native resolutions are is very naive

Your "some" is zero monitors, plus a 2 TVs where one would get the native resolution and one won't and all of them will be 20 years old before the OS is released.

onlyonemac wrote:

• Sacrifice image quality and pretend that it's insignificant due to some "innovative" rendering which apparently isn't affected by blur

Do you honestly think that grossly misrepresenting issues makes your argument seem more intelligent?

onlyonemac wrote:

• Restrict our choice of font sizes and styles (which will affect far more users than any manual monitor configuration ever would) to avoid illegible text on certain random combinations of video card resolution and monitor resolution

Nowhere did I say font sizes would be restricted. When the camera is very close to the text a single character can be 100 times larger than the screen, and when the camera is very far away from the text each character can be 1/100th of a pixel in size. Of course when you've got 100 characters all squished into one pixel (and that pixel is far in the distance nowhere near the camera's focal point and deliberately blurred) those characters might not be readable.

onlyonemac wrote:just to avoid one little configuration file which no users and most administrators won't even know, or need to know, exists.

Before I explained how wrong you are last time you said this, "one little configuration file" could be forgiven as an honest mistake. After I explained how wrong you are last time, "one little configuration file" is a lie and you know it.

It's hacks in every single video driver, more hacks in the "session manager" to give the right settings for each monitor to its video driver, a dialog box to change settings, crippling the video drivers ability to change resolution on the fly (to meet frame rate guarantees when renderer consistently fails to keep up), and documenting all of that (in the user manual, help system and device driver guide; possibly in multiple different languages), and maintaining all of it "forever". All of this for the sake of time travellers that might want to use an unsupported TV that would be unusable regardless.

onlyonemac wrote:

Brendan wrote:But enough about me... Let's talk about your OS.

How does your OS currently handle video mode auto-selection (and ensure that the chosen video mode is actually visible/supported by the monitor)? How does your OS avoid the "user has to change a setting to get video to work but user can't see anything because video doesn't work" problem? How long did it take you to write all of the native video drivers so that you could avoid "not-native resolution" on all computers?

I missed this earlier because I accidentally interrupted my screenreader halfway through your post and didn't feel like listening to the whole thing again, but currently my OS doesn't support video output due to being early in development and when it gets more mature it probably still won't due to difficulty in testing such output (if I have to explain why then clearly you haven't been paying attention to the thread), and if it ever does it'll boot up in a text mode and then allow the user to start a graphical session with either a manually-configured resolution or perhaps later an auto-configured resolution, with the ability to fall back to a text mode (note that ultimately the starting of the graphical session may be automated/scripted by a startup script, but the user will still have a way to escape to a text mode via a key combination or bootloader parameter or something if it fails).

My prediction is that (when your OS is finished) the OS won't work at all on 25% of computers (where UEFI doesn't support text mode), won't support graphics modes for 75% of computers (because BIOS will be long dead and you can't change video modes without a native video driver after boot on UEFI systems, and there won't be enough native video drivers), 33% of people won't be able to start a graphics session (because it needs a key-combination, and they're using a tablet with an "on touch screen" keyboard that doesn't work without graphics), and 50% of people will delete the OS without ever finding out there's a graphical session because they can't read English and can't understand anything on your "ASCII only" screen.

Basically; the number of people that will be able to get graphics to work at all on your OS will be less than the number of people that would have a problem with graphics on my OS; and you're telling me to fix my graphics(!)?


Cheers,

Brendan

Brendan wrote:Your "some" is zero monitors, plus a 2 TVs where one would get the native resolution and one won't and all of them will be 20 years old before the OS is released.

Lie. I don't care how old it is, but I have such a monitor in good working order and in regular use until I couldn't see it anymore sitting approximately one and a half meters away at my 10 o'clock.

Brendan wrote:Nowhere did I say font sizes would be restricted.

Then what was that other post all about where you listed all sorts of seemingly random character sizes (sounding very "text mode"-ish) and equally random-sounding monitor resolutions (where I believe you were implying that those are the only monitor resolutions that will be in existence in ten years' time or something like that)?

Brendan wrote:

onlyonemac wrote:just to avoid one little configuration file which no users and most administrators won't even know, or need to know, exists.

Before I explained how wrong you are last time you said this, "one little configuration file" could be forgiven as an honest mistake. After I explained how wrong you are last time, "one little configuration file" is a lie and you know it.

You still haven't (justifiably) explained what makes it more than "one little configuration file".

Brendan wrote:It's hacks in every single video driver, more hacks in the "session manager" to give the right settings for each monitor to its video driver, a dialog box to change settings, crippling the video drivers ability to change resolution on the fly (to meet frame rate guarantees when renderer consistently fails to keep up), and documenting all of that (in the user manual, help system and device driver guide; possibly in multiple different languages), and maintaining all of it "forever".

The fact that you have to hack the video drivers makes me think that your driver architecture has no way to pass parameters to drivers when they are loaded, which sounds very short-sighted to me. You don't need a dialog box; the rest of the world with our "outdated" 2D operating systems uses a text editor to edit a configuration *file*, which is like a string of bytes representing text characters which in turn represent various parameters for whatever is being configured, and which can be reconfigured with any application capable of editing such an arcane format, such as the venerable text editor, which if you're not supplying with your OS then I can tell you the IT department will be smashing the virtual disks on which it is supplied out of frustration. And you don't have to cripple anything with the video drivers; it's up to them what they do with the information, but quite frankly changing the resolution "on the fly" to meet frame rate limitations is the stupidest thing ever because even today monitors take a few milliseconds to sync with a new resolution and during that time their output is undefined (and may consist of a frozen frame, a black screen, or flicker). If you're seriously planning on changing the monitor resolution on such an ad-hoc basis, then quite frankly you can forget about anyone ever using your OS for more than a few minutes because they will get very frustrated (and by the way the correct way to handle frame rate guarantees is to either drop frames or lower the *renderer* resolution, not the *video output* resolution). Finally, I've told you I don't know how many times that the documentation can be (and should be) as simple as "The 'resolution' parameter specifies the default monitor resolution" and if people can't read English they can run that through Google translate.

Brendan wrote:My prediction is that (when your OS is finished) the OS won't work at all on 25% of computers (where UEFI doesn't support text mode), won't support graphics modes for 75% of computers (because BIOS will be long dead and you can't change video modes without a native video driver after boot on UEFI systems, and there won't be enough native video drivers), 33% of people won't be able to start a graphics session (because it needs a key-combination, and they're using a tablet with an "on touch screen" keyboard that doesn't work without graphics), and 50% of people will delete the OS without ever finding out there's a graphical session because they can't read English and can't understand anything on your "ASCII only" screen.

Perhaps I actually care about making something that works *now* and that can be developed *now* (try developing a hobby OS on one of those "closed" touchscreen devices that are available today and you'll see what I mean) rather than something that's designed to work on any computer available in 20 years time but which I can't enjoy hacking around with on my old PC now (and wasting time implementing all sorts of UEFI and video driver crap when I could rather be working on the core concepts that make up my OS and writing the code to implement them). For me, OSdev is not about "let me try to make something that's better than the rest of the world and will work on computers for the next 50 years" but rather a project to explore new ideas in operating system design and a framework for further experimentation.

In your case, stop trying to run monitors at resolutions that they only implement to avoid "mode not supported" errors when some idiot sets the wrong resolution, and claiming that these resolutions are acceptable for everyday use. As far as I know there's no standard that even says how monitors should handle non-native resolutions and even if there is manufacturers are probably less likely to follow it than they are to follow EDID standards and if they don't follow EDID standards then don't expect them to follow any other standards, so GIVE USERS/ADMINISTRATORS A FUCKING CONFIGURATION OPTION.

onlyonemac wrote:(...)so GIVE USERS/ADMINISTRATORS A FUCKING CONFIGURATION OPTION.

I don't think he will.

Brendan wrote:There's so many different reasons why graphics on Linux is "less than good" (especially ancient Linux that was around in the "CRT era" - it has improved since) that it's impossible for me to determine how your problem relates to anything. Note that I do vaguely remember trying to get Linux to work in the 1990s, and Xorg defaulting to a hideous video mode that abused VGA registers to get a "800*600 with 16 colours", where the refresh rate was so bad (due to relying on VGA's pixel clock, which only goes up to about 30 MHz) that it was like it was designed specifically to cause seizures. Of course it's likely that your problem is different (and isn't the same as the "Xorg didn't use auto-configuration and had bad default configuration" problem that I remember).

This was 2002-era hardware, and it still confuses the graphics auto-configuration in current (as of last year) Linux distros into running the monitor at the wrong resolution (note that Linux hasn't used Xorg to configure the graphics hardware in a long time; these days the kernel configures the hardware and gets it wrong because of the exact same incorrect data from the monitor that caused Xorg to get it wrong when I first tried Linux on that system, but the Linux kernel accepts a bootloader parameter to override the auto-configuration with the correct resolution, which always fixes the problem for me because I know what the monitor's correct resolution is (and if I didn't then I could try different values until I get one that looks right, and if I get a "mode not supported" error in the process then I can hit the reset switch, enter the GRUB configuration while the system is still in a text mode, and change the parameter)).

kiznit wrote:

onlyonemac wrote:(...)so GIVE USERS/ADMINISTRATORS A FUCKING CONFIGURATION OPTION.

I don't think he will.

...without justification besides "dumb administrators will **** it up and manufacturers will use it as a cop-out", neither of which sounds very plausible.

onlyonemac wrote:as simple as "The 'resolution' parameter specifies the default monitor resolution" and if people can't read English they can run that through Google translate

In general, if a developer has this attitude, e.g. "if people can't read English, it is their problem", I am fairly sure that it is a major issue when trying to design and implement something that is not intended to be a hobby hack. Please note that there are valid reasons for limiting some things to English only. What I am trying to say is that the attitude matters. It makes a huge difference if the developer is truly sorry that some things are in English only (e.g. error messages in unlikely "kernel panics" etc.) due to technical reasons and does everything for assisting the users, e.g. providing (or having an option for someone to provide) localized documentation about the "cryptic text" on the screen.

Maybe this is offtopic, but I think one problem with "free" is that people assume they have to be thankful for the software author that they are "allowed" to use the software to begin with. It should be the exact opposite. The software authors should be thankful. Of course this does not happen in practice because typically there is not much choice and those few software authors have way too much power and it makes it possible to say something like "I don't care, it's your problem."

Hi,

onlyonemac wrote:

Brendan wrote:Your "some" is zero monitors, plus a 2 TVs where one would get the native resolution and one won't and all of them will be 20 years old before the OS is released.

Lie. I don't care how old it is, but I have such a monitor in good working order and in regular use until I couldn't see it anymore sitting approximately one and a half meters away at my 10 o'clock.

No, you don't.

You might have a monitor that gives incorrect video mode timings from its EDID (which can be trivially worked around via. my "monitor description" files); and you have a monitor that gives correct video mode timings but incorrect PnP ID (which can be trivially worked around by not having a "monitor description" file to force the OS to use the EDID); and you might have a monitor where the EDID is perfectly correct (but Linux was broken and you felt like blaming the monitor).

onlyonemac wrote:

Brendan wrote:Nowhere did I say font sizes would be restricted.

Then what was that other post all about where you listed all sorts of seemingly random character sizes (sounding very "text mode"-ish) and equally random-sounding monitor resolutions (where I believe you were implying that those are the only monitor resolutions that will be in existence in ten years' time or something like that)?

In that post I measured (with a ruler) the physical font size (in millimetres) that I do use (from the text editor I use for programming) as a typical/representative font size; and then calculated/estimated the resolution and/or monitor size that would be needed to avoid "too blurry to read" text (and for "nice clear text") for that one specific representative font size, to show (using mathematics based on factual evidence as opposed to your "incessant barrage of unfounded whining") that your "too blurry to read" myth is nonsense for everything that will matter; including the 2 most common resolution that are in use today (based on Steam's latest hardware survey) and the resolutions that are likely to be in use (based on extrapolating statistical data from Steam's surveys) when the OS is released.

onlyonemac wrote:

Brendan wrote:Before I explained how wrong you are last time you said this, "one little configuration file" could be forgiven as an honest mistake. After I explained how wrong you are last time, "one little configuration file" is a lie and you know it.

You still haven't (justifiably) explained what makes it more than "one little configuration file".

I have at least twice now; including in the post you are replying to. You are literally claiming that something doesn't exist while including it (as a quote) in the same post as your claim, and arguing about the details within the explanation that you're attempting to pretend didn't exist.

onlyonemac wrote:

Brendan wrote:It's hacks in every single video driver, more hacks in the "session manager" to give the right settings for each monitor to its video driver, a dialog box to change settings, crippling the video drivers ability to change resolution on the fly (to meet frame rate guarantees when renderer consistently fails to keep up), and documenting all of that (in the user manual, help system and device driver guide; possibly in multiple different languages), and maintaining all of it "forever".

The fact that you have to hack the video drivers makes me think that your driver architecture has no way to pass parameters to drivers when they are loaded, which sounds very short-sighted to me.

The device manager provides information obtained via. auto-detection from PCI (IRQ, BARs) when starting the device driver. Device drivers may store and track information for maintenance purposes (e.g. hours in service, mean time between failures, etc) and report this information to a maintenance utility framework. Video drivers report information back to "session manager" (or "station manager" or "user interface manager" or whatever I decide to call it - I really haven't found a good name for it yet) about monitor details it auto-detected (so that "session manager" can coordinate things, like handling user login when a monitor comes online); plus feedback (from video driver to "session manager") from every frame rendered to allow multi-monitor HDR and multi-monitor focus to work. Then there's "accessibility" information from user's profiles (colour blindness for hue shifting/compensation purposes, photosensitive epilepsy for flash limiting purposes, etc) sent from "session manager" to all video cards/monitors being used by that user as part of user login. Of course on top of that is the graphics data itself going to the video driver describing what frame/s should contain.

Basically there's plenty of information going in all directions; but nothing originating from any user (including admin) to any specific video driver.

onlyonemac wrote:You don't need a dialog box; the rest of the world with our "outdated" 2D operating systems uses a text editor to edit a configuration *file*, which is like a string of bytes representing text characters which in turn represent various parameters for whatever is being configured, and which can be reconfigured with any application capable of editing such an arcane format, such as the venerable text editor, which if you're not supplying with your OS then I can tell you the IT department will be smashing the virtual disks on which it is supplied out of frustration.

For all things (including programming) you only ever need a text editor for cases where the designer/programmer was too lazy to do their job and provide a solution that isn't crap. If I allowed antiquated plain text puss (and quite frankly, I can't see a reason for a text editor to exist at all on my OS) then it'd mean implementing a parser and dealing with parsing errors (typos, etc) while trying to configure video (and not when user is entering the information); and it would end up being at least as complicated as a dialog box (if not worse).

If the IT department get annoyed, it'll be because I made their jobs too easy (so easy that half will be redundant and the other half will be reclassified as "unskilled labour" and will be working for minimum wage).

onlyonemac wrote:And you don't have to cripple anything with the video drivers; it's up to them what they do with the information, but quite frankly changing the resolution "on the fly" to meet frame rate limitations is the stupidest thing ever because even today monitors take a few milliseconds to sync with a new resolution and during that time their output is undefined (and may consist of a frozen frame, a black screen, or flicker). If you're seriously planning on changing the monitor resolution on such an ad-hoc basis, then quite frankly you can forget about anyone ever using your OS for more than a few minutes because they will get very frustrated (and by the way the correct way to handle frame rate guarantees is to either drop frames or lower the *renderer* resolution, not the *video output* resolution).

Like I already explained, it would only reduce the renderer resolution for brief periods of "too much overhead", and would only reduce the video output resolution for prolonged "too much overhead" (and only if/when there's no user activity for 5+ minutes). For brief periods of "too much overhead" it wouldn't change output resolution (and would adjust renderer resolution, impostor detail, rendering distance, lighting quality, etc).

Like I already explained, lowering the renderer resolution (when rendering overhead is too high) means that the renderer now has the additional overhead of scaling the resulting image up (when rendering overhead is too high), and has to lower the renderer resolution even more to compensate for the additional overhead of scaling, where "even lower renderer resolution" is worse. By making the monitor do the scaling "for free" there's less total overhead for the video driver/renderer, so the rendering resolution doesn't need to be reduced as much, so the resulting graphics are better.

Note that for existing software (mostly games because real-time 3D has only been around since last century and is therefore too new for "modern" GUIs) the user is given settings that are impossible to set correctly because they're static and can't cope with dynamically changing conditions. They end up being forced to compromise between "poor frame rate for complex scenes" and "poor frame quality for simple scenes". It's incredibly stupid and it's caused by "variable frame rate, fixed quality". The point of "fixed frame rate, variable quality" is to avoid the need to force users to make the compromise, and let them have "best quality achievable for each individual frame despite dynamically changing conditions".

Note: "fixed frame rate, variable quality" isn't quite the right name for it any more. It was the right name when displays had a fixed frame rate; but recently there's been attempts to change that (Nvidia's proprietary "G-Sync", and AMD's "FreeSync" that was adopted by VESA). With these technologies it's more appropriate to call it "fixed minimum frame rate, variable quality".

onlyonemac wrote:Finally, I've told you I don't know how many times that the documentation can be (and should be) as simple as "The 'resolution' parameter specifies the default monitor resolution" and if people can't read English they can run that through Google translate.

Which, as I've said, is inadequate because there's an almost infinite number of video mode timings that match any specific resolution, with at least 4 "common" timings (at various refresh rates, with and without "reduced blanking") to choose from; and this is important if you want it to be reliable (rather than merely "works by accident if you're lucky").

Your "if people can't read English" statement is pure arrogance. If anything, the OS should default to Mandarin (as there's over twice as many people using Mandarin than the second most common language, where the second most common language is Spanish and not English). English is only preferred by a minority (5.52% of the world's population). Note: This is all based on Wikipedia's page.

onlyonemac wrote:

Brendan wrote:My prediction is that (when your OS is finished) the OS won't work at all on 25% of computers (where UEFI doesn't support text mode), won't support graphics modes for 75% of computers (because BIOS will be long dead and you can't change video modes without a native video driver after boot on UEFI systems, and there won't be enough native video drivers), 33% of people won't be able to start a graphics session (because it needs a key-combination, and they're using a tablet with an "on touch screen" keyboard that doesn't work without graphics), and 50% of people will delete the OS without ever finding out there's a graphical session because they can't read English and can't understand anything on your "ASCII only" screen.

Perhaps I actually care about making something that works *now* and that can be developed *now* (try developing a hobby OS on one of those "closed" touchscreen devices that are available today and you'll see what I mean) rather than something that's designed to work on any computer available in 20 years time but which I can't enjoy hacking around with on my old PC now (and wasting time implementing all sorts of UEFI and video driver crap when I could rather be working on the core concepts that make up my OS and writing the code to implement them). For me, OSdev is not about "let me try to make something that's better than the rest of the world and will work on computers for the next 50 years" but rather a project to explore new ideas in operating system design and a framework for further experimentation.

Yes; our goals are different - you're trying to write something that will be obsolete before it's finished, while I'm not. That's fine in general; until you try to convince me that your "designed to be obsolete before it's finished" ideas are appropriate for my OS.

onlyonemac wrote:In your case, stop trying to run monitors at resolutions that they only implement to avoid "mode not supported" errors when some idiot sets the wrong resolution, and claiming that these resolutions are acceptable for everyday use. As far as I know there's no standard that even says how monitors should handle non-native resolutions and even if there is manufacturers are probably less likely to follow it than they are to follow EDID standards and if they don't follow EDID standards then don't expect them to follow any other standards, so GIVE USERS/ADMINISTRATORS A FUCKING CONFIGURATION OPTION.

If I spent 2 entire weeks trying to convince you to ram a whole pineapple up your butt for no good reason at all; do you think if I typed in capital letters you'd suddenly change your mind and decide it's a good idea? I will only ever provide a configuration option if I'm convinced it's a good idea for my OS. You have consistently failed to provide any evidence that suggests it might be a good idea. Your personal opinion and/or insistence is not evidence.


Cheers,

Brendan

Hi,

onlyonemac wrote:

Brendan wrote:There's so many different reasons why graphics on Linux is "less than good" (especially ancient Linux that was around in the "CRT era" - it has improved since) that it's impossible for me to determine how your problem relates to anything. Note that I do vaguely remember trying to get Linux to work in the 1990s, and Xorg defaulting to a hideous video mode that abused VGA registers to get a "800*600 with 16 colours", where the refresh rate was so bad (due to relying on VGA's pixel clock, which only goes up to about 30 MHz) that it was like it was designed specifically to cause seizures. Of course it's likely that your problem is different (and isn't the same as the "Xorg didn't use auto-configuration and had bad default configuration" problem that I remember).

This was 2002-era hardware, and it still confuses the graphics auto-configuration in current (as of last year) Linux distros into running the monitor at the wrong resolution (note that Linux hasn't used Xorg to configure the graphics hardware in a long time; these days the kernel configures the hardware and gets it wrong because of the exact same incorrect data from the monitor that caused Xorg to get it wrong when I first tried Linux on that system, but the Linux kernel accepts a bootloader parameter to override the auto-configuration with the correct resolution, which always fixes the problem for me because I know what the monitor's correct resolution is (and if I didn't then I could try different values until I get one that looks right, and if I get a "mode not supported" error in the process then I can hit the reset switch, enter the GRUB configuration while the system is still in a text mode, and change the parameter)).

As I suspected; for my OS this would only require a correct "monitor description" file (where OS uses monitor's PnP ID to choose the "monitor description" file); and only needs end user configuration on Linux because Linux isn't good enough (in comparison).


Cheers,

Brendan

Brendan wrote:

onlyonemac wrote:

Brendan wrote:Your "some" is zero monitors, plus a 2 TVs where one would get the native resolution and one won't and all of them will be 20 years old before the OS is released.

Lie. I don't care how old it is, but I have such a monitor in good working order and in regular use until I couldn't see it anymore sitting approximately one and a half meters away at my 10 o'clock.

No, you don't.

You might have a monitor that gives incorrect video mode timings from its EDID (which can be trivially worked around via. my "monitor description" files); and you have a monitor that gives correct video mode timings but incorrect PnP ID (which can be trivially worked around by not having a "monitor description" file to force the OS to use the EDID); and you might have a monitor where the EDID is perfectly correct (but Linux was broken and you felt like blaming the monitor).

There's no point arguing this until you tell me what data you want from the monitor and how to get it, otherwise we'll never know what's wrong with the monitor. But despite you seeing this as an opportunity to have another dig at Linux, I can tell you that it is not Linux's fault because Haiku did the same thing. There is clearly *something* wrong with the monitor.

Brendan wrote:In that post I measured (with a ruler) the physical font size (in millimetres) that I do use (from the text editor I use for programming) as a typical/representative font size; and then calculated/estimated the resolution and/or monitor size that would be needed to avoid "too blurry to read" text (and for "nice clear text") for that one specific representative font size, to show (using mathematics based on factual evidence as opposed to your "incessant barrage of unfounded whining") that your "too blurry to read" myth is nonsense for everything that will matter; including the 2 most common resolution that are in use today (based on Steam's latest hardware survey) and the resolutions that are likely to be in use (based on extrapolating statistical data from Steam's surveys) when the OS is released.

Perhaps in your particular mathematical fantasy world the "too blurry to read" thing is a "myth", but from experience I know that I have dealt with such situations on multiple occasions with multiple monitors running at non-native resolutions.

Brendan wrote:

onlyonemac wrote:The fact that you have to hack the video drivers makes me think that your driver architecture has no way to pass parameters to drivers when they are loaded, which sounds very short-sighted to me.

The device manager provides information obtained via. auto-detection from PCI (IRQ, BARs) when starting the device driver. Device drivers may store and track information for maintenance purposes (e.g. hours in service, mean time between failures, etc) and report this information to a maintenance utility framework. Video drivers report information back to "session manager" (or "station manager" or "user interface manager" or whatever I decide to call it - I really haven't found a good name for it yet) about monitor details it auto-detected (so that "session manager" can coordinate things, like handling user login when a monitor comes online); plus feedback (from video driver to "session manager") from every frame rendered to allow multi-monitor HDR and multi-monitor focus to work. Then there's "accessibility" information from user's profiles (colour blindness for hue shifting/compensation purposes, photosensitive epilepsy for flash limiting purposes, etc) sent from "session manager" to all video cards/monitors being used by that user as part of user login. Of course on top of that is the graphics data itself going to the video driver describing what frame/s should contain.

Basically there's plenty of information going in all directions; but nothing originating from any user (including admin) to any specific video driver.

It's one extra step in your driver architecture: when the device manager loads the device driver from the boot server (I gather that the drivers are being loaded over a network?) then it passes the auto-detected information along with the request for the driver, and the server then passes the parameters back to use when initialising the driver. Then, if the server needs to, it can alter the parameters before passing them back if needed, such as if the admin has said "workstations with ID numbers 452, 523, and 789 should override the monitor resolution with <insert monitor resolution here>." and the server will alter the parameter before passing the value back.

Brendan wrote:If the IT department get annoyed, it'll be because I made their jobs too easy (so easy that half will be redundant and the other half will be reclassified as "unskilled labour" and will be working for minimum wage).

If the IT department gets annoyed, it'll be because you restricted their configuration choices and forced them to use restrictive GUI configuration utilities. I can cite three Windows administrators who have expressed frustration on unrelated occasions with Windows's restrictive GUI configuration. Quite simply, GUI configuration will either restrict the available choices or have a ridiculously complicated interface; text-based configuration allows for a theoretically infinite number of configuration options without complicating the interface.

Brendan wrote:By making the monitor do the scaling "for free" there's less total overhead for the video driver/renderer, so the rendering resolution doesn't need to be reduced as much, so the resulting graphics are better.

So let's just assume that the monitor will scale the picture in a particular way, even though there's no standard for this.

Other than that, your "variable quality" idea does sound good, so you don't need to justify it to me, but keep it to changing just the renderer resolution; if one upscaling operation at the end of each rendering cycle is too much overhead, then you seriously need to improve the performance of your scaling algorithm - you'll be using that algorithm a lot, and one extra upscaling operation should be negligible in times when resources are tight.

Brendan wrote:Which, as I've said, is inadequate because there's an almost infinite number of video mode timings that match any specific resolution, with at least 4 "common" timings (at various refresh rates, with and without "reduced blanking") to choose from; and this is important if you want it to be reliable (rather than merely "works by accident if you're lucky").

I still have never needed to enter refresh rates and blanking periods, but whatever, include those then if you think they're necessary. You still don't need to say what they all mean; you can just say something like "parameter takes four values describing monitor: horizontal resolution, vertical resolution, vertical refresh rate, blanking period" or whatever you think is necessary and let the person doing the configuration do their own research if they care enough about configuring their monitor.

Brendan wrote:Your "if people can't read English" statement is pure arrogance. If anything, the OS should default to Mandarin (as there's over twice as many people using Mandarin than the second most common language, where the second most common language is Spanish and not English). English is only preferred by a minority (5.52% of the world's population). Note: This is all based on Wikipedia's page.

Then write it in whatever language you want; I was just using English as an example.

Brendan wrote:You have consistently failed to provide any evidence that suggests it might be a good idea. Your personal opinion and/or insistence is not evidence.

I have provided evidence. You have just chosen to ignore it.

Hi,

onlyonemac wrote:There's no point arguing this until you tell me what data you want from the monitor and how to get it, otherwise we'll never know what's wrong with the monitor. But despite you seeing this as an opportunity to have another dig at Linux, I can tell you that it is not Linux's fault because Haiku did the same thing. There is clearly *something* wrong with the monitor.

Every existing OS that I know of just uses whatever video mode timings that EDID says the monitor supports; typically with a strong preference for whatever EDID's first "detailed timing descriptor" says (which normally indicates the best video mode timing for the monitor - e.g. the native resolution at the best refresh rate).

There's 4 possible cases:

• EDID's PnP ID is unique and EDID's video timings are correct (about 98% of monitors): In this case the auto-configuration in existing OSs works perfectly (and the same for my OS)
• EDID's PnP ID is unique but EDID's video timings are wrong (about 1.99% of monitors): In this case the auto-configuration in existing OSs fails. My OS works around this problem by using the monitor's PnP ID to find a "display info" file (that can be corrected by OS developers and provided to users as part of the OS, in the same way device drivers are) if/when necessary, so that auto-configuration can work perfectly for normal users of my OS (even though auto-configuration won't work for existing OSs). It's extremely likely that this is the problem with your monitor.
• EDID's PnP ID is not unique and EDID's video timings are correct (about 0.01% of monitors): In this case the auto-configuration in existing OSs works perfectly. For my OS (assuming there's deliberately no "display info" file) the auto-configuration only works as well as it does in existing OSs (e.g. without the additional information I put in "display info" files that isn't present in EDID, like the display's max. luminance, display shape, more accurate video mode timing preferences, additional video timings that EDID doesn't report, etc). As far as I know this case is limited to about 5 monitors made by Sony in the late 1990s.
• EDID's PnP ID is not unique and EDID's video timings are also wrong (about 0.00% of monitors): In this case the auto-configuration in existing OSs fails; and the auto-configuration in my OSs fails. This is the only case where auto-configuration in my OS fails. As far as I know this case is limited to 2 TVs (and zero monitors) that were manufactured by Syntax-Brillian Corporation in 2005.

To determine exactly what the problem is for your monitor, someone would need to examine/decode the EDID and compare it to the monitor's actual specs. If it's an old CRT monitor it's unlikely that anyone will be able to find the specs (and there's also a possibility that the specs, if found, are wrong). This means someone might have to resort to "exhaustive trial and error" (using something capable of generating video mode timings that the monitor doesn't say it supports) to figure out what it actually does supports (possibly made slightly easier if the monitor's max. horizontal and vertical frequencies are written on the back of the monitor, which was common practice years ago). Note that for some old CRTs there's a possibility that exceeding its max. horizontal or vertical frequencies can cause hardware damage.

onlyonemac wrote:Perhaps in your particular mathematical fantasy world the "too blurry to read" thing is a "myth", but from experience I know that I have dealt with such situations on multiple occasions with multiple monitors running at non-native resolutions.

From your extensive experience using the graphics in my OS (especially the software renderer that hasn't been written yet); can you tell me anything about performance? I would very much like to know; because software rendering is always expensive (and because I'm doing things most renderers don't), and it could save me a lot of work if you told me how it performs before I start implementing it.

I'd also like to know how I implemented mouse support - when you move the mouse, does the camera rotate, or does the camera stay stationary and a mouse pointer move, or did I do a hybrid scheme (where camera rotates if mouse pointer gets close to the edge of the screen), or did I have 2 different modes (camera rotates in one mode, pointer moves in another mode)? This is one of the things I keep changing my mind about (I want "mouse causes camera to rotate" like in 3D games, but it'd be disorienting for clicking buttons in menus and toolbars, and awkward for selecting text for copy&paste).

onlyonemac wrote:

Brendan wrote:Basically there's plenty of information going in all directions; but nothing originating from any user (including admin) to any specific video driver.

It's one extra step in your driver architecture: when the device manager loads the device driver from the boot server (I gather that the drivers are being loaded over a network?) then it passes the auto-detected information along with the request for the driver, and the server then passes the parameters back to use when initialising the driver. Then, if the server needs to, it can alter the parameters before passing them back if needed, such as if the admin has said "workstations with ID numbers 452, 523, and 789 should override the monitor resolution with <insert monitor resolution here>." and the server will alter the parameter before passing the value back.

Sorry - I should've been more precise I guess. It's a "peer to peer distributed" OS, not a "client server distributed" OS. There isn't one server (or "one single point of failure") for anything. When a file (e.g. a device driver's executable file) is requested it's more like "Hey, who has the most recent version of <filename>?". There is no auto-detected information with the request (in the same way that "open()" on POSIX OSs doesn't include auto-detected information). From the replies the computer determines which computer actually has the most recent version (and if 2 or more have the most recent version, which one is closest/fastest) and downloads it from wherever it happens to be.

For video drivers; one process ("device manager") determines which resources (IO ports, memory mapped IO areas, IRQs) the device uses; then (using PCI configuration space "vendor ID and product ID" information) determines which executable file the device driver should be and asks kernel to start that executable file. If/when that works "device manager" sends a startup message to the driver to tell it which resources it can use, and also tells another process ("session manager") that a video driver was started. The video driver does some initialisation and contacts "session manager", and tells "session manager" that it is up and running/usable.

If admin was allowed to screw everything up for no sane reason; you'd probably have an additional file that describes what the admin wants done wrong, where "device manager" has to load that special file, sanity check/decode it (and report errors if any) and extract the information for the video card, and pass that (in conjunction with the resources the driver should use) to the driver when the driver is started. Of course if the monitor is plugged in somewhere else, or if the video card is shifted to a different slot (and no longer matches the "PCI bus:device:function:monitor" info in the special file; then the "misconfiguration" would fail and the monitor would actually work properly despite admin's attempt to screw everything up. However; if the monitor is replaced the OS ("device manager") won't know so it'd apply the old misconfiguration to the new monitor, and the admin would successfully screw up the new monitor as badly as they screwed up the old monitor.

onlyonemac wrote:

Brendan wrote:If the IT department get annoyed, it'll be because I made their jobs too easy (so easy that half will be redundant and the other half will be reclassified as "unskilled labour" and will be working for minimum wage).

If the IT department gets annoyed, it'll be because you restricted their configuration choices and forced them to use restrictive GUI configuration utilities. I can cite three Windows administrators who have expressed frustration on unrelated occasions with Windows's restrictive GUI configuration. Quite simply, GUI configuration will either restrict the available choices or have a ridiculously complicated interface; text-based configuration allows for a theoretically infinite number of configuration options without complicating the interface.

I agree - Windows would be much much better if there was no configuration (no GUI configuration and no plain text configuration).

However; if you must have configuration then "flexible/non-restrictive GUI configuration" is better than "flexible/non-restrictive plain text syntax errors and bloated manual"; and "inflexible/restrictive GUI configuration" is better than "inflexible/restrictive plain text syntax errors and bloated manual".

onlyonemac wrote:

Brendan wrote:By making the monitor do the scaling "for free" there's less total overhead for the video driver/renderer, so the rendering resolution doesn't need to be reduced as much, so the resulting graphics are better.

So let's just assume that the monitor will scale the picture in a particular way, even though there's no standard for this.

I didn't think of this during my research. I've added a "scaling method" field to my OS's "display info" file format now.

onlyonemac wrote:Other than that, your "variable quality" idea does sound good, so you don't need to justify it to me, but keep it to changing just the renderer resolution; if one upscaling operation at the end of each rendering cycle is too much overhead, then you seriously need to improve the performance of your scaling algorithm - you'll be using that algorithm a lot, and one extra upscaling operation should be negligible in times when resources are tight.

It's going to take a lot of "trial and error" to determine which things to adjust under which conditions to get the best compromises.

Because everything is 3D, most scaling is "vertex scaling" and not "pixel scaling" - the only thing I can think of is downscaling textures when they're loaded (not when they're used) to generate mipmaps, but that's a special case (always halving).

onlyonemac wrote:

Brendan wrote:Which, as I've said, is inadequate because there's an almost infinite number of video mode timings that match any specific resolution, with at least 4 "common" timings (at various refresh rates, with and without "reduced blanking") to choose from; and this is important if you want it to be reliable (rather than merely "works by accident if you're lucky").

I still have never needed to enter refresh rates and blanking periods, but whatever, include those then if you think they're necessary. You still don't need to say what they all mean; you can just say something like "parameter takes four values describing monitor: horizontal resolution, vertical resolution, vertical refresh rate, blanking period" or whatever you think is necessary and let the person doing the configuration do their own research if they care enough about configuring their monitor.

I've never needed to enter any of them (including resolution) to work around problems with monitors; only to work around bad software (either bad auto-configuration, lack of resolution independence, or lack of "fixed frame rate, variable quality").


Cheers,

Brendan

Brendan wrote:Sorry - I should've been more precise I guess. It's a "peer to peer distributed" OS, not a "client server distributed" OS. There isn't one server (or "one single point of failure") for anything. When a file (e.g. a device driver's executable file) is requested it's more like "Hey, who has the most recent version of <filename>?". There is no auto-detected information with the request (in the same way that "open()" on POSIX OSs doesn't include auto-detected information). From the replies the computer determines which computer actually has the most recent version (and if 2 or more have the most recent version, which one is closest/fastest) and downloads it from wherever it happens to be.

For video drivers; one process ("device manager") determines which resources (IO ports, memory mapped IO areas, IRQs) the device uses; then (using PCI configuration space "vendor ID and product ID" information) determines which executable file the device driver should be and asks kernel to start that executable file. If/when that works "device manager" sends a startup message to the driver to tell it which resources it can use, and also tells another process ("session manager") that a video driver was started. The video driver does some initialisation and contacts "session manager", and tells "session manager" that it is up and running/usable.

Perhaps then the client that is starting up could, in addition to asking for the most recent version of the driver, ask for the most recent version of the administrator's configuration file? You could distribute this file in the same way that your drivers are distributed, and then leave it up to the "device manager" to apply the relevant configuration options to each driver through a parameter passed to the driver. Then, for example, your video driver could say "I've been told to use the video card with this ID (or however you're referring to each video card), and there's no resolution data in my parameters so I'll auto-detect the resolution and then initialise the card" or it could say "I've been told to use the video card with this ID, and there is resolution data in my parameters so I'll perform a sanity check (make sure that the numbers are in fact positive, numeric values or whatever sanity check you feel is appropriate) so I'll initialise the card with this resolution".

Brendan wrote:If admin was allowed to screw everything up for no sane reason; you'd probably have an additional file that describes what the admin wants done wrong, where "device manager" has to load that special file, sanity check/decode it (and report errors if any) and extract the information for the video card, and pass that (in conjunction with the resources the driver should use) to the driver when the driver is started. Of course if the monitor is plugged in somewhere else, or if the video card is shifted to a different slot (and no longer matches the "PCI bus:device:function:monitor" info in the special file; then the "misconfiguration" would fail and the monitor would actually work properly despite admin's attempt to screw everything up. However; if the monitor is replaced the OS ("device manager") won't know so it'd apply the old misconfiguration to the new monitor, and the admin would successfully screw up the new monitor as badly as they screwed up the old monitor.

You don't need to be sarcastic. Quite why you think that an admin setting a monitor that's running at a non-native resolution to run at the native resolution is "screwing up" I have no idea. I can only assume that you are either conceited or deluded - quite possibly both.

Brendan wrote:

onlyonemac wrote:

Brendan wrote:If the IT department get annoyed, it'll be because I made their jobs too easy (so easy that half will be redundant and the other half will be reclassified as "unskilled labour" and will be working for minimum wage).

If the IT department gets annoyed, it'll be because you restricted their configuration choices and forced them to use restrictive GUI configuration utilities. I can cite three Windows administrators who have expressed frustration on unrelated occasions with Windows's restrictive GUI configuration. Quite simply, GUI configuration will either restrict the available choices or have a ridiculously complicated interface; text-based configuration allows for a theoretically infinite number of configuration options without complicating the interface.

I agree - Windows would be much much better if there was no configuration (no GUI configuration and no plain text configuration).

I'm talking about people getting annoyed and Windows's restrictive configuration due to using GUI configuration utilities, and that they would much rather there was some text-based configuration for advanced users. Furthermore, you know that's what I mean so don't pretend that you don't just so that you can try to make me think that you're agreeing with me.

Brendan wrote:It's going to take a lot of "trial and error" to determine which things to adjust under which conditions to get the best compromises.

Because everything is 3D, most scaling is "vertex scaling" and not "pixel scaling" - the only thing I can think of is downscaling textures when they're loaded (not when they're used) to generate mipmaps, but that's a special case (always halving).

OK, so maybe you won't be using a raster scaling algorithm that much, but I still don't think the extra overhead justifies lowering the monitor resolution as a hackish way to improve framerates.

Hi,

onlyonemac wrote:

Brendan wrote:If admin was allowed to screw everything up for no sane reason; you'd probably have an additional file that describes what the admin wants done wrong, where "device manager" has to load that special file, sanity check/decode it (and report errors if any) and extract the information for the video card, and pass that (in conjunction with the resources the driver should use) to the driver when the driver is started. Of course if the monitor is plugged in somewhere else, or if the video card is shifted to a different slot (and no longer matches the "PCI bus:device:function:monitor" info in the special file; then the "misconfiguration" would fail and the monitor would actually work properly despite admin's attempt to screw everything up. However; if the monitor is replaced the OS ("device manager") won't know so it'd apply the old misconfiguration to the new monitor, and the admin would successfully screw up the new monitor as badly as they screwed up the old monitor.

You don't need to be sarcastic. Quite why you think that an admin setting a monitor that's running at a non-native resolution to run at the native resolution is "screwing up" I have no idea. I can only assume that you are either conceited or deluded - quite possibly both.

The chance of the auto-configuration getting it wrong is extremely low (e.g. less than the chance of admin being hit by lighting). The chance of the admin getting it wrong is higher; either due to mistakes/typos, difficulty in finding the information needed (given that they can't just get it from EDID and it's not published in monitor's specs), or because the admin actually managed to get it right once upon a time but people shifted/changed monitors around 4 times since then and it's too inflexible to cope with that, or because admin simply has better things to do with their time and couldn't be bothered and set every single monitor to "1024*768" to save time.

onlyonemac wrote:

Brendan wrote:I agree - Windows would be much much better if there was no configuration (no GUI configuration and no plain text configuration).

I'm talking about people getting annoyed and Windows's restrictive configuration due to using GUI configuration utilities, and that they would much rather there was some text-based configuration for advanced users. Furthermore, you know that's what I mean so don't pretend that you don't just so that you can try to make me think that you're agreeing with me.

Why have you assumed that just because Window's GUI configuration utilities are restrictive in some way; that my GUI configuration utilities would also be restrictive in some way? What makes you think some restrictions (e.g. the inability to save the file when there's obvious errors that make it useless) aren't beneficial?

onlyonemac wrote:

Brendan wrote:It's going to take a lot of "trial and error" to determine which things to adjust under which conditions to get the best compromises.

Because everything is 3D, most scaling is "vertex scaling" and not "pixel scaling" - the only thing I can think of is downscaling textures when they're loaded (not when they're used) to generate mipmaps, but that's a special case (always halving).

OK, so maybe you won't be using a raster scaling algorithm that much, but I still don't think the extra overhead justifies lowering the monitor resolution as a hackish way to improve framerates.

You're saying that it's better to do something in software (running on CPU/s that are already overloaded) when there's a purpose built "scaling accelerator" built directly into silicon that's easy to use and doing nothing?

It's not a question of "if it's beneficial", it's only a question of "when it's beneficial".

Sadly, changing video modes (enabling/disabling/reconfiguring the monitor's built in "scaling accelerator") causes the screen to flicker (e.g. "black screen" for far too long while monitor adjusts to the new resolution); so changing video modes before every single frame can't work.


Cheers,

Brendan

Brendan wrote:The chance of the auto-configuration getting it wrong is extremely low (e.g. less than the chance of admin being hit by lighting). The chance of the admin getting it wrong is higher; either due to mistakes/typos, difficulty in finding the information needed (given that they can't just get it from EDID and it's not published in monitor's specs), or because the admin actually managed to get it right once upon a time but people shifted/changed monitors around 4 times since then and it's too inflexible to cope with that, or because admin simply has better things to do with their time and couldn't be bothered and set every single monitor to "1024*768" to save time.

No admin would set every monitor to 1024x768. If people complain about the resolution of their monitors, the admin will either try to fix it (and know how to avoid messing it up) or tell them that they're not going to fix it. If they decide to try to fix it, they will try to find the correct resolution either by finding specifications or by experiment, and if they fail to find the correct resolution they will say "sorry, we can't fix it".

And it's your fault if your OS is so inflexible that it just assumes that a particular configuration is correct without checking what hardware is attached. So you could say something like "as long as the EDID of the attached monitor remains the same, apply the resolution specified in the configuration file".

Brendan wrote:Why have you assumed that just because Window's GUI configuration utilities are restrictive in some way; that my GUI configuration utilities would also be restrictive in some way?

Because it is inherent in the design of GUIs that only a limited range of options can be presented to the user (what fits on the screen, and what can be easily navigated with a mouse; long menus for example are impractical).

Brendan wrote:What makes you think some restrictions (e.g. the inability to save the file when there's obvious errors that make it useless) aren't beneficial?

I never said that that wasn't beneficial; all I said was that if you're complaining about having to perform error-checking on every configuration option when the configuration file is saved, then don't bother because we've never had error-checking of that form on configuration files and people who frequently deal with configuration files are practiced at checking for errors themselves.

Brendan wrote:

onlyonemac wrote:OK, so maybe you won't be using a raster scaling algorithm that much, but I still don't think the extra overhead justifies lowering the monitor resolution as a hackish way to improve framerates.

You're saying that it's better to do something in software (running on CPU/s that are already overloaded) when there's a purpose built "scaling accelerator" built directly into silicon that's easy to use and doing nothing?

Yes - because that "scaling accelerator" isn't purpose-built; it's purpose is to try to make a somewhat-usable picture out of an incorrect video signal, not to perform the last step of your software rendering for you. Besides, any modern graphics card should be able to upscale a raster in hardware, with a purpose-built piece of hardware designed for situations exactly like this (where you want to render at one resolution, but display at another). Your approach is hackish, which isn't a good idea for something that you're hoping to make a commercial project out of.

Let's look at a definition of the work "hackish" from the Jargon File:

1. Said of something that is or involves a hack.
2. Of or pertaining to hackers or the hacker subculture. See also true-hacker.

According to the first meaning, it is something that involves a hack. Let's look then at what a "hack" is:

1. n. Originally, a quick job that produces what is needed, but not well.
2. n. An incredibly good, and perhaps very time-consuming, piece of work that produces exactly what is needed.
3. vt. To bear emotionally or physically. "I can't hack this heat!"
<snip>

Again looking at the first meaning, it is "a quick job that produces what is needed, but not well". That's what you're doing here: you're performing a quick job (i.e. just changing the monitor resolution, instead of writing a scaling algorithm/using graphics card scaling hardware or some other more time-consuming (to implement) technique) that produces what is needed, but it doesn't do it well (because it is not the intended use of the tools that you are using to do it). Thus we can say that your design is hackish, and therefore a Bad Idea.