Re: Multi-seat XFree solution under Linux with framebuffers.

[Stian H. <sti...@it...>]

Hi, Svetljo, and sorry about the delay in answering you mail.

> > for more than one card/manufacturer (eg. Nvidia, ATI, Matrox, sis).
> what do you mean by that  ^^^^^^

What I mean is that I want to ba able to use one Nvidia card as the main
card, one ATI on the first X-Server and one Matrox card on the second,
and maybe a SIS on a third one.


> can you get more then one fb device for cards other then Matrox,

I think this will be ok, yes. The driver is hopefully finished in about
14 days for ATI (For our specific card).

> if the card has several heads but in one chip, i think you wont be able 
> to get them work , as they register a single fb device, i think can get all 
> heads only under windows or with special closed source drivers driven by a 

The solution on our card is 4 ATI Mobility chips with "dual head"/ two
independant outputs functionality. This makes a total of 8 output from
one card.

> single X server. I was thinking that most of the cards act to the OS as a 
> single head, but the card itself drives/ separates /manage more monitors.
> (i'm having the Nvidia cards in mind, i don't think you can get them work as 
> dual head with the open source driver, but i might be misstaken) 

We have not been able to get dualhead functionality for the Nvidia
cards. (We are not able to have more than one Nvidia card in the machine
at the same time either. This should be a driver problem, and I have not
had the time or knowledge to examine this.)

 
> > I will look into this once again, but I know we had some problems with
> > only one X-session showing at the time (and the rest went blank or
> > "sleeping") when we used the patch from Freitas.
> 
> i know, some cards doesn't play nice, the explanation was that they need to 
> disable all other PCI resources in order to initialise.
> 
> i had a found some discussion about the problem, but i don't have right now the 
> link, i'll post it later. 

Thank you !


> > We have also tried the backstreet ruby solution, but this was not
> > supporting the kernel version that we needed at the time when we tried
> > it. Maybe it will work now ? (Kernel 2.4.21-pre5 or later)
> > 
> 
> it's up to 2.4.20, do you really need a bleeding new kernel?

I'm sorry to say, yes. We need some USB functionality that has been
taken into the new 2.4.21-pre5 (We are sending 32 mouses and keyboards
over a network protocol, and need them to be treated as USB keyboards
and mouses at the target machine.)

> you can try to sync it to 2.4.21-pre5.

I will try to do this in the weekend if I get the time to do it....


> best,
> 
> svetljo


WBR Stian Hartviksen