From guest Mon Apr 4 10:29:47 1994 Date: Mon, 4 Apr 1994 13:27:01 -0400 (EDT) From: Kevin Mueller Subject: Queued devices To: info-performer@sgi.sgi.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: OR Hi All: While trying to learn about queued devices in/with Proformer calls, I ran across the following problem. Queued devices do not appear to work properly when pfMultiprocess() is called with PFMP_DEFAULT. I used the code sample.c in /usr/src/Performer/src/pguide/libpf/progs to add queued device calls. After some time I called pfMultiprocess() with PFMP_APPCULLDRAW and the code worked fine. I have a diff of the code but I was worried if make this massage to long. Has anybody else seen this situation our am I just missing something? If more info is needed I can provide the code or a diff of my code with the original code sample.c. -- Kevin Mueller Institute for Simulation and Training University of Central Florida Mueller@vsl.ist.ucf.edu Orlando, Florida 32822 (407) 239-4711 - Office (407) 239-4703 - Lab From guest Mon Apr 4 15:44:52 1994 Message-Id: <9404042243.AA20242@surreal.asd.sgi.com> To: Kevin Mueller Cc: info-performer@sgi.sgi.com Subject: Re: Queued devices In-Reply-To: Your message of "Mon, 04 Apr 94 13:27:01 EDT." Date: Mon, 04 Apr 94 15:43:08 -0700 From: Jim Helman Status: OR > While trying to learn about queued devices in/with Proformer calls, I ran > across the following problem. Queued devices do not appear to > work properly when pfMultiprocess() is called with PFMP_DEFAULT. > I used the code sample.c in /usr/src/Performer/src/pguide/libpf/progs to > add queued device calls. After some time I called pfMultiprocess() with > PFMP_APPCULLDRAW and the code worked fine. I have a diff of the > code but I was worried if make this massage to long. When something works in PFMP_APPCULLDRAW but doesn't in other process models, the problem is almost always that the application is making calls in the wrong process or is not passing information properly through shared memory. In this case, the issue is probably that GL calls should only be made in the DRAW process. Check out how perfly handles things. In the long term, you'd be better off going with X-based input and window handling since OpenGL will require it. rgds, -jim helman jimh@surreal.asd.sgi.com 415/390-1151 From guest Mon Apr 4 16:06:30 1994 Date: Mon, 4 Apr 94 16:06:16 -0700 From: mtj@babar (Michael Jones) Message-Id: <9404042306.AA05502@babar.asd.sgi.com> To: info-performer@sgi.sgi.com, Kevin Mueller Subject: Re: Queued devices Status: OR Sounds like a data-synchronization/address-space issue. Is there any chance that you're making GL-calls (qtest, etc.) from the cull or app processes? That's my bet. If this is not it, we'll need more info, such as the manner in which it fails, the error codes returned, the code itself, a stack trace if it core dumps, etc. Be seeing you, mtj@sgi.com 415.390.1455 M/S 7L-590 Michael Jones Silicon Graphics, Advanced Graphics Division 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311 From guest Mon Apr 4 16:12:08 1994 From: "Sharon Fischler" Message-Id: <9404041608.ZM17100@rose.asd.sgi.com> Date: Mon, 4 Apr 1994 16:08:59 -0700 In-Reply-To: Jim Helman "Re: Queued devices" (Apr 4, 3:43pm) References: <9404042243.AA20242@surreal.asd.sgi.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Jim Helman , Kevin Mueller Subject: Re: Queued devices Cc: info-performer@sgi.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR +>---- On Apr 4, 3:43pm, Jim Helman wrote: > Subject: Re: Queued devices -> -> ->> While trying to learn about queued devices in/with Proformer calls, I ran ->> across the following problem. Queued devices do not appear to ->> work properly when pfMultiprocess() is called with PFMP_DEFAULT. ->> I used the code sample.c in /usr/src/Performer/src/pguide/libpf/progs to ->> add queued device calls. After some time I called pfMultiprocess() with ->> PFMP_APPCULLDRAW and the code worked fine. I have a diff of the ->> code but I was worried if make this massage to long. -> ->When something works in PFMP_APPCULLDRAW but doesn't in other process models, ->the problem is almost always that the application is making calls in the ->wrong process or is not passing information properly through shared memory. -> ->In this case, the issue is probably that GL calls should only be made in the ->DRAW process. Check out how perfly handles things. In the long term, you'd Exactly. Make sure that your call to pfuCollectInput() is being done in the draw process - I would venture to guess that you are calling it in the application process. srf. -- -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ Sharon Rose Fischler - Silicon Graphics, Advanced Graphics Development srf@sgi.com (415) 390 - 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---@ -----{----{---@ -----{----{---@ -----{----{---@ From guest Wed Jun 15 10:00:50 1994 Date: Wed, 15 Jun 94 17:48:36 +0100 From: angus@death.reading.sgi.com (Angus Henderson) Message-Id: <9406151648.AA07390@death.reading.sgi.com> To: info-performer@sgi.sgi.com Subject: Mouse input Status: OR What is the best way of determining which channel the mouse is in, on a 3 chaannel, 3 pipe performer application ? I am using pfuGetMouse, but I need to collectInput in whichever channel/pipe has the mouse. I am using GL input. a.t.b ANgus The Sharks Are Swimming Again "Imagine your witty quote here" From guest Thu Jun 16 12:30:49 1994 From: jrohlf@tubes (John Rohlf) Message-Id: <9406161930.AA05192@tubes.asd.sgi.com> Subject: Re: Mouse input To: guest (Angus Henderson) Date: Thu, 16 Jun 94 12:30:57 PDT Cc: info-performer@sgi.sgi.com In-Reply-To: <9406151648.AA07390@death.reading.sgi.com>; from "Angus Henderson" at Jun 15, 94 5:48 pm X-Mailer: ELM [version 2.3 PL8] Status: O > > > What is the best way of determining which channel the mouse is in, on > a 3 chaannel, 3 pipe performer application ? > > I am using pfuGetMouse, but I need to collectInput in whichever > channel/pipe has the mouse. I am using GL input. > > a.t.b > > ANgus > > The Sharks Are Swimming Again > > "Imagine your witty quote here" I know of no easy way to find out which pipe the cursor is in and the comment in collectGLInput, which implies that mouse x/y are returned as -1 if the cursor is not in the collecting pipe, no longer seems to be correct. -jr From guest Tue May 24 06:01:45 1994 From: "knut" Message-Id: <9405241324.ZM1016@knut.oslo.sgi.com> Date: Tue, 24 May 1994 13:24:05 -0600 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: info-performer@sgi.sgi.com Subject: Pointing devices Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Status: OR Hello I have a customer that needs an extaernal pointing device attaced to his Onyx RE2 . He needs to stand 10 -20 feet away from the screen ( Barco Heads Up ) and point with a "laser mouse" on the screen (wall). Does any of you know about a device like this ? Wher can I advice my customer to go to ? -- ------------------------------------------------- - Knut Ivar Foshaug - - Email: knut@oslo.sgi.com - - Tlf: +47 22 73 00 29 - - Mailstop: INO-335 - - VoiceMail: 5-8600 - -------------------------------------------------