On Mon, 24 Jan 2000, Kendall Bennett wrote:
> 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.
Currently there are atleast three sys calls per framebuffer
operation: a read(2) for the request, write(2) for reply
and synchronization and one or multiple vm86(2). Executing the real mode
code happens in a kind of mini-emulator if I understood the LRMI code
correctly. This I suppose is not a particularly light operation.
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).
Acceleration for user-space application I think is best kept where it is
today.
Btw. I assume you are talking about supporting the VBE/AF specification
(which I don't have - seen only a passing mention in the VBE 3.0
standard)? Are there currently any cards which have a proper
implementation of those extensions? I'm asking this for the possible
multi-head support in vesafb too. Are these documents (I'd be interested
in DDC aswell) available free from anywhere? I guess not or VESA wouldn't
be asking $550 in total for the both of them.
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?
Another issue is that the communication is implemented currently via
device file. Would that be accepted? There are certain pro device
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. When having a
separate device for the daemon, the access can be restricted to root
only. Second advantage to a separate device is the ability to control
having only one instance opened at any time. Third kernel gets
notified immediately if the daemon dies and can act accordingly.
Another issue which occurred to me was extending vesafbd to be more
a generic "support calling real-mode BIOS/whatever functions" from kernel
like facility. Would there be use for it elsewhere in the kernel?
> 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
When I've modularised the vesafb driver, this will be possible. The
current mode of operation is to set a graphics mode at boot time before
the kernel goes in protected mode. When the device file is opened, the
`dummy' functions in vesafb are simply replaced by functions which can
request vesafbd to do the job on behalf of them.
> BTW, if the developer of this code is interested, we have tons of
> source code showing how to properly program the VESA VBE BIOS that we
> have developed over the years (shipped in tons of commercial apps and
> games). I am more than willing to re-license code portions under GPL
> for kernel use if desired (since I wrote all the code I can do that
Of course I'd appreciate any information concerning VBE BIOS
programming. For example I'd imagine you had a database of buggy bioses
which would be extremely useful. DDC/AF and other code for which
programming information is unreachable could be useful for fbdev in
general (in case of DDC).
PS.
New version of the patch and the daemon are always at:
http://www.cs.helsinki.fi/u/amlaukka/vesafb.html
I haven't had even a single "You are a crappy programmer. Your buggy
patch killed the machine and now fsck won't go through. I'll sue
you!" mails and neither positive reports. The code's there for a reason.
-- D.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:15 EST