[ANNOUNCE] vesafb full VBE 2.0 support

From: Aki M Laukkanen (amlaukka@cc.helsinki.fi)
Date: Sat Jan 22 2000 - 09:21:48 EST

Patch to vesafb adds support for communicating with a user-space
daemon. This user-space daemon uses the LRMI library by Josh Vanderhoof
(need his e-mail) to call real-mode VBE 2.0 functions to set the mode,
pan the display and perform other framebuffer functions. Thanks to
Alan Cox for the idea and mailing the LRMI library.

This is a very preliminary version and released because it works for
me. Your mileage may vary. The communication between kernel/user-space is
achieved via a special character device file (/dev/vesafb).

~$ file /dev/vesafb
/dev/vesafb: character special (10/180)

When vesafbd successfully opens the vesafb device, the `dummy' functions
in the vesafb driver are overrided with the ones capable of communicating
with the daemon. Issued FB ioctls are then added to a request/reply
queue which is processed by the device read/write functions. A queue is
needed because console switching is done from an interrupt context.

In practice this seems to work quite well. Even panning (for example in
X) is completely smooth on my Pentium/133. By default the patch writes a
lot of debug info but this may be omitted by commenting out the DEBUG
define in the code. The patch itself is against 2.3.x (I doubt there has
been any changes during that time) but needs only small changes to work
with 2.2.x.

Download from:
http://www.cs.helsinki.fi/u/amlaukka/vesafb/

I've also setting up a web page at:
http://www.cs.helsinki.fi/u/amlaukka/vesafb.html

TODO 

----
 
vesafb:
* VBE 2.0/3.0 PMI support
* modularisation
* palette modes: can not change palette right now
* wrap daemon support in CONFIG_VESAFB_VESAFBD for those who need it?
* generic clean up
* mix of text and vesafb virtual consoles might work with the SAVESTATE/
  RESTORESTATE VBE functions.
* documentation

vesafbd:
* SVGAlib support
* XFree 4 modularized driver support 
* might need changes in the /dev/vesafb interface because of above
* rename appropriate?
* clean up code and automake/configure stuff
* black-list non-working BIOSes (PMI/3.0 and/or PMI/2.0 does not work,
  real mode interface does not work - more fine grained?) 
* derive the acceleration fields from the information which VBE provides
* Red Hat/Debian initscript support and packages.
* documentation

-- 
D.

-
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 : Sun Jan 23 2000 - 21:00:27 EST