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

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

> 
> This scheme is very close to what we have now. The only thing that is
> changed is
> that there is no way for a text VT to write to the graphics hardware
> without the
> help of a process running on the graphical console. The advantage of
> this scheme
> is that there only a single login ever on the graphics hardware.
> 
I don't see the advantage, look as MSs switch user functionality.  I don't
see WHY you would want to 'bg' then 'su' to a new user, like MS dose.  I
like the simplicity of a hot-key the gets you QWICKLY to another
virtual-terminal.  If you have a plan for that then why are you saying to
get rid of VT-swaps?

> In a multiuser scheme there needs to be a more complex interface. The
> text VTs
> have to track who created them. You wouldn't want another user attaching
> an
> active text VT that isn't theirs.
> 
> --- Alan Cox <[EMAIL PROTECTED]> wrote:
> > On Iau, 2004-05-20 at 01:55, Jon Smirl wrote:
> > > It's not going to allow multiple login prompts on different VTs on
> the same
> > > head.
> > 
Will it allow ONE login prompt on a different VT?  I guess if done that
way it'd be better then what we have now.

> > In which case its completely useless. You might want to get away from
> a
> > kernel virtualisation of video services but you just can't do it. You
> > can pull a *lot* of the fancier stuff out of kernel as you've
> suggested
> > but the basic VT and memory management just won't fit your model
> > 
> 
> =====
> Jon Smirl
> [EMAIL PROTECTED]
> 



        
                
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer 


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