Finding Aki M Laukkanen's VESAFBD project?
Hi Guys,
A long time ago in early 2000, Aki M Laukkanen was a guy working on a VESA framebuffer console daemon for Linux. This driver was structured as a as a user land daemon that the kernel vesafb console driver would call back into once the system was up, allowing the userland VESA driver to use the vm86() service to change modes, program the palette and other useful things that can't be done by the basic VESA driver that uses a mode set previously by LILO or GRUB.
After some research I discovered that unfortunately Aki was killed in an accident in January 2001, and hence this project was forgotten about. I would very much like to resurrect this project and complete it on Aki's behalf. Below is the original announcement email from Aki in January 2000, but none of the links work anymore. If anyone downloaded this code at the time or knows where to find the code that Aki was working on, please let me know.
--- cut here ----
Subject: [ANNOUNCE] vesafb full VBE 2.0 support
From: Aki M Laukkanen ([email protected])
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
---- cut here ----
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! ~
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Most of the code your need is located in the x86emu-XX files on the ftp.scitechsoft.com server. x86emu has all of the VBIOS support for calling the INT functions. You would just need to hook it up so that the fb drivers can call it.
But wouldn't the time be better spent on getting the info out of the board manufacturers that would allow protected mode versions of these routines to be implemented? With that info we could eliminate the need for this VM86 stuff forever.
=====
Jon Smirl
[email protected]
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Quoted 2 lines · Jon Smirl
Most of the code your need is located in the x86emu-XX files on the ftp.scitechsoft.com server.
Er, did you check my email address? I am the maintainer of the x86emu project on our site ;-)
Quoted 3 lines
x86emu has all of the VBIOS support for calling the INT functions. You would just need to hook it up so that the fb drivers can call it.
Yes, but it is a BIOS emulator only. What I am looking for is the code that Aki did that allowed the kernel mode VESA fbdev driver call out into a userland daemon to do the actual calls to the BIOS. Whether the calls are made using the x86emu emulator (for non-x86 platforms) or via the real BIOS is irrelevant. What is important is the userland daemon hookup; that is what I am looking for.
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! ~
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
I noticed the email but I wasn't sure if you knew
about the code from the way your mail was worded.
I used fasync and poll to implement user space communications in a driver I just finished. Use kill_fasync(&fasync, SIGIO) from the device driver to signal the user app. The signal causes the app to poll which the driver replies POLLIN to. Polling identifies which device caused the signal. Now the user app knows it needs to IOCTL the handle to do whatever the driver needs it to. It only takes about 100 lines of code to implement the communication.
google for: fasync sigio user
=====
Jon Smirl
[email protected]
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Quoted 2 lines · Jon Smirl
I noticed the email but I wasn't sure if you knew about the code from the way your mail was worded.
;-)
Quoted 7 lines
I used fasync and poll to implement user space communications in a driver I just finished. Use
kill_fasync(&fasync, SIGIO)from the device driver to signal the user app. The signal causes the app to poll which the driver replies POLLIN to. Polling identifies which device caused the signal. Now the user app knows it needs to IOCTL the handle to do whatever the driver needs it to. It only takes about 100 lines of code to implement the communication.
Does the user space daemon block waiting to be woken up from the kernel module? I think the way Aki had it done initially was to have the user space daemon call into the kernel via an ioctl() or something, and the kernel would block on that thread and when something needed to be done, it would fill in the return structure for the ioctl() and then unblock the thread. The user space daemon would process the ioctl() and and then call it agin once the service was completed.
Does that system make sense at all?
Thanks!
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
You can do it either way. With blocking IO you would need one thread per adapter. With the signal method you can be single threaded and sleep waiting for a signal. Both styles will work.
With single threaded you make an array of handles for the framebuffers. When you get a signal you do poll() on the array. For each active poll you will need to do the IOCTL. Keep looping on poll/IOCTL until the poll goes inactive, then sleep waiting for a SIGIO.
Quoted 48 lines · --- Kendall Bennett
Quoted 1 line · Jon Smirl
I noticed the email but I wasn't sure if you knew
about the code
Quoted 1 line
from the way your mail was worded.
;-)
Quoted 1 line
I used fasync and poll to implement user space
communications in a
Quoted 1 line
driver I just finished. Use kill_fasync(&fasync,
SIGIO) from the
Quoted 1 line
device driver to signal the user app. The signal
causes the app to
Quoted 1 line
poll which the driver replies POLLIN to. Polling
identifies which
Quoted 1 line
device caused the signal. Now the user app knows
it needs to IOCTL
Quoted 1 line
the handle to do whatever the driver needs it to.
It only takes
Quoted 1 line
about 100 lines of code to implement the
communication.
Does the user space daemon block waiting to be woken up from the kernel
module? I think the way Aki had it done initially was to have the user
space daemon call into the kernel via anioctl()or something, and the
kernel would block on that thread and when something needed to be done,
it would fill in the return structure for theioctl()and then unblock
the thread. The user space daemon would process theioctl()and and then
call it agin once the service was completed.Does that system make sense at all?
Thanks!
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
Quoted 6 lines
~ SciTech SNAP - The future of device driver
technology! ~
-------------------------------------------------------
Quoted 6 lines
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Quoted 4 lines
_______________________________________________
Linux-fbdev-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
=====
Jon Smirl
[email protected]
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Quoted 2 lines · Kendall Bennett
After some research I discovered that unfortunately Aki was killed in an accident in January 2001, and hence this project was forgotten about. I
Oops...
Quoted 8 lines
would very much like to resurrect this project and complete it on Aki's behalf. Below is the original announcement email from Aki in January 2000, but none of the links work anymore. If anyone downloaded this code at the time or knows where to find the code that Aki was working on, please let me know.
Download from:
http://www.cs.helsinki.fi/u/amlaukka/vesafb/
Since the code used to be at a university webserver, you may want to ask the sysadmin team of cs.helsinki.fi whether they have a backup.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Quoted 9 lines · Kendall Bennett
Hi Guys,
A long time ago in early 2000, Aki M Laukkanen was a guy working on a VESA framebuffer console daemon for Linux. This driver was structured as a as a user land daemon that the kernel vesafb console driver would call back into once the system was up, allowing the userland VESA driver to use the
vm86()service to change modes, program the palette and other useful things that can't be done by the basic VESA driver that uses a mode set previously by LILO or GRUB.
That is a very neat project :-) It can also be expanded to something not just the VESA driver will use, but as a general interface whenever the BIOS services are to be needed. I can already think several uses for it (warmboot secondary cards, save/restore current video state, disable/enable the display, DDC/EDID, etc). I will be very interested if that project is revived.
BTW: I want to initialize multiple VGA adapters during the early boot sequence. The machine will be in real mode, so there's no such thing as copy-on-write. I'm pretty sure it's not possible, but do you know of a way to disable the BIOS write protection of the C000:0000 segment?
Tony
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Quoted 11 lines · Antonino Daplas
Quoted 7 lines
A long time ago in early 2000, Aki M Laukkanen was a guy working on a VESA framebuffer console daemon for Linux. This driver was structured as a as a user land daemon that the kernel vesafb console driver would call back into once the system was up, allowing the userland VESA driver to use the
vm86()service to change modes, program the palette and other useful things that can't be done by the basic VESA driver that uses a mode set previously by LILO or GRUB.That is a very neat project :-) It can also be expanded to something not just the VESA driver will use, but as a general interface whenever the BIOS services are to be needed.
Yes, it could. It also doesn't need to be used just for VESA/BIOS services, but could be used to implement real mode fbconsole drivers using existing driver modules from XFree86 if desired.
Quoted 5 lines
BTW: I want to initialize multiple VGA adapters during the early boot sequence. The machine will be in real mode, so there's no such thing as copy-on-write. I'm pretty sure it's not possible, but do you know of a way to disable the BIOS write protection of the C000:0000 segment?
I don't think it is possible to do this because the BIOS is in ROM on the graphics card. If the system BIOS is shadowing it (quite likely) then it would be possible, but you would need to know how to disable the write protection in the system chipset which is probably different for each motherboard.
The other option is to use the x86emu BIOS emulator project. Then you don't need to do any of this stuff and instead can warm boot all the graphics controllers using the BIOS from the card (see the sample 'warmboot' program included in the source code archives). The code is presently 32-bit specific I believe, so you would have two choices for running this from real mode - port the code to a 16-bit C compiler or port it to run in 32-bit real mode. I assume you are probably thinking of during the boot phase of GRUB or LILO, so at that point you will have full control and should be able to execute 32-bit real mode code. You may even be able to put the machine into protected mode and run the code as 32-bit protected mode code also if needed (but you would need to then write your own protected mode kernel).
The BIOS emulator code is available from:
ftp://ftp.scitechsoft.com/devel/x86emu
I 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! ~
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Quoted 6 lines · Geert Uytterhoeven
Quoted 2 lines
Download from:
http://www.cs.helsinki.fi/u/amlaukka/vesafb/Since the code used to be at a university webserver, you may want to ask the sysadmin team of cs.helsinki.fi whether they have a backup.
Good point. Do you have an email contact there or should I just email them at postmaster or something? I will go dig around and see if I can find a contact.
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! ~
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
Quoted 9 lines · Kendall Bennett
The other option is to use the x86emu BIOS emulator project. Then you don't need to do any of this stuff and instead can warm boot all the graphics controllers using the BIOS from the card (see the sample 'warmboot' program included in the source code archives). The code is presently 32-bit specific I believe, so you would have two choices for running this from real mode - port the code to a 16-bit C compiler or port it to run in 32-bit real mode. I assume you are probably thinking of during the boot phase of GRUB or LILO, so at that point you will have full control and should be able to execute 32-bit real mode code. You may
Interesting, an x86 emulator while in real mode... This is probably worth a try. Thanks.
Tony
-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en