Re: Xephyr instead of Xnest

[James v. Z. <ja...@dv...>]

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