Hi, 2010/4/21 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>: > Brendan Trotter wrote: >> Where possible, I currently use the EDID information to determine the >> physical size of the monitor (e.g. "520 mm wide and 320 mm high"), and >> then scale font data, etc to suit; so that everything is the same >> shape regardless of the monitor's aspect ratio, so that things aren't >> too small on a small screen or too big on a large screen, and so that >> everything looks the same in all video modes (resolution independent). >> For an example, for a 1600*1200 video mode on a small 4:3 monitor I >> might end up with 32*42 characters, for a 800*600 video mode on the >> same small 4:3 monitor I might end up with 16*21 characters, and for a >> 800*600 video mode on a large 16:9 monitor I might end up with 8*19 >> characters; and in all of these cases I can draw a square box (that >> doesn't look like a rectangle in any case). >> >> > Perhaps it's better to just supply estimated DPI?
Would "100 DPI" be tall and narrow, or short and wide? If the boot loader supplied screen width and height (rather than EDID) it'd work; but obtaining the EDID and then extracting the width and height would probably be more work for the boot loader than just supplying the raw EDID data (and potentially less useful to the OS). >>>> Alternatively, (for my OS) for headless systems; I use RTS/CTS and the >>>> VT100 "identify" command to detect if anything is listening on the >>>> serial port (and if it's a terminal or something else). When nothing >>>> is listening on the other end the OS can't talk so it uses the PC >>>> speaker as a fallback (but continues monitoring the serial port). >>>> Basically if something goes wrong at any stage, the OS beeps, and the >>>> user can plug a terminal in afterwards to find out what went wrong >>>> (rather than having no idea what caused the problem, then connecting a >>>> terminal and rebooting to see if it happens again while they are >>>> watching). >>>> >>>> >>> I feel like here it's not anymore about present hardware or its state >>> but about user configuration. Generally for this type of parameters >>> command line is better suited. >>> >> >> It's about "what does the OS do when it needs to tell the user there's >> been a problem but can't talk to the user using the normal console/s >> for any reason (regardless of what the normal console/s are and >> regardless of what the reason/s may be)". >> >> > If you put it this way it's configuration Sigh. There's only 2 types of "user configuration". The first type is really "user preferences", where everything works regardless of which preferences the user has setup (or even if they haven't set any preferences). This sort of configuration is fine (as long as it's not too excessive or intrusive, it's a good thing). The second type of user configuration is "design failure"; where (due to bad design) the user is forced to tell software something, and the system can't work properly until/unless the user has been hassled. In all cases this sort of configuration is bad. Unfortunately, in a lot of cases it's unavoidable because the design failure was made by someone else. An example of this is the keyboard layout for PS/2 keyboards - software can't autodetect the keyboard layout due to design failures made by IBM several decades ago. Another example is figuring out if the firmware's time is UTC or local time (and which time zone). The goal is to minimise the total amount of "design failure configuration" for the system as a whole (not for any specific OS, or any specific piece of software). For an example, it'd probably be better if the firmware told all OSs which keyboard layout to use and if the user told the firmware which keyboard layout (so the user only needs to be hassled once when setting up the firmware, and not each time they install any OS). The same could be done with the time - the real time clock hardware could've been "always UTC" and maybe there could've been a "time zone" firmware setting. In both of these cases you're looking at "cascading design failure" - the original failure caused by the design of the hardware, with a secondary failure caused by the design of the firmware. One way to minimise "design failure configuration" is the use of known defaults for the expected case. For example, rather than the user being forced to tell software that the real time clock is UTC or local time, it might be reasonable for software to assume the clock is set to UTC unless the user tells it otherwise. That way, if most computers do use UTC then most users don't need to configure it. Now, let's consider a potential scenario. Someone writes a multi-boot compliant OS called "FooBarOS" (where "multi-boot compliant" does NOT mean "complaint with some specific version of GRUB" - it means it should work on any boot loader that supports multi-boot, whether it's GRUB or not). Someone else puts "FooBarOS" onto a bootable CD, along with GRUB and 3 other OSs (and a pretty menu, so the user can easily choose which OS they'd like to boot/install). A normal user downloads an image of this bootable CD from the internet and burns it onto a CD, then tries to boot "FooBarOS". "FooBarOS" starts but realises it can't talk to the user using the normal (video or serial) method or has some other problem before it's able to use the normal method. In this case, what does the author of "FooBarOS" do? Do they make "FooBarOS" ask the user (how??) if it is allowed to return some sort of error code to the boot loader? Do they use kernel parameters and hope the person who made the bootable CD knows enough (and cares enough) to get it right? Do they assume the OS can return to the boot loader with an error code and then blame someone else when their OS tries to return to the boot loader and crashes? Wouldn't it be nice to avoid the "design failure configuration" entirely, and just make the boot loader tell the OS if the OS is able to return to the boot loader or not? What about the PC speaker - can "FooBarOS" ask the user (how??) if it can/should use the PC speaker; or does the author of "FooBarOS" use some sort of configuration and let whoever made the CD stuff it up; or do they assume that the PC speaker can be used (even if the people who make the bootable CD are using the CD as a free promotional thing that's supplied with a range of computers that don't have a PC speaker)? For the PC speaker, the boot loader itself may not know if the computer supports a PC speaker or not - it's unavoidable "design failure configuration". However, the "design failure configuration" can be minimised - you could rely on the boot loader's default (so that most of the time nobody needs to configure anything), and if some sort of "don't use the PC speaker" setting must be made then it only needs to be made once for all of the OSs on the CD, not once for each OS (and not each time any of the OSs are booted). Cheers, Brendan _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
