From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Russ Cox" To: 9fans@cse.psu.edu Subject: Re: [9fans] hardware acceleration MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20010214014018.3E196199D5@mail.cse.psu.edu> Date: Tue, 13 Feb 2001 20:40:09 -0500 Topicbox-Message-UUID: 62e3fa92-eac9-11e9-9e20-41e7f4b1d025 because frankly, the install process is baroque. Besides the VESA problems (which I really would like to see done, but I've a thesis to write and currently don't even have a working Plan 9 terminal) what else could be improved? I'm always interested in ways to make it better. The hardware detection aspect is admittedly not as good as it could be, but that's a problem permeating the system rather than a shortcoming of the install process. Are there other inadequacies that stand out? How about writing it to drive off the serial port, and bypassing the screen altogether for some level of bootstrap? Others have done this (in text mode, which amounts to the same thing). The problem is that it's not a particularly usable system -- without rio, there's no functional equivalent of job control or even an interrupt key, so the result is a bit tough to use. But if you want to do it, the diffs are in the archives. I started to write a reply to the VESA discussion earlier this evening, in which I complained that VBE < 3.0 (by far the common case) needs a real-mode call to jumpstart it, and that would mean passing the info about graphics mode through the boot loaders. There's no room for font data and graphics code in ld.com, and I'd rather keep it out of 9load too. While writing this it occurred to me that we can probably defer the switch from text to graphics mode, so I canned the reply. Then again, if you want VBE 1.2, you need to do the graphics switch right away, and all the problems come back. I did a google search for XFree86 startup dumps and found that there were a huge number of VBE 1.2 (non-VBE 2.0) cards still out there, so it seems reasonable to want to support them. An approach that works even for VBE 1.2 is to simulate the BIOS code rather than run it directly. The Alpha PC does this in firmware, I'm told. I wrote a 3000-line real mode x86 emulator that seems to do a decent job, and it keeps the x86 creepiness contained. The only problem is that the mode switch on my particular card makes some INT 15 calls to grub around PCI space, and simulating those in turn requires turning off interrupts, which I'd rather not do from user space. Answering the INT15 calls directly is probably enough to get the mode switches working, but I haven't gotten back to it. g% 8.out >> info signature: VESA version: 2.0 oem string: Diamond Mutlimedia. Savage4 [sic -rsc] capabilities: 8-bit-dac video modes: 0109 010a 012e 010e 010f 0131 0133 0134 0141 0143 0144 0151 0153 0154 0100 011d 011e 0101 0111 0112 0171 0173 0174 017c 017e 017f 0102 0103 0114 0115 0104 0105 0117 0118 0161 0163 0164 0106 0107 011a 011b 0120 0122 0124 0191 0193 0194 01a1 01a3 01a4 0136 0138 0139 total memory: 16777216 oem software rev: 1.1 vendor name: Diamond Multimedia Inc. product name: Stealth III Savage4 product rev: Rev C >> modeinfo 0x0139 mode attributes: supported color graphics linear bytes per scan line: 7680 resolution: 1920x1440 charsize: 8x16 1 planes, 32 bpp, 1 banks @ 0 kb each memory model 6 (direct) r8g8b8x8 r@16 g@8 b@0 x@24 directcolor: physptr: 0xE0000000 g% Russ