[lkml]   [2004]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Generic VESA framebuffer driver and Video card BOOT?
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

> 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
> but it doesn't work right yet. This driver is
> designed to run after the VGAdriver has reset the hardware.

Sounds interesting!


Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400

~ SciTech SNAP - The future of device driver technology! ~

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:07    [W:0.068 / U:1.716 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site