[linux-fbdev] Re: vm86 in kernel [was: vesafb...]

[James A Simmons]

> > So now that this has been brought up, why can't a user land daemon 
> > type thing be used to implement accelerated fbdev type functionality? 
 > I'm not quite sure what is the level of acceleration you mean? Are you
> talking about text acceleration for virtual consoles? Obviously this
> would be restricted to bigger blits only because of the overhead.

Because fbdev job is not to handle accels. It job is to abstarct mode
setting and if the hardware supports it to mmap the framebuffer. Yes
fbdev drivers do use accels to speed up console functions. This is to
elminate the latency problems people have. Consider the vesafb driver
since you can't access accels via the VESA protocol. Writing a huge area
of the framebuffer takes a good amount of time. Enough to cause dma
timeouts and other problems people reported. Accel handling will be done
in the future with DRI and /dev/graphics for higher end hardware.

> However this poses no problem with the type of operations (set mode
> etc.) which the daemon currently implements. However I can drive the
> vesafbd process upto 20 percent in top when pushing mouse wildly around
> on a virtual screen in X (on P133). 

Latency problems :(

> Completely another point is whether supporting VBE 3.0 PMI should be done
> in user-land or kernel-space? I haven't asked before but what is every
> body's opinion in getting vesafb changes in the distribution kernel if
> cleaned up/completed as planned (Alan)? In this case would you accept
> calling PMI functions from kernel-space or should it be done from
> user-space? 

The purpose of fbdev was to have mode setting in the kernel. I know
someone that was playing with Vesa3.0 support before. I have to look at
what he did to see if its "safe" to do from userland. I really doubt it
and also some things you can only do from the kernel in reasonable time
(ex interrupt handling). 

> vs. ioctl arguments. First of all I've made /dev/fbn to be in the same
> group as myself to be able to use framebuffer programs as a normal
> user. I suppose most of the people have a similar setup. 

Here too. I also have a few custom patches to make /dev/fb secure so I
don't have to run X or any graphical program as root.

> When having a
> separate device for the daemon, the access can be restricted to root
> only. 

Why should you make it so only root can change a video mode ? Like me
you have /dev/fb so any local user can use it so for fbdev driver
that does support mode switching then a normal user can change the
video mode. I can the video mode at home all the time as a normal user. I
run Mesa-GGI on top of fbdev. This way anyone can run OpenGL program off
my home system without needed root access. 

> Second advantage to a separate device is the ability to control
> having only one instance opened at any time. 

Look at linux/include/linux/fb.h in the newest kernel. Look at struct
fb_info you will see a open flag. That's what this is for. I will soon
make use of this flag. That patch also looks to see if you are trying
to open /dev/fb locally. You don't want someone remotely starting up a X
server or another graphical program while you are using fbcon. Not good.

> Third kernel gets
> notified immediately if the daemon dies and can act accordingly.

When daemons normally die you have to start them yourself. I have cron
jobs that. I never seen a kernel that restarts a deamon. 

> > Or better yet, have the system boot up initially in hardware text 
> > mode (assuming VGA text mode is available), and then switch into 
> > graphics mode when the user land deamon initialises? Then *all* the 

I also have a patch that does this. In fact you can run vgacon on some VTs
and fbcon on another and VT switch between the two of them with no
problem. This I hope will also go into 2.3.X soon. 

Codito, ergo sum - "I code, therefore I am"
James Simmons                                                      (o_
fbdev/gfx developer                                      (o_  (o_ //\
http://www.linux-fbdev.org                              (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/