Re: Xephyr instead of Xnest

[Hugo V. <hvw...@ya...>]

--- James van Zeeland <ja...@dv...> wrote:

> 
> I tend to agree with Aivils. Any nested X server is
> going to be doubling
> up on certain resources. good multi console support
> in X is basically
> there for me, with one intermittent exception; use
> of text/framebuffer
> consoles and unstable console switching, with
> frambuffers and/or text
> consoles becoming corrupted: It's not just int10h
> video calls, I've
> tried using noint10 on all servers and then int10 on
> primary console but
> noint10 on secondaries, there are a few X patches I
> have not tried yet,
> but for one machine out of three (?), the console
> instability is an
> issue; faketty and ruby both. I use nVidia binary
> drivers and all nV
> cards. 

Interesting. I use nVidia binary drivers + faketty
with 2.6.14-ck6
(http://members.optusnet.com.au/ckolivas/kernel/ ) and
(knock on wood!!!) I do not see any console
instability. I have one machine with 2 Xservers, one
of them on vt7 and the other on vt51.


Apart from this it is rock solid. I believe
> 2.6.9-vz11 ruby
> patched kernel was stable and this problem was
> resolved: I had no
> machines that displayed this console instability
> that I recall, but
> later kernels it has reappeared.
> 
> The nested solution, for me, although an excellent
> workaround for
> machines that will not perform multi-X stably for
> driver or other
> reasons, will play the role of non-preferred option
> first because
> multi-X is more feature full than nested-X and
> secondly because Xnest in
> it's stock form has demonstrated itself to be
> unstable for the entire
> time I've used it. Perhaps multiXnest has fixed
> this. I don't see any
> way around the increased resource requirements (?)
> however.
> 
> Xephyr sounds like a good replacement for Xnest and
> if the proposed
> features were applied, that would be an excellent
> one that I would be
> keen to use. However, I suspect for multi-console
> implementations, it
> will still play second place to ruby/faketty/evdev
> multi-X.
> 
> The "ideal" solution I feel would provide multiple
> text/framebuffer
> consoles alongside multiple X. For now that is
> probably asking a bit
> much, and I'll settle for a single text console that
> is never corrupted.
> 
> J
> 
> Under vmware DirectX hardware accelleration is like
> programmers toy
> > but not a practical value.
> 
> But improving with 5.5?
> 
> On Wed, 2005-11-30 at 17:40, Aivils Stoss wrote:
> > On Otrdiena, 29. Novembris 2005 19:32, Michael
> Pardee wrote:
> > > > Having mouse and keyboards specified makes
> Xephyr as good as
> > > > multiXnest for us, but once again we want to
> move to Xephyr for the
> > > > future.
> > >
> > > Xephyr does have other advantages over Xnest -
> server side support for
> > > modern X extensions like XRender, XRandr,
> XDamage etc.
> > >
> > > > What kind of work (or costs) would be involved
> to:
> > > > 1. use the xv extension for video overlays
> > > > 2. handle the keyboard leds properly
> > > > 3. use nvidia 3d hardware excelleration
> > >
> > > (1) I think would be possible and *maybe* not
> that hard. Would need more
> > > investigation.
> > > (2) Could very likely be fairly trivial with the
> above evdev additions.
> > > (3) This is probably extremely difficult and
> maybe not even possible at
> > > all. Though that said vmware can do direct3d
> accel via h/w afaik on
> > > Linux so there is likely a way. Needs much more
> thought though. You are
> > > likely looking at months rather than weeks of
> work here.
> > >
> > > > If those tasks are just about impossible in
> the next year, moving to
> > > > Xephyr doesn't help all that much, except
> maybe Xephyr is faster than
> > > > xnest.
> > >
> > > Depending on the underlying card and X operation
> Xephyr likely does out
> > > perform Xnest though I've never ran any figures
> on this.
> > 
> > 	In my opinition in far future better is having
> pointer and keyboard for
> > each X screen. X server screen as separate
> workstation from view point
> > of end user already solve all troubles notified
> above. Most of X device
> > drivers support xv, OpenGL hardware acceleration
> for each screen.
> > 	One trouble left - X authentification.
> > 
> > 	In case when xv or 3d hardware accelleration goes
> via another X emulator
> > Xnest or Xephyr , then it becames slower. Anybody
> cant test it with
> > windows games via Wine or WineX, where emulator
> calls host openGL only.
> > Under vmware DirectX hardware accelleration is
> like programmers toy
> > but not a practical value.
> > 
> > Aivils
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> > for problems?  Stop!  Download the new AJAX search
> engine that makes
> > searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
> >
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > Linuxconsole-dev mailing list
> > Lin...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> > 
> 



		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free. 
http://music.yahoo.com/unlimited/