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 (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
---- 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
From: Jon Smirl <hidden> Date: 2003-03-14 18:56:50
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
jonsmirl@yahoo.com
__________________________________________________
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
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 ;-)
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
From: Jon Smirl <hidden> Date: 2003-03-14 20:11:52
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
jonsmirl@yahoo.com
__________________________________________________
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
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.
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
From: Jon Smirl <hidden> Date: 2003-03-14 23:22:56
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.
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:
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...
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.
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 -- geert@linux-m68k.org
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
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
On Sat, 2003-03-15 at 02:37, Kendall Bennett wrote:
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
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.
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
On Tue, 2003-03-18 at 02:22, Kendall Bennett wrote:
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