From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1O4WMx-0008MF-CJ for mharc-grub-devel@gnu.org; Wed, 21 Apr 2010 05:37:19 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O4WMt-0008Kt-SE for grub-devel@gnu.org; Wed, 21 Apr 2010 05:37:15 -0400 Received: from [140.186.70.92] (port=37339 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O4WMe-0008CB-Vl for grub-devel@gnu.org; Wed, 21 Apr 2010 05:37:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O4WMd-0005Px-67 for grub-devel@gnu.org; Wed, 21 Apr 2010 05:37:00 -0400 Received: from mail-bw0-f225.google.com ([209.85.218.225]:50246) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O4WMc-0005Pg-4H for grub-devel@gnu.org; Wed, 21 Apr 2010 05:36:59 -0400 Received: by bwz25 with SMTP id 25so6924448bwz.8 for ; Wed, 21 Apr 2010 02:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=ksH5qoWMPrWxXUn+4a99W4H2T8wOsbHS8QbvAs/R9/U=; b=VtsV+cQPj6XCtKtgfXef+71OYir013rkUXhhu9wUBceepKuvFEP4icpAQNu5FhYU1T w/CRZ+IFyANrtLKBE+yHjTbhPYM8v5liQfPx7qA9kCQ2317YFvG2elpgwY7aaUSlqQRY csrC8F5oQYCHsdz0VMNWliTZUNsJz46IbAchw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=ZUK2s0va03o1VjChWQqmxDLfBtLBHcaHzTCPjidI9bF7MY+6x/OAFBwp8N6RoLNDJ0 s6zLn247Z2um+egjrVzLE3u2tVHfGoLKQVWiZAZbnrNJ8GN/5RWE426CtZAbimipNIm3 W1dGacP1a8DmmxyKCW5bBAHI+rf1pdMtuHY3o= Received: by 10.204.163.129 with SMTP id a1mr6776930bky.144.1271842616995; Wed, 21 Apr 2010 02:36:56 -0700 (PDT) Received: from debian.bg45.phnet (public-docking-hg-3-197.ethz.ch [129.132.246.197]) by mx.google.com with ESMTPS id 13sm4034460bwz.15.2010.04.21.02.36.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Apr 2010 02:36:55 -0700 (PDT) Message-ID: <4BCEC736.9040409@gmail.com> Date: Wed, 21 Apr 2010 11:36:54 +0200 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: <4BB73D72.6080806@gmail.com> <4BBF6261.6070109@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigBEF6740420D19E3C61976770" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Multiboot2 Suggestions X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:37:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBEF6740420D19E3C61976770 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brendan Trotter wrote: >>> I currently use "PC speaker" as my "critical error notification >>> method" - it's about 15 instructions that use I/O ports only and >>> doesn't require memory allocations or anything else. I doubt setting >>> keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on >>> anything more than I/O ports. >>> >>> In comparison, my video setup code is around 64 KiB of code that >>> starts with trying to get EDID information from the monitor, filterin= g >>> a list of video modes (from VGA and/or VBE), allocating several MiB o= f >>> RAM for video buffers and font data, scaling font data, etc. If >>> there's a problem setting up the memory management it's all useless >>> and I fall back to the "critical error notification method" so the >>> user knows the OS failed to initialise something (e.g. couldn't >>> allocate several MiB of RAM). >>> >>> =20 >> If you use frmaebuffer info in mbi you can have basic video much faste= r. >> =20 > > I'm not planning to have any support for "basic video" (only "eye > candy video"). I don't support text modes either (and have no desire > to add support for text modes). > > I'm also wondering if a "primary monitor's EDID" tag could be added to > the multi-boot information. This tag would optional - if the boot > loader can't get the information, or if the boot loader doesn't even > try to get the information, then the boot loader can skip the EDID tag > (but the EDID information is easy to obtain from VBE and U/EFI if > you're writing "firmware specific" code). > > 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). > > =20 Perhaps it's better to just supply estimated DPI? >>> Alternatively, (for my OS) for headless systems; I use RTS/CTS and th= e >>> 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). >>> >>> =20 >> 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. >> =20 > > 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)". > > =20 If you put it this way it's configuration --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigBEF6740420D19E3C61976770 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAkvOxzYACgkQNak7dOguQgnNfQD/Yz7OMIaUxGb6WZBECfGkCloK +JyWi0jdIxF3o9KWaxEA/jaaLqtMkszxPx+tTRg2aV59xjcMHNK6MoY6brxT5ZDU =hsIx -----END PGP SIGNATURE----- --------------enigBEF6740420D19E3C61976770--