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

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

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>>         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
>
>The call to 0xC000:0x0003 is the entry point to POST the card. However 
>for PCI cards you need to make sure that AX is loaded with the 
>bus, slot 
>and function for the card that is being POST'ed. It will pass 
>this value 
>to the PCI BIOS Int 0x1A functions in order to find itself, so 
>if this is 
>not set many BIOS'es will not work.
>
>The rest of the code you have above seems superfluous to me as we have 
>never needed to do that. Then again we boot the card using the BIOS 
>emulator, which is different because it runs within a 
>protected machine 
>state.
>
>Have you taken a look at the X.org code? They have code in 
>there to POST 
>the video card also (either using vm86() or the BIOS emulator).
>

I have done some experiments with this video post stuff.
I think this should be done using x86 emulator rather than doing 
in real mode. The reason being, with an userlevel emulator we can call
it at different times during resume. The current real mode videopost
does 
it before the driver has restored the PCI config space. Some systems 
(mostly the ones with Radeon card) requires this to be done after 
PCI config space is restored. With a userspace emulator, we can 
call it at various places during the driver restore.

I have seen the SciTech's x86 emulator in X.org. I could seperate it out

from X into a stand alone application that does x86 emulation. I use it
to get 
the video back on my laptop (which has radeon card), by calling this
user level 
emulator using usermodehelper call. I hope we will have x86 emulator
sitting in 
a standard place in userspace. That way we can use it in driver restore
and 
solve the S3 video restore problem in a more generic way.

Thanks,
Venki

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

[Pavel Machek]

Hi!

> >The rest of the code you have above seems superfluous to me as we have 
> >never needed to do that. Then again we boot the card using the BIOS 
> >emulator, which is different because it runs within a 
> >protected machine 
> >state.
> >
> >Have you taken a look at the X.org code? They have code in 
> >there to POST 
> >the video card also (either using vm86() or the BIOS emulator).
> >
> 
> I have done some experiments with this video post stuff.
> I think this should be done using x86 emulator rather than doing 
> in real mode. The reason being, with an userlevel emulator we can call
> it at different times during resume. The current real mode videopost
> does 

Actually Ole Rohne has patch that allows you to call real mode any
time you want.
								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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:

> I have done some experiments with this video post stuff. I think
> this should be done using x86 emulator rather than doing in real
> mode. The reason being, with an userlevel emulator we can call it
> at different times during resume. The current real mode videopost
> does it before the driver has restored the PCI config space. Some
> systems (mostly the ones with Radeon card) requires this to be
> done after PCI config space is restored. With a userspace
> emulator, we can call it at various places during the driver
> restore. 
> 
> I have seen the SciTech's x86 emulator in X.org. I could seperate
> it out from X into a stand alone application that does x86
> emulation. I use it to get the video back on my laptop (which has
> radeon card), by calling this user level emulator using
> usermodehelper call. I hope we will have x86 emulator sitting in a
> standard place in userspace. That way we can use it in driver
> restore and solve the S3 video restore problem in a more generic
> way. 

We already have all this code completely separate from X and would 
release this as part of the Video Boot package for Linux. The kernel 
module is one part of it, but the code can be compiled as a stand alone 
user land program as well (SNAPBoot we call it right now). 

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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Jon Smirl [mailto:jonsmirl@gmail.com] 
>Sent: Friday, October 22, 2004 10:19 AM
>To: Pallipadi, Venkatesh
>Cc: Matthew Garrett; stefandoesinger@gmx.at; 
>linux-kernel@vger.kernel.org
>Subject: Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer 
>driver and Video card BOOT?
>
>On Fri, 22 Oct 2004 09:36:40 -0700, Pallipadi, Venkatesh
><venkatesh.pallipadi@intel.com> wrote:
>> Actually I sent the kernel patch to call some userlevel 
>vgapost utility
>> on this same thread around a week back. I am sending it here again.
>
>It is more complex to restart the VGA system when there are multiple
>cards. You have to disable all of the other VGA devices before
>reseting one otherwise you will end up with two enabled VGA devices
>and address ownership conflicts. You also have to move the PCI bus
>routing around so that it points to the correct card.
>
>There is a pending patch in mm, bk-pci, that exposes video ROMs via
>sysfs. That makes writing the reset program cleaner. You should not
>play with the ROM or the PIC bus routine from user space, that needs
>to be done in the kernel.
>

Yes. I looked at that patch which exposes video ROM through sysfs. 
But, we will also need either a kernel or user level x86 emulator, 
to use this ROM for things like vgapost. Right? 
I was using the video ROM exposed through sysfs for my userlevel 
emulation, until I found out the vgapost calls also uses some other 
things outside video ROM as it makes other INT calls internally.
That's when I moved out to use the X approach of mapping /dev/mem.

I agree with you on all the things about multiple VGA card and 
their initializations. But, I am more concerned about the more 
common single video card systems, which doesn't get video back after 
S3 suspend and resume, just because the kernel doesn't do vgapost 
at proper time. With thousands of such systems being used already, 
I feel we need to have some working solution for that sooner.

Thanks,
Venki

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

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Kendall Bennett [mailto:KendallB@scitechsoft.com] 
>Sent: Friday, October 22, 2004 10:11 AM
>To: Pallipadi, Venkatesh
>Cc: linux-kernel@vger.kernel.org; 
>linux-fbdev-devel@lists.sourceforge.net
>Subject: RE: [Linux-fbdev-devel] Re: Generic VESA framebuffer 
>driver and Video card BOOT?
>
>"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:
>
>> I have done some experiments with this video post stuff. I think
>> this should be done using x86 emulator rather than doing in real
>> mode. The reason being, with an userlevel emulator we can call it
>> at different times during resume. The current real mode videopost
>> does it before the driver has restored the PCI config space. Some
>> systems (mostly the ones with Radeon card) requires this to be
>> done after PCI config space is restored. With a userspace
>> emulator, we can call it at various places during the driver
>> restore. 
>> 
>> I have seen the SciTech's x86 emulator in X.org. I could seperate
>> it out from X into a stand alone application that does x86
>> emulation. I use it to get the video back on my laptop (which has
>> radeon card), by calling this user level emulator using
>> usermodehelper call. I hope we will have x86 emulator sitting in a
>> standard place in userspace. That way we can use it in driver
>> restore and solve the S3 video restore problem in a more generic
>> way. 
>
>We already have all this code completely separate from X and would 
>release this as part of the Video Boot package for Linux. The kernel 
>module is one part of it, but the code can be compiled as a 
>stand alone 
>user land program as well (SNAPBoot we call it right now). 
>

That is really nice to know. That will make "video on S3 resume" problem
go away on quite a few laptops. Will look forward to release of such a
code.

Thanks,
Venki

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

[Pallipadi, Venkatesh]

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

>-----Original Message-----
>From: Matthew Garrett [mailto:mgarrett@chiark.greenend.org.uk] 
>Sent: Thursday, October 21, 2004 6:39 PM
>To: Pallipadi, Venkatesh
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer 
>driver and Video card BOOT?
>
>Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:
>
>Hi,
>
>> Even I thought so. But, with the emulator it doesn't hang. It brings 
>> back my video. I double checked this using another vm86 
>emulator too. 
>> No hang even there. I couldn't figure out why Ole's patch won't work 
>> though. Right now I am using call_usermodehelper() to call the 
>> emulator during resume and the video comes back just fine on this 
>> system where Ole's patch didn't work.
>
>Is it possible to get this patch and code off you? I'd be interested in
>testing this solution on various bits of hardware I've been working on.
>

Actually I sent the kernel patch to call some userlevel vgapost utility 
on this same thread around a week back. I am sending it here again. 

I don't think sending a big userlevel code tar file is appropriate on
lkml. 
I will send that in a separate mail to Matthew and Stefan. If anyone
else 
wants to play with it, just let me know.

It works for me on various systems with Radeon card. It didn't help on 
systems with Intel Graphics card.

Stefan: Yes. Usermodehelper won't work during the driver resume. But, it

works later after the kernel threads are woken up. With attached patch
and
with user level vgapost I can get video back, both on X and VGA console.
It doesn't help with framebuffer, as the framebuffer reinitialization 
happens during the driver resume, which is earlier than this vgapost
call.


Thanks,
Venki

[-- Attachment #2: vgapost2.patch --]
[-- Type: application/octet-stream, Size: 1916 bytes --]

--- linux-2.6.9/kernel/power/main.c.org	2004-10-22 11:11:58.000000000 -0700
+++ linux-2.6.9/kernel/power/main.c	2004-10-22 11:15:45.000000000 -0700
@@ -93,6 +93,19 @@ static int suspend_enter(u32 state)
 	return error;
 }
 
+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);
+}
 
 /**
  *	suspend_finish - Do final work before exiting suspend sequence.
@@ -107,6 +120,10 @@ static void suspend_finish(u32 state)
 	device_resume();
 	if (pm_ops && pm_ops->finish)
 		pm_ops->finish(state);
+
+        thaw_processes_kernel();
+        vgapost_usermode();
+
 	thaw_processes();
 	pm_restore_console();
 }
--- linux-2.6.9/kernel/power/process.c.org	2004-10-22 11:12:14.000000000 -0700
+++ linux-2.6.9/kernel/power/process.c	2004-10-22 11:20:37.000000000 -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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

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

On Fri, 22 Oct 2004 09:36:40 -0700, Pallipadi, Venkatesh
<venkatesh.pallipadi@intel.com> wrote:
> Actually I sent the kernel patch to call some userlevel vgapost utility
> on this same thread around a week back. I am sending it here again.

It is more complex to restart the VGA system when there are multiple
cards. You have to disable all of the other VGA devices before
reseting one otherwise you will end up with two enabled VGA devices
and address ownership conflicts. You also have to move the PCI bus
routing around so that it points to the correct card.

There is a pending patch in mm, bk-pci, that exposes video ROMs via
sysfs. That makes writing the reset program cleaner. You should not
play with the ROM or the PIC bus routine from user space, that needs
to be done in the kernel.

Another proposal is that basic VGA control be moved to a separate
driver. I'll attach some code I started for this driver but I never
finished.

In a complete driver VGAcon should move to the active VGA device if
sysfs is used to change it.

-- 
Jon Smirl
jonsmirl@gmail.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: vga.patch --]
[-- Type: text/x-patch; name="vga.patch", Size: 15928 bytes --]

===== arch/i386/pci/fixup.c 1.21 vs edited =====
--- 1.21/arch/i386/pci/fixup.c	Sun Aug 29 00:21:23 2004
+++ edited/arch/i386/pci/fixup.c	Fri Sep 10 01:03:06 2004
@@ -225,7 +225,7 @@
  * issue another HALT within 80 ns of the initial HALT, the failure condition
  * is avoided.
  */
-static void __init pci_fixup_nforce2(struct pci_dev *dev)
+static void __devinit pci_fixup_nforce2(struct pci_dev *dev)
 {
 	u32 val, fixed_val;
 	u8 rev;
@@ -290,6 +290,6 @@
 		}
 		bus = bus->parent;
 	}
-	pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW;
+	pdev->resource[PCI_ROM_RESOURCE].flags |= IORESOURCE_ROM_SHADOW | IORESOURCE_VGA_ENABLE;
 }
 DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, pci_fixup_video);
===== drivers/pci/Kconfig 1.6 vs edited =====
--- 1.6/drivers/pci/Kconfig	Mon Aug  2 04:00:43 2004
+++ edited/drivers/pci/Kconfig	Fri Sep 10 01:03:06 2004
@@ -47,3 +47,13 @@
 
 	  When in doubt, say Y.
 
+config VGA_CONTROL
+	bool "VGA Control Device"
+	depends on PCI
+	---help---
+	  Provides a VGA Control Device for ensuring that only a single VGA
+	  device can be enabled per PCI domain. If a VGA device is removed
+	  via hotplug, display is routed to another VGA device if available.
+
+	  If you have more than one VGA device, say Y.
+
===== drivers/pci/Makefile 1.41 vs edited =====
--- 1.41/drivers/pci/Makefile	Sun Aug 29 00:21:23 2004
+++ edited/drivers/pci/Makefile	Sat Sep 11 22:44:22 2004
@@ -28,6 +28,7 @@
 obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
 obj-$(CONFIG_X86_VISWS) += setup-irq.o
 obj-$(CONFIG_PCI_MSI) += msi.o
+obj-$(CONFIG_VGA_CONTROL) += vga.o
 
 # Cardbus & CompactPCI use setup-bus
 obj-$(CONFIG_HOTPLUG) += setup-bus.o
===== drivers/pci/bus.c 1.9 vs edited =====
--- 1.9/drivers/pci/bus.c	Sat Apr 10 18:27:59 2004
+++ edited/drivers/pci/bus.c	Sat Sep 11 22:48:04 2004
@@ -100,7 +100,9 @@
 
 		pci_proc_attach_device(dev);
 		pci_create_sysfs_dev_files(dev);
-
+#if CONFIG_VGA_DEVICE
+		pci_vga_add_device(dev);
+#endif
 	}
 
 	list_for_each_entry(dev, &bus->devices, bus_list) {
===== drivers/pci/pci.h 1.13 vs edited =====
--- 1.13/drivers/pci/pci.h	Sun Aug 29 00:21:23 2004
+++ edited/drivers/pci/pci.h	Fri Sep 10 01:03:08 2004
@@ -11,6 +11,7 @@
 				  void (*alignf)(void *, struct resource *,
 					  	 unsigned long, unsigned long),
 				  void *alignf_data);
+int pci_vga_add_device(struct pci_dev *pdev);
 /* PCI /proc functions */
 #ifdef CONFIG_PROC_FS
 extern int pci_proc_attach_device(struct pci_dev *dev);
===== drivers/pci/setup-bus.c 1.25 vs edited =====
--- 1.25/drivers/pci/setup-bus.c	Sun Jul 11 08:41:20 2004
+++ edited/drivers/pci/setup-bus.c	Fri Sep 10 01:03:09 2004
@@ -51,16 +51,8 @@
 	struct resource_list head, *list, *tmp;
 	int idx;
 
-	bus->bridge_ctl &= ~PCI_BRIDGE_CTL_VGA;
-
 	head.next = NULL;
 	list_for_each_entry(dev, &bus->devices, bus_list) {
-		u16 class = dev->class >> 8;
-
-		if (class == PCI_CLASS_DISPLAY_VGA
-				|| class == PCI_CLASS_NOT_DEFINED_VGA)
-			bus->bridge_ctl |= PCI_BRIDGE_CTL_VGA;
-
 		pdev_sort_resources(dev, &head);
 	}
 
@@ -499,12 +491,6 @@
 
 	pbus_assign_resources_sorted(bus);
 
-	if (bus->bridge_ctl & PCI_BRIDGE_CTL_VGA) {
-		/* Propagate presence of the VGA to upstream bridges */
-		for (b = bus; b->parent; b = b->parent) {
-			b->bridge_ctl |= PCI_BRIDGE_CTL_VGA;
-		}
-	}
 	list_for_each_entry(dev, &bus->devices, bus_list) {
 		b = dev->subordinate;
 		if (!b)
===== drivers/pci/vga.c 1.1 vs edited =====
--- 1.1/drivers/pci/vga.c	Fri Sep 10 01:01:47 2004
+++ edited/drivers/pci/vga.c	Sat Sep 11 01:05:37 2004
@@ -1 +1,381 @@
+/*
+ * linux/drivers/char/vga.c
+ *
+ * (C) Copyright 2004 Jon Smirl <jonsmirl@gmail.com>
+ *
+ * VGA control device for ensuring only a single enabled VGA device
+ *
+ * Reuses the DRM major 226, starts minors at VGA_MINOR_BASE, 0x200
+ */
+
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/cdev.h>
+#include <linux/pci.h>
+#include <linux/major.h>
+#include <linux/vga.h>
+
+struct vga_dev {
+	struct class_device class_dev;
+	struct list_head node;
+	dev_t dev;
+	int enabled;
+};
+#define to_vga_dev(d) container_of(d, struct vga_dev, class_dev)
+
+static struct class *vga_class;
+static struct vga_dev *vga_device;
+static DECLARE_MUTEX(vga_mutex);
+static int vga_initialized;	/* = 0 */
+
+/*
+ * Open/close code for vga IO.
+ */
+static int vga_open(struct inode *inode, struct file *filp)
+{
+//	const int minor = iminor(inode);
+
+	down(&vga_mutex);
+	up(&vga_mutex);
+
+	return 0;
+}
+
+/*
+ */
+static int vga_release(struct inode *inode, struct file *filp)
+{
+	down(&vga_mutex);
+	up(&vga_mutex);
+
+	return 0;
+}
+
+/*
+ */
+static int
+vga_ioctl(struct inode *inode, struct file *filp,
+		  unsigned int command, unsigned long arg)
+{
+	return 0;
+}
+
+static struct file_operations vga_fops = {
+	.open	=	vga_open,
+	.release=	vga_release,
+	.ioctl	=	vga_ioctl,
+	.owner	=	THIS_MODULE,
+};
+
+static struct cdev vga_cdev = {
+	.kobj	=	{.name = "vga", },
+	.owner	=	THIS_MODULE,
+};
+
+static void bridge_yes(drm_device_t *dev)
+{
+	struct pci_dev *bridge;
+	struct pci_bus *bus;
+	
+	/* Make sure the bridges route to us */
+	bus = dev->pdev->bus;
+	while (bus) {
+		bridge = bus->self;
+		if (bridge) {
+			pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, &pbus->bridge_ctl);
+			pbus->bridge_ctl |= PCI_BRIDGE_CTL_VGA;
+			pci_write_config_word(bridge, PCI_BRIDGE_CONTROL, pbus->bridge_ctl);
+		}
+		bus = bus->parent;
+	}
+}
+
+static void bridge_no(drm_device_t *dev)
+{
+	struct pci_dev *bridge;
+	struct pci_bus *bus;
+	
+	/* Make sure the bridges don't route to us */
+	bus = dev->pdev->bus;
+	while (bus) {
+		bridge = bus->self;
+		if (bridge) {
+			pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, &pbus->bridge_ctl);
+			pbus->bridge_ctl &= ~PCI_BRIDGE_CTL_VGA;
+			pci_write_config_word(bridge, PCI_BRIDGE_CONTROL, pbus->bridge_ctl);
+		}
+		bus = bus->parent;
+	}
+}
+
+
+/* sysfs for VGA device */
+static ssize_t vga_device_show(struct device *dev, char *buf)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	return sprintf(bus, "%d\n", (pdev->resource[PCI_ROM_RESOURCE].flags & IORESOURCE_VGA_ENABLE) != 0);
+}
+static ssize_t vga_device_store(struct device *dev, const char *buf, size_t count)
+{
+	return count;
+}
+static struct device_attribute vga_device_attr = __ATTR(vga, S_IRUGO|S_IWUSR, vga_device_show, vga_device_store);
+
+/* sysfs for VGA routing bridge */
+static ssize_t vga_bridge_show(struct device *dev, char *buf)
+{
+	struct pci_dev *pdev = to_pci_dev(dev);
+	u16 l;
+
+	/* don't trust the shadow PCI_BRIDGE_CTL_VGA in pdev */
+	/* user space may change hardware without telling the kernel */
+	pci_read_config_word(pdev, PCI_BRIDGE_CONTROL, &l);
+	return sprintf(buf, "%d\n", (l & PCI_BRIDGE_CTL_VGA) != 0);
+}
+static struct device_attribute vga_bridge_attr = __ATTR(vga, S_IRUGO, vga_bridge_show, NULL);
+
+/* sysfs for VGA root legacy space */
+static ssize_t vga_root_show(struct class_device *class_dev, char *buf)
+{
+	struct vga_dev *vga = to_vga_dev(class_dev);
+	return sprintf(buf, "%d\n", vga->enabled);
+}
+static ssize_t vga_root_store(struct class_device *class_dev, const char *buf, size_t count)
+{
+	char *endp;
+	struct vga_dev *vga = to_vga_dev(class_dev);
+	
+	vga->enabled =  (simple_strtoul(buf, &endp, 0) != 0);
+	return count;
+}
+static struct class_device_attribute vga_root_attr = __ATTR(vga, S_IRUGO|S_IWUSR, vga_root_show, vga_root_store);
+
+/* sysfs for /class/vga/vga0/dev */
+static ssize_t show_dev(struct class_device *class_dev, char *buf)
+{
+	struct vga_dev *vga = to_vga_dev(class_dev);
+	return print_dev_t(buf, vga->dev);
+}
+CLASS_DEVICE_ATTR(dev, S_IRUGO, show_dev, NULL);
+
+int pci_vga_add_device(struct pci_dev *pdev)
+{
+	char name[20];
+	int class = pdev->class >> 8;
+
+	if (!vga_initialized)
+		return -EACCES;
+
+	if (class == PCI_CLASS_DISPLAY_VGA) {
+		device_create_file(&pdev->dev, &vga_device_attr);
+		snprintf(name, sizeof(name), "%04x:%02x:%02x.%d", pci_domain_nr(pdev->bus), 
+			pdev->bus->number, PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+		sysfs_create_link(&vga_device->class_dev.kobj, &pdev->dev.kobj, name);
+		return 0;
+	}
+
+	if ((class == PCI_CLASS_BRIDGE_PCI) || (class == PCI_CLASS_BRIDGE_CARDBUS)) {
+		device_create_file(&pdev->dev, &vga_bridge_attr);
+	}
+
+	return 0;
+}
+
+static int __init vga_init(void)
+{
+	int ret;
+	dev_t dev;
+	int minor = 0;
+	struct pci_dev *pdev = NULL;
+
+	vga_initialized = 1;
+	dev = MKDEV(DRM_MAJOR, VGA_MINOR_BASE);
+
+	if (register_chrdev_region(dev, VGA_MINOR_MAX, "vga"))
+		goto err_i1;
+
+	cdev_init(&vga_cdev, &vga_fops);
+	if (cdev_add(&vga_cdev, dev, VGA_MINOR_MAX)) {
+		kobject_put(&vga_cdev.kobj);
+		goto err_i2;
+	}
+
+	vga_class = kmalloc(sizeof(*vga_class), GFP_KERNEL);
+	if (!vga_class)
+		goto err_i3;
+	memset(vga_class, 0x00, sizeof(*vga_class));
+
+	vga_class->name = "vga";
+	if ((ret = class_register(vga_class)))
+		goto err_i4;
+
+	vga_device = kmalloc(sizeof(*vga_device), GFP_KERNEL);
+	if (!vga_device)
+		goto err_i5;
+	memset(vga_device, 0x00, sizeof(*vga_device));
+
+	vga_device->dev = MKDEV(DRM_MAJOR, VGA_MINOR_BASE + minor);
+	vga_device->class_dev.dev = NULL;
+	vga_device->class_dev.class = vga_class;
+	snprintf(vga_device->class_dev.class_id, BUS_ID_SIZE, "vga%d", minor);
+	
+	if ((ret = class_device_register(&vga_device->class_dev)))
+		goto err_i6;
+
+	class_device_create_file(&vga_device->class_dev, &class_device_attr_dev);
+	class_device_create_file(&vga_device->class_dev, &vga_root_attr);
+
+	while ((pdev = pci_find_device(PCI_ANY_ID, PCI_ANY_ID, pdev)) != NULL)
+		pci_vga_add_device(pdev);
+		
+	printk(KERN_INFO "VGA control device 1.0 initialized\n");
+
+	return 0;
+
+err_i6:
+	kfree(vga_device);
+err_i5:
+	class_unregister(vga_class);
+err_i4:
+	kfree(vga_class);
+err_i3:
+	cdev_del(&vga_cdev);
+err_i2:
+	unregister_chrdev_region(dev, VGA_MINOR_MAX);
+err_i1:
+	printk(KERN_ERR "error initializing VGA control device\n");
+	return 1;
+}
+
+static void __exit vga_exit(void)
+{
+	class_device_unregister(&vga_device->class_dev);
+	kfree(vga_device);
+	class_unregister(vga_class);
+	kfree(vga_class);
+	cdev_del(&vga_cdev);
+	unregister_chrdev_region(MKDEV(DRM_MAJOR, VGA_MINOR_BASE), VGA_MINOR_MAX);
+}
+
+__initcall(vga_init);
+__exitcall(vga_exit);
+
+
+
+/*
+ * 0 - Disable all VGA and cards
+ * 1 - Enable only active card and VGA (assumes other devices are disabled)
+ * 2 - Enable all pci devices
+ *
+ * This is a driver specific function accessed via DRM(stub)
+ * doing it this way allows for driver specific overrides if needed
+ */
+#define VE_DISABLE 0
+#define VE_ACTIVE 1
+#define VE_ENABLE 2
+int DRM(vgaenable)(int enable, int clear_active) {
+	int i;
+	drm_device_t *dev;
+	
+	switch (enable) {	
+	case VE_DISABLE:
+		/* disable all VGA and all devices */
+		/* loop over all the driver's cards */
+		for (i = 0; i < DRM(numdevs); i++) {
+			dev = &DRM(device)[i];
+			if (clear_active)
+				dev->vga_active = FALSE;
+		
+			bridge_yes(dev);
+			/* 0x3CC and 0x3C2 are correct, it's not a typo */
+			outb(~0x03 & inb(0x3CC),  0x3C2);
+			outb(~0x01 & inb(0x3C3),  0x3C3);
+			outb(~0x08 & inb(0x46e8), 0x46e8);
+			outb(~0x01 & inb(0x102),  0x102);
+			pci_disable_device(dev->pdev);
+			bridge_no(dev);
+		}
+		return 0;
+	case VE_ACTIVE:
+		/* enable device and VGA on active device */	
+		/* loop over all the driver's cards */
+		for (i = 0; i < DRM(numdevs); i++) {
+			dev = &DRM(device)[i];
+			if (!dev->vga_active)
+				continue;
+			/* this assumes all other potential VGA devices are disabled */
+			bridge_yes(dev);
+			pci_enable_device(dev->pdev);
+			/* 0x3CC and 0x3C2 are correct, it's not a typo */
+			outb(0x03 | inb(0x3CC),  0x3C2);
+			outb(0x01 | inb(0x3C3),  0x3C3);
+			outb(0x08 | inb(0x46e8), 0x46e8);
+			outb(0x01 | inb(0x102),  0x102);
+			return 0;
+		}
+		return 0;
+	case VE_ENABLE:
+		/* loop over all the driver's cards */
+		for (i = 0; i < DRM(numdevs); i++) {
+			dev = &DRM(device)[i];
+			pci_enable_device(dev->pdev);
+		}
+		return 0;
+	default:
+		return -1;
+	}
+}
+
+/*
+ * VGA_ENABLE_ACTIVE=0 - Make sure all DRM VGAs are disabled, if this one not active reenable active VGA
+ * VGA_ENABLE_THIS=1 - Make sure all DRM VGAs are disabled and enable this DRM VGA, mark as active VGA
+ * Used while resetting a board
+ * VGA_DISABLE_ALL=2 - Disable all DRM VGA and devices, remember active VGA
+ */
+int DRM(vga_enable)( DRM_IOCTL_ARGS ) {
+	DRM_DEVICE;
+	drm_file_t *filp_priv;
+	drm_vga_enable_t ve;
+	struct drm_stub_info *pStub;
+	
+	DRM_GET_PRIV_WITH_RETURN( filp_priv, filp );
+
+	DRM_COPY_FROM_USER_IOCTL( ve, ( drm_vga_enable_t* )data, sizeof( ve ) );
+
+	if ((ve.enable < VGA_ENABLE_ACTIVE) || (ve.enable > VGA_DISABLE_ALL))
+		return -1;
+
+	/* First disable all VGA and all devices */
+	/* loop over all drivers */
+	pStub = &DRM(stub_info);
+	do {
+		/* clear the active device if enable 1 */
+		pStub->vgaenable(VE_DISABLE, (ve.enable == VGA_ENABLE_THIS));
+		pStub = pStub->next;
+	} while (pStub != &DRM(stub_info));
+	
+	if (ve.enable == VGA_DISABLE_ALL)
+		return 0;
+
+	/* Mark us active if requested */	
+	if (ve.enable == VGA_ENABLE_THIS)
+		dev->vga_active = TRUE;
+		
+	/* Now enable VGA on the target device */
+	/* loop over all drivers; don't know where the device is */
+	pStub = &DRM(stub_info);
+	do {
+		pStub->vgaenable(VE_ACTIVE, 0);
+		pStub = pStub->next;
+	} while (pStub != &DRM(stub_info));
+	
+	/* Reenable all PCI devices but don't touch VGA state */
+	pStub = &DRM(stub_info);
+	do {
+		pStub->vgaenable(VE_ENABLE, 0);
+		pStub = pStub->next;
+	} while (pStub != &DRM(stub_info));
+	
+	return 0;
+}
 
===== include/linux/ioport.h 1.15 vs edited =====
--- 1.15/include/linux/ioport.h	Sun Aug 29 00:21:23 2004
+++ edited/include/linux/ioport.h	Fri Sep 10 01:03:10 2004
@@ -41,7 +41,6 @@
 #define IORESOURCE_CACHEABLE	0x00004000
 #define IORESOURCE_RANGELENGTH	0x00008000
 #define IORESOURCE_SHADOWABLE	0x00010000
-#define IORESOURCE_BUS_HAS_VGA	0x00080000
 
 #define IORESOURCE_DISABLED	0x10000000
 #define IORESOURCE_UNSET	0x20000000
@@ -86,6 +85,7 @@
 #define IORESOURCE_ROM_ENABLE		(1<<0)	/* ROM is enabled, same as PCI_ROM_ADDRESS_ENABLE */
 #define IORESOURCE_ROM_SHADOW		(1<<1)	/* ROM is copy at C000:0 */
 #define IORESOURCE_ROM_COPY		(1<<2)	/* ROM is alloc'd copy, resource field overlaid */
+#define IORESOURCE_VGA_ENABLE		(1<<3)	/* VGA device is active */
 
 /* PC/ISA/whatever - the normal PC address spaces: IO and memory */
 extern struct resource ioport_resource;
===== include/linux/major.h 1.12 vs edited =====
--- 1.12/include/linux/major.h	Fri Mar 19 00:59:29 2004
+++ edited/include/linux/major.h	Fri Sep 10 21:29:53 2004
@@ -160,6 +160,7 @@
 
 #define OSST_MAJOR		206	/* OnStream-SCx0 SCSI tape */
 
+#define DRM_MAJOR		226	/* Direct Rendering Manager */
 #define IBM_TTY3270_MAJOR	227
 #define IBM_FS3270_MAJOR	228
 
===== include/linux/vga.h 1.1 vs edited =====
--- 1.1/include/linux/vga.h	Fri Sep 10 01:01:47 2004
+++ edited/include/linux/vga.h	Fri Sep 10 21:41:00 2004
@@ -1 +1,14 @@
+/*
+ * include/linux/vga.h
+ *
+ * (C) Copyright 2004 Jon Smirl <jonsmirl@yahoo.com>
+ *
+ * VGA control device for ensuring only a single enabled VGA device
+ */
  
+/* VGA device shares it's major device number with the DRM devices */
+/* DRM_MAJOR defines the major number in major.h */
+
+#define VGA_MINOR_BASE	0x200	/* First VGA minor starts here */
+#define VGA_MINOR_MAX	16 
+

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

[Stefan Dösinger]

> Actually I sent the kernel patch to call some userlevel vgapost utility
> on this same thread around a week back. I am sending it here again.
>
> I don't think sending a big userlevel code tar file is appropriate on
> lkml.
> I will send that in a separate mail to Matthew and Stefan. If anyone
> else
> wants to play with it, just let me know.
>
> It works for me on various systems with Radeon card. It didn't help on
> systems with Intel Graphics card.
Works for me too. You can add "Acer Travelmate 800" to the it_works_on 
list ;-)

> Stefan: Yes. Usermodehelper won't work during the driver resume. But, it
>
> works later after the kernel threads are woken up. With attached patch
> and
> with user level vgapost I can get video back, both on X and VGA console.
> It doesn't help with framebuffer, as the framebuffer reinitialization
> happens during the driver resume, which is earlier than this vgapost
> call.
I expected this, but I hoped that it works somehow with radeonfb.

Stefan

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

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Pavel Machek
>Sent: Thursday, October 21, 2004 4:23 PM
>To: Pallipadi, Venkatesh
>Cc: Kendall Bennett; linux-kernel@vger.kernel.org; 
>linux-fbdev-devel@lists.sourceforge.net; stefandoesinger@gmx.at
>Subject: Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer 
>driver and Video card BOOT?
>
>Hi!
>
>> >> I have done some experiments with this video post stuff.
>> >> I think this should be done using x86 emulator rather than doing 
>> >> in real mode. The reason being, with an userlevel emulator 
>> >we can call
>> >> it at different times during resume. The current real 
>mode videopost
>> >> does 
>> >
>> >Actually Ole Rohne has patch that allows you to call real mode any
>> >time you want.
>> 
>> Yes. I tried Ole's patch. That helped on one of my laptops. But, on 
>> the other one it doesn't work. It goes into real mode but 
>never returns.
>> Both systems had Radeom 9000M cards, but one with older 
>version of the 
>> firmware (didn't work) and one with newer version.
>> 
>> IIRC, even Stefan had similar problems with Ole's patch.
>
>It did not work for me, either, but I verified that it works as
>expected if I comment out actuall call of BIOS. So the problem is not
>with Ole's patch but with bios, and it may be the same if you emulate
>it...
>
>[Of course, it will not crash whole system when emulated, but system
>without video is not too good, either].

Even I thought so. But, with the emulator it doesn't hang. It brings 
back my video. I double checked this using another vm86 emulator too. 
No hang even there. I couldn't figure out why Ole's patch won't work 
though. Right now I am using call_usermodehelper() to call the 
emulator during resume and the video comes back just fine on this 
system where Ole's patch didn't work.

Thanks,
Venki

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

[Matthew Garrett]

Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> wrote:

Hi,

> Even I thought so. But, with the emulator it doesn't hang. It brings 
> back my video. I double checked this using another vm86 emulator too. 
> No hang even there. I couldn't figure out why Ole's patch won't work 
> though. Right now I am using call_usermodehelper() to call the 
> emulator during resume and the video comes back just fine on this 
> system where Ole's patch didn't work.

Is it possible to get this patch and code off you? I'd be interested in
testing this solution on various bits of hardware I've been working on.

Thanks,
-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

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

[Stefan Dösinger]

> Right now I am using call_usermodehelper() to call the
> emulator during resume and the video comes back just fine on this
> system where Ole's patch didn't work.
Can you explain me how you do this? call_usermodehelper() doesn't work for me 
at resume time.

BTW, I had a look at the radeon card's resume code at 0xc000:3 and attempted 
to implement it in a kernel module. The code is pretty simple, but it's quite 
long. My module isn't finished, it only turns off the display and resets the 
memory. I had to stop because I've a lot of things to do for school now.

Ole Rohne meant that the code is potentially dangerous because it pokes around 
with undocumented PLL registers, so I will not send it to the list: I will 
send it only to those who explicitly ask for it.

Stefan Dösinger

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

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: Pavel Machek [mailto:pavel@ucw.cz] 
>Sent: Thursday, October 21, 2004 4:00 PM
>To: Pallipadi, Venkatesh
>Cc: Kendall Bennett; linux-kernel@vger.kernel.org; 
>linux-fbdev-devel@lists.sourceforge.net
>Subject: Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer 
>driver and Video card BOOT?
>
>Hi!
>
>> >The rest of the code you have above seems superfluous to me 
>as we have 
>> >never needed to do that. Then again we boot the card using the BIOS 
>> >emulator, which is different because it runs within a 
>> >protected machine 
>> >state.
>> >
>> >Have you taken a look at the X.org code? They have code in 
>> >there to POST 
>> >the video card also (either using vm86() or the BIOS emulator).
>> >
>> 
>> I have done some experiments with this video post stuff.
>> I think this should be done using x86 emulator rather than doing 
>> in real mode. The reason being, with an userlevel emulator 
>we can call
>> it at different times during resume. The current real mode videopost
>> does 
>
>Actually Ole Rohne has patch that allows you to call real mode any
>time you want.
>								Pavel

Yes. I tried Ole's patch. That helped on one of my laptops. But, on 
the other one it doesn't work. It goes into real mode but never returns.
Both systems had Radeom 9000M cards, but one with older version of the 
firmware (didn't work) and one with newer version.

IIRC, even Stefan had similar problems with Ole's patch.

Thanks,
Venki

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

[Pavel Machek]

Hi!

> >> I have done some experiments with this video post stuff.
> >> I think this should be done using x86 emulator rather than doing 
> >> in real mode. The reason being, with an userlevel emulator 
> >we can call
> >> it at different times during resume. The current real mode videopost
> >> does 
> >
> >Actually Ole Rohne has patch that allows you to call real mode any
> >time you want.
> 
> Yes. I tried Ole's patch. That helped on one of my laptops. But, on 
> the other one it doesn't work. It goes into real mode but never returns.
> Both systems had Radeom 9000M cards, but one with older version of the 
> firmware (didn't work) and one with newer version.
> 
> IIRC, even Stefan had similar problems with Ole's patch.

It did not work for me, either, but I verified that it works as
expected if I comment out actuall call of BIOS. So the problem is not
with Ole's patch but with bios, and it may be the same if you emulate
it...

[Of course, it will not crash whole system when emulated, but system
without video is not too good, either].
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

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?

[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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 02:36, Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > On 14-10-2004 21:02:36, Kendall Bennett wrote:
>
> How does the framebuffer console system handle secondary controllers
> right now? It seems from my look at the code that it only brings up the
> primary and not the secondary?

By default, the first driver to initialize is used by the fb console.   If
there are more than 1 fb driver, one can either use:

- con2fbmap
- the "fbcon=map:abcd" kernel boot option

Of course, the secondary card must be POSTed.

Tony

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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
> 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:
> > That's fine.  What I meant, was please make it independent of the
> > VESA framebuffer driver, because one might want to use an
> > acellerated driver when one is available.
>
> Oh, it already is. The VESA driver is not actually done yet so the only
> drivers using VideoBoot right now are the accelerated ones ;-)
>

If these get in (emulator with/without the video boot), I'm willing to
modify the vesafb driver.

Tony

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

[Paulo Marques]

Antonino A. Daplas wrote:
> On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
> 
>>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:
>>>
>>>That's fine.  What I meant, was please make it independent of the
>>>VESA framebuffer driver, because one might want to use an
>>>acellerated driver when one is available.
>>
>>Oh, it already is. The VESA driver is not actually done yet so the only
>>drivers using VideoBoot right now are the accelerated ones ;-)
>>
> 
> 
> If these get in (emulator with/without the video boot), I'm willing to
> modify the vesafb driver.

Well, I played with the emulator last night to see if I could reduce the 
code size, so that it would be easier to make it to the official kernel.

I only took ops.c and did some transformations, like using a single 
function to make several operations based on the opcode, instead of a 
separate function for each opcode, etc.[1]

This is the result. Before:

Size of stripped libx86emu.a: ~74kb
ops.c source code lines: 11682
ops.o .text size: 36136
ops.o .data: 1312

After:

Size of stripped libx86emu.a: ~57kb
ops.c source code lines: 5908
ops.o .text size: 19320
ops.o .data: 1280

If the same treatment is applied to ops2.c and prim_ops.c, I believe it 
would be possible to have a functional emulator for about 32kb of kernel 
code size, which seems pretty reasonable to me and could solve a lot of 
problems.

The decrease in source code size also helps maintenance, since there is 
not so much repeated code has it was before.

Of course, these changes are optimizing the emulator for code size, and 
not execution speed. I haven't done any benchmarks to see if there is a 
noticeable difference in speed.






[1] The worst offenders were actually constructions like:

FETCH_DECODE_MODRM(mod, rh, rl);
switch (mod) {
   case 0:
       ...<some code>
       addr = decode_rm00_address(rl);
       ...<some more code>
       break;
   case 1:
       ...<exactly the same code as above>
       addr = decode_rm01_address(rl);
       ...<exactly the same code as above>
       break;
   case 2:
       ...<exactly the same code as above>
       addr = decode_rm10_address(rl);
       ...<exactly the same code as above>
       break;
    case 3:
       <diferent code to handle register-register ops>
       break;
   }

This could be easily changed to:

FETCH_DECODE_MODRM(mod, rh, rl);
if (mod < 3) {
       ...<some code>
       addr = decode_rmXX_address(mod, rl);
       ...<some more code>
   } else {
       <diferent code to handle register-register ops>
   }

simply by making a new decode_rmXX_address function that handles the mod 
parameter. There were more than 20 of these, and some of them were 
pretty big.

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

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

[Kendall Bennett]

Paulo Marques <pmarques@grupopie.com> wrote:

> Well, I played with the emulator last night to see if I could
> reduce the code size, so that it would be easier to make it to the
> official kernel. 
> 
> I only took ops.c and did some transformations, like using a
> single function to make several operations based on the opcode,
> instead of a separate function for each opcode, etc.[1] 
> 
> This is the result. Before:
> 
> Size of stripped libx86emu.a: ~74kb
> ops.c source code lines: 11682
> ops.o .text size: 36136
> ops.o .data: 1312
> 
> After:
> 
> Size of stripped libx86emu.a: ~57kb
> ops.c source code lines: 5908
> ops.o .text size: 19320
> ops.o .data: 1280
> 
> If the same treatment is applied to ops2.c and prim_ops.c, I
> believe it would be possible to have a functional emulator for
> about 32kb of kernel code size, which seems pretty reasonable to
> me and could solve a lot of problems. 

Wow, that is great!

> The decrease in source code size also helps maintenance, since
> there is not so much repeated code has it was before. 
> 
> Of course, these changes are optimizing the emulator for code
> size, and not execution speed. I haven't done any benchmarks to
> see if there is a noticeable difference in speed. 

Did you get the latest code? I have been sick with the flu and I think I 
forgot to send you the latest code to play with. We should get you set up 
so you can merge your changes into our tree and then we can update the 
one in the X.org tree as well (Egbert Eich usually does that from our 
tree).

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

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

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

[Paulo Marques]

Kendall Bennett wrote:
> Paulo Marques <pmarques@grupopie.com> wrote:
> .....
>>If the same treatment is applied to ops2.c and prim_ops.c, I
>>believe it would be possible to have a functional emulator for
>>about 32kb of kernel code size, which seems pretty reasonable to
>>me and could solve a lot of problems. 
> 
> 
> Wow, that is great!

Thanks :)

> 
>>The decrease in source code size also helps maintenance, since
>>there is not so much repeated code has it was before. 
>>
>>Of course, these changes are optimizing the emulator for code
>>size, and not execution speed. I haven't done any benchmarks to
>>see if there is a noticeable difference in speed. 
> 
> 
> Did you get the latest code? I have been sick with the flu and I think I 
> forgot to send you the latest code to play with. We should get you set up 
> so you can merge your changes into our tree and then we can update the 
> one in the X.org tree as well (Egbert Eich usually does that from our 
> tree).

No, I didn't get the latest source (you did disapear for a while :) ).

I started to work on the old source because:

  A - I really wanted to know if this could be done and what kind of 
improvements could be expected, even if the actual changes were thrown 
away in the end

  B - you said that only small bug fixes were made since this version, 
so I probably could diff the source I started from against the latest 
and do the same fixes to my latest source.

One other thing, is there a simple way to test the emulator? I've been 
careful with the changes I did not to change the resulting behaviour of 
the emulator, but I can not _absolutely_ sure that I didn't break 
anything. It would be very good to try the emulator in a controlled 
environment.

Anyway, I think I'll have some more time tonight, so probably tomorrow 
I'll have more information about the final code size.

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

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

[Kendall Bennett]

Paulo Marques <pmarques@grupopie.com> wrote:

> One other thing, is there a simple way to test the emulator? I've
> been careful with the changes I did not to change the resulting
> behaviour of the emulator, but I can not _absolutely_ sure that I
> didn't break anything. It would be very good to try the emulator
> in a controlled environment. 

Unfortunately the test code I wrote years ago is only for Open Watcom and 
uses inline assembler. It hasn't been used for some time and I am not 
sure if it works properly or not (I don't think it does right now). Plus 
we recently found out that it doesn't test everything, just the 
implementation of prim_ops.c.

The only real way to test the emulator is to use it to emulate some code. 
We don't have any code we use on a regular basis to test it, but perhaps 
we should think about building a test suite for it. Usually we test it on 
Video BIOS ROM's, but that is painful because you have to switch video 
cards all the time.

XFree86 and X.org do use the same code so it could be tested there, but 
once again it is only used for Video BIOS ROM stuff. 

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

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

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

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

[Kendall Bennett]

Jon Smirl <jonsmirl@gmail.com> wrote:

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

Yep. The code I have ported to the Linux kernel right now does not 
support multiple consoles because porting that code would be a lot more 
work (I would prefer to keep it in userland if possible since it already 
works there).

Anyway the way the system works for multiple controllers is that there is 
a separate BIOS image and separate machine state maintained for each 
graphics card. So you can run the VBE driver on the primary, secondary 
and ternary drivers if you want. We do it all the time with SNAP just for 
fun and giggles ;-)

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?

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

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

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

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

What is this for?

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

We have never needed to set up a private stack. What ASUS board was it 
that you had problems with and needed to do this for?

>         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

The call to 0xC000:0x0003 is the entry point to POST the card. However 
for PCI cards you need to make sure that AX is loaded with the bus, slot 
and function for the card that is being POST'ed. It will pass this value 
to the PCI BIOS Int 0x1A functions in order to find itself, so if this is 
not set many BIOS'es will not work.

The rest of the code you have above seems superfluous to me as we have 
never needed to do that. Then again we boot the card using the BIOS 
emulator, which is different because it runs within a protected machine 
state.

Have you taken a look at the X.org code? They have code in there to POST 
the video card also (either using vm86() or the BIOS emulator).

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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> > 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)
> 
> What is this for?

Debugging.

> >         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)
> 
> We have never needed to set up a private stack. What ASUS board was it 
> that you had problems with and needed to do this for?

This is running at system resume, so it is not normal boot. Some ASUS
Athlon 900MHz machine needed this; I'm no longer using this one.

> >         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
> 
> The call to 0xC000:0x0003 is the entry point to POST the card. However 
> for PCI cards you need to make sure that AX is loaded with the bus, slot 
> and function for the card that is being POST'ed. It will pass this value 
> to the PCI BIOS Int 0x1A functions in order to find itself, so if this is 
> not set many BIOS'es will not work.

Ok, this one is bad... ... In case of just one vga adapter, we should
be able to store its parameters in some well-known place. For more
than one adapter, we'll definitely need to run BIOS in emulator.

								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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

> > > 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)
> > 
> > What is this for?
> 
> Debugging.

Ok ;-)

> > >         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)
> > 
> > We have never needed to set up a private stack. What ASUS board was it 
> > that you had problems with and needed to do this for?
> 
> This is running at system resume, so it is not normal boot. Some
> ASUS Athlon 900MHz machine needed this; I'm no longer using this
> one. 

Ok. For the BIOS emulator the code always has it's own local stack anyway 
so I assume the problme you had may have been that the BIOS on the board 
was using too much stack space, so setting up a local stack that is big 
enough is probably a good idea.

> > >         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
> > 
> > The call to 0xC000:0x0003 is the entry point to POST the card. However 
> > for PCI cards you need to make sure that AX is loaded with the bus, slot 
> > and function for the card that is being POST'ed. It will pass this value 
> > to the PCI BIOS Int 0x1A functions in order to find itself, so if this is 
> > not set many BIOS'es will not work.
> 
> Ok, this one is bad... ... In case of just one vga adapter, we
> should be able to store its parameters in some well-known place.
> For more than one adapter, we'll definitely need to run BIOS in
> emulator. 

Yes. If you are running this in real mode you don't have any option but 
to use the BIOS emulator. If you are running in protected mode and using 
vm86() style service, the 0xC0000 memory is just memory and can be re-
written. For instance on Linux you can map 0xC0000 into your process 
address space as copy on write, which then allows you to re-write the 
BIOS image for a secondary controller and then restore it when you are 
done.

But you will also need to make sure you can hook the Int 0x1A interrupt 
to hide any other graphics cards on the bus as some BIOS'es are pretty 
stupid and will find the first card on the bus that matches their 
Vendor/Device ID's. So if you have two of the same card, it will find th 
wrong 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! ~

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

[Pavel Machek]

Hi!

> > > >         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
> > > 
> > > The call to 0xC000:0x0003 is the entry point to POST the card. However 
> > > for PCI cards you need to make sure that AX is loaded with the bus, slot 
> > > and function for the card that is being POST'ed. It will pass this value 
> > > to the PCI BIOS Int 0x1A functions in order to find itself, so if this is 
> > > not set many BIOS'es will not work.
> > 
> > Ok, this one is bad... ... In case of just one vga adapter, we
> > should be able to store its parameters in some well-known place.
> > For more than one adapter, we'll definitely need to run BIOS in
> > emulator. 
> 
> Yes. If you are running this in real mode you don't have any option but 
> to use the BIOS emulator. If you are running in protected mode and using 
> vm86() style service, the 0xC0000 memory is just memory and can be re-
> written. For instance on Linux you can map 0xC0000 into your process 
> address space as copy on write, which then allows you to re-write the 
> BIOS image for a secondary controller and then restore it when you are 
> done.

One more question: Does 0xc0000 POST method work even on notebooks? On
regular machines, PCI card must have normal bios and stuff is easy. On
notebooks there was talk about "integrated bios" where it really has
no video bios at all and system bios POSTs the card. Have you seen
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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

> One more question: Does 0xc0000 POST method work even on
> notebooks? On regular machines, PCI card must have normal bios and
> stuff is easy. On notebooks there was talk about "integrated bios"
> where it really has no video bios at all and system bios POSTs the
> card. Have you seen that? 

We have never had a need to POST a notebook Video BIOS so I don't know 
what would happen. It is an interesting question, and if this is to be 
used for resume operations something that should be investigated.

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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Richard Smith]

Kendall Bennett wrote:

>>One more question: Does 0xc0000 POST method work even on
>>notebooks? On regular machines, PCI card must have normal bios and
>>stuff is easy. On notebooks there was talk about "integrated bios"
>>where it really has no video bios at all and system bios POSTs the
>>card. Have you seen that? 

With all the video chips I've worked with the mfg gives me a binary 
formatted up as an option ROM and I'm responsible for getting it called.

> We have never had a need to POST a notebook Video BIOS so I don't know 
> what would happen. It is an interesting question, and if this is to be 
> used for resume operations something that should be investigated.
> 

What I've seen is that they simply place a copy of the video bios at the 
shadowed legacy vbios range usually 0xc0000 but it can be anywhere in 
the 0xc0000-0x0e0000 range.  Or physically locate the vbios in the 
onboard ROM such that it will show up in that range.

Then when the system bios goes through its scan of the legacy ranges 
looking for option roms it hits the video bios and runs it.

-- 
Richard A. Smith