Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > So now that this has been brought up, why can't a user land daemon
> > type thing be used to implement accelerated fbdev type functionality?
>
> For a limited subset it probably can. Except that the vesa
> acceleration I've seen is pretty piss poor.
I wasn't talking about VESA acceleration, but having the a user land
binary that can do everything for fbdev, including mode sets, palette
programming, acceleration (for text modes, scrolling etc) and
anything else fbdev does. This would not be implementing using VESA
services, but instead be implemented via user land daemon chipset
drivers that go native to the hardware.
The obvious question is 'why', when you can already do chipset
specific drivers in the kernel. The answer to that is twofold:
1. You can more easily replace the drivers or update them without
having to modify your kernel at all (and it is more protected
since the fbdev driver can't cause a kernel oops).
2. The source for the drivers does not need to be under GPL.
The second issue is very important, because with XFree86 4.0's new
modular chipset driver architecture, it may well be possible to build
this user land daemon such that it can use standard XFree86 4.0
chipset driver. It is simply not possible to do this in the kernel,
because XFree86's license is not GPL compatible (and never will be).
This would provide a mechanism to completely avoid duplication of
work, and more importantly the XFree86 drivers would not have to
fight with the framebuffer console drivers since there would really
only be one driver running the graphics card in the system (ie:
save/restore state becomes a *lot* easier).
> For consoles Vesa 1.2 is also a problem due to the banking and the
> fact we may want to change bank during an IRQ. A vesa 1.2 bios X
> server would be a great hack, but probably not terribly productive.
Sure, but I wasn't thinking of a VESA fbdev driver, but a fully
accelerated chipset specific driver.
> > description to get the card into graphics mode (or even the BIOS
> > could be used for that), and all the complex stuff (acceleration etc)
> > can be handled by the user land daemon.
>
> I'm under the impression Egbert Eich is doing exactly this for
> XFree 4.0 to bios initialise some cards.
Yes, both Egbert and I have been working on this for some time. The
stuff that Egbert has done was based on code I did, but he re-
implemented it because our license (MPL) was not comaptible with the
XFree86 license. We are also both working on the x86emu library
(which I re-vamped and brought back to life!) so that the BIOS can be
used to initialise secondary controllers as well as supporting int10
functions on non x86 CPU platforms.
Most of the work I do is all generic and OS neutral, and Egbert works
on the XFree86/Linux integration.
Regards,
+---------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+---------------------------------------------------------------+
| Kendall Bennett | Email: KendallB@scitechsoft.com |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+---------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:15 EST