Re: three-pipe operation using the Triple Keyboard Option
Daniel C. Williams X-2453 (dcw++at++sarnoff.com)
Fri, 20 Oct 1995 11:34:15 -0400 (EDT)
According to Allan Schaffer:
>
>On Oct 19, 2:38pm, Daniel C. Williams X-2453 wrote:
>>
>> I'm trying to get Performer1.2 to run in multipipe, multiple channel
>> mode when using the Triple Keyboard Option on my client's 3-pipe
>> RE2. That is, when running three X servers as :0, :1 and :2 instead
>> of one X server as :0.0, :0.1 and :0.2.
>
>> When I run in non-TKO mode and the display strings are :0.0, :0.1 and :0.2,
>> it works fine. When I run in TKO mode and the display strings are
>> :0, :1 and :2, it fails with this stack trace when it tries to open the
>> second pipe:
>>
>> Am I doing something wrong, or is this a limitation of Performer1.2?
>> If the latter, will it be addressed by Performer2.0?
>
>This is ultimately a shortcoming of Performer 1.2; I haven't tried it
>with Performer 2.0 but think it should work better there.
>
>I'm inclined to believe the bus errors you get come from using
>XOpenDisplay outright. I've been able to get it to work by using
>putenv("DISPLAY=:0"); [and :1, :2 etc] in 3 separate initPipe
>routines, which is more hackishly indirect than XOpenDisplay().
>
>I'll include the toy program I used to test below, based on
>multipipe.c. It's not clean but you'll get the idea. Two
>things to remember:
>
> - the 'putenv()' must precede any calls from the GL library
> (including 'foreground')
>
> - remember to 'winset' to the correct window in the draw callback
>
>Allan
>
> [Source code here]
>
Your example runs fine on two pipes in TKO mode. However, when
I use your technique for setting the DISPLAY in perfly (and three
draw functions as well) it's as if it is ignored, because all three
windows come up on the default display.
This made me pull out gldebug, which shows the following activity
happening before the per-pipe functions are called:
getgdesc(GD_XPMAX);
getgdesc(GD_YPMAX);
gversion(OUT);
getgdesc(GD_NSCRNS);
scrnselect(0);
foreground();
noport();
winopen("pfvsync");
Is this the culprit? If so, what part of Performer is doing it
and can I turn it off or work around it?
Dan
--
Daniel Williams, Consultant to: David Sarnoff Research Center
Voice: (609) 734-2153 Email: dcw++at++sarnoff.com, dan++at++sass.com
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:51:58 PDT