Finding Aki M Laukkanen's VESAFBD project?

Finding Aki M Laukkanen's VESAFBD project?

[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.

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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Jon Smirl]

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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Kendall Bennett]

Jon Smirl <jonsmirl@yahoo.com> wrote:

> 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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Jon Smirl]

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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Kendall Bennett]

Jon Smirl <jonsmirl@yahoo.com> wrote:

> 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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Jon Smirl]

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.

--- Kendall Bennett <KendallB@scitechsoft.com> wrote:
> Jon Smirl <jonsmirl@yahoo.com> wrote:
> 
> > 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
> _______________________________________________
> Linux-fbdev-devel mailing list
> Linux-fbdev-devel@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel


=====
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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Geert Uytterhoeven]

On Fri, 14 Mar 2003, Kendall Bennett wrote:
> 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.

> 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 -- 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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Antonino Daplas]

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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Kendall Bennett]

Antonino Daplas <adaplas@pol.net> wrote:

> > 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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Kendall Bennett]

Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> > 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

Re: Finding Aki M Laukkanen's VESAFBD project?

[Antonino Daplas]

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