lkml.org 
[lkml]   [2000]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-fbdev] Re: vm86 in kernel [was: vesafb...]

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

I'm nearly done writing a accel engine console wrapper. It should also be
able to be used with non framebuffer cards as well as fbdev drivers.
I need to deal with one more issus then test then submit the patch.

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

No!!! Don't let user land have access to mode setting registers for video
cards. A rogue app could fry a monitor by miss programming the CRTC
register on purpose.

> 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!).

First you missed the point fo fbdev. It's to abstract mode setting. The
server doesn't need to know about the video hardware. Mode setting for
fbdev is done by opening /dev/fb and calling the set var ioctl call. As
for using the accel functions. I have written a console accel wrapper to
use accels. Right now fbdev drivers mmap the MMIO regions so the X server
can use the blit functions etc. I have patches to deal with MMIO access by
userland and accel use for the console systems. So their is no worry about
that.

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

Most fbdev driver can do that with fbset. Yes vesafb doesn't have that
ability.

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@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.294 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site