Re: Thread-private mappings and graphics (was Re: Per-Processor Data

James Simmons (jsimmons@edgeglobal.com)
Sun, 19 Dec 1999 21:47:07 -0500 (EST)

> There is one disadvantage of any direct rendering solution with current
> hardware. We can't prevent an application from scribbling over the
> entire screen instead of staying contained to their own window. Any
> solution that gives applications direct access to the hardware will have
> this problem unless the hardware has some way of limiting drawing
> arbitrarily complex sets of pixels. (For those who know graphics
> hardware, hardware with GID planes may be able to do this) Your page
> mapping system, if it worked on current hardware, would have the exact
> same limitations.
>
> Another possible solution to the problem of scribbling is to not provide
> direct access to the hardware, and instead have the graphics interface
> in the kernel. This is an unacceptible answer because it would bloat the
> kernel and would have horrible performance. So direct access (of one
> form or another) really is the only reasonable solution.

We had this problem with video4linux and fbdev. A soultion we where
thinking of was to implement mmaping a window of the framebuffer to a
processes memory space. For older ISA cards that use page flipping you
could use a page fault trick to make it seem that the framebuffer is
linear when it isn't. Since the framebuffer window is 64K when the page
fault happens beyond the 64 K region (you have to allocate the A000 to
BFFFF region for this to work). Then you flip the page on this page fault.
You are thinking what doe sthis have to do with the problem you
discussed. Thing about it in the reverse. Instead of allocating a bunch of
small chunks together to make it look like a big region you can take a
small chunk out of a big linear region. The problem is you don't get
perfect windows since you have page alignment and page size to deal with. So
it might draw a few pixel over to much. Of course you can arrange it so at
window creation time the window will be the right size.

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/