So what we would like to find out is how much interest there might be
in
both an updated VESA framebuffer console driver as well as the code
for
the Video card BOOT process being contributed to the maintstream
kernel.
The BOOT stuff is very interesting. Currently, both my videocards
(in the same pc)
have nice hw-specific framebuffer drivers, but they require that
the card is initialized by the bios first and this only ever
happens to one of the cards. Xfree _can_ do the job, but way
too late for setting up the framebuffer device.
If there is interest, we would start out by first contributing the
core
emulator and Video BOOT code, and then work on building a better VESA
framebuffer console driver.
Having video BOOT would be great, and please make it independent
of the framebuffer drivers. I might want to try your vesa driver,
but I might also want to use the hw-accelerated chip specific driver
that happens to need an initialized video card.
Helge Hafting
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
So what we would like to find out is how much interest there might be
in
both an updated VESA framebuffer console driver as well as the code
for
the Video card BOOT process being contributed to the maintstream
kernel.
The BOOT stuff is very interesting. Currently, both my videocards
(in the same pc) have nice hw-specific framebuffer drivers, but
they require that the card is initialized by the bios first and
this only ever happens to one of the cards. Xfree _can_ do the
job, but way too late for setting up the framebuffer device.
Exactly.
quoted
If there is interest, we would start out by first contributing the
core
emulator and Video BOOT code, and then work on building a better VESA
framebuffer console driver.
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.
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.
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?
I might want to try your vesa driver, but I might also want to use
the hw-accelerated chip specific driver that happens to need an
initialized video card.
Yep, you could use either. In fact you could even use the VGA text
console driver on PowerPC and MIPS platforms provided the kernel
correctly sets up the proper VGA resource mappings (which many embedded
kernels do not do).
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! ~
On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
Helge Hafting [off-list ref] wrote:
[...]
quoted
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: Antonino A. Daplas <hidden> Date: 2004-10-15 21:53:49
On Saturday 16 October 2004 02:36, Kendall Bennett wrote:
Helge Hafting [off-list ref] wrote:
quoted
On 14-10-2004 21:02:36, Kendall Bennett wrote:
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?
By default, the first driver to initialize is used by the fb console. If
there are more than 1 fb driver, one can either use:
- con2fbmap
- the "fbcon=map:abcd" kernel boot option
Of course, the secondary card must be POSTed.
Tony
On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
quoted
Helge Hafting [off-list ref] wrote:
[...]
quoted
quoted
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 ;-)
quoted
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.
quoted
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. Daplas <hidden> Date: 2004-10-16 00:40:57
On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
Helge Hafting [off-list ref] wrote:
quoted
On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
quoted
Helge Hafting [off-list ref] 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 Marques <hidden> Date: 2004-10-26 11:18:54
Antonino A. Daplas wrote:
On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
quoted
Helge Hafting [off-list ref] wrote:
quoted
On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
quoted
Helge Hafting [off-list ref] 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)
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
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 Marques <hidden> Date: 2004-10-27 11:12:15
Kendall Bennett wrote:
Paulo Marques [off-list ref] wrote:
.....
quoted
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 :)
quoted
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)
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! ~
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click