Help with Aki Laukkanen's vesafbd project?

Help with Aki Laukkanen's vesafbd project?

[Kendall Bennett]

Hi Guys,

I am re-posting this message here that I originally posted on the kernel 
mailing list. It is probably more appropriate to discuss the details of 
this project here:

Well I managed to finally dig up the old code that Aki Laukkanen 
developed sometime in early 2000. Unfortunately Aki died sometime in 
January 2001, so his work on the vesafbd daemon and patches to the vesafb 
device driver were lost - until now.   

I would like to revive this project, and the code I received from Matan 
Ziv-Av still configures and compiles correctly on Red Hat 8.0. I need to 
patch the latest kernel vesafb driver, but I think his patch is very old 
(probably around 2.2.14 timeframe). I am grabbing the 2.2.14 code to see 
if the patch will apply to that code, and then try to port the patch to 
the latest kernel release. Which brings up the first question. What 
kernel version should I patch against? 2.4.x or 2.5.x?  

However since I am not that familiar with the patching mechanism for the 
Linux kernel, would someone more familiar with this be willing to help 
out? I would like to modify the vesafb module in the kernel to optionally 
support the vesafbd daemon if it is present on the system, if not it will 
function as it does today. If vesafbd is present, it will be used to 
provide extended features to the default VESA framebuffer console driver. 
 I would also like to generalise the daemon module a bit such that it 
does not need to be a VESA specific daemon, but could in fact contain 
it's own hardware interfacing module. For instance the daemon could use 
XFree86 loadable driver modules to implement the functions rather than 
the VESA interface code, which would also open up the option of doing 
accelerated screen blits using the existing XFree86 driver modules. Hence 
I was thinking that the name 'vesafbd' for the daemon is a misnomer and 
should probably be changed to something else like 'fbcond' or something. 
Any suggestions? Or should we just leave it as 'vesafbd' even though it 
could be updated to support more than just the VESA BIOS interface?  

Also the code I have right now for the daemon relies on the /dev/vesafb 
special file to have been created, which is used as the communication 
mechanism between the modified vesafb kernel driver and the daemon code. 
The daemon simply constantly reads from /dev/vesafb for command packets 
to process and writes the results to /dev/vesafb. Some people suggested 
in the past that a better approach might be to either use extended 
ioctl()'s to the existing /dev/fb special file, and have the kernel 
module sleep until it needs to do something, or use other polling methods 
(of which I am not familiar). I would like some guidance here as to the 
best way to implement this daemon if people think it should be changed.  

Finally, before I embark on this project, will this patch will be 
accepted into the kernel source code tree? I would hate to spend my time 
on it only to find out that the kernel developers don't like it and won't 
accept it.  

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: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Help with Aki Laukkanen's vesafbd project?

[Antonino Daplas]

On Thu, 2003-03-20 at 03:32, Kendall Bennett wrote:
> I would like to revive this project, and the code I received from Matan 
> Ziv-Av still configures and compiles correctly on Red Hat 8.0. I need to 
> patch the latest kernel vesafb driver, but I think his patch is very old 
> (probably around 2.2.14 timeframe). I am grabbing the 2.2.14 code to see 
> if the patch will apply to that code, and then try to port the patch to 
> the latest kernel release. Which brings up the first question. What 
> kernel version should I patch against? 2.4.x or 2.5.x?  

I guess, 2.5.x.

> 
> However since I am not that familiar with the patching mechanism for the 
> Linux kernel, would someone more familiar with this be willing to help 
> out? I would like to modify the vesafb module in the kernel to optionally 

Yes, I'll be interested and willing to help out.

> support the vesafbd daemon if it is present on the system, if not it will 
> function as it does today. If vesafbd is present, it will be used to 
> provide extended features to the default VESA framebuffer console driver. 
>  I would also like to generalise the daemon module a bit such that it 
> does not need to be a VESA specific daemon, but could in fact contain 
> it's own hardware interfacing module. For instance the daemon could use 
> XFree86 loadable driver modules to implement the functions rather than 
> the VESA interface code, which would also open up the option of doing 
> accelerated screen blits using the existing XFree86 driver modules. Hence 
> I was thinking that the name 'vesafbd' for the daemon is a misnomer and 
> should probably be changed to something else like 'fbcond' or something. 
> Any suggestions? Or should we just leave it as 'vesafbd' even though it 
> could be updated to support more than just the VESA BIOS interface?  

I'm more inclined to generalize this as a vm86 daemon.  What I'm
thinking is to create a character device /dev/vm86.  A daemon (perhaps
named vm86d) will sleep waiting for a signal which when it arrives, does
a file read.  It should get a generic structure containing all the
registers and the type of request (initialization, interrupt service or
general x86-specific code).  After executing the request, it will do a
file write returning the results of the request.

Within the kernel side, an exportable function (perhaps named vm86_exec)
will be available to anyone.  When this function is called, it will send
a signal to the daemon (for select(), poll() or signal()), then
optionally sleep. The read function will pass the generic request
structure to the daemon.  The write function will get the result from
the daemon and also wake up vm86_exec().  

As a sidenote:  There are specific contexts in the kernel where the
module cannot sleep (ie during vt switches).  In these cases, the module
has to exit immediately without waiting for the daemon to write back the
results, unless we find another method of waiting for the daemon to
finish without the kernel module sleeping.

Optionally, we need to make sure that the correct process opened
/dev/vm86 perhaps by letting the daemon do a specific ioctl which
basically says "I'm here, ignore everyone else".  We would then prevent
kernel confusion when a user does a cat /dev/vm86.

This way, the interface can be useful for other subsystems (APM, IDE,
etc).  Plus, the interface will be very simple (the request structure
will just contain x86's register set, the bus, device, function number,
and perhaps a few flags) and it need not know if this is graphics,
block, power, etc.  The daemon will have the option, perhaps with
suggestions from the kernel, on what to use (vm86, vm86emu, or perhaps
even parse VBE/AF requests into specific XFree86 instructions).
     
> 
> Finally, before I embark on this project, will this patch will be 
> accepted into the kernel source code tree? I would hate to spend my time 
> on it only to find out that the kernel developers don't like it and won't 
> accept it.  

Probably not.  However, if a lot of users find it useful, Linus tends to
succumb to user demand (not vendor demand though), and might even accept
patches which he personally thinks is ugly.  Also, if one of the main
kernel hackers supports this, it might be easier for Linus to accept as
he tends to listen to them.

Tony





-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Help with Aki Laukkanen's vesafbd project?

[Kendall Bennett]

Antonino Daplas <adaplas@pol.net> wrote:

> I guess, 2.5.x.

Ok.

> > However since I am not that familiar with the patching mechanism for the 
> > Linux kernel, would someone more familiar with this be willing to help 
> > out? I would like to modify the vesafb module in the kernel to optionally 
> 
> Yes, I'll be interested and willing to help out.

Great!

> I'm more inclined to generalize this as a vm86 daemon.  What I'm
> thinking is to create a character device /dev/vm86.  

Right, that is actually not a bad idea, especially as a way for making 
vm86 services available to Linux kernel modules. However one of the 
offshoots of the vesafbd daemon is also the ability to handle full mode 
setting and blitting from the userland daemon without needing the vm86() 
BIOS support (ie: using XFree86 modules or allowing other vendor supplied 
modules to support this).

Hence although I like the idea of a vm86d deamon, I do think there is a 
place for a userland framebuffer console daemon as well.

> A daemon (perhaps named vm86d) will sleep waiting for a signal
> which when it arrives, does a file read.  

It can just do the read and it will block in the read until there is 
something to read. No need to wait on a signal ;-)

> Within the kernel side, an exportable function (perhaps named
> vm86_exec) will be available to anyone.  When this function is
> called, it will send a signal to the daemon (for select(), poll()
> or signal()), then optionally sleep. The read function will pass
> the generic request structure to the daemon.  The write function
> will get the result from the daemon and also wake up vm86_exec().  

An interesting side effect of this is that the vm86d daemon could be 
built using the x86emu BIOS emulator for support on non-x86 platforms 
such as Alpha and PowerPC.

> As a sidenote:  There are specific contexts in the kernel where
> the module cannot sleep (ie during vt switches).  In these cases,
> the module has to exit immediately without waiting for the daemon
> to write back the results, unless we find another method of waiting
> for the daemon to finish without the kernel module sleeping. 

Interesting, I had not thought of that.

> This way, the interface can be useful for other subsystems (APM, IDE,
> etc).  Plus, the interface will be very simple (the request structure
> will just contain x86's register set, the bus, device, function number,
> and perhaps a few flags) and it need not know if this is graphics,
> block, power, etc.  

I like the idea, but the downside is that some people on the Linux kernel 
list feel that the availability of a generic BIOS interface would allow 
hardware vendors to be 'lazy' and rely on these services, making their 
code less portable to non-x86 platforms. Hence the generic vm86d project 
might be a bit of a hard sell for those folks ;-)

> > Finally, before I embark on this project, will this patch will be 
> > accepted into the kernel source code tree? I would hate to spend my time 
> > on it only to find out that the kernel developers don't like it and won't 
> > accept it.  
> 
> Probably not.  However, if a lot of users find it useful, Linus
> tends to succumb to user demand (not vendor demand though), and
> might even accept patches which he personally thinks is ugly. 
> Also, if one of the main kernel hackers supports this, it might be
> easier for Linus to accept as he tends to listen to them. 

Right. So basically we should just go ahead and do it as a loadable 
module and then see how many people like it and start using it? Hopefully 
enough interest will get the patches into the kernel proper.

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: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Help with Aki Laukkanen's vesafbd project?

[Antonino Daplas]

On Thu, 2003-03-20 at 10:51, Kendall Bennett wrote:
> Antonino Daplas <adaplas@pol.net> wrote:
> 
> > I guess, 2.5.x.
> 
> Ok.
> 
> > > However since I am not that familiar with the patching mechanism for the 
> > > Linux kernel, would someone more familiar with this be willing to help 
> > > out? I would like to modify the vesafb module in the kernel to optionally 
> > 
> > Yes, I'll be interested and willing to help out.
> 
> Great!
> 
> > I'm more inclined to generalize this as a vm86 daemon.  What I'm
> > thinking is to create a character device /dev/vm86.  
> 
> Right, that is actually not a bad idea, especially as a way for making 
> vm86 services available to Linux kernel modules. However one of the 
> offshoots of the vesafbd daemon is also the ability to handle full mode 
> setting and blitting from the userland daemon without needing the vm86() 
> BIOS support (ie: using XFree86 modules or allowing other vendor supplied 
> modules to support this).

I think that's not a problem, except perhaps for efficiency.  For
instance, if the kernel module sent a request for int 0x10 with AX =
0x4f02 (Set VBE mode), the user daemon can choose to either:

a. parse the request so it is compatible with XFree86 or some non-VBE
modules for video mode changing

b. execute the instruction as is via VBE

Similarly for blits, we can use the VBE/AF standard.

This should make the kernel->user interface as simple and as generic as
possible, and we just let the user daemon do whatever it wants perhaps
with some suggestions from the kernel (such as "use the BIOS
exclusively" or "use the BIOS only as a last resort").

> 
> Hence although I like the idea of a vm86d deamon, I do think there is a 
> place for a userland framebuffer console daemon as well.
> 
> > A daemon (perhaps named vm86d) will sleep waiting for a signal
> > which when it arrives, does a file read.  
> 
> It can just do the read and it will block in the read until there is 
> something to read. No need to wait on a signal ;-)

Okay.  How the user daemon gets the request probably does not matter. 
Also, I don't think asynchronous IO works other than for sockets and
tty's, yet.  Learned it the hard way :-)

> 
> > Within the kernel side, an exportable function (perhaps named
> > vm86_exec) will be available to anyone.  When this function is
> > called, it will send a signal to the daemon (for select(), poll()
> > or signal()), then optionally sleep. The read function will pass
> > the generic request structure to the daemon.  The write function
> > will get the result from the daemon and also wake up vm86_exec().  
> 
> An interesting side effect of this is that the vm86d daemon could be 
> built using the x86emu BIOS emulator for support on non-x86 platforms 
> such as Alpha and PowerPC.

Yes.

> 
> > As a sidenote:  There are specific contexts in the kernel where
> > the module cannot sleep (ie during vt switches).  In these cases,
> > the module has to exit immediately without waiting for the daemon
> > to write back the results, unless we find another method of waiting
> > for the daemon to finish without the kernel module sleeping. 
> 
> Interesting, I had not thought of that.

Yes, again learned it the hard way. 

> 
> > This way, the interface can be useful for other subsystems (APM, IDE,
> > etc).  Plus, the interface will be very simple (the request structure
> > will just contain x86's register set, the bus, device, function number,
> > and perhaps a few flags) and it need not know if this is graphics,
> > block, power, etc.  
> 
> I like the idea, but the downside is that some people on the Linux kernel 
> list feel that the availability of a generic BIOS interface would allow 
> hardware vendors to be 'lazy' and rely on these services, making their 
> code less portable to non-x86 platforms. Hence the generic vm86d project 
> might be a bit of a hard sell for those folks ;-)

Hmm, I hope not.  Using the BIOS is just too inefficient.

Tony



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en

Re: Help with Aki Laukkanen's vesafbd project?

[Kendall Bennett]

Antonino Daplas <adaplas@pol.net> wrote:

> > > I'm more inclined to generalize this as a vm86 daemon.  What I'm
> > > thinking is to create a character device /dev/vm86.  
> > 
> > Right, that is actually not a bad idea, especially as a way for making 
> > vm86 services available to Linux kernel modules. However one of the 
> > offshoots of the vesafbd daemon is also the ability to handle full mode 
> > setting and blitting from the userland daemon without needing the vm86() 
> > BIOS support (ie: using XFree86 modules or allowing other vendor supplied 
> > modules to support this).
> 
> I think that's not a problem, except perhaps for efficiency.  For
> instance, if the kernel module sent a request for int 0x10 with AX
> = 0x4f02 (Set VBE mode), the user daemon can choose to either: 
> 
> a. parse the request so it is compatible with XFree86 or some non-VBE
> modules for video mode changing

Yes, that is true, provided everything that can be done has an interface 
via the regular VBE standard.

> Similarly for blits, we can use the VBE/AF standard.

Actually no, because the VBE/AF standard is a loadable driver module 
interface, and the only ratified standard of VBE/AF 1.0 was only an 
assembler interface. VBE/AF 2.0 which had a C calling interface is dead 
and was never ratified by VESA. Instead we took what was good about 
VBE/AF 2.0, killed what was bad and created SciTech Nucleus which has now 
morphed into what is SciTech SNAP today.

So if you wanted an acceleration interface in this daemon, it could not 
be done via a BIOS style interface since there is no standard for this.

> This should make the kernel->user interface as simple and as
> generic as possible, and we just let the user daemon do whatever it
> wants perhaps with some suggestions from the kernel (such as "use
> the BIOS exclusively" or "use the BIOS only as a last resort"). 

Being a daemon IMHO the suggestions would be better coming from the user 
when the daemon starts up ;-)

> > > This way, the interface can be useful for other subsystems (APM, IDE,
> > > etc).  Plus, the interface will be very simple (the request structure
> > > will just contain x86's register set, the bus, device, function number,
> > > and perhaps a few flags) and it need not know if this is graphics,
> > > block, power, etc.  
> > 
> > I like the idea, but the downside is that some people on the Linux kernel 
> > list feel that the availability of a generic BIOS interface would allow 
> > hardware vendors to be 'lazy' and rely on these services, making their 
> > code less portable to non-x86 platforms. Hence the generic vm86d project 
> > might be a bit of a hard sell for those folks ;-)
> 
> Hmm, I hope not.  Using the BIOS is just too inefficient.

Inefficient, but it would work. Personally I don't see it as a big issue, 
but that is what some folks said on the kernel lists.

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: Tablet PC.  
Does your code think in ink? You could win a Tablet PC. 
Get a free Tablet PC hat just for playing. What are you waiting for? 
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en