Quoting Antonino Daplas ([EMAIL PROTECTED]): > On Tue, 2003-04-01 at 12:01, Jon Smirl wrote: > > --- Antonino Daplas <[EMAIL PROTECTED]> wrote: > > > A new device seems more powerful and more generic. > > > Generic in a sense > > > that other subsystems besides fbdev can use it to > > > access the BIOS or > > > > The new device is going to need to sort out multiple > > adapters. Using /dev/fbX avoids that problem. You'll > > No, it won't. If multiple graphics adapters are to be supported, what's > needed is a hardware unique identifier that is known to both caller and > callee. /dev/fbX will not tell you anything about the device. This > unique ID can be the bus, device and function number. So whether the > request is done through /dev/fbX or /dev/vm86, the ID must still be > specified.
I'm wondering if there are plans to have /dev/fbX provide bus/device/function number for easier mapping. It's PCI related, but it would help fbDRI etc. > > also be able to get the /dev/fb code into the kernel. > > Getting a driver in that creates /dev/vm86 is going to > > be harder. > > I would rather have the code rejected than back-dooring it behind fbdev. > If it's going to be accepted, it has to be on its own merit. If vm86 doesn't (need to) know anything about the framebuffer drivers I would prefer an extra device, too. > > I'm not clear on what /dev/vm86 does. Why couldn't the > > /dev/vm86 just controls how data gets to and from the daemon. What kind > of data passes through it does not matter. Only the daemon and the > caller should know what protocol is used. > > > radeon driver exec vm86d with a parameter of /dev/fb0. > > vm86d would then open/IOCTL the radeon driver to > > identify the PCI device and what actions are needed. > > After it resets and gets the EDID data it would IOCTL > > them back into /dev/fb0 and exit. You need to know > > which PCI device so that you can set up the right > > VBIOS ROM. Each adapter would get it's own vm86d, but > > they wouldn't hang around long. > > > > Yes, in a similar manner, fbdev can pass a request through /dev/vm86 > that says "run expansion ROM code of device with this unique ID". The > daemon will then do just that. It does not matter if the device is a > VGA controller, or some other PCI device. It also will not matter if > the expansion ROM is in x86 form, OpenFirmware, etc, it's up to the > daemon. Why is it called /dev/vm86 if it's not restricted to x86? Sounds more like a /dev/firmwared or /dev/biosd. -- Best regards, Denis Oliver Kropp .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" Convergence GmbH -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe directfb-dev" as subject.
