Re: Generic VESA framebuffer driver and Video card BOOT?

Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Fri, 15 Oct 2004 11:20:21 -0700, Kendall Bennett
<kendallb@scitechsoft.com> wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> 
> > On Iau, 2004-10-14 at 21:46, Kendall Bennett wrote:
> > > a way to spawn a user mode process that early in the boot sequence (it
> > > would have to come from the initrd image I expect) then the only option
> > > is to compile it into the kernel.
> >
> > There is exactly that in 2.6 - the hotplug interfaces allow the
> > kernel to fire off userspace programs. Jon Smirl (who you should
> > definitely talk to about this stuff) has been hammering out a
> > design for moving almost all the mode switching into user space for
> > kernel video.
> 
> That is awesome! I am all for moving this outside of the kernel, as it
> would allow the use of ream vm86() services for VGA/VESA BIOS access on
> x86 and the user of the emulator for non-x86 platforms.
> 
> The only catch would be making sure this stuff is available really early
> in the boot sequence. As it stands right now the solution we have brings
> up the video almost imediately after you see the 'uncompressing kernel
> image' message on the serial port. The other solution of course is to get
> this into the boot loader which is what the AmigaOne folks did for their
> machines (U-Boot brings up the video). We are working with those guys to
> update their BIOS emulator to the latest version as the one they have
> doesn't work that reliably.
> 
> Anyway how do I find out more about this in 2.6?
> 
> Also I assume the code would need to end up in the initrg image, correct?
> Can you point me at some resources to learn more about how to get custom
> code into the initrd image?

The plan for this in 2.6 is to first write a VGA device driver. This
driver is responsible for identifying all of the VGA devices in a
system and ensuring only one of them gets enabled a time. I started
writing this but I haven't finished. This driver would be compiled
into the kernel. I can send source if you are interested.

I have added hooks to the PCI subsystem to record the boot video
device. If the VGA driver finds VGA devices other than the boot one it
will generate hotplug events on them. Initramfs should contain a reset
program for using X86 mode to reset these cards. To do this you need
two things from the kernel: 1) a way to make sure only a single VGA
device is active (VGA driver, allow you to disable the current VGA
device, reset the card, restore the active VGA device) and 2) a way to
get the ROM image. There is a patch in -mm that makes the ROMs visible
in sysfs that should be in the kernel shortly.

So, when you first boot you have two choices, 1) use a display the
boot ROM setup, such as VGAcon or PROMcon. or 2) have no display.
People want this both ways. VGAcon/PROMcon will let you get output
very early in the boot process.

Next the VGA driver will initialize. This will trigger user space
resets using the program on initramfs. Now it is possible to use all
of your displays. To control this from something like resume, the
driver sets a lock that is cleared by the reset app and the end of
reset. This will keep other processes out of the driver until reset is
finished.

Right now I am working on a merged fbdev/DRM that supports multi-head
adapters. It's turning out to be much more work than I though because
neither DRM or fbdev handle multihead at the device driver level. You
can get snapshots of the code at mesa3d.bkbits.net but it doesn't work
right yet. This driver is designed to run after the VGAdriver has
reset the hardware.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Hi Jon,

> The plan for this in 2.6 is to first write a VGA device driver.
> This driver is responsible for identifying all of the VGA devices
> in a system and ensuring only one of them gets enabled a time. I
> started writing this but I haven't finished. This driver would be
> compiled into the kernel. I can send source if you are interested.

I am interested but I probably wouldn't have the time to look at it right 
now.

> I have added hooks to the PCI subsystem to record the boot video
> device. If the VGA driver finds VGA devices other than the boot
> one it will generate hotplug events on them. Initramfs should
> contain a reset program for using X86 mode to reset these cards. To
> do this you need two things from the kernel: 1) a way to make sure
> only a single VGA device is active (VGA driver, allow you to
> disable the current VGA device, reset the card, restore the active
> VGA device) and 2) a way to get the ROM image. There is a patch in
> -mm that makes the ROMs visible in sysfs that should be in the
> kernel shortly. 
> 
> So, when you first boot you have two choices, 1) use a display the
> boot ROM setup, such as VGAcon or PROMcon. or 2) have no display.
> People want this both ways. VGAcon/PROMcon will let you get output
> very early in the boot process. 

What about non-x86 platforms such as PowerPC and MIPS embedded devices 
that want video (TiVo type platforms, media players etc). How would these 
fit into the picture? Would this require the boot loader (ie: U-Boot or 
whatever) to have the ability to POST the card? 

Or perhaps the VideoBoot module would be a useful addition to the VGA 
boot driver compiled into the kernel to bring up the video card into a 
sane state on any system (even a dumb framebuffer linear mode) so a fully 
accelerated console driver in user space can take over later on?

> Right now I am working on a merged fbdev/DRM that supports
> multi-head adapters. It's turning out to be much more work than I
> though because neither DRM or fbdev handle multihead at the device
> driver level. You can get snapshots of the code at
> mesa3d.bkbits.net but it doesn't work right yet. This driver is
> designed to run after the VGAdriver has reset the hardware. 

Sounds interesting!

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: 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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Fri, 15 Oct 2004 15:22:51 -0700, Kendall Bennett
<kendallb@scitechsoft.com> wrote:
> What about non-x86 platforms such as PowerPC and MIPS embedded devices
> that want video (TiVo type platforms, media players etc). How would these
> fit into the picture? Would this require the boot loader (ie: U-Boot or
> whatever) to have the ability to POST the card?

There is the assumption that whatever BIOS the device has can get up a
very early console that can output critical error messages before the
kernel and early user space is loaded. For example the "I can't find
the kernel" or  "initramfs is missing" error message. This also
assumes that the BIOS can post whatever display it is using.

I'm not trying to fix the problem of getting early boot messages out
of a Mac with an x86 card plugged into it. The card will work after
early user space initializes. The right way to fix that would be to
switch to something like LinuxBIOS and build the x86 emulator into it.

Also note that a lot of what you think are early boot messages are not
really being printed out during early boot. The kernel queues printks
until a console is running and then outputs them. An example of
queuing is the processor initialization messages for the first
processor. I believe there is a way to force messages like this to
print as they occur using the BIOS on x86.

> Or perhaps the VideoBoot module would be a useful addition to the VGA
> boot driver compiled into the kernel to bring up the video card into a
> sane state on any system (even a dumb framebuffer linear mode) so a fully
> accelerated console driver in user space can take over later on?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> > What about non-x86 platforms such as PowerPC and MIPS embedded devices
> > that want video (TiVo type platforms, media players etc). How would these
> > fit into the picture? Would this require the boot loader (ie: U-Boot or
> > whatever) to have the ability to POST the card?
> 
> There is the assumption that whatever BIOS the device has can get up a
> very early console that can output critical error messages before the
> kernel and early user space is loaded. For example the "I can't find
> the kernel" or  "initramfs is missing" error message. This also
> assumes that the BIOS can post whatever display it is using.
> 
> I'm not trying to fix the problem of getting early boot messages out
> of a Mac with an x86 card plugged into it. The card will work after
> early user space initializes. The right way to fix that would be to
> switch to something like LinuxBIOS and build the x86 emulator into
> it.

That still does not solve resume from suspend-to-RAM. We need to post
VGA there. We probably could do it late in userspace... but it makes
debugging resume pretty hard.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

RE: Generic VESA framebuffer driver and Video card BOOT?

[Yu, Luming]

It is hard to use native VGA for s3 debugging. 
I don know if serial console or net console 
can help s3 debugging. 

Thanks
Luming 

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Pavel Machek
>Sent: 2004Äê10ÔÂ20ÈÕ 5:09
>To: Jon Smirl
>Cc: Kendall Bennett; Alan Cox; Linux Kernel Mailing List; fbdev
>Subject: Re: Generic VESA framebuffer driver and Video card BOOT?
>
>Hi!
>
>> > What about non-x86 platforms such as PowerPC and MIPS 
>embedded devices
>> > that want video (TiVo type platforms, media players etc). 
>How would these
>> > fit into the picture? Would this require the boot loader 
>(ie: U-Boot or
>> > whatever) to have the ability to POST the card?
>> 
>> There is the assumption that whatever BIOS the device has 
>can get up a
>> very early console that can output critical error messages before the
>> kernel and early user space is loaded. For example the "I can't find
>> the kernel" or  "initramfs is missing" error message. This also
>> assumes that the BIOS can post whatever display it is using.
>> 
>> I'm not trying to fix the problem of getting early boot messages out
>> of a Mac with an x86 card plugged into it. The card will work after
>> early user space initializes. The right way to fix that would be to
>> switch to something like LinuxBIOS and build the x86 emulator into
>> it.
>
>That still does not solve resume from suspend-to-RAM. We need to post
>VGA there. We probably could do it late in userspace... but it makes
>debugging resume pretty hard.
>								Pavel
>-- 
>People were complaining that M$ turns users into beta-testers...
>...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
>-
>To unsubscribe from this list: send the line "unsubscribe 
>linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 07:20, Jon Smirl wrote:
> On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
>
> <adaplas@hotpop.com> wrote:
> > Yes, that is the downside to a userspace solution. How bad will that be?
> > Note that Jon Smirl is proposing a temporary console driver for early
> > boot messages until the primary console driver activates.
>
> Does anyone know exactly how big the window is from when a compiled in
> console activates until one that relies on initramfs loads? I don't
> think it is very big given that a lot of the early printk's are queued
> before they are displayed.

There's a log of initialization that goes on between console_init() and
populate_rootfs().  However, console_init() will only initialize built-in
consoles (as pointed to by conswitchp) such as vgacon or dummycon.
However, the framebuffer system initialization does happen after
populate_rootfs().  

So, at least in the framebuffer perspective, the emulator/video boot may be
loaded as part of initramfs.

Tony

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Sat, 16 Oct 2004 09:50:32 +0800, Antonino A. Daplas
<adaplas@hotpop.com> wrote:
> On Saturday 16 October 2004 07:20, Jon Smirl wrote:
> > On Sat, 16 Oct 2004 05:51:38 +0800, Antonino A. Daplas
> >
> > <adaplas@hotpop.com> wrote:
> > > Yes, that is the downside to a userspace solution. How bad will that be?
> > > Note that Jon Smirl is proposing a temporary console driver for early
> > > boot messages until the primary console driver activates.
> >
> > Does anyone know exactly how big the window is from when a compiled in
> > console activates until one that relies on initramfs loads? I don't
> > think it is very big given that a lot of the early printk's are queued
> > before they are displayed.
> 
> There's a log of initialization that goes on between console_init() and
> populate_rootfs().  However, console_init() will only initialize built-in
> consoles (as pointed to by conswitchp) such as vgacon or dummycon.
> However, the framebuffer system initialization does happen after
> populate_rootfs().

We already have vgacon, promcon, sticon, mgacon, newportcon. What
platforms (other than embedded) are not covered by these?

The idea is to use one of these as a temporary console and not print
anything on it except KERN_ERR level messages. Of course if you are a
kernel developer you can change this. A working system would non have
KERN_ERR messages during this phase and the screen would remain blank.

Messages at levels other than KERN_ERR would be queued until
populate_rootfs()/early user space time where they would then get
displayed on the fbcon. fbcon will be a full console with mode setting
capability and other fancy features. It would immediately go into
graphics mode.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Jon Smirl <jonsmirl@gmail.com> wrote:

> > There's a log of initialization that goes on between console_init() and
> > populate_rootfs().  However, console_init() will only initialize built-in
> > consoles (as pointed to by conswitchp) such as vgacon or dummycon.
> > However, the framebuffer system initialization does happen after
> > populate_rootfs().
> 
> We already have vgacon, promcon, sticon, mgacon, newportcon. What
> platforms (other than embedded) are not covered by these? 

Many embedded platforms do not map VGA resources in, so it is not 
possible to get VGACon to work on those machines unless the kernel/boot 
loader is modified to properly map VGA resources (which should be 
possible).

Then there are Macintosh machines that also do not map VGA resources. I 
am not sure if it is possible to map them on Macintosh machines or not.

I would assume however a serial port console would be fine for embedded 
machines until the framebuffer driver could come up anyway.

> The idea is to use one of these as a temporary console and not
> print anything on it except KERN_ERR level messages. Of course if
> you are a kernel developer you can change this. A working system
> would non have KERN_ERR messages during this phase and the screen
> would remain blank. 
> 
> Messages at levels other than KERN_ERR would be queued until
> populate_rootfs()/early user space time where they would then get
> displayed on the fbcon. fbcon will be a full console with mode
> setting capability and other fancy features. It would immediately
> go into graphics mode. 

As long as this process happens quickly and the machine boots into 
graphics mode within 1-2 seconds from poweron, that would probably be OK. 
If it starts taking too long for the system to get into graphics mode to 
display something the user can easily think something is wrong and the 
machine is not working.

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: 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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

Kendall Bennett wrote:

> 
> I would assume however a serial port console would be fine for embedded 
> machines until the framebuffer driver could come up anyway.
> 
This would be an incorrect assumption.  Speaking as a developer of one 
said embedded system I must have video at boot and be able to dump 
critical kernel messages to the screen.

In the field, hooking up a serial cable to see why the unit doesn't boot 
requires the dispatch of a tech who would have open up the unit to get 
to the serial port.  This costs the end client lots of $$.  They don't 
like that.

By having video on boot the support person can tell the end user to look 
at the screen and read back any messages and then make the determination 
  if a tech dispatch is needed.

And its common practice to only have as many serial ports as the system 
needs during runtime.  During development you can dual purpose them but 
in the final system their may not be a serial port free (or even 
installed) to get that console info from.

-- 
Richard A. Smith




-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Mon, 18 Oct 2004 15:34:58 -0500, Richard Smith <rsmith@bitworks.com> wrote:
> Kendall Bennett wrote:
> >
> > I would assume however a serial port console would be fine for embedded
> > machines until the framebuffer driver could come up anyway.
> > 
> This would be an incorrect assumption.  Speaking as a developer of one
> said embedded system I must have video at boot and be able to dump
> critical kernel messages to the screen.

I don't see it as the kernel's responsibility to compensate for lack
of something in an embedded system's BIOS. Embedded programmers are
free to go in and add basic display code to their arch specific
directories for printing out this class of messages. Better yet would
be to fix the embedded ROM to support basic display.

What I don't want to do is get a graphics driver system capable of
supporting multi-head console and openGL running before the kernel
initializes. I'm also trying to move big chunks of the display system
(vm86 reset and EDID) out of the kernel and into user space in order
to reduce the size of the graphic drivers. Moving this code means that
the full display system can not initialize until at least early user
space is running.

Every system has to be able to somehow indicate that it can find/load the
kernel image or that the image is corrupt or that hardware diagnostics failed.
Displaying this info is the responsibility of the BIOS.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

Jon Smirl wrote:

> Every system has to be able to somehow indicate that it can find/load the
> kernel image or that the image is corrupt or that hardware diagnostics failed.
> Displaying this info is the responsibility of the BIOS.
> 

Jon, I agree with you 100%.  I was merely responding to a statement I 
saw as false.

If we could get the video chip manufacturers to provide me with all the 
necessary documentation we embedded folk would be happy to do exactly as 
you say.  We could code up a nice robust boot time init procedure to 
serve our purposes.  OF would be great if all the mfgs would support it.

Its a sad fact though that we are (x86 anyway) dependant on some 
amazingly fragile, stupid, usually binary only, legacy bloated, and 
quite often buggy, 16-bit realmode video init code that should have been 
put to pasture many years ago.

LinuxBIOS has been trying to come up with a solution to the video BOOT 
problems for good while now.  Emulation seems to be the only thing that 
really has a chance of working.

I don't currently (see next paragraph) need the kernel to try and do all 
that stuff for me since I need it prior to when the kernel loads.  But 
what I would like is to be able to use/build on kernel framework without 
having to completely re-invent the wheel.

A long term goal of LinuxBIOS however is to use Linux _AS_ the bios 
which kind of nullifies your BIOS responsibility statement.  Some of the 
LANL clusters are doing this right now.  The only reason we aren't doing 
it 100% of the time is that a lot of motherboards don't have a big 
enough flash. Yet.  But with projects like linux-tiny and larger flashes 
headed our way those days are numbered.

Linux far exceeds the hardware support level and flexablity of any bios 
and already does 90% of the job a bios does anyway. In most cases better 
than the bios ever could.  Linux booting Linux is the ultimate 
bios/bootloader.

-- 
Richard A. Smith




-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

On Mon, 18 Oct 2004 17:34:45 -0500, Richard Smith <rsmith@bitworks.com> wrote:
> A long term goal of LinuxBIOS however is to use Linux _AS_ the bios
> which kind of nullifies your BIOS responsibility statement.  Some of the
> LANL clusters are doing this right now.  The only reason we aren't doing
> it 100% of the time is that a lot of motherboards don't have a big
> enough flash. Yet.  But with projects like linux-tiny and larger flashes
> headed our way those days are numbered.
> 
> Linux far exceeds the hardware support level and flexablity of any bios
> and already does 90% of the job a bios does anyway. In most cases better
> than the bios ever could.  Linux booting Linux is the ultimate
> bios/bootloader.

LinuxBIOS can do things the real kernel probably shouldn't be doing.
For example on an x86 it can find the expansion ROMs and post all of
the video cards. On non-x86 it can embed emu86 and run the ROMs that
way. And for a few cards that we have the docs on it can directly
initialize them.  These options should be selected when LinuxBIOS is
built for the hardware.

But getting Int10 video up and running does not mean that the kernel
framebuffer/DRM subsystem has to be up and running. Int10 or Open
Firmware text output should be used for these critical messages before
the kernel video system is loaded. As far as I know every video card
has some sort of ROM on it to support BIOS level display. If someone
is going to embed a graphics chip without a ROM and run LinuxBIOS on
it, then it is the hardware manufacturer responsibility to acquire
enough documentation from the graphics vendor so that a boot display
can be implemented.

To achieve pure graphical boot, don't print out anything except
KERN_ERR level messages to the Int10 display. Queue all non-KERN_ERR
until the framebuffer loads and then dump them if you want.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

Jon Smirl wrote:

> LinuxBIOS can do things the real kernel probably shouldn't be doing.
> For example on an x86 it can find the expansion ROMs and post all of
 > the video cards. On non-x86 it can embed emu86 and run the ROMs that
 > way. And for a few cards that we have the docs on it can directly
 > initialize them.  These options should be selected when LinuxBIOS is
 > built for the hardware.

Well we see it the other way around.  We want to do a little as possible 
and let Linux handle as much as possible.  Otherwise your bios turns 
into a mini-OS.  The path is littered with dead projects that went that 
route.  Keeping current with driver support kills them.

> But getting Int10 video up and running does not mean that the kernel
> framebuffer/DRM subsystem has to be up and running. Int10 or Open

Agreed.

> it, then it is the hardware manufacturer responsibility to acquire
> enough documentation from the graphics vendor so that a boot display
> can be implemented.

If only it were that easy. *grin*

Ok well I really don't want to start a off-topic argument here so I'll 
shut up after this. Especially since I'm not really argueing anything 
that hasn't already be thrashed over many times.

I and many others would like to see a unified int10 solution that could 
be used by as many projects that need it rather than the fragmented 
setup we have now.  The kernel proper may or may not be one of those.

-- 
Richard A. Smith




-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Richard Smith <rsmith@bitworks.com> wrote:

> Jon Smirl wrote:
> 
> > Every system has to be able to somehow indicate that it can find/load the
> > kernel image or that the image is corrupt or that hardware diagnostics failed.
> > Displaying this info is the responsibility of the BIOS.
> 
> Jon, I agree with you 100%.  I was merely responding to a
> statement I saw as false. 
> 
> If we could get the video chip manufacturers to provide me with
> all the necessary documentation we embedded folk would be happy to
> do exactly as you say.  We could code up a nice robust boot time
> init procedure to serve our purposes.  OF would be great if all
> the mfgs would support it. 

Well being able to use this BIOS emulator logic to bring up the primary 
video card in the firmware should solve this problem, right? Just ignore 
the fact that the BIOS image we are using happens to be x86 code, and 
think about is as a set of instructions that we execute using an 
interpreter (ie: the same as Open Firmware really).

> Its a sad fact though that we are (x86 anyway) dependant on some
> amazingly fragile, stupid, usually binary only, legacy bloated, and
> quite often buggy, 16-bit realmode video init code that should have
> been put to pasture many years ago. 

Actually there is nothing wrong with the x86 BIOS from the perspective of 
functionality and useability (or bloat for that matter). It contains all 
the functionality we need and armed with something like the x86 emulator 
we can use it for what we need on any platform.

Open Firmware may be a 'nicer' solution, but I guarantee that if the 
vendors started supporting that it would be just a bug ridden as any 16-
bit real mode BIOS code. For the Video BIOS the code always works for 
what it is tested for. Some vendors spend more time testing the VBE BIOS 
side of things fully (if they are smart they have licensed our VBETest 
tools for this purpose). Unfortunatley some vendors do not test this 
stuff thoroughly and it has problems. But the same testing issues would 
exist whether the firmware was written as a 16-bit x86 blob or as an Open 
Firmware blob.

> LinuxBIOS has been trying to come up with a solution to the video
> BOOT problems for good while now.  Emulation seems to be the only
> thing that really has a chance of working. 

IMHO that is the best solution to the problem because it will be using 
code that has been heavily tested by the vendor. The one thing x86 Video 
BIOS'es can do reliably is POST the graphics card ;-)

> I don't currently (see next paragraph) need the kernel to try and
> do all that stuff for me since I need it prior to when the kernel
> loads.  But what I would like is to be able to use/build on kernel
> framework without having to completely re-invent the wheel. 

Assuming you put the video init code into the firmware, then yes, the 
kernel does not need it. However part of the project to put this into the 
kernel involves building a better VESA framebuffer console driver, and to 
do that we either need vm86() services from kernel land (frowned upon by 
the kernel community and inherently x86 centric) or support for x86 
emulation.

If you want to try and build a better standard than the x86 VESA VBE 
BIOS, be my guest. I lobbied for years on the VESA Software Standards 
Committee to build the next generation firmware that would be cross 
platform, but nobody was interested. In fact the SSC eventually closed 
due to lack of interest so we took all our technology and turned it into 
SciTech SNAP. 

I see Intel is trying to do something similar with EFI, but when will 
that actually be here?

So for now we have the x86 BIOS and it works today. We should use it.

> Linux far exceeds the hardware support level and flexablity of any
> bios and already does 90% of the job a bios does anyway. In most
> cases better than the bios ever could.  Linux booting Linux is the
> ultimate bios/bootloader. 

That would be nice if you could trim it down ;-) Would certainly save a 
lot of code bloat. But if you do that, then you would need this code in 
the kernel since now it would be the boot loader as well ;-)

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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

Kendall Bennett wrote:

> Actually there is nothing wrong with the x86 BIOS from the perspective of 
> functionality and useability (or bloat for that matter). It contains all 
> the functionality we need and armed with something like the x86 emulator 
> we can use it for what we need on any platform.

> IMHO that is the best solution to the problem because it will be using 
> code that has been heavily tested by the vendor. The one thing x86 Video 
> BIOS'es can do reliably is POST the graphics card ;-)

I'm just going to take your word on this since you have messed with far 
more video bioses than I.  I've just got a few too many scars over the 
years from trying to make the whole BIOS sub-system robust enough for 
embedded standards.

> That would be nice if you could trim it down ;-) Would certainly save a 

Check out linux-tiny (http://www.selenic.com/tiny-about/)

> lot of code bloat. But if you do that, then you would need this code in 
> the kernel since now it would be the boot loader as well ;-)

Exactly. Which is why I like your project and I think its a good thing. 
    The only reason I have to carry around the legacy BIOS baggage is 
for video.

How big is your in-kernel implementation?

-- 
Richard A. Smith




-------------------------------------------------------
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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Richard Smith <rsmith@bitworks.com> wrote:

> Kendall Bennett wrote:
> 
> > Actually there is nothing wrong with the x86 BIOS from the perspective of 
> > functionality and useability (or bloat for that matter). It contains all 
> > the functionality we need and armed with something like the x86 emulator 
> > we can use it for what we need on any platform.
> 
> > IMHO that is the best solution to the problem because it will be using 
> > code that has been heavily tested by the vendor. The one thing x86 Video 
> > BIOS'es can do reliably is POST the graphics card ;-)
> 
> I'm just going to take your word on this since you have messed
> with far more video bioses than I.  I've just got a few too many
> scars over the years from trying to make the whole BIOS sub-system
> robust enough for embedded standards. 

Most BIOS'es are relatively good, but there are some terrible ones. We 
have one a lot of work over the years making our VESA VBE drivers work 
well with all the BIOS'es out there, working around the issues in the 
broken ones. I plan to use that same module for the kernel VESA driver 
when I get around to re-writing it.

> > lot of code bloat. But if you do that, then you would need this code in 
> > the kernel since now it would be the boot loader as well ;-)
> 
> Exactly. Which is why I like your project and I think its a good
> thing. The only reason I have to carry around the legacy BIOS
> baggage is for video. 

Yep.

> How big is your in-kernel implementation?

Right now the compiled x86 code is about 100K in size. PowerPC code 
appears to be about twice that size and x86-64 is about 130K I think. I 
have no idea how big an Open Firmware interpreter would be for comparison 
purposes because I have never seen an Open Source implementation of one.

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: 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> > Its a sad fact though that we are (x86 anyway) dependant on some
> > amazingly fragile, stupid, usually binary only, legacy bloated, and
> > quite often buggy, 16-bit realmode video init code that should have
> > been put to pasture many years ago. 
> 
> Actually there is nothing wrong with the x86 BIOS from the perspective of 
> functionality and useability (or bloat for that matter). It contains all 
> the functionality we need and armed with something like the x86 emulator 
> we can use it for what we need on any platform.
> 
> Open Firmware may be a 'nicer' solution, but I guarantee that if the 
> vendors started supporting that it would be just a bug ridden as any 16-
> bit real mode BIOS code. For the Video BIOS the code always works for 
> what it is tested for. Some vendors spend more time testing the VBE BIOS 
> side of things fully (if they are smart they have licensed our VBETest 
> tools for this purpose). Unfortunatley some vendors do not test this 
> stuff thoroughly and it has problems. But the same testing issues would 
> exist whether the firmware was written as a 16-bit x86 blob or as an Open 
> Firmware blob.

Actually that 16-bit x86 blob can access any PC hardware, and that's
where the stuff gets hard.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

> > Open Firmware may be a 'nicer' solution, but I guarantee that if the 
> > vendors started supporting that it would be just a bug ridden as any 16-
> > bit real mode BIOS code. For the Video BIOS the code always works for 
> > what it is tested for. Some vendors spend more time testing the VBE BIOS 
> > side of things fully (if they are smart they have licensed our VBETest 
> > tools for this purpose). Unfortunatley some vendors do not test this 
> > stuff thoroughly and it has problems. But the same testing issues would 
> > exist whether the firmware was written as a 16-bit x86 blob or as an Open 
> > Firmware blob.
> 
> Actually that 16-bit x86 blob can access any PC hardware, and that's
> where the stuff gets hard.

Yes, but there is only a very small set of PC hardware features you need 
to implement, and most BIOS'es only look at those things for timing 
purposes. Unfortunately there is no standard for how BIOS'es do internal 
timing and delay loops, so we emulate them all (8253 timers, speaker 
ports and CMOS time/date support ;-).

When we come across a new card that doesn't work we figure out why and 
make new additions to the video boot code. However at this point we think 
we have covered just about every card out there, as I don't think there 
are any cards in our labs that don't work at present. If there are, 
fixing them is just a matter of spending the time to debug it.

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: 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> > > Open Firmware may be a 'nicer' solution, but I guarantee that if the 
> > > vendors started supporting that it would be just a bug ridden as any 16-
> > > bit real mode BIOS code. For the Video BIOS the code always works for 
> > > what it is tested for. Some vendors spend more time testing the VBE BIOS 
> > > side of things fully (if they are smart they have licensed our VBETest 
> > > tools for this purpose). Unfortunatley some vendors do not test this 
> > > stuff thoroughly and it has problems. But the same testing issues would 
> > > exist whether the firmware was written as a 16-bit x86 blob or as an Open 
> > > Firmware blob.
> > 
> > Actually that 16-bit x86 blob can access any PC hardware, and that's
> > where the stuff gets hard.
> 
> Yes, but there is only a very small set of PC hardware features you need 
> to implement, and most BIOS'es only look at those things for timing 
> purposes. Unfortunately there is no standard for how BIOS'es do internal 
> timing and delay loops, so we emulate them all (8253 timers, speaker 
> ports and CMOS time/date support ;-).

Hmm, that does not seem that bad. Did you need to emulate interrupt
controller, too? That one seemed most scary to me.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

> > Yes, but there is only a very small set of PC hardware features you need 
> > to implement, and most BIOS'es only look at those things for timing 
> > purposes. Unfortunately there is no standard for how BIOS'es do internal 
> > timing and delay loops, so we emulate them all (8253 timers, speaker 
> > ports and CMOS time/date support ;-).
> 
> Hmm, that does not seem that bad. Did you need to emulate interrupt
> controller, too? That one seemed most scary to me.

No. Only software interrupts. The BIOS never deals with hardware 
interrupts since there is no standard, reliable way to hook them from 
real mode so it never uses them ;-)

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: 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

Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Hello All,

I am writing this email to guage the interest in having code contributed 
to the main stream Linux kernel that would support the user of a generic, 
full featured VESA framebuffer driver that works on any CPU architecture 
along with a generic Video card BOOT or POST mechanism.

We have been working on a project under contract to ATI that involves 
porting a version of our SNAPBoot BIOS emulator solution to the PowerPC 
Linux kernel. The SNAPBoot code supports initialising a graphics card 
using an x86 BIOS image on any platform (currently tesed on x86, x86-64 
and PowerPC). Initially SNAPBoot was developed to work across multiple 
operating systems and CPU architectures from user space, but the desire 
to use it to initialise the graphics card on embedded PowerPC kernels 
prompted us to port a version of it for use within the Linux kernel. The 
version we have ported for use in the kernel can be used to initialise 
the graphics card for use with any accelerated framebuffer console 
driver, such as the radeonfb driver which we are currently using it with.

Note that the SNAPBoot code uses the x86emu BIOS emulator project as the 
core CPU emulation technology, and project we have been actively involved 
with for many years since the licensing on the project was changed to 
MIT/BSD style licensing and incorporated into the XFree86 project. We 
have built code on top of x86emu to provide generic support for 
initialising graphics cards on multiple platforms as well as supporting 
initialisation of modern NonVGA graphics cards (like the ATI Radeon 
family) without needing access to real VGA resources such as VGA I/O 
ports and physical memory at 0xA0000-0xBFFFF.

More importantly we have used SNAPBoot to port our generic VESA SNAP 
display driver to work on multiple operating systems and platforms, 
including both x86-64 and PowerPC platforms. Using this driver you can 
use any graphics card in the machine and it will support all the features 
provided by the graphics cards VESA BIOS, including support for refresh 
rate control on cards that support VBE 3.0 services. We have been 
actively testing both the SNAPBoot capability and the BIOS emulator on 
many platforms and graphics cards, and the latest version work flawlessly 
on just about every graphics card we have tested.

What this means is that it should be possible to build a new version of 
the VESA framebuffer console driver for the Linux kernel that will have 
these important features:

1. Be able to switch display modes on the fly, supporting all modes 
enumerated by the Video BIOS.

2. Be able to support refresh rate control on graphics cards that support 
the VBE 3.0 services.

3. Be able to support 8-bit and 32-bit display modes on any graphics card 
on big endian machines (16-bit is not possible unless software rendering 
code is written to enable endian swapping in software, which may be 
possible).

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. 
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. 

So what do you guys think? 

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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Zachary Smith]

This is a problem of the videocard manufacturers' making which,
in the spirit of good engineering, they should fix before requiring
a downstream kludge.

Specifically, ATI, rather than advocate x86 emulation in order
to use their BIOS on non-x86 machines, should put a pseudocode BIOS
(something like java bytecode) in the ROM instead, including
an interpreter of course, perhaps gutting the x86 BIOS calls to use the
pseudocode routines so there is only one version to maintain.
And provide an entrypoint for non-x86 CPUs.

Zack


Kendall Bennett wrote:
> Hello All,
> 
> I am writing this email to guage the interest in having code contributed 
> to the main stream Linux kernel that would support the user of a generic, 
> full featured VESA framebuffer driver that works on any CPU architecture 
> along with a generic Video card BOOT or POST mechanism.
> 
> We have been working on a project under contract to ATI that involves 
> porting a version of our SNAPBoot BIOS emulator solution to the PowerPC 
> Linux kernel. The SNAPBoot code supports initialising a graphics card 
> using an x86 BIOS image on any platform (currently tesed on x86, x86-64 
> and PowerPC). Initially SNAPBoot was developed to work across multiple 
> operating systems and CPU architectures from user space, but the desire 
> to use it to initialise the graphics card on embedded PowerPC kernels 
> prompted us to port a version of it for use within the Linux kernel. The 
> version we have ported for use in the kernel can be used to initialise 
> the graphics card for use with any accelerated framebuffer console 
> driver, such as the radeonfb driver which we are currently using it with.
> 
> Note that the SNAPBoot code uses the x86emu BIOS emulator project as the 
> core CPU emulation technology, and project we have been actively involved 
> with for many years since the licensing on the project was changed to 
> MIT/BSD style licensing and incorporated into the XFree86 project. We 
> have built code on top of x86emu to provide generic support for 
> initialising graphics cards on multiple platforms as well as supporting 
> initialisation of modern NonVGA graphics cards (like the ATI Radeon 
> family) without needing access to real VGA resources such as VGA I/O 
> ports and physical memory at 0xA0000-0xBFFFF.
> 
> More importantly we have used SNAPBoot to port our generic VESA SNAP 
> display driver to work on multiple operating systems and platforms, 
> including both x86-64 and PowerPC platforms. Using this driver you can 
> use any graphics card in the machine and it will support all the features 
> provided by the graphics cards VESA BIOS, including support for refresh 
> rate control on cards that support VBE 3.0 services. We have been 
> actively testing both the SNAPBoot capability and the BIOS emulator on 
> many platforms and graphics cards, and the latest version work flawlessly 
> on just about every graphics card we have tested.
> 
> What this means is that it should be possible to build a new version of 
> the VESA framebuffer console driver for the Linux kernel that will have 
> these important features:
> 
> 1. Be able to switch display modes on the fly, supporting all modes 
> enumerated by the Video BIOS.
> 
> 2. Be able to support refresh rate control on graphics cards that support 
> the VBE 3.0 services.
> 
> 3. Be able to support 8-bit and 32-bit display modes on any graphics card 
> on big endian machines (16-bit is not possible unless software rendering 
> code is written to enable endian swapping in software, which may be 
> possible).
> 
> 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. 
> 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. 
> 
> So what do you guys think? 
> 
> 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: 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 



-------------------------------------------------------
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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Ian Romanick]

Zachary Smith wrote:

> This is a problem of the videocard manufacturers' making which,
> in the spirit of good engineering, they should fix before requiring
> a downstream kludge.
> 
> Specifically, ATI, rather than advocate x86 emulation in order
> to use their BIOS on non-x86 machines, should put a pseudocode BIOS
> (something like java bytecode) in the ROM instead, including
> an interpreter of course, perhaps gutting the x86 BIOS calls to use the
> pseudocode routines so there is only one version to maintain.
> And provide an entrypoint for non-x86 CPUs.

Isn't that basically what OpenFirmware is?  I think part of the issue is 
the x86 compiled BIOS is smaller than the OF BIOS, so they use smaller 
(i.e., cheaper) flash on the card.  That has prevented people from 
re-flashing PC cards with OF images from Mac cards.

I think Digital had the right idea from the beginning:  put the x86 BIOS 
emulator in the system firmware and be done with it.


-------------------------------------------------------
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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Zachary Smith]

The problem of x86-only BIOSes is one of the videocard manufacturers'
own making which, in the spirit of good engineering, they should fix
before requiring a downstream kludge.

It's strange that they seem to want to sell these cards for use in
non-x86 machines yet they won't pay to have people write BIOSes
for PPC or other CPUs, or even provide a pseudocode solution.

Zack

Kendall Bennett wrote:
> Hello All,
> 
> I am writing this email to guage the interest in having code contributed 
> to the main stream Linux kernel that would support the user of a generic, 
> full featured VESA framebuffer driver that works on any CPU architecture 
> along with a generic Video card BOOT or POST mechanism.
> 
> We have been working on a project under contract to ATI that involves 
> porting a version of our SNAPBoot BIOS emulator solution to the PowerPC 
> Linux kernel. The SNAPBoot code supports initialising a graphics card 
> using an x86 BIOS image on any platform (currently tesed on x86, x86-64 
> and PowerPC). Initially SNAPBoot was developed to work across multiple 
> operating systems and CPU architectures from user space, but the desire 
> to use it to initialise the graphics card on embedded PowerPC kernels 
> prompted us to port a version of it for use within the Linux kernel. The 
> version we have ported for use in the kernel can be used to initialise 
> the graphics card for use with any accelerated framebuffer console 
> driver, such as the radeonfb driver which we are currently using it with.
> 
> Note that the SNAPBoot code uses the x86emu BIOS emulator project as the 
> core CPU emulation technology, and project we have been actively involved 
> with for many years since the licensing on the project was changed to 
> MIT/BSD style licensing and incorporated into the XFree86 project. We 
> have built code on top of x86emu to provide generic support for 
> initialising graphics cards on multiple platforms as well as supporting 
> initialisation of modern NonVGA graphics cards (like the ATI Radeon 
> family) without needing access to real VGA resources such as VGA I/O 
> ports and physical memory at 0xA0000-0xBFFFF.
> 
> More importantly we have used SNAPBoot to port our generic VESA SNAP 
> display driver to work on multiple operating systems and platforms, 
> including both x86-64 and PowerPC platforms. Using this driver you can 
> use any graphics card in the machine and it will support all the features 
> provided by the graphics cards VESA BIOS, including support for refresh 
> rate control on cards that support VBE 3.0 services. We have been 
> actively testing both the SNAPBoot capability and the BIOS emulator on 
> many platforms and graphics cards, and the latest version work flawlessly 
> on just about every graphics card we have tested.
> 
> What this means is that it should be possible to build a new version of 
> the VESA framebuffer console driver for the Linux kernel that will have 
> these important features:
> 
> 1. Be able to switch display modes on the fly, supporting all modes 
> enumerated by the Video BIOS.
> 
> 2. Be able to support refresh rate control on graphics cards that support 
> the VBE 3.0 services.
> 
> 3. Be able to support 8-bit and 32-bit display modes on any graphics card 
> on big endian machines (16-bit is not possible unless software rendering 
> code is written to enable endian swapping in software, which may be 
> possible).
> 
> 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. 
> 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. 
> 
> So what do you guys think? 
> 
> 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: 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 




-------------------------------------------------------
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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Zachary Smith <plinius@comcast.net> wrote:

> The problem of x86-only BIOSes is one of the videocard
> manufacturers' own making which, in the spirit of good engineering,
> they should fix before requiring a downstream kludge. 
> 
> It's strange that they seem to want to sell these cards for use in
> non-x86 machines yet they won't pay to have people write BIOSes for
> PPC or other CPUs, or even provide a pseudocode solution. 

Interesting perspective. Given that you find this such a 'downstream 
kludge', perhaps you would like to explain exactly what PPC BIOS 
specification the manufacturers should be using instead?

Given that there isn't one, this is an option that works today. The only 
other option is Open Firmware and manufacturers such as ATI *do* support 
Open Firmware for Macintosh machines. The problem of course is that Open 
Firmware is not exactly open, and there are no Linux implementations of 
an Open Firmware exection environment that could be used. If there was, 
this project would not exist.

Lastly perhaps it would be worth while thinking about this project a 
little differently. Forgetting the fact that the BIOS image is x86, why 
not think about the x86 BIOS image as being a set of 'generic' 
instructions or p-code that can be excuted on any platform provided you 
have the correct runtime interpreter. That is basically what the x86 BIOS 
emulator solution does - it turns the x86 BIOS image into something that 
can be interpreted on any platform.

Now if you think about it that way, perhaps you will realise that it 
really isn't any different from Open Firmware! Any cross platform 
'firmware' solution is developed such that the code in the firmware is 
not processor specific but rather a 'p-code' that is interpreted on the 
target processor platform. 

So now if you ignore the fact that the 'firmware' runs natively in 16-bit 
x86 environments, maybe this solution won't seem so dirty after all?

Regards,

> Kendall Bennett wrote:
> > Hello All,
> > 
> > I am writing this email to guage the interest in having code contributed 
> > to the main stream Linux kernel that would support the user of a generic, 
> > full featured VESA framebuffer driver that works on any CPU architecture 
> > along with a generic Video card BOOT or POST mechanism.
> > 
> > We have been working on a project under contract to ATI that involves 
> > porting a version of our SNAPBoot BIOS emulator solution to the PowerPC 
> > Linux kernel. The SNAPBoot code supports initialising a graphics card 
> > using an x86 BIOS image on any platform (currently tesed on x86, x86-64 
> > and PowerPC). Initially SNAPBoot was developed to work across multiple 
> > operating systems and CPU architectures from user space, but the desire 
> > to use it to initialise the graphics card on embedded PowerPC kernels 
> > prompted us to port a version of it for use within the Linux kernel. The 
> > version we have ported for use in the kernel can be used to initialise 
> > the graphics card for use with any accelerated framebuffer console 
> > driver, such as the radeonfb driver which we are currently using it with.
> > 
> > Note that the SNAPBoot code uses the x86emu BIOS emulator project as the 
> > core CPU emulation technology, and project we have been actively involved 
> > with for many years since the licensing on the project was changed to 
> > MIT/BSD style licensing and incorporated into the XFree86 project. We 
> > have built code on top of x86emu to provide generic support for 
> > initialising graphics cards on multiple platforms as well as supporting 
> > initialisation of modern NonVGA graphics cards (like the ATI Radeon 
> > family) without needing access to real VGA resources such as VGA I/O 
> > ports and physical memory at 0xA0000-0xBFFFF.
> > 
> > More importantly we have used SNAPBoot to port our generic VESA SNAP 
> > display driver to work on multiple operating systems and platforms, 
> > including both x86-64 and PowerPC platforms. Using this driver you can 
> > use any graphics card in the machine and it will support all the features 
> > provided by the graphics cards VESA BIOS, including support for refresh 
> > rate control on cards that support VBE 3.0 services. We have been 
> > actively testing both the SNAPBoot capability and the BIOS emulator on 
> > many platforms and graphics cards, and the latest version work flawlessly 
> > on just about every graphics card we have tested.
> > 
> > What this means is that it should be possible to build a new version of 
> > the VESA framebuffer console driver for the Linux kernel that will have 
> > these important features:
> > 
> > 1. Be able to switch display modes on the fly, supporting all modes 
> > enumerated by the Video BIOS.
> > 
> > 2. Be able to support refresh rate control on graphics cards that support 
> > the VBE 3.0 services.
> > 
> > 3. Be able to support 8-bit and 32-bit display modes on any graphics card 
> > on big endian machines (16-bit is not possible unless software rendering 
> > code is written to enable endian swapping in software, which may be 
> > possible).
> > 
> > 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. 
> > 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. 
> > 
> > So what do you guys think? 
> > 
> > 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: 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
> > _______________________________________________
> > Linux-fbdev-devel mailing list
> > Linux-fbdev-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel


---
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: 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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Zachary Smith]

Kendall Bennett wrote:
> Zachary Smith <plinius@comcast.net> wrote:
> 
>>The problem of x86-only BIOSes is one of the videocard
>>manufacturers' own making which, in the spirit of good engineering,
>>they should fix before requiring a downstream kludge. 

 > Forgetting the fact that the BIOS image is x86, why
 > not think about the x86 BIOS image as being a set of 'generic'
 > instructions or p-code

Yes, this idea occurred to me after I posted my response.

But if you're going to add x86 emulation to the non-x86 kernels
perhaps it would be nice if you could find a way to permit
users to run x86 applications as well seamlessly.

Although that would introduce a tradeoff: kernel code should be
small which is bound to be slow in the case of an emulator,
which is OK for running BIOS code, but a user running apps
probably prefer optimized code which may be bigger.

On the other hand, a person running a free emulator doesn't
really have the option of great speed :)

Cheers,
Zack


-------------------------------------------------------
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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Geert Uytterhoeven]

On Fri, 15 Oct 2004, Zachary Smith wrote:
> Kendall Bennett wrote:
> > Zachary Smith <plinius@comcast.net> wrote:
> > 
> > > The problem of x86-only BIOSes is one of the videocard
> > > manufacturers' own making which, in the spirit of good engineering,
> > > they should fix before requiring a downstream kludge. 
> 
> > Forgetting the fact that the BIOS image is x86, why
> > not think about the x86 BIOS image as being a set of 'generic'
> > instructions or p-code
> 
> Yes, this idea occurred to me after I posted my response.
> 
> But if you're going to add x86 emulation to the non-x86 kernels
> perhaps it would be nice if you could find a way to permit
> users to run x86 applications as well seamlessly.

Ugh... There's a big difference between a 16-bit 8086 emulator to run BIOS code
and a full-fletched 32-bit 80386 (or higher) emulator...

> Although that would introduce a tradeoff: kernel code should be
> small which is bound to be slow in the case of an emulator,
> which is OK for running BIOS code, but a user running apps
> probably prefer optimized code which may be bigger.

We already have qemu.

> On the other hand, a person running a free emulator doesn't
> really have the option of great speed :)

Really? We already have qemu.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Zachary Smith <plinius@comcast.net> wrote:

> Kendall Bennett wrote:
> > Zachary Smith <plinius@comcast.net> wrote:
> > 
> >>The problem of x86-only BIOSes is one of the videocard
> >>manufacturers' own making which, in the spirit of good engineering,
> >>they should fix before requiring a downstream kludge. 
> 
>  > Forgetting the fact that the BIOS image is x86, why
>  > not think about the x86 BIOS image as being a set of 'generic'
>  > instructions or p-code
> 
> Yes, this idea occurred to me after I posted my response.
> 
> But if you're going to add x86 emulation to the non-x86 kernels
> perhaps it would be nice if you could find a way to permit users to
> run x86 applications as well seamlessly. 

Well there is a big difference between a simple CPU emulator and a full 
fledged machine emulation environment. Although if you only plan to run 
Linux user space programs that might be easier to handle because you just 
need to handle the system calls. But you would still need x86 shared 
libraries and such which at the end of the day doesn't make much sense 
(too much bloat). 

Also the emulator only emulates real mode code at present. It had full 
support for 32-bit instructions and could probably be tweaked to run user 
space 32-bit code, but it has never been tested.

> Although that would introduce a tradeoff: kernel code should be
> small which is bound to be slow in the case of an emulator, which
> is OK for running BIOS code, but a user running apps probably
> prefer optimized code which may be bigger. 

Probably. Although we have been very surprised at just how well the 
PowerPC compiled version of the emulator runs BIOS code. It seems the 
PowerPC compilers can optimise the code a lot better than x86 compilers.

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: 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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

"Kendall Bennett" <KendallB@scitechsoft.com> writes:

> Note that the SNAPBoot code uses the x86emu BIOS emulator project as the 
> core CPU emulation technology, and project we have been actively involved 
> with for many years since the licensing on the project was changed to 
> MIT/BSD style licensing and incorporated into the XFree86 project.

> 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. 

It certainly would be nice to have that.  Not nessesarely in the
kernel through, people tend not to like such complex stuff like cpu
emulation in the kernel for good reasons.  The kernel can run
userspace apps (modprobe, hotplug), that mechanism could be used to
invoke a userspace tool which does the boot / mode switching.  Having
it in userspace likely also makes it easier to share code with X11.

Have you talked to the powermanagement guys btw.?  One of the major
issues with suspend-to-ram is to get the graphics card back online,
and SNAPBoot might help to fix this too.  I'm not sure a userspace
solution would work for *that* through.

  Gerd

-- 
return -ENOSIG;

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Geert Uytterhoeven]

On Fri, 15 Oct 2004, Gerd Knorr wrote:
> Have you talked to the powermanagement guys btw.?  One of the major
> issues with suspend-to-ram is to get the graphics card back online,
> and SNAPBoot might help to fix this too.  I'm not sure a userspace
> solution would work for *that* through.

Why not? Of course you won't get any output before the graphics card has been
re-initialized to a sane and usable state...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Fri, 15 Oct 2004, Gerd Knorr wrote:
> > Have you talked to the powermanagement guys btw.?  One of the major
> > issues with suspend-to-ram is to get the graphics card back online,
> > and SNAPBoot might help to fix this too.  I'm not sure a userspace
> > solution would work for *that* through.
> 
> Why not? Of course you won't get any output before the graphics card has been
> re-initialized to a sane and usable state...

You have a application running which uses the framebuffer device, then
suspend with that app running.  You'll have to restore the state of
the device _before_ restarting all the userspace proccesses, otherwise
the app will not be very happy.  I'm not sure if the kernel can run a
userspace helper in that situation (i.e. before waking all the
processes).

  Gerd

-- 
return -ENOSIG;

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

hi :)

On Fri, Oct 15, 2004 at 03:13:13PM +0200, Gerd Knorr wrote:
> You have a application running which uses the framebuffer device, then
> suspend with that app running.  You'll have to restore the state of
> the device _before_ restarting all the userspace proccesses, otherwise
> the app will not be very happy.

As long as the app only interfaces with the framebuffer device and not
directly with the hardware it won't notice.
The apps data will simply not show up on the screen until the
usermode helper finishes.

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

On Sun, Oct 17, 2004 at 02:07:28PM +0200, Martin Waitz wrote:
> hi :)
> 
> On Fri, Oct 15, 2004 at 03:13:13PM +0200, Gerd Knorr wrote:
> > You have a application running which uses the framebuffer device, then
> > suspend with that app running.  You'll have to restore the state of
> > the device _before_ restarting all the userspace proccesses, otherwise
> > the app will not be very happy.
> 
> As long as the app only interfaces with the framebuffer device and not
> directly with the hardware it won't notice.

Well, mmap("/dev/fb") will just map the gfx cards memory into
the applications address space, so they _will_ interface with
the hardware.

> The apps data will simply not show up on the screen until the
> usermode helper finishes.

Whenever writing to the gfx memory before finishing the initialization
is harmless or not probably depends on the hardware, I'd better not
count on it ...

  Gerd

-- 
return -ENOSIG;


-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

hi :)

On Mon, Oct 18, 2004 at 10:36:32AM +0200, Gerd Knorr wrote:
> On Sun, Oct 17, 2004 at 02:07:28PM +0200, Martin Waitz wrote:
> > On Fri, Oct 15, 2004 at 03:13:13PM +0200, Gerd Knorr wrote:
> > > You have a application running which uses the framebuffer device, then
> > > suspend with that app running.  You'll have to restore the state of
> > > the device _before_ restarting all the userspace proccesses, otherwise
> > > the app will not be very happy.
> > 
> > As long as the app only interfaces with the framebuffer device and not
> > directly with the hardware it won't notice.
> 
> Well, mmap("/dev/fb") will just map the gfx cards memory into
> the applications address space, so they _will_ interface with
> the hardware.

but still through a driver which can take care of this access.

> > The apps data will simply not show up on the screen until the
> > usermode helper finishes.
> 
> Whenever writing to the gfx memory before finishing the initialization
> is harmless or not probably depends on the hardware, I'd better not
> count on it ...

when the application tries to access the framebuffer memory then
the driver is asked to map the corresponding page.
If the hardware does not cope with framebuffer access while it
is not correctly initialized, then the driver can defer those
mappings until the userspace helper is run.

-- 
Martin Waitz

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Generic VESA framebuffer driver and Video card BOOT?

[Gerd Knorr]

On Mon, Oct 18, 2004 at 01:39:29PM +0200, Martin Waitz wrote:
> hi :)
> 
> > Whenever writing to the gfx memory before finishing the initialization
> > is harmless or not probably depends on the hardware, I'd better not
> > count on it ...
> 
> when the application tries to access the framebuffer memory then
> the driver is asked to map the corresponding page.

On first access only, and even that only if the driver doesn't map the
pages at mmap() time already.  Not a single fb driver seems to map the
pages lazy today, grepping in drivers/video for nopage handles shows
nothing.  I'm not sure you can actually do that for iomem mappings.

  Gerd

-- 
return -ENOSIG;


-------------------------------------------------------
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

Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT?

[Venkatesh Pallipadi]

On Fri, Oct 15, 2004 at 02:38:01PM +0200, Geert Uytterhoeven wrote:
> On Fri, 15 Oct 2004, Gerd Knorr wrote:
> > Have you talked to the powermanagement guys btw.?  One of the major
> > issues with suspend-to-ram is to get the graphics card back online,
> > and SNAPBoot might help to fix this too.  I'm not sure a userspace
> > solution would work for *that* through.
> 
> Why not? Of course you won't get any output before the graphics card has been
> re-initialized to a sane and usable state...
> 

True. I do it on my Dell 600m (Radeon 9000M) using usermodehelper and it works just fine. It works both with VGA and X. I need to split up the thaw_processes into two stages though. It may not work with fb as fb driver resumes earlier. I use the patch below for the kernel and a userlevel x86 emulator.

I have to say though, it will help if we have a such an emulator in the kernel.

Thanks,
Venki


--- linux-2.6.9-rc2/kernel/power/main.c.org	2004-09-12 18:23:00.671546520 -0700
+++ linux-2.6.9-rc2/kernel/power/main.c	2004-09-12 18:22:27.548581976 -0700
@@ -106,12 +106,28 @@ static int suspend_enter(u32 state)
  *	console that we've allocated.
  */
 
+int vgapost_usermode(void)
+{
+	char	*argv[3] = {NULL, NULL, NULL};
+	char	*envp[3] = {NULL, NULL, NULL};
+
+	argv[0] = "/root/emu/video_post";
+
+	/* minimal command environment */
+	envp[0] = "HOME=/";
+	envp[1] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";
+        
+	return call_usermodehelper(argv[0], argv, envp, 1);
+}
+
 static void suspend_finish(u32 state)
 {
 	int retval;
 	device_resume();
 	if (pm_ops && pm_ops->finish)
 		pm_ops->finish(state);
+	thaw_processes_kernel();
+	retval = vgapost_usermode();
 	thaw_processes();
 
 	pm_restore_console();
--- linux-2.6.9-rc2/kernel/power/process.c.org	2004-09-12 18:21:48.266553752 -0700
+++ linux-2.6.9-rc2/kernel/power/process.c	2004-09-12 18:22:06.851728376 -0700
@@ -97,6 +97,29 @@ int freeze_processes(void)
 	return 0;
 }
 
+void thaw_processes_kernel(void)
+{
+	struct task_struct *g, *p;
+
+	printk( "Restarting kernel tasks..." );
+	read_lock(&tasklist_lock);
+	do_each_thread(g, p) {
+		if (!freezeable(p))
+			continue;
+		if (p->parent->pid != 1)
+			continue;
+		if (p->flags & PF_FROZEN) {
+			p->flags &= ~PF_FROZEN;
+			wake_up_process(p);
+		} else
+			printk(KERN_INFO " Strange, %s not stopped\n", p->comm );
+	} while_each_thread(g, p);
+
+	read_unlock(&tasklist_lock);
+	schedule();
+	printk( " done\n" );
+}
+
 void thaw_processes(void)
 {
 	struct task_struct *g, *p;
@@ -106,6 +129,8 @@ void thaw_processes(void)
 	do_each_thread(g, p) {
 		if (!freezeable(p))
 			continue;
+		if (p->parent->pid == 1)
+			continue;
 		if (p->flags & PF_FROZEN) {
 			p->flags &= ~PF_FROZEN;
 			wake_up_process(p);

Re: Generic VESA framebuffer driver and Video card BOOT?

[Nigel Cunningham]

Hi.

On Sat, 2004-10-16 at 04:29, Venkatesh Pallipadi wrote:
> > Why not? Of course you won't get any output before the graphics card has been
> > re-initialized to a sane and usable state...
> > 
> 
> True. I do it on my Dell 600m (Radeon 9000M) using usermodehelper and
> it works just fine. It works both with VGA and X. I need to split up
> the thaw_processes into two stages though. It may not work with fb as
> fb driver resumes earlier. I use the patch below for the kernel and a
> userlevel x86 emulator.
> 
> I have to say though, it will help if we have a such an emulator in the kernel.

Just a quick question: is this the right way to distinguish kernel
threads? I've been checking if the process has an mm context (if p->mm).

> +		if (p->parent->pid != 1)
> +			continue;

Regards,

Nigel
-- 
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901

Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.



-------------------------------------------------------
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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Helge Hafting]

On 14-10-2004 21:02:36, Kendall Bennett wrote:
> Hello All,
[...]
> 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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Helge Hafting <helgehaf@aitel.hist.no> wrote:

> On 14-10-2004 21:02:36, Kendall Bennett wrote:
> > Hello All,
> [...]
> > 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.

> > 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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Helge Hafting]

On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> 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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Helge Hafting <helgehaf@aitel.hist.no> wrote:

> On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> > Helge Hafting <helgehaf@aitel.hist.no> 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! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

> What this means is that it should be possible to build a new version of
> the VESA framebuffer console driver for the Linux kernel that will have
> these important features:
> 
> 1. Be able to switch display modes on the fly, supporting all modes
> enumerated by the Video BIOS.
> 
> 2. Be able to support refresh rate control on graphics cards that support
> the VBE 3.0 services.

How is this going to work if there are multiple graphics cards
installed? Each card will want to install it's own VBE extension
interrupt.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
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

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> I am writing this email to guage the interest in having code contributed 
> to the main stream Linux kernel that would support the user of a generic, 
> full featured VESA framebuffer driver that works on any CPU architecture 
> along with a generic Video card BOOT or POST mechanism.

This is pretty much neccessary for suspend-to-RAM, and there's a *lot*
of interest in that.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> I am writing this email to guage the interest in having code contributed 
> to the main stream Linux kernel that would support the user of a generic, 
> full featured VESA framebuffer driver that works on any CPU architecture 
> along with a generic Video card BOOT or POST mechanism.

BTW, does this look like right way to POST VGA BIOS from real mode? It
is what we currently use... and it works on some machines...

        movw    $0xb800, %ax
        movw    %ax,%fs
        movw    $0x0e00 + 'L', %fs:(0x10)

        cli
        cld

        # setup data segment
        movw    %cs, %ax
        movw    %ax, %ds                                        # Make ds:0 point to wakeup_start
        movw    %ax, %ss
        mov     $(wakeup_stack - wakeup_code), %sp              # Private stack is needed for ASUS board
        movw    $0x0e00 + 'S', %fs:(0x12)

        pushl   $0                                              # Kill any dangerous flags
        popfl

        movl    real_magic - wakeup_code, %eax
        cmpl    $0x12345678, %eax
        jne     bogus_real_magic

        testl   $1, video_flags - wakeup_code
        jz      1f
        lcall   $0xc000,$3
        movw    %cs, %ax
        movw    %ax, %ds                                        # Bios might have played with that
        movw    %ax, %ss
1:

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!