linuxconsole-dev

multiXnest

[Ander C. de O. <ac...@in...>]

Hello,

We're writing to annouce a new multiseat solution: multiXnest. This
solution is based on a modified Xnest server which reads it's input from
the kernel event interface. This solution should work with any video
card supported by the Xorg/Xfree86 X server.

For the last weeks, we've been working to make this usable.

A pre-compiled binary can be download from
http://www.c3sl.ufpr.br/multiterminal/multiXnest .

The patch include 7 new command line options to the orginal Xnest server:

-kbd file              evdev file to read keyboard events
-ptr file              evdev file to read pointer events
-xkb-rules string      specify the XKB rules
-xkb-layout string     specify the XKB layout
-xkb-model string      specify the XKB model
-xkb-variant string    specify the XKB variant
-xkb-options string    specify the XKB options

Know issues:
- the keyboard mapping is incomplete,
- keyboard leds don't work
- multiXnest consumes more CPU than it should

We use the multiXnest-wrapper script to start the X server because gdm
always passes a vt option in the command line. This script also=20
introduces an option to pass the .Xauthority file to use.

A sample gdm config file looks like this:
[...]

[servers]
0=3DHardware
1=3DMonitor0
2=3DMonitor1

[server-Hardware]
name=3DHardware
command=3D/usr/X11R6/bin/X
handled=3Dfalse
flexible=3Dfalse

[server-Monitor0]
name=3DMonitor0
command=3D/root/multiXnest-wrapper -display :0.0 -xauthority \=20
/var/lib/gdm/:0.Xauth
-geometry 1024x768+0+0 -kbd /dev/input/kbd0ev -ptr /dev/input/mouse0ev
-dpi 92
handled=3Dtrue
flexible=3Dfalse

[server-Monitor1]
name=3DMonitor0
command=3D/root/multiXnest-wrapper -display :0.1 -xauthority \=20
/var/lib/gdm/:0.Xauth
-geometry 1024x768+0+0 -kbd /dev/input/kbd0ev -ptr /dev/input/mouse0ev
-dpi 92
handled=3Dtrue
flexible=3Dfalse

The X server is configured with one layout with all the screens and
without Xinerama.


Ander Conselvan de Oliveira
Centro de Computa=E7=E3o Cient=EDfica e Software Livre - C3SL	  www.c3sl.=
ufpr.br

Re: multiXnest

[Helge H. <hel...@ai...>]

Ander Conselvan de Oliveira wrote:

> Helge Hafting wrote:
>
>> Ander Conselvan de Oliveira wrote:
>
> >
>
>>> We're writing to annouce a new multiseat solution: multiXnest. This
>>> solution is based on a modified Xnest server which reads it's input 
>>> from
>>> the kernel event interface. This solution should work with any video
>>> card supported by the Xorg/Xfree86 X server. 
>>
>>
>> Just curious: what does this achieve, that you can't already achieve
>> with a non-nested xserver that reads input from evdev?
>
>
> The XFree86/Xorg server is able to run using several video cards but 
> with only one pointer/keyboard. 

Well, ordinary x.org (from debian and several others) is capable of
using several pointers and keyboards.  (One pointer+kbd per seat.)
That's why I asked - I already run such a setup. :-)

> A module called RAC (Resource Access Control) prevents conflicts 
> beetween the video cards, allowing a server with several cards from 
> different manufacturers to be used.

Now this may be interesting, plain xorg sometimes struggle with this.
I.e. restarting one of my xorg servers blanks the other display, so I
have to resize it (ctrl+keyboad+) to get it back.  Easy for me, confuses
my users.  RAC avoids such problems?

>
> Using the the multiXnest server, we can take advantage o the 
> XFree86/Xorg RAC in a multiseat environment. Today, we have three 
> different hardware configurations stable:
>
> - 4 seats with 1 Radeon Dual 7000/VE AGP + 1 Radeon Dual 7000/VE PCI
> - 4 seats with 1 Rage 128 + 3 Rage XL
> - 4 seats with 4 SiS 315
>
> It should work with dual nvidias and any other combination that works 
> with an ordnary xinerama x server configuration.

Can all of the users use accelerated 3D at the same time too, like they can
with a xorg setup?  (Well, with some xorg setups - not all cards will
cooperate nicely. But some do. Children tend to want to play the same
game, so a setup where not _all_ heads have the same fetures won't do.)

Helge Hafting

Re: multiXnest

[Ander C. de O. <ac...@in...>]

Helge Hafting wrote:
> Ander Conselvan de Oliveira wrote: 
>> Helge Hafting wrote:
> 
> Well, ordinary x.org (from debian and several others) is capable of
> using several pointers and keyboards.  (One pointer+kbd per seat.)
> That's why I asked - I already run such a setup. :-)
That's the point. The x.org was modified to allow multiseat. But this is 
a hack. The whole thing is made so that just one instance of the server 
is controlling all the hardware. The right way to do it, would be 
implement something like RAC into the kernel.

>> A module called RAC (Resource Access Control) prevents conflicts 
>> beetween the video cards, allowing a server with several cards from 
>> different manufacturers to be used.
> 
> 
> Now this may be interesting, plain xorg sometimes struggle with this.
> I.e. restarting one of my xorg servers blanks the other display, so I
> have to resize it (ctrl+keyboad+) to get it back.  Easy for me, confuses
> my users.  RAC avoids such problems?
Yes. But to take advantage of RAC, you have to run an X server with 
Xinerama. And, on top of that X server, run multiXnest.


> Can all of the users use accelerated 3D at the same time too, like they can
> with a xorg setup?  (Well, with some xorg setups - not all cards will
> cooperate nicely. But some do. Children tend to want to play the same
> game, so a setup where not _all_ heads have the same fetures won't do.)
Xnest lacks accelerated 3d support. I guess it could be implemented though.

Ander

Re: multiXnest

[Aivils S. <ai...@un...>]

On Tre=F0diena, 9. Novembris 2005 13:38, Ander Conselvan de Oliveira wrote:
> Helge Hafting wrote:
> > Ander Conselvan de Oliveira wrote:
> >> Helge Hafting wrote:
> >
> > Well, ordinary x.org (from debian and several others) is capable of
> > using several pointers and keyboards.  (One pointer+kbd per seat.)
> > That's why I asked - I already run such a setup. :-)
>
> That's the point. The x.org was modified to allow multiseat. But this is
> a hack. The whole thing is made so that just one instance of the server
> is controlling all the hardware. The right way to do it, would be
> implement something like RAC into the kernel.

Yep. That Debian modification is not acepted by X men. It is nonpro solution
as all as i provide. I think working state is a lucky case more than=20
regularity, even so many peoples use it.

> >> A module called RAC (Resource Access Control) prevents conflicts
> >> beetween the video cards, allowing a server with several cards from
> >> different manufacturers to be used.
> >
> > Now this may be interesting, plain xorg sometimes struggle with this.
> > I.e. restarting one of my xorg servers blanks the other display, so I
> > have to resize it (ctrl+keyboad+) to get it back.  Easy for me, confuses
> > my users.  RAC avoids such problems?
>
> Yes. But to take advantage of RAC, you have to run an X server with
> Xinerama. And, on top of that X server, run multiXnest.
>
> > Can all of the users use accelerated 3D at the same time too, like they
> > can with a xorg setup?  (Well, with some xorg setups - not all cards wi=
ll
> > cooperate nicely. But some do. Children tend to want to play the same
> > game, so a setup where not _all_ heads have the same fetures won't do.)
>
> Xnest lacks accelerated 3d support. I guess it could be implemented thoug=
h.

Best way of course is N pointers and N focus windows of X server, but
here is an authorisation troubles.
At least nvidia runs accelerated GLX on both heads of one videocard.

Aivils

Re: multiXnest

[Helge H. <hel...@ai...>]

Aivils Stoss wrote:

>On Trešdiena, 9. Novembris 2005 13:38, Ander Conselvan de Oliveira wrote:
>  
>
>>Helge Hafting wrote:
>>    
>>
>>>Ander Conselvan de Oliveira wrote:
>>>      
>>>
>>>>Helge Hafting wrote:
>>>>        
>>>>
>>>Well, ordinary x.org (from debian and several others) is capable of
>>>using several pointers and keyboards.  (One pointer+kbd per seat.)
>>>That's why I asked - I already run such a setup. :-)
>>>      
>>>
>>That's the point. The x.org was modified to allow multiseat. But this is
>>a hack. The whole thing is made so that just one instance of the server
>>is controlling all the hardware. The right way to do it, would be
>>implement something like RAC into the kernel.
>>    
>>
>
>Yep. That Debian modification is not acepted by X men. It is nonpro solution
>as all as i provide. I think working state is a lucky case more than 
>regularity, even so many peoples use it.
>  
>
Hm.  Do those "X-men" have a long-term plan for a better
solution than the working one they don't like?

Helge Hafting

Re: multiXnest

[Aivils S. <ai...@un...>]

On Ceturtdiena, 10. Novembris 2005 09:51, Helge Hafting wrote:
> Aivils Stoss wrote:
> >On Tre=C5=A1diena, 9. Novembris 2005 13:38, Ander Conselvan de Oliveira =
wrote:
> >>Helge Hafting wrote:
> >>>Ander Conselvan de Oliveira wrote:
> >>>>Helge Hafting wrote:
> >>>
> >>>Well, ordinary x.org (from debian and several others) is capable of
> >>>using several pointers and keyboards.  (One pointer+kbd per seat.)
> >>>That's why I asked - I already run such a setup. :-)
> >>
> >>That's the point. The x.org was modified to allow multiseat. But this is
> >>a hack. The whole thing is made so that just one instance of the server
> >>is controlling all the hardware. The right way to do it, would be
> >>implement something like RAC into the kernel.
> >
> >Yep. That Debian modification is not acepted by X men. It is nonpro
> > solution as all as i provide. I think working state is a lucky case more
> > than regularity, even so many peoples use it.
>
> Hm.  Do those "X-men" have a long-term plan for a better
> solution than the working one they don't like?

Someone should make public a political volition about multi seat, like
petition to Xorg "We want to live as humans".
I have read discussions about multi seat. two anti conditions are
notified allways:
1) multiple X cannot manage hardware resources.
2) _nonstandard_ solution increase costs anyway, even if hardware is cheape=
r.

standard or nonstandard is a public opinition only. At least i do not
know how to ISO commite,ANSI,DIN defines a PC.

Aivils

Multiseat supported by Xorg or not?

[Friedrich W. H. K. <Fri...@ko...>]

Am Dienstag 15 November 2005 11:41, schrieb Aivils Stoss:
> On Ceturtdiena, 10. Novembris 2005 09:51, Helge Hafting wrote:
> > Aivils Stoss wrote:
> > >On Tre=C5=A1diena, 9. Novembris 2005 13:38, Ander Conselvan de Oliveir=
a wrote:
> > >>Helge Hafting wrote:
> > >>>Ander Conselvan de Oliveira wrote:
> > >>>>Helge Hafting wrote:
> > >>>
> > >>>Well, ordinary x.org (from debian and several others) is capable of
> > >>>using several pointers and keyboards.  (One pointer+kbd per seat.)
> > >>>That's why I asked - I already run such a setup. :-)
> > >>
> > >>That's the point. The x.org was modified to allow multiseat. But this
> > >> is a hack. The whole thing is made so that just one instance of the
> > >> server is controlling all the hardware. The right way to do it, would
> > >> be implement something like RAC into the kernel.
> > >
> > >Yep. That Debian modification is not acepted by X men. It is nonpro
> > > solution as all as i provide. I think working state is a lucky case
> > > more than regularity, even so many peoples use it.
> >
> > Hm.  Do those "X-men" have a long-term plan for a better
> > solution than the working one they don't like?
>
> Someone should make public a political volition about multi seat, like
> petition to Xorg "We want to live as humans".
> I have read discussions about multi seat. two anti conditions are
> notified allways:
> 1) multiple X cannot manage hardware resources.
> 2) _nonstandard_ solution increase costs anyway, even if hardware is
> cheaper.
>
> standard or nonstandard is a public opinition only. At least i do not
> know how to ISO commite,ANSI,DIN defines a PC.

Hm, I wonder what relation these comments have to the attached emails from =
=20
xo...@li... just yesterday.

Regards
=46riedrich

Re: Multiseat supported by Xorg or not?

[Aivils S. <ai...@un...>]

On Tre=F0diena, 16. Novembris 2005 14:40, Friedrich W. H. Kossebau wrote:
> Am Dienstag 15 November 2005 11:41, schrieb Aivils Stoss:
> > On Ceturtdiena, 10. Novembris 2005 09:51, Helge Hafting wrote:
> > > Aivils Stoss wrote:
> > > >On Tre=F0diena, 9. Novembris 2005 13:38, Ander Conselvan de Oliveira=
=20
wrote:
> > > >>Helge Hafting wrote:
> > > >>>Ander Conselvan de Oliveira wrote:
> > > >>>>Helge Hafting wrote:
> > > >>>
> > > >>>Well, ordinary x.org (from debian and several others) is capable of
> > > >>>using several pointers and keyboards.  (One pointer+kbd per seat.)
> > > >>>That's why I asked - I already run such a setup. :-)
> > > >>
> > > >>That's the point. The x.org was modified to allow multiseat. But th=
is
> > > >> is a hack. The whole thing is made so that just one instance of the
> > > >> server is controlling all the hardware. The right way to do it,
> > > >> would be implement something like RAC into the kernel.
> > > >
> > > >Yep. That Debian modification is not acepted by X men. It is nonpro
> > > > solution as all as i provide. I think working state is a lucky case
> > > > more than regularity, even so many peoples use it.
> > >
> > > Hm.  Do those "X-men" have a long-term plan for a better
> > > solution than the working one they don't like?
> >
> > Someone should make public a political volition about multi seat, like
> > petition to Xorg "We want to live as humans".
> > I have read discussions about multi seat. two anti conditions are
> > notified allways:
> > 1) multiple X cannot manage hardware resources.
> > 2) _nonstandard_ solution increase costs anyway, even if hardware is
> > cheaper.
> >
> > standard or nonstandard is a public opinition only. At least i do not
> > know how to ISO commite,ANSI,DIN defines a PC.
>
> Hm, I wonder what relation these comments have to the attached emails from
> xo...@li... just yesterday.
>
That is third party code. Try to ask Xorg why similar keyboard driver,
shipped by Debian, created at fall of 2003, does not fit for main stream.
key word: 055_lnx_evdev_keyboard.diff
destination: www.debian.org
Debian stable shipped with this one.

Aivils

Re: Multiseat supported by Xorg or not?

[Aivils S. <ai...@un...>]

On Tre=F0diena, 16. Novembris 2005 14:40, Friedrich W. H. Kossebau wrote:
> Am Dienstag 15 November 2005 11:41, schrieb Aivils Stoss:
> > On Ceturtdiena, 10. Novembris 2005 09:51, Helge Hafting wrote:
> > > Aivils Stoss wrote:
> > > >On Tre=F0diena, 9. Novembris 2005 13:38, Ander Conselvan de Oliveira=
=20
wrote:
> > > >>Helge Hafting wrote:
> > > >>>Ander Conselvan de Oliveira wrote:
> > > >>>>Helge Hafting wrote:
> > > >>>
> > > >>>Well, ordinary x.org (from debian and several others) is capable of
> > > >>>using several pointers and keyboards.  (One pointer+kbd per seat.)
> > > >>>That's why I asked - I already run such a setup. :-)
> > > >>
> > > >>That's the point. The x.org was modified to allow multiseat. But th=
is
> > > >> is a hack. The whole thing is made so that just one instance of the
> > > >> server is controlling all the hardware. The right way to do it,
> > > >> would be implement something like RAC into the kernel.
> > > >
> > > >Yep. That Debian modification is not acepted by X men. It is nonpro
> > > > solution as all as i provide. I think working state is a lucky case
> > > > more than regularity, even so many peoples use it.
> > >
> > > Hm.  Do those "X-men" have a long-term plan for a better
> > > solution than the working one they don't like?
> >
> > Someone should make public a political volition about multi seat, like
> > petition to Xorg "We want to live as humans".
> > I have read discussions about multi seat. two anti conditions are
> > notified allways:
> > 1) multiple X cannot manage hardware resources.
> > 2) _nonstandard_ solution increase costs anyway, even if hardware is
> > cheaper.
> >
> > standard or nonstandard is a public opinition only. At least i do not
> > know how to ISO commite,ANSI,DIN defines a PC.
>
> Hm, I wonder what relation these comments have to the attached emails from
> xo...@li... just yesterday.

Wow! Dummy me!
xorg-x11-6.8.99.902.tar.bz2 realy contain -sharevts and -isolateDevice
commandline options and undocumented (no manual, no readme) evdev driver fr=
om=20
RedHat. X men give up.

Now anybody can write to Xorg "Why video card A is not compatible with
video card B , if multiple X runs simultaneous?" or "Why i cannot start
2nd X on my dual head video card?" ;-)

Aivils

Re: multiXnest

[Helge H. <hel...@ai...>]

Ander Conselvan de Oliveira wrote:

> Hello,
>
> We're writing to annouce a new multiseat solution: multiXnest. This
> solution is based on a modified Xnest server which reads it's input from
> the kernel event interface. This solution should work with any video
> card supported by the Xorg/Xfree86 X server.

Just curious: what does this achieve, that you can't already achieve
with a non-nested xserver that reads input from evdev?

Helge Hafting

Re: multiXnest

[Aivils S. <ai...@un...>]

On Otrdiena, 8. Novembris 2005 14:30, Helge Hafting wrote:
> Ander Conselvan de Oliveira wrote:
> > Hello,
> >
> > We're writing to annouce a new multiseat solution: multiXnest. This
> > solution is based on a modified Xnest server which reads it's input from
> > the kernel event interface. This solution should work with any video
> > card supported by the Xorg/Xfree86 X server.
>
> Just curious: what does this achieve, that you can't already achieve
> with a non-nested xserver that reads input from evdev?

Support of multihead video cards like matrox g550 ;o)

Aivils

Re: multiXnest

[Ander C. de O. <an...@c3...>]

Helge Hafting wrote:
> Ander Conselvan de Oliveira wrote:
 >
>> We're writing to annouce a new multiseat solution: multiXnest. This
>> solution is based on a modified Xnest server which reads it's input from
>> the kernel event interface. This solution should work with any video
>> card supported by the Xorg/Xfree86 X server. 
> 
> Just curious: what does this achieve, that you can't already achieve
> with a non-nested xserver that reads input from evdev?

The XFree86/Xorg server is able to run using several video cards but 
with only one pointer/keyboard. A module called RAC (Resource Access 
Control) prevents conflicts beetween the video cards, allowing a server 
with several cards from different manufacturers to be used.

Using the the multiXnest server, we can take advantage o the 
XFree86/Xorg RAC in a multiseat environment. Today, we have three 
different hardware configurations stable:

- 4 seats with 1 Radeon Dual 7000/VE AGP + 1 Radeon Dual 7000/VE PCI
- 4 seats with 1 Rage 128 + 3 Rage XL
- 4 seats with 4 SiS 315

It should work with dual nvidias and any other combination that works 
with an ordnary xinerama x server configuration.

Ander
C3SL

Re: multiXnest

[Aivils S. <ai...@un...>]

On Piektdiena, 4. Novembris 2005 21:36, Ander Conselvan de Oliveira wrote:
> Hello,
>
> We're writing to annouce a new multiseat solution: multiXnest. This
> solution is based on a modified Xnest server which reads it's input from
> the kernel event interface. This solution should work with any video
> card supported by the Xorg/Xfree86 X server.
>
> For the last weeks, we've been working to make this usable.
>
> A pre-compiled binary can be download from
> http://www.c3sl.ufpr.br/multiterminal/multiXnest .
>
> The patch include 7 new command line options to the orginal Xnest server:
>
> -kbd file              evdev file to read keyboard events
> -ptr file              evdev file to read pointer events
> -xkb-rules string      specify the XKB rules
> -xkb-layout string     specify the XKB layout
> -xkb-model string      specify the XKB model
> -xkb-variant string    specify the XKB variant
> -xkb-options string    specify the XKB options
>
> Know issues:
> - the keyboard mapping is incomplete,
> - keyboard leds don't work
> - multiXnest consumes more CPU than it should
>
> We use the multiXnest-wrapper script to start the X server because gdm
> always passes a vt option in the command line. This script also
> introduces an option to pass the .Xauthority file to use.

You can compare code :) Main difference - i use runtime modification.
Share half of your desktop right now. Xnest still is without cursor :(

Xnest :2 uses /usr/X11R6/lib/X11/xkb/X2-config.keyboard . May be -xkb-*
command line options became unnecessary, if this file is properly
configured.

Issues: same as above.

Aivils Stoss