Mike Mestnik wrote:
--- Jon Smirl <[EMAIL PROTECTED]> wrote:

There are two types of VTs - text and graphical. It is only practical to
have a
single graphical VT because of the complexity of state swapping a
graphical VT
at VT swap.


Right now we can all-ready run X on multiple VTs and with DRI-reinit can run GL apps on all of them. It may noy be the most elegant thing but it workes. We need the OS to keep state, even graphical, GART and all. I don't see how a 128M GART is diffrent then 2Gb system memory. Should we have GART swap space on the HD, a GART partition?

I'm for making the OS VT swap multiheaded DR?I? setups at whatever cost.

An elegant implementation would not swap the entire GART at VT switches but only present the new VT framebuffer as new display on the screen while maintaining the AGP states.


Check out e.g. MacOS-X's animated multiple login screen: At every new session start the current session just rotates smoothly animated into the background and a new one is brought up.

In this model you can retain the entire graphics state at VT switch, only another (currently invisible) frambuffer/screen/display/VT is made visible. This allows straightforward multihead implementations, any frambuffer/screen/display/VT can get attached to any head, they are just a piece of framebuffer memory which is either located in graphics memory or system memory and can get relocated on request, even to other graphics cards.


How about this for a new way to look at the problem?


System based xterm, that's a new one. I don't see how it's better then what we have now.

probably not -- the MacOS-X alike approach looks more promising. At SAK a new display framebuffer would get launched and brought to front, the currently running application is only need get killed if it locks the graphics engine in an locked state.


Unfortunally that means that parts of the window stack implementation need to run in kernel space (or a tightly connected trusted agent in userspace). Don't know whether this is a problem, the DirectFB core showed that it's possible to implement this cleanly in a few thousand lines of code.

Holger


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to