Menu
▾
▴
linuxconsole-dev
|
From: Helge H. <hel...@ai...> - 2004-10-15 21:39:26
|
On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote: > Helge Hafting <hel...@ai...> wrote: > [...] > > Having video BOOT would be great, and please make it independent of > > the framebuffer drivers. > > Right now it is independent but I added a single line of code to the > Radeon driver to init the card prior to initing the rest of the driver. That's fine. What I meant, was please make it independent of the VESA framebuffer driver, because one might want to use an acellerated driver when one is available. > It can be done earlier than that inside fbmem.c, but I wasn't sure how to > set up the code so it would only POST each card as it is needed as I > don't want to bring up secondary controllers unless the user actually > wants this. > Selecting which cards to "boot" can probably be done with a kernel parameter? The default could be to bring up all cards except the one the bios brought up already. Wanting to _not_ bring up some cards seems to be the unusual case to me. > How does the framebuffer console system handle secondary controllers > right now? It seems from my look at the code that it only brings up the > primary and not the secondary? > The stock 2.6.x fbcon only use one framebuffer console. I use the ruby patch which supports multiple consoles. The ruby patch for 2.6.7 support multiple fbcons so you can have several keyboards attached to separate framebuffers thus supporting several users. (VT1-VT16 is the first kbd on the first fbcon, VT17-VT32 is the second kbd on the second fbcon, and so on.) The ruby patch for 2.6.8.1 is somewhat broken, and doesn't work with fbcon. It still support multiple keyboards and multiple framebuffers, so I can support several users with separate xservers but currently not gettys on separate fbcons. Note that soft-booting the "extra" video card in order to support a framebuffer driver is nice even if it doesn't attach to the console, because there is other software that can utilize a framebuffer. X is the most well-known of them. Helge Hafting |
|
From: Kendall B. <Ken...@sc...> - 2004-10-15 22:12:46
|
Helge Hafting <hel...@ai...> wrote: > On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote: > > Helge Hafting <hel...@ai...> wrote: > > > [...] > > > Having video BOOT would be great, and please make it independent of > > > the framebuffer drivers. > > > > Right now it is independent but I added a single line of code to the > > Radeon driver to init the card prior to initing the rest of the driver. > > That's fine. What I meant, was please make it independent of the > VESA framebuffer driver, because one might want to use an > acellerated driver when one is available. Oh, it already is. The VESA driver is not actually done yet so the only drivers using VideoBoot right now are the accelerated ones ;-) > > It can be done earlier than that inside fbmem.c, but I wasn't sure how to > > set up the code so it would only POST each card as it is needed as I > > don't want to bring up secondary controllers unless the user actually > > wants this. > > Selecting which cards to "boot" can probably be done with a kernel > parameter? The default could be to bring up all cards except the > one the bios brought up already. Wanting to _not_ bring up some > cards seems to be the unusual case to me. Not really. In many cases there may be a secondary controller on the system that is not wanted, such as when the user has an i915G or other chipset with integrated video but has plugged a different video card into the system. The integrated video can still be active so trying to bring it up may be problematic unless it is really wanted. > > How does the framebuffer console system handle secondary controllers > > right now? It seems from my look at the code that it only brings up the > > primary and not the secondary? > > The stock 2.6.x fbcon only use one framebuffer console. I use the > ruby patch which supports multiple consoles. The ruby patch for > 2.6.7 support multiple fbcons so you can have several keyboards > attached to separate framebuffers thus supporting several users. > (VT1-VT16 is the first kbd on the first fbcon, VT17-VT32 is the > second kbd on the second fbcon, and so on.) > > The ruby patch for 2.6.8.1 is somewhat broken, and doesn't work > with fbcon. It still support multiple keyboards and multiple > framebuffers, so I can support several users with separate xservers > but currently not gettys on separate fbcons. Cool. So this stuff is not yet in the official kernel trees. Is that going to happen or is the project to move the video out of the kernel going to happen first? > Note that soft-booting the "extra" video card in order to support a > framebuffer driver is nice even if it doesn't attach to the > console, because there is other software that can utilize a > framebuffer. X is the most well-known of them. Yes, but if you don't need a framebuffer console on the card then X or whatever can bring up the secondary controller from user space once the kernel has booted. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ |
|
From: Antonino A. D. <ad...@ho...> - 2004-10-16 00:41:10
|
On Saturday 16 October 2004 06:12, Kendall Bennett wrote: > Helge Hafting <hel...@ai...> wrote: > > On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote: > > > Helge Hafting <hel...@ai...> wrote: > > That's fine. What I meant, was please make it independent of the > > VESA framebuffer driver, because one might want to use an > > acellerated driver when one is available. > > Oh, it already is. The VESA driver is not actually done yet so the only > drivers using VideoBoot right now are the accelerated ones ;-) > If these get in (emulator with/without the video boot), I'm willing to modify the vesafb driver. Tony |
|
From: Paulo M. <pma...@gr...> - 2004-10-26 11:14:34
|
Antonino A. Daplas wrote:
> On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
>
>>Helge Hafting <hel...@ai...> wrote:
>>
>>>On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
>>>
>>>>Helge Hafting <hel...@ai...> wrote:
>>>
>>>That's fine. What I meant, was please make it independent of the
>>>VESA framebuffer driver, because one might want to use an
>>>acellerated driver when one is available.
>>
>>Oh, it already is. The VESA driver is not actually done yet so the only
>>drivers using VideoBoot right now are the accelerated ones ;-)
>>
>
>
> If these get in (emulator with/without the video boot), I'm willing to
> modify the vesafb driver.
Well, I played with the emulator last night to see if I could reduce the
code size, so that it would be easier to make it to the official kernel.
I only took ops.c and did some transformations, like using a single
function to make several operations based on the opcode, instead of a
separate function for each opcode, etc.[1]
This is the result. Before:
Size of stripped libx86emu.a: ~74kb
ops.c source code lines: 11682
ops.o .text size: 36136
ops.o .data: 1312
After:
Size of stripped libx86emu.a: ~57kb
ops.c source code lines: 5908
ops.o .text size: 19320
ops.o .data: 1280
If the same treatment is applied to ops2.c and prim_ops.c, I believe it
would be possible to have a functional emulator for about 32kb of kernel
code size, which seems pretty reasonable to me and could solve a lot of
problems.
The decrease in source code size also helps maintenance, since there is
not so much repeated code has it was before.
Of course, these changes are optimizing the emulator for code size, and
not execution speed. I haven't done any benchmarks to see if there is a
noticeable difference in speed.
[1] The worst offenders were actually constructions like:
FETCH_DECODE_MODRM(mod, rh, rl);
switch (mod) {
case 0:
...<some code>
addr = decode_rm00_address(rl);
...<some more code>
break;
case 1:
...<exactly the same code as above>
addr = decode_rm01_address(rl);
...<exactly the same code as above>
break;
case 2:
...<exactly the same code as above>
addr = decode_rm10_address(rl);
...<exactly the same code as above>
break;
case 3:
<diferent code to handle register-register ops>
break;
}
This could be easily changed to:
FETCH_DECODE_MODRM(mod, rh, rl);
if (mod < 3) {
...<some code>
addr = decode_rmXX_address(mod, rl);
...<some more code>
} else {
<diferent code to handle register-register ops>
}
simply by making a new decode_rmXX_address function that handles the mod
parameter. There were more than 20 of these, and some of them were
pretty big.
--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
|
|
From: Kendall B. <Ken...@sc...> - 2004-10-27 01:58:14
|
Paulo Marques <pma...@gr...> wrote: > Well, I played with the emulator last night to see if I could > reduce the code size, so that it would be easier to make it to the > official kernel. > > I only took ops.c and did some transformations, like using a > single function to make several operations based on the opcode, > instead of a separate function for each opcode, etc.[1] > > This is the result. Before: > > Size of stripped libx86emu.a: ~74kb > ops.c source code lines: 11682 > ops.o .text size: 36136 > ops.o .data: 1312 > > After: > > Size of stripped libx86emu.a: ~57kb > ops.c source code lines: 5908 > ops.o .text size: 19320 > ops.o .data: 1280 > > If the same treatment is applied to ops2.c and prim_ops.c, I > believe it would be possible to have a functional emulator for > about 32kb of kernel code size, which seems pretty reasonable to > me and could solve a lot of problems. Wow, that is great! > The decrease in source code size also helps maintenance, since > there is not so much repeated code has it was before. > > Of course, these changes are optimizing the emulator for code > size, and not execution speed. I haven't done any benchmarks to > see if there is a noticeable difference in speed. Did you get the latest code? I have been sick with the flu and I think I forgot to send you the latest code to play with. We should get you set up so you can merge your changes into our tree and then we can update the one in the X.org tree as well (Egbert Eich usually does that from our tree). Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ |
|
From: Paulo M. <pma...@gr...> - 2004-10-27 11:11:54
|
Kendall Bennett wrote: > Paulo Marques <pma...@gr...> wrote: > ..... >>If the same treatment is applied to ops2.c and prim_ops.c, I >>believe it would be possible to have a functional emulator for >>about 32kb of kernel code size, which seems pretty reasonable to >>me and could solve a lot of problems. > > > Wow, that is great! Thanks :) > >>The decrease in source code size also helps maintenance, since >>there is not so much repeated code has it was before. >> >>Of course, these changes are optimizing the emulator for code >>size, and not execution speed. I haven't done any benchmarks to >>see if there is a noticeable difference in speed. > > > Did you get the latest code? I have been sick with the flu and I think I > forgot to send you the latest code to play with. We should get you set up > so you can merge your changes into our tree and then we can update the > one in the X.org tree as well (Egbert Eich usually does that from our > tree). No, I didn't get the latest source (you did disapear for a while :) ). I started to work on the old source because: A - I really wanted to know if this could be done and what kind of improvements could be expected, even if the actual changes were thrown away in the end B - you said that only small bug fixes were made since this version, so I probably could diff the source I started from against the latest and do the same fixes to my latest source. One other thing, is there a simple way to test the emulator? I've been careful with the changes I did not to change the resulting behaviour of the emulator, but I can not _absolutely_ sure that I didn't break anything. It would be very good to try the emulator in a controlled environment. Anyway, I think I'll have some more time tonight, so probably tomorrow I'll have more information about the final code size. -- Paulo Marques - www.grupopie.com All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke (1729 - 1797) |
|
From: Kendall B. <Ken...@sc...> - 2004-10-27 19:52:56
|
Paulo Marques <pma...@gr...> wrote: > One other thing, is there a simple way to test the emulator? I've > been careful with the changes I did not to change the resulting > behaviour of the emulator, but I can not _absolutely_ sure that I > didn't break anything. It would be very good to try the emulator > in a controlled environment. Unfortunately the test code I wrote years ago is only for Open Watcom and uses inline assembler. It hasn't been used for some time and I am not sure if it works properly or not (I don't think it does right now). Plus we recently found out that it doesn't test everything, just the implementation of prim_ops.c. The only real way to test the emulator is to use it to emulate some code. We don't have any code we use on a regular basis to test it, but perhaps we should think about building a test suite for it. Usually we test it on Video BIOS ROM's, but that is painful because you have to switch video cards all the time. XFree86 and X.org do use the same code so it could be tested there, but once again it is only used for Video BIOS ROM stuff. Regards, --- Kendall Bennett Chief Executive Officer SciTech Software, Inc. Phone: (530) 894 8400 http://www.scitechsoft.com ~ SciTech SNAP - The future of device driver technology! ~ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X