Aki M Laukkanen <amlaukka@cc.helsinki.fi> wrote:
> 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.
Yes, I am talking about text framebuffer console acceleration and
mode sets. Graphics mode consoles can benefit tremendously from
hardware accelerated blitting (for scrolling) and hardware
accelerated text rendering for drawing the fonts.
> 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.
A call to vm86 simply goes into the kernel, and the code is then run
at ring 3 in a vm86 task (ie: the code runs natively as real mode
code, and is not emulated). The only complication is some I/O port
writes cannot be unvirtualised, so we have to virtualise them in user
land to go to the hardware directly. That code could also be done
inside the kernel if there was a performance overhead for this, but
our testing indicated this was not necessary (once I worked the bugs
out of LRMI for Josh so that it actually worked properly, quite a
while ago now ;-).
> 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).
I am not thinking of this for X11 support; native XFree86 drivers
should be used for that running in user land. I am thinking of
framebuffer console support that can utilise XFree86 4.0 loadable
modules to implement the mode set and blitting functions. Why re-
write code when it could be re-used (even at the binary level!).
> Acceleration for user-space application I think is best kept where
> it is today.
I totally agree.
> 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)?
No, I was thinking of utilising XFree86 4.0 loadable chipset driver
modules to implement the daemon.
> Are there currently any cards which have a proper implementation of
> those extensions?
Nope. VBE/AF is dead.
> 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.
Don't pay VESA a cent for the specs. I invented VBE/AF (both version
1.0 which is a standard, and 2.0 which never passed), wrote the
specifications, sample code and initial implementations. As much as
we tried and tried, they would never release the VBE/AF
specifications freely so that people could actually *use* it, but
instead tried charging ridiculous fees for it. Hence VESA essentially
destroyed VBE/AF, as they only sold less than 10 copies over a period
of two years!
Then they canned the VESA Software Standards Committee due to lack of
interest. No wonder no-one was interested when no-one was using the
damn specs!
> 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?
Forget the VBE 3.0 PMI interface functions, at least for now.
Unfortunately a number of well known graphics cards (NVIDIA boards
from Diamond) shipped with a broken VBE 3.0 PMI interface. NVIDIA
fixed their implementation ages ago, but Diamond refused to update
their BIOS code and ship the fix, so using VBE 3.0 on any Diamond
boards will likely result in a hard crash.
Also the VBE 3.0 PMI interface is an optional part of the spec
(something I fought hard to get changed, but the vendors wanted it
optional), and hence most VBE 3.0 BIOS'es I have seen do not
implement this interface at all.
> 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?
I can't comment on this definitively, but off the top of my head I
can't think of anything that would need real mode BIOS access except
the graphics card support.
> > 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.
Right. So we could boot up in text mode and then change to a graphics
mode console when the daemon loads (kinda like the SVGA text mode
facilities are used to change resolutions etc after the system has
booted).
> > 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).
I will email you copies of the code that you can use, under the GPL
license. Feel free to cut and paste what stuff you need, but make
sure you retain my copyright in your code somewhere.
You should be able to use the DDC BIOS functions easily enough from
user land to read the EDID from the monitor. Red Hat already does
this (initially using code I sent them, which they re-wrote somewhat)
in their latest 6.1 install program to determine the best refresh
rate to use.
Regards,
+---------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+---------------------------------------------------------------+
| Kendall Bennett | Email: KendallB@scitechsoft.com |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+---------------------------------------------------------------+
-
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