Menu
▾
▴
vrjuggler-info
|
From: Kejian J. <kj...@uc...> - 2005-07-15 17:08:01
|
Hi,
Following up the previous message from us:
Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and starting
it up with the command:
#!/bin/csh
./simplePf Bounding3.flt standalone.jconf |& tee jj
Using your standalone.jconf and the debug version of vrJuggler
And having added the following of my own debug statements to
PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* disp)
std::cerr << "JES PfDrawManager 2\n";
// Secondary
if(NULL != pf_viewport.chans[pfViewport::SECONDARY])
{
mSimChannels.push_back(pf_viewport.chans[pfViewport::SECONDARY])
; mSimMasterChan->attach(pf_viewport.chans[pfViewport::SECONDARY]
); }
std::cerr << "JES PfDrawManager 3\n";
}
std::cerr << "JES PfDrawManager 4\n";
// Add viewport to the display list
pf_disp.viewports.push_back(pf_viewport);
std::cerr << "JES PfDrawManager 5\n";
} // is viewport active
std::cerr << "JES PfDrawManager 6\n";
} // for each viewport
std::cerr << "JES PfDrawManager 7\n";
// -- Add new pfDisp to disp Vector -- //
mDisplays.push_back(pf_disp);
std::cerr << "JES PfDrawManager 8\n";
// Call pfFrame to cause the pipeWindow configured to be opened and setup.
pfFrame();
std::cerr << "JES PfDrawManager 9\n";
////pfuInitInput( pWin, PFUINPUT_NOFORK_X );
//pfuInitInput( pf_disp.pWin, PFUINPUT_X );
////pfPWinType( pWin, PFPWIN_TYPE_X_NOFORK );
//pfPWinType( pf_disp.pWin, PFPWIN_TYPE_X );
//pfuInputHandler(&handlePerformerEvents, PFUINPUT_CATCH_ALL);
PfInputHandler* new_input_handler = new PfInputHandler(pf_disp.pWin, disp->
getName());
std::cerr << "JES PfDrawManager a\n";
// Configure the Performer window to accept events.
jccl::ConfigElementPtr display_elt = disp->getConfigElement();
std::cerr << "JES PfDrawManager b\n";
new_input_handler->config(display_elt, disp);
std::cerr << "JES PfDrawManager c\n";
I get the following debug output:
And from It I know that the error on opening the window is coming from the
line:
PfInputHandler* new_input_handler = new PfInputHandler(pf_disp.pWin,
disp->getName());
[0364479/000] vrjDRAW: [vrj::PfDrawManager::initAPI()] Exiting.
[0364479/000] vrjDISP: vjDisplayManager: Setting draw manager.
[0364479/000] vrjDRAW: vrj::PfDrawManager: ---- Opening new Display
--------
[0364479/000] vrjDRAW: Display is:0x10104228
[0364479/000] vrjDRAW: PfDrawManager::add Display:
Got Display:
Name ............. SimWindow
Origin ........... 50, 100
Size ............. 800x800
Pipe number ...... 0
Stereo requested . No
Active ........... Yes
Viewport 0:
Name ........... Contained Sim Viewports 0
Active ......... Yes
User ........... User1
Origin ......... 0, 0
Size ........... 1x1
View ........... Right[0364479/000] vrjDRAW: OpenGL
visual request settings for SimWindow:
Color buffer red size
................ 1
Color buffer green size
.............. 1
Color buffer blue size
............... 1
Color buffer alpha size
.............. 1
Auxiliary buffer count
............... 0
Depth buffer size
.................... 1
Stencil buffer size
.................. 1
Accumulation buffer red size
......... 1
Accumulation buffer green size
....... 1
Accumulation buffer blue size
........ 1
Accumulation buffer alpha size
....... 1
Full-screen anti-aliasing
............ false
[0364479/000] vrjDRAW: [vrj::PfDrawManager::addDisplay()] Got
Mono FB config
5
4
8
1
9
1
10
1
11
1
7
0
12
1
13
1
14
1
15
1
16
1
17
1
0
[0364479/000] vrjDRAW: [vrj::PfDrawManager::addDisplay()]
Configuring mono window attribs.
[0364479/000] vrjDRAW: Num viewports: 1
[0364479/000] vrjDRAW: PfDrawManager::addDisplay() creating
simulator of type 'default_simulator'
[0364479/000] DBG: DeviceInterface found proxy: SimCamera
Proxy [ OK ]
[0364479/000] DBG: DeviceInterface found proxy: VJWand
[ OK ]
[0364479/000] vrjDRAW: PfBasicSimulator::configPerformerAPI:
Configuring Performer
[0364479/000] vrjDRAW: Head Model:
/software/apps/vrjuggler-2.0-beta3/build64/instlinks/share/vrjuggler/data/model
s/head.flt
Wand Model: /software/apps/vrjuggler-2.0-beta3/build64/instlinks/share/vrjuggle
r/data/models/wand.flt
[0364479/000] vrjDRAW: [vrj::PfBasicSimulator::initSimulatorGr
aph()] Loaded head model: /software/apps/vrjuggler-2.0-beta3/build64/instlinks/
share/vrjuggler/data/models/head.flt
[0364479/000] vrjDRAW: [vrj::PfBasicSImulator::initSimulatorGr
aph()] Loaded wand model: /software/apps/vrjuggler-2.0-beta3/build64/instlinks/
share/vrjuggler/data/models/wand.flt
JES PfDrawManager 1
JES PfDrawManager 2
JES PfDrawManager 3
JES PfDrawManager 4
JES PfDrawManager 5
JES PfDrawManager 6
JES PfDrawManager 7
JES PfDrawManager 8
JES PfDrawManager 9
X Error of failed request: BadWindow (invalid Window parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
Resource id in failed request: 0x0
Serial number of failed request: 12
Current serial number in output stream: 15
Joan Slottow
UCLA ATS
|
|
From: Doug M. <mc...@ia...> - 2005-08-22 15:20:40
|
> Hi, > Following up the previous message from us: > > > Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and > starting > it up with the command: > > #!/bin/csh > ./simplePf Bounding3.flt standalone.jconf |& tee jj > > Using your standalone.jconf and the debug version of vrJuggler > And having added the following of my own debug statements to > PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* disp= ) > > std::cerr << "JES PfDrawManager 2\n"; [snip] I can reproduce this as well. Unfortunately gdb is not being helpful on irix so I am unable to provide any more info. Is there a specific place that can be looked at to better pin point the problem? Also, I am unable to reproduce this issue on any other platform. Doug |
|
From: Patrick H. <pa...@in...> - 2005-08-22 15:37:06
Attachments:
signature.asc
|
Doug McCorkle wrote: >>Hi, >> Following up the previous message from us: >> >> >>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and >>starting >>it up with the command: >> >> #!/bin/csh >> ./simplePf Bounding3.flt standalone.jconf |& tee jj >> >>Using your standalone.jconf and the debug version of vrJuggler >>And having added the following of my own debug statements to >>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* disp) >> >>std::cerr << "JES PfDrawManager 2\n"; > > > [snip] > > I can reproduce this as well. Unfortunately gdb is not being helpful on > irix You have to use DBX or CVD on IRIX. The last I knew, GDB does not understand the debug data format produced by the MIPSpro Compilers. -Patrick > so I am unable to provide any more info. Is there a specific place > that can be looked at to better pin point the problem? Also, I am unable > to reproduce this issue on any other platform. > > Doug > > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > vrjuggler-info mailing list > vrj...@li... > https://lists.sourceforge.net/lists/listinfo/vrjuggler-info -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ |
|
From: Doug M. <mc...@ia...> - 2005-08-22 18:13:47
|
> Doug McCorkle wrote: >>>Hi, >>> Following up the previous message from us: >>> >>> >>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and >>>starting >>>it up with the command: >>> >>> #!/bin/csh >>> ./simplePf Bounding3.flt standalone.jconf |& tee jj >>> >>>Using your standalone.jconf and the debug version of vrJuggler >>>And having added the following of my own debug statements to >>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* dis= p) >>> >>>std::cerr << "JES PfDrawManager 2\n"; >> >> >> [snip] >> >> I can reproduce this as well. Unfortunately gdb is not being helpful o= n >> irix > > You have to use DBX or CVD on IRIX. The last I knew, GDB does not > understand > the debug data format produced by the MIPSpro Compilers. > Thanks Patrick. It appears that things are going south in openConnection in void PfInputHandler::openConnection(). I am still working with CVD to figure out which line exactly. Hopefully this provides some more usefull info to further debug the problem. > -Patrick > >> so I am unable to provide any more info. Is there a specific place >> that can be looked at to better pin point the problem? Also, I am unab= le >> to reproduce this issue on any other platform. >> >> Doug >> >> >> >> >> ------------------------------------------------------- >> SF.Net email is Sponsored by the Better Software Conference & EXPO >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle >> Practices >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing = & >> QA >> Security * Process Improvement & Measurement * >> http://www.sqe.com/bsce5sf >> _______________________________________________ >> vrjuggler-info mailing list >> vrj...@li... >> https://lists.sourceforge.net/lists/listinfo/vrjuggler-info > > > -- > Patrick L. Hartling | VP Engineering, Infiscape Corp= . > PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ > |
|
From: Doug M. <mc...@ia...> - 2005-08-22 18:30:30
|
>> Doug McCorkle wrote: >>>>Hi, >>>> Following up the previous message from us: >>>> >>>> >>>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and >>>>starting >>>>it up with the command: >>>> >>>> #!/bin/csh >>>> ./simplePf Bounding3.flt standalone.jconf |& tee jj >>>> >>>>Using your standalone.jconf and the debug version of vrJuggler >>>>And having added the following of my own debug statements to >>>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* >>>> disp) >>>> >>>>std::cerr << "JES PfDrawManager 2\n"; >>> >>> >>> [snip] >>> >>> I can reproduce this as well. Unfortunately gdb is not being helpful = on >>> irix >> >> You have to use DBX or CVD on IRIX. The last I knew, GDB does not >> understand >> the debug data format produced by the MIPSpro Compilers. >> > Thanks Patrick. It appears that things are going south in openConnectio= n > in void PfInputHandler::openConnection(). I am still working with CVD t= o > figure out which line exactly. Hopefully this provides some more useful= l > info to further debug the problem. > I show that my app crashes on XSync(mXDisplay,false); in openConnection. Any thoughts? Doug >> -Patrick >> >>> so I am unable to provide any more info. Is there a specific place >>> that can be looked at to better pin point the problem? Also, I am >>> unable >>> to reproduce this issue on any other platform. >>> >>> Doug >>> >>> >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is Sponsored by the Better Software Conference & EXPO >>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle >>> Practices >>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing= & >>> QA >>> Security * Process Improvement & Measurement * >>> http://www.sqe.com/bsce5sf >>> _______________________________________________ >>> vrjuggler-info mailing list >>> vrj...@li... >>> https://lists.sourceforge.net/lists/listinfo/vrjuggler-info >> >> >> -- >> Patrick L. Hartling | VP Engineering, Infiscape Cor= p. >> PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ >> > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &= QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5= sf > _______________________________________________ > vrjuggler-info mailing list > vrj...@li... > https://lists.sourceforge.net/lists/listinfo/vrjuggler-info > |
|
From: Doug M. <mc...@ia...> - 2005-08-22 19:17:26
|
>>> Doug McCorkle wrote:
>>>>>Hi,
>>>>> Following up the previous message from us:
>>>>>
>>>>>
>>>>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and
>>>>>starting
>>>>>it up with the command:
>>>>>
>>>>> #!/bin/csh
>>>>> ./simplePf Bounding3.flt standalone.jconf |& tee jj
>>>>>
>>>>>Using your standalone.jconf and the debug version of vrJuggler
>>>>>And having added the following of my own debug statements to
>>>>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display*
>>>>> disp)
>>>>>
>>>>>std::cerr << "JES PfDrawManager 2\n";
>>>>
>>>>
>>>> [snip]
>>>>
>>>> I can reproduce this as well. Unfortunately gdb is not being helpful
>>>> on
>>>> irix
>>>
>>> You have to use DBX or CVD on IRIX. The last I knew, GDB does not
>>> understand
>>> the debug data format produced by the MIPSpro Compilers.
>>>
>> Thanks Patrick. It appears that things are going south in openConnecti=
on
>> in void PfInputHandler::openConnection(). I am still working with CVD =
to
>> figure out which line exactly. Hopefully this provides some more usefu=
ll
>> info to further debug the problem.
>>
> I show that my app crashes on
>
> XSync(mXDisplay,false);
>
> in openConnection. Any thoughts?
>
This is what the man page on irix says:
DESCRIPTION
The XFlush function flushes the output buffer. Most client
applications need not use this function because the output
buffer is automatically flushed as needed by calls to
XPending, XNextEvent, and XWindowEvent. Events generated by
the server may be enqueued into the library's event queue.
The XSync function flushes the output buffer and then waits
until all requests have been received and processed by the X
server. Any errors generated must be handled by the error
handler. For each protocol error received by Xlib, XSync
calls the client application's error handling routine (see
section 11.8.2). Any events generated by the server are
enqueued into the library's event queue.
Finally, if you passed False, XSync does not discard the
events in the queue. If you passed True, XSync discards all
events in the queue, including those events that were on the
queue before XSync was called. Client applications seldom
need to call XSync.
Do we really need XSync?
> Doug
>>> -Patrick
>>>
>>>> so I am unable to provide any more info. Is there a specific place
>>>> that can be looked at to better pin point the problem? Also, I am
>>>> unable
>>>> to reproduce this issue on any other platform.
>>>>
>>>> Doug
>>>>
>>>>
>>>>
|
|
From: Patrick H. <pa...@in...> - 2005-08-22 20:56:50
Attachments:
signature.asc
|
Doug McCorkle wrote: >>>>Doug McCorkle wrote: >>>> >>>>>>Hi, >>>>>> Following up the previous message from us: >>>>>> >>>>>> >>>>>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and >>>>>>starting >>>>>>it up with the command: >>>>>> >>>>>> #!/bin/csh >>>>>> ./simplePf Bounding3.flt standalone.jconf |& tee jj >>>>>> >>>>>>Using your standalone.jconf and the debug version of vrJuggler >>>>>>And having added the following of my own debug statements to >>>>>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* >>>>>>disp) >>>>>> >>>>>>std::cerr << "JES PfDrawManager 2\n"; >>>>> >>>>> >>>>>[snip] >>>>> >>>>>I can reproduce this as well. Unfortunately gdb is not being helpful >>>>>on >>>>>irix >>>> >>>>You have to use DBX or CVD on IRIX. The last I knew, GDB does not >>>>understand >>>>the debug data format produced by the MIPSpro Compilers. >>>> >>> >>>Thanks Patrick. It appears that things are going south in openConnection >>>in void PfInputHandler::openConnection(). I am still working with CVD to >>>figure out which line exactly. Hopefully this provides some more usefull >>>info to further debug the problem. >>> >> >>I show that my app crashes on >> >>XSync(mXDisplay,false); >> >>in openConnection. Any thoughts? >> > > > This is what the man page on irix says: > > DESCRIPTION > The XFlush function flushes the output buffer. Most client > applications need not use this function because the output > buffer is automatically flushed as needed by calls to > XPending, XNextEvent, and XWindowEvent. Events generated by > the server may be enqueued into the library's event queue. > > The XSync function flushes the output buffer and then waits > until all requests have been received and processed by the X > server. Any errors generated must be handled by the error > handler. For each protocol error received by Xlib, XSync > calls the client application's error handling routine (see > section 11.8.2). Any events generated by the server are > enqueued into the library's event queue. > > Finally, if you passed False, XSync does not discard the > events in the queue. If you passed True, XSync discards all > events in the queue, including those events that were on the > queue before XSync was called. Client applications seldom > need to call XSync. > > > Do we really need XSync? What happens if you remove the call to it? -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ |
|
From: Doug M. <mc...@ia...> - 2005-08-22 21:14:33
|
Patrick Hartling wrote: > Doug McCorkle wrote: > >>>>>Doug McCorkle wrote: >>>>> >>>>> >>>>>>>Hi, >>>>>>> Following up the previous message from us: >>>>>>> >>>>>>> >>>>>>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and >>>>>>>starting >>>>>>>it up with the command: >>>>>>> >>>>>>> #!/bin/csh >>>>>>> ./simplePf Bounding3.flt standalone.jconf |& tee jj >>>>>>> >>>>>>>Using your standalone.jconf and the debug version of vrJuggler >>>>>>>And having added the following of my own debug statements to >>>>>>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* >>>>>>>disp) >>>>>>> >>>>>>>std::cerr << "JES PfDrawManager 2\n"; >>>>>> >>>>>> >>>>>>[snip] >>>>>> >>>>>>I can reproduce this as well. Unfortunately gdb is not being helpful >>>>>>on >>>>>>irix >>>>> >>>>>You have to use DBX or CVD on IRIX. The last I knew, GDB does not >>>>>understand >>>>>the debug data format produced by the MIPSpro Compilers. >>>>> >>>> >>>>Thanks Patrick. It appears that things are going south in openConnection >>>>in void PfInputHandler::openConnection(). I am still working with CVD to >>>>figure out which line exactly. Hopefully this provides some more usefull >>>>info to further debug the problem. >>>> >>> >>>I show that my app crashes on >>> >>>XSync(mXDisplay,false); >>> >>>in openConnection. Any thoughts? >>> >> >> >>This is what the man page on irix says: >> >> DESCRIPTION >> The XFlush function flushes the output buffer. Most client >> applications need not use this function because the output >> buffer is automatically flushed as needed by calls to >> XPending, XNextEvent, and XWindowEvent. Events generated by >> the server may be enqueued into the library's event queue. >> >> The XSync function flushes the output buffer and then waits >> until all requests have been received and processed by the X >> server. Any errors generated must be handled by the error >> handler. For each protocol error received by Xlib, XSync >> calls the client application's error handling routine (see >> section 11.8.2). Any events generated by the server are >> enqueued into the library's event queue. >> >> Finally, if you passed False, XSync does not discard the >> events in the queue. If you passed True, XSync discards all >> events in the queue, including those events that were on the >> queue before XSync was called. Client applications seldom >> need to call XSync. >> >> >>Do we really need XSync? > > > What happens if you remove the call to it? > I just finished testing that. On IRIX everything works in sim mode as well as in the C6 so it appears that it isn't needed. I am building right now on RHEL3 to see if that works as well. I was unable to find anything of significance on the web about why XSync would fail like that especially since all the calls above it have no problems with the display pointer being passed in. > -Patrick > > |
|
From: Doug M. <mc...@ia...> - 2005-08-22 21:20:06
|
> Patrick Hartling wrote: >> Doug McCorkle wrote: >> >>>>>>Doug McCorkle wrote: >>>>>> >>>>>> >>>>>>>>Hi, >>>>>>>> Following up the previous message from us: >>>>>>>> >>>>>>>> >>>>>>>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX an= d >>>>>>>>starting >>>>>>>>it up with the command: >>>>>>>> >>>>>>>> #!/bin/csh >>>>>>>> ./simplePf Bounding3.flt standalone.jconf |& tee jj >>>>>>>> >>>>>>>>Using your standalone.jconf and the debug version of vrJuggler >>>>>>>>And having added the following of my own debug statements to >>>>>>>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display= * >>>>>>>>disp) >>>>>>>> >>>>>>>>std::cerr << "JES PfDrawManager 2\n"; >>>>>>> >>>>>>> >>>>>>>[snip] >>>>>>> >>>>>>>I can reproduce this as well. Unfortunately gdb is not being helpf= ul >>>>>>>on >>>>>>>irix >>>>>> >>>>>>You have to use DBX or CVD on IRIX. The last I knew, GDB does not >>>>>>understand >>>>>>the debug data format produced by the MIPSpro Compilers. >>>>>> >>>>> >>>>>Thanks Patrick. It appears that things are going south in >>>>> openConnection >>>>>in void PfInputHandler::openConnection(). I am still working with CV= D >>>>> to >>>>>figure out which line exactly. Hopefully this provides some more >>>>> usefull >>>>>info to further debug the problem. >>>>> >>>> >>>>I show that my app crashes on >>>> >>>>XSync(mXDisplay,false); >>>> >>>>in openConnection. Any thoughts? >>>> >>> >>> >>>This is what the man page on irix says: >>> >>> DESCRIPTION >>> The XFlush function flushes the output buffer. Most client >>> applications need not use this function because the output >>> buffer is automatically flushed as needed by calls to >>> XPending, XNextEvent, and XWindowEvent. Events generated by >>> the server may be enqueued into the library's event queue. >>> >>> The XSync function flushes the output buffer and then waits >>> until all requests have been received and processed by the X >>> server. Any errors generated must be handled by the error >>> handler. For each protocol error received by Xlib, XSync >>> calls the client application's error handling routine (see >>> section 11.8.2). Any events generated by the server are >>> enqueued into the library's event queue. >>> >>> Finally, if you passed False, XSync does not discard the >>> events in the queue. If you passed True, XSync discards all >>> events in the queue, including those events that were on the >>> queue before XSync was called. Client applications seldom >>> need to call XSync. >>> >>> >>>Do we really need XSync? >> >> >> What happens if you remove the call to it? >> > I just finished testing that. On IRIX everything works in sim mode as > well as in the C6 so it appears that it isn't needed. I am building > right now on RHEL3 to see if that works as well. > > I was unable to find anything of significance on the web about why XSyn= c > would fail like that especially since all the calls above it have no > problems with the display pointer being passed in. > I should say that I tested to make sure that the app comes up and that everything looked ok. I didn't tested to see if any of the new input into display windows worked or if the mouse hiding code worked. >> -Patrick >> |
|
From: Patrick H. <pa...@in...> - 2005-08-22 21:42:45
Attachments:
signature.asc
|
Doug McCorkle wrote: >>Patrick Hartling wrote: >> >>>Doug McCorkle wrote: >>> >>> >>>>>>>Doug McCorkle wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>Hi, >>>>>>>>>Following up the previous message from us: >>>>>>>>> >>>>>>>>> >>>>>>>>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and >>>>>>>>>starting >>>>>>>>>it up with the command: >>>>>>>>> >>>>>>>>>#!/bin/csh >>>>>>>>>./simplePf Bounding3.flt standalone.jconf |& tee jj >>>>>>>>> >>>>>>>>>Using your standalone.jconf and the debug version of vrJuggler >>>>>>>>>And having added the following of my own debug statements to >>>>>>>>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* >>>>>>>>>disp) >>>>>>>>> >>>>>>>>>std::cerr << "JES PfDrawManager 2\n"; >>>>>>>> >>>>>>>> >>>>>>>>[snip] >>>>>>>> >>>>>>>>I can reproduce this as well. Unfortunately gdb is not being helpful >>>>>>>>on >>>>>>>>irix >>>>>>> >>>>>>>You have to use DBX or CVD on IRIX. The last I knew, GDB does not >>>>>>>understand >>>>>>>the debug data format produced by the MIPSpro Compilers. >>>>>>> >>>>>> >>>>>>Thanks Patrick. It appears that things are going south in >>>>>>openConnection >>>>>>in void PfInputHandler::openConnection(). I am still working with CVD >>>>>>to >>>>>>figure out which line exactly. Hopefully this provides some more >>>>>>usefull >>>>>>info to further debug the problem. >>>>>> >>>>> >>>>>I show that my app crashes on >>>>> >>>>>XSync(mXDisplay,false); >>>>> >>>>>in openConnection. Any thoughts? >>>>> >>>> >>>> >>>>This is what the man page on irix says: >>>> >>>> DESCRIPTION >>>> The XFlush function flushes the output buffer. Most client >>>> applications need not use this function because the output >>>> buffer is automatically flushed as needed by calls to >>>> XPending, XNextEvent, and XWindowEvent. Events generated by >>>> the server may be enqueued into the library's event queue. >>>> >>>> The XSync function flushes the output buffer and then waits >>>> until all requests have been received and processed by the X >>>> server. Any errors generated must be handled by the error >>>> handler. For each protocol error received by Xlib, XSync >>>> calls the client application's error handling routine (see >>>> section 11.8.2). Any events generated by the server are >>>> enqueued into the library's event queue. >>>> >>>> Finally, if you passed False, XSync does not discard the >>>> events in the queue. If you passed True, XSync discards all >>>> events in the queue, including those events that were on the >>>> queue before XSync was called. Client applications seldom >>>> need to call XSync. >>>> >>>> >>>>Do we really need XSync? >>> >>> >>>What happens if you remove the call to it? >>> >> >>I just finished testing that. On IRIX everything works in sim mode as >>well as in the C6 so it appears that it isn't needed. I am building >>right now on RHEL3 to see if that works as well. I have tested on Fedora Core 4 and seen no problems. >>I was unable to find anything of significance on the web about why XSync >>would fail like that especially since all the calls above it have no >>problems with the display pointer being passed in. >> > > I should say that I tested to make sure that the app comes up and that > everything looked ok. I didn't tested to see if any of the new input into > display windows worked or if the mouse hiding code worked. Well, those are pretty important things to test. Now that the windows are actually opening, we need to be sure that the keyboard/mouse input feature works on IRIX. That is, after all, the point. :) -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ |
|
From: Doug M. <mc...@ia...> - 2005-08-22 21:57:32
|
Patrick Hartling wrote: > Doug McCorkle wrote: > >>>Patrick Hartling wrote: >>> >>> >>>>Doug McCorkle wrote: >>>> >>>> >>>> >>>>>>>>Doug McCorkle wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>Hi, >>>>>>>>>>Following up the previous message from us: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and >>>>>>>>>>starting >>>>>>>>>>it up with the command: >>>>>>>>>> >>>>>>>>>>#!/bin/csh >>>>>>>>>>./simplePf Bounding3.flt standalone.jconf |& tee jj >>>>>>>>>> >>>>>>>>>>Using your standalone.jconf and the debug version of vrJuggler >>>>>>>>>>And having added the following of my own debug statements to >>>>>>>>>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* >>>>>>>>>>disp) >>>>>>>>>> >>>>>>>>>>std::cerr << "JES PfDrawManager 2\n"; >>>>>>>>> >>>>>>>>> >>>>>>>>>[snip] >>>>>>>>> >>>>>>>>>I can reproduce this as well. Unfortunately gdb is not being helpful >>>>>>>>>on >>>>>>>>>irix >>>>>>>> >>>>>>>>You have to use DBX or CVD on IRIX. The last I knew, GDB does not >>>>>>>>understand >>>>>>>>the debug data format produced by the MIPSpro Compilers. >>>>>>>> >>>>>>> >>>>>>>Thanks Patrick. It appears that things are going south in >>>>>>>openConnection >>>>>>>in void PfInputHandler::openConnection(). I am still working with CVD >>>>>>>to >>>>>>>figure out which line exactly. Hopefully this provides some more >>>>>>>usefull >>>>>>>info to further debug the problem. >>>>>>> >>>>>> >>>>>>I show that my app crashes on >>>>>> >>>>>>XSync(mXDisplay,false); >>>>>> >>>>>>in openConnection. Any thoughts? >>>>>> >>>>> >>>>> >>>>>This is what the man page on irix says: >>>>> >>>>> DESCRIPTION >>>>> The XFlush function flushes the output buffer. Most client >>>>> applications need not use this function because the output >>>>> buffer is automatically flushed as needed by calls to >>>>> XPending, XNextEvent, and XWindowEvent. Events generated by >>>>> the server may be enqueued into the library's event queue. >>>>> >>>>> The XSync function flushes the output buffer and then waits >>>>> until all requests have been received and processed by the X >>>>> server. Any errors generated must be handled by the error >>>>> handler. For each protocol error received by Xlib, XSync >>>>> calls the client application's error handling routine (see >>>>> section 11.8.2). Any events generated by the server are >>>>> enqueued into the library's event queue. >>>>> >>>>> Finally, if you passed False, XSync does not discard the >>>>> events in the queue. If you passed True, XSync discards all >>>>> events in the queue, including those events that were on the >>>>> queue before XSync was called. Client applications seldom >>>>> need to call XSync. >>>>> >>>>> >>>>>Do we really need XSync? >>>> >>>> >>>>What happens if you remove the call to it? >>>> >>> >>>I just finished testing that. On IRIX everything works in sim mode as >>>well as in the C6 so it appears that it isn't needed. I am building >>>right now on RHEL3 to see if that works as well. > > > I have tested on Fedora Core 4 and seen no problems. > > >>>I was unable to find anything of significance on the web about why XSync >>>would fail like that especially since all the calls above it have no >>>problems with the display pointer being passed in. >>> >> >>I should say that I tested to make sure that the app comes up and that >>everything looked ok. I didn't tested to see if any of the new input into >>display windows worked or if the mouse hiding code worked. > > > Well, those are pretty important things to test. Now that the windows are > actually opening, we need to be sure that the keyboard/mouse input feature > works on IRIX. That is, after all, the point. :) > > -Patrick RHEL3 works just fine with display window input and mouse hiding. IRIX does not appear to be working but I am not sure if that functionality has worked on anyway. I have never tested that functionality on IRIX so I can't say if this new change is causing problems or not. Doug |
|
From: Doug M. <mc...@ia...> - 2005-08-22 21:58:48
|
Patrick Hartling wrote: > Doug McCorkle wrote: > >>>Patrick Hartling wrote: >>> >>> >>>>Doug McCorkle wrote: >>>> >>>> >>>> >>>>>>>>Doug McCorkle wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>>Hi, >>>>>>>>>>Following up the previous message from us: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Running your simplePf program with vrJuggler-2.0-beta3 on IRIX and >>>>>>>>>>starting >>>>>>>>>>it up with the command: >>>>>>>>>> >>>>>>>>>>#!/bin/csh >>>>>>>>>>./simplePf Bounding3.flt standalone.jconf |& tee jj >>>>>>>>>> >>>>>>>>>>Using your standalone.jconf and the debug version of vrJuggler >>>>>>>>>>And having added the following of my own debug statements to >>>>>>>>>>PfDrawManager.cpp function void PfDrawManager::addDisplay(Display* >>>>>>>>>>disp) >>>>>>>>>> >>>>>>>>>>std::cerr << "JES PfDrawManager 2\n"; >>>>>>>>> >>>>>>>>> >>>>>>>>>[snip] >>>>>>>>> >>>>>>>>>I can reproduce this as well. Unfortunately gdb is not being helpful >>>>>>>>>on >>>>>>>>>irix >>>>>>>> >>>>>>>>You have to use DBX or CVD on IRIX. The last I knew, GDB does not >>>>>>>>understand >>>>>>>>the debug data format produced by the MIPSpro Compilers. >>>>>>>> >>>>>>> >>>>>>>Thanks Patrick. It appears that things are going south in >>>>>>>openConnection >>>>>>>in void PfInputHandler::openConnection(). I am still working with CVD >>>>>>>to >>>>>>>figure out which line exactly. Hopefully this provides some more >>>>>>>usefull >>>>>>>info to further debug the problem. >>>>>>> >>>>>> >>>>>>I show that my app crashes on >>>>>> >>>>>>XSync(mXDisplay,false); >>>>>> >>>>>>in openConnection. Any thoughts? >>>>>> >>>>> >>>>> >>>>>This is what the man page on irix says: >>>>> >>>>> DESCRIPTION >>>>> The XFlush function flushes the output buffer. Most client >>>>> applications need not use this function because the output >>>>> buffer is automatically flushed as needed by calls to >>>>> XPending, XNextEvent, and XWindowEvent. Events generated by >>>>> the server may be enqueued into the library's event queue. >>>>> >>>>> The XSync function flushes the output buffer and then waits >>>>> until all requests have been received and processed by the X >>>>> server. Any errors generated must be handled by the error >>>>> handler. For each protocol error received by Xlib, XSync >>>>> calls the client application's error handling routine (see >>>>> section 11.8.2). Any events generated by the server are >>>>> enqueued into the library's event queue. >>>>> >>>>> Finally, if you passed False, XSync does not discard the >>>>> events in the queue. If you passed True, XSync discards all >>>>> events in the queue, including those events that were on the >>>>> queue before XSync was called. Client applications seldom >>>>> need to call XSync. >>>>> >>>>> >>>>>Do we really need XSync? >>>> >>>> >>>>What happens if you remove the call to it? >>>> >>> >>>I just finished testing that. On IRIX everything works in sim mode as >>>well as in the C6 so it appears that it isn't needed. I am building >>>right now on RHEL3 to see if that works as well. > > > I have tested on Fedora Core 4 and seen no problems. > > >>>I was unable to find anything of significance on the web about why XSync >>>would fail like that especially since all the calls above it have no >>>problems with the display pointer being passed in. >>> >> >>I should say that I tested to make sure that the app comes up and that >>everything looked ok. I didn't tested to see if any of the new input into >>display windows worked or if the mouse hiding code worked. > > > Well, those are pretty important things to test. Now that the windows are > actually opening, we need to be sure that the keyboard/mouse input feature > works on IRIX. That is, after all, the point. :) > > -Patrick Keyboard and mouse input work on IRIX just not in display/sim windows. Doug |
|
From: Patrick H. <pa...@in...> - 2005-08-23 03:54:31
Attachments:
signature.asc
|
Doug McCorkle wrote: > Patrick Hartling wrote: > >> Doug McCorkle wrote: >> >>>> Patrick Hartling wrote: >>>> >>>>> Doug McCorkle wrote: [snip] >>>>>> Do we really need XSync? >>>>> >>>>> What happens if you remove the call to it? >>>> >>>> I just finished testing that. On IRIX everything works in sim mode as >>>> well as in the C6 so it appears that it isn't needed. I am building >>>> right now on RHEL3 to see if that works as well. >> >> I have tested on Fedora Core 4 and seen no problems. >> >>>> I was unable to find anything of significance on the web about why >>>> XSync >>>> would fail like that especially since all the calls above it have no >>>> problems with the display pointer being passed in. >>> >>> I should say that I tested to make sure that the app comes up and that >>> everything looked ok. I didn't tested to see if any of the new input >>> into >>> display windows worked or if the mouse hiding code worked. >> >> Well, those are pretty important things to test. Now that the windows are >> actually opening, we need to be sure that the keyboard/mouse input >> feature >> works on IRIX. That is, after all, the point. :) >> >> -Patrick > > > Keyboard and mouse input work on IRIX just not in display/sim windows. Getting keyboard/mouse input working with Performer sure seems to be a difficult balancing act. :( At least with the XSync() call removed it is possible to test Performer on IRIX and get keyboard/mouse input working in Performer windows. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ |
|
From: Doug M. <mc...@ia...> - 2005-08-23 11:30:58
|
On Aug 22, 2005, at 10:54 PM, Patrick Hartling wrote: > Doug McCorkle wrote: > >> Patrick Hartling wrote: >> >> >>> Doug McCorkle wrote: >>> >>> >>>>> Patrick Hartling wrote: >>>>> >>>>> >>>>>> Doug McCorkle wrote: >>>>>> > > [snip] > > >>>>>>> Do we really need XSync? >>>>>>> >>>>>> >>>>>> What happens if you remove the call to it? >>>>>> >>>>> >>>>> I just finished testing that. On IRIX everything works in sim >>>>> mode as >>>>> well as in the C6 so it appears that it isn't needed. I am >>>>> building >>>>> right now on RHEL3 to see if that works as well. >>>>> >>> >>> I have tested on Fedora Core 4 and seen no problems. >>> >>> >>>>> I was unable to find anything of significance on the web about why >>>>> XSync >>>>> would fail like that especially since all the calls above it >>>>> have no >>>>> problems with the display pointer being passed in. >>>>> >>>> >>>> I should say that I tested to make sure that the app comes up >>>> and that >>>> everything looked ok. I didn't tested to see if any of the new >>>> input >>>> into >>>> display windows worked or if the mouse hiding code worked. >>>> >>> >>> Well, those are pretty important things to test. Now that the >>> windows are >>> actually opening, we need to be sure that the keyboard/mouse input >>> feature >>> works on IRIX. That is, after all, the point. :) >>> >>> -Patrick >>> >> >> >> Keyboard and mouse input work on IRIX just not in display/sim >> windows. >> > > Getting keyboard/mouse input working with Performer sure seems to be a > difficult balancing act. :( At least with the XSync() call removed > it is > possible to test Performer on IRIX and get keyboard/mouse input > working in > Performer windows. > What does this mean for the 2.0.1 release? I realize that this doesn't fix your problems but out off all the platforms that we do use the display windows for input and hiding the mouse pointer IRIX is not one off them. For us not having that working on IRIX is not that big of a deal but I don't know if anyone else is planning on that functionality. Also, do you all have some example code of how to get mouse/keyboard input from display windows or is that all put together from man pages? > -Patrick > > > -- > Patrick L. Hartling | VP Engineering, Infiscape > Corp. > PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ > |
|
From: Patrick H. <pa...@in...> - 2005-08-23 14:09:09
Attachments:
signature.asc
|
Doug McCorkle wrote: > > On Aug 22, 2005, at 10:54 PM, Patrick Hartling wrote: > >> Doug McCorkle wrote: >> >>> Patrick Hartling wrote: >>> >>> >>>> Doug McCorkle wrote: >>>> >>>> >>>>>> Patrick Hartling wrote: [snip] >>>> Well, those are pretty important things to test. Now that the >>>> windows are >>>> actually opening, we need to be sure that the keyboard/mouse input >>>> feature >>>> works on IRIX. That is, after all, the point. :) >>>> >>>> -Patrick >>>> >>> >>> >>> Keyboard and mouse input work on IRIX just not in display/sim windows. >>> >> >> Getting keyboard/mouse input working with Performer sure seems to be a >> difficult balancing act. :( At least with the XSync() call removed it is >> possible to test Performer on IRIX and get keyboard/mouse input >> working in >> Performer windows. >> > What does this mean for the 2.0.1 release? I realize that this doesn't > fix your problems but out off all the platforms that we do use the > display windows for input and hiding the mouse pointer IRIX is not one > off them. For us not having that working on IRIX is not that big of a > deal but I don't know if anyone else is planning on that functionality. I am inclined to hold off on the 2.0.1 release until Performer keyboard/mouse input is working on IRIX. That said, I did make a comment several days ago saying that I felt that the InterSense driver bug fixes are more important than the Performer+IRIX issues. I do still feel that way, but after all the work Aron and Dan did to get it working on Windows and Linux, I should think that there is probably just some minor bug that prevents the use of this feature on IRIX. Of course, I know nothing about how keyboard/mouse input works with Performer graphics windows, so my assumption could not be more naive. The biggest problem, IMHO, is that this did not get resolved before classes resumed at Iowa State. Frankly, it should have been fixed back in April, but that is neither here nor there. I am concerned that the ISU people now have even less time to devote to tracking down what is going wrong with keyboard/mouse input in Performer graphics windows on IRIX. It is, in many ways, a corner case for a platform that appears to be seeing less and less use. Volunteering time to do work for corner cases that are not widely used anyway is not exactly easy. For that reason, how about a compromise? If someone actually takes the time to try to fix the IRIX+Performer keyboard/mouse input problems and cannot solve it by August 29, then we will release 2.0.1 without that feature. However, if no one can commit even a little bit of time to solving this problem once and for all, then I am inclined to think that we will need to re-evaluate just exactly what roles people are going to be playing in the development of VR Juggler. This is the kind of thing that members of the development team and the community can be helping with--especially those people to whom this capability really matters. If I had the time, the resources, and the knowledge to fix this, I would certainly do so if for no other reason than to put all of this to rest. I am, however, not in any position to be able to fix this, and neither is anyone else at Infiscape. > Also, do you all have some example code of how to get mouse/keyboard > input from display windows or is that all put together from man pages? Whether the keyboard/mouse input comes from display windows does not make a difference; the input is the same. So, if your question is about how to get the input and use it, see the following: http://www.vrjuggler.org/vrjuggler/2.0/programmer.guide/programmer.guide/ch03s03.html#d0e2931 Scroll down to "Using gadget::KeyboardMouseInterface." If your question is about how to configure display windows to be input sources, then see this page instead: http://www.infiscape.com/~patrick/vrjuggler-config/2.0/configuring_vr_juggler/ch03s05.html -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ |
|
From: Doug M. <mc...@ia...> - 2005-08-23 16:08:23
|
> Doug McCorkle wrote: >> >> On Aug 22, 2005, at 10:54 PM, Patrick Hartling wrote: >> >>> Doug McCorkle wrote: >>> >>>> Patrick Hartling wrote: >>>> >>>> >>>>> Doug McCorkle wrote: >>>>> >>>>> >>>>>>> Patrick Hartling wrote: > > [snip] > >>>>> Well, those are pretty important things to test. Now that the >>>>> windows are >>>>> actually opening, we need to be sure that the keyboard/mouse input >>>>> feature >>>>> works on IRIX. That is, after all, the point. :) >>>>> >>>>> -Patrick >>>>> >>>> >>>> >>>> Keyboard and mouse input work on IRIX just not in display/sim >>>> windows. >>>> >>> >>> Getting keyboard/mouse input working with Performer sure seems to be = a >>> difficult balancing act. :( At least with the XSync() call removed i= t >>> is >>> possible to test Performer on IRIX and get keyboard/mouse input >>> working in >>> Performer windows. >>> >> What does this mean for the 2.0.1 release? I realize that this doesn'= t >> fix your problems but out off all the platforms that we do use the >> display windows for input and hiding the mouse pointer IRIX is not on= e >> off them. For us not having that working on IRIX is not that big of a >> deal but I don't know if anyone else is planning on that functionalit= y. > > I am inclined to hold off on the 2.0.1 release until Performer > keyboard/mouse input is working on IRIX. That said, I did make a commen= t > several days ago saying that I felt that the InterSense driver bug fixe= s > are > more important than the Performer+IRIX issues. I do still feel that way= , > but > after all the work Aron and Dan did to get it working on Windows and > Linux, > I should think that there is probably just some minor bug that prevents > the > use of this feature on IRIX. Of course, I know nothing about how > keyboard/mouse input works with Performer graphics windows, so my > assumption > could not be more naive. > > The biggest problem, IMHO, is that this did not get resolved before > classes > resumed at Iowa State. Frankly, it should have been fixed back in April= , > but > that is neither here nor there. I am concerned that the ISU people now > have > even less time to devote to tracking down what is going wrong with > keyboard/mouse input in Performer graphics windows on IRIX. It is, in m= any > ways, a corner case for a platform that appears to be seeing less and l= ess > use. Volunteering time to do work for corner cases that are not widely > used > anyway is not exactly easy. > > For that reason, how about a compromise? If someone actually takes the > time > to try to fix the IRIX+Performer keyboard/mouse input problems and cann= ot > solve it by August 29, then we will release 2.0.1 without that feature. > However, if no one can commit even a little bit of time to solving this > problem once and for all, then I am inclined to think that we will need= to > re-evaluate just exactly what roles people are going to be playing in t= he > development of VR Juggler. This is the kind of thing that members of th= e > development team and the community can be helping with--especially thos= e > people to whom this capability really matters. If I had the time, the > resources, and the knowledge to fix this, I would certainly do so if fo= r > no > other reason than to put all of this to rest. I am, however, not in any > position to be able to fix this, and neither is anyone else at Infiscap= e. > That sounds fair to me. Dan has offered to help me with the problem since I have everything built up on IRIX. Hopefully there will be a fix shortly= . >> Also, do you all have some example code of how to get mouse/keyboard >> input from display windows or is that all put together from man pages? > > Whether the keyboard/mouse input comes from display windows does not ma= ke > a > difference; the input is the same. So, if your question is about how to > get > the input and use it, see the following: > > http://www.vrjuggler.org/vrjuggler/2.0/programmer.guide/programmer.guid= e/ch03s03.html#d0e2931 > > Scroll down to "Using gadget::KeyboardMouseInterface." If your question= is > about how to configure display windows to be input sources, then see th= is > page instead: > > http://www.infiscape.com/~patrick/vrjuggler-config/2.0/configuring_vr_j= uggler/ch03s05.html > I am more concerned about the stuff that Dan will help me with later toda= y. > -Patrick > > > -- > Patrick L. Hartling | VP Engineering, Infiscape Corp= . > PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ > |
|
From: Daniel E. S. <dsh...@ia...> - 2005-08-26 19:41:46
|
Doug and I have solved this problem and it is committed to the main branch....As soon as some people test it out besides us we can merge it into the 2.0 release and get 2.0.1 released :) -dan Doug McCorkle wrote: >>Doug McCorkle wrote: >> >> >>>On Aug 22, 2005, at 10:54 PM, Patrick Hartling wrote: >>> >>> >>> >>>>Doug McCorkle wrote: >>>> >>>> >>>> >>>>>Patrick Hartling wrote: >>>>> >>>>> >>>>> >>>>> >>>>>>Doug McCorkle wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>Patrick Hartling wrote: >>>>>>>> >>>>>>>> >>[snip] >> >> >> >>>>>>Well, those are pretty important things to test. Now that the >>>>>>windows are >>>>>>actually opening, we need to be sure that the keyboard/mouse input >>>>>>feature >>>>>>works on IRIX. That is, after all, the point. :) >>>>>> >>>>>> -Patrick >>>>>> >>>>>> >>>>>> >>>>>Keyboard and mouse input work on IRIX just not in display/sim >>>>>windows. >>>>> >>>>> >>>>> >>>>Getting keyboard/mouse input working with Performer sure seems to be a >>>>difficult balancing act. :( At least with the XSync() call removed it >>>>is >>>>possible to test Performer on IRIX and get keyboard/mouse input >>>>working in >>>>Performer windows. >>>> >>>> >>>> >>>What does this mean for the 2.0.1 release? I realize that this doesn't >>>fix your problems but out off all the platforms that we do use the >>>display windows for input and hiding the mouse pointer IRIX is not one >>>off them. For us not having that working on IRIX is not that big of a >>>deal but I don't know if anyone else is planning on that functionality. >>> >>> >>I am inclined to hold off on the 2.0.1 release until Performer >>keyboard/mouse input is working on IRIX. That said, I did make a comment >>several days ago saying that I felt that the InterSense driver bug fixes >>are >>more important than the Performer+IRIX issues. I do still feel that way, >>but >>after all the work Aron and Dan did to get it working on Windows and >>Linux, >>I should think that there is probably just some minor bug that prevents >>the >>use of this feature on IRIX. Of course, I know nothing about how >>keyboard/mouse input works with Performer graphics windows, so my >>assumption >>could not be more naive. >> >>The biggest problem, IMHO, is that this did not get resolved before >>classes >>resumed at Iowa State. Frankly, it should have been fixed back in April, >>but >>that is neither here nor there. I am concerned that the ISU people now >>have >>even less time to devote to tracking down what is going wrong with >>keyboard/mouse input in Performer graphics windows on IRIX. It is, in many >>ways, a corner case for a platform that appears to be seeing less and less >>use. Volunteering time to do work for corner cases that are not widely >>used >>anyway is not exactly easy. >> >>For that reason, how about a compromise? If someone actually takes the >>time >>to try to fix the IRIX+Performer keyboard/mouse input problems and cannot >>solve it by August 29, then we will release 2.0.1 without that feature. >>However, if no one can commit even a little bit of time to solving this >>problem once and for all, then I am inclined to think that we will need to >>re-evaluate just exactly what roles people are going to be playing in the >>development of VR Juggler. This is the kind of thing that members of the >>development team and the community can be helping with--especially those >>people to whom this capability really matters. If I had the time, the >>resources, and the knowledge to fix this, I would certainly do so if for >>no >>other reason than to put all of this to rest. I am, however, not in any >>position to be able to fix this, and neither is anyone else at Infiscape. >> >> >> >That sounds fair to me. Dan has offered to help me with the problem since >I have everything built up on IRIX. Hopefully there will be a fix shortly. > > > > >>>Also, do you all have some example code of how to get mouse/keyboard >>>input from display windows or is that all put together from man pages? >>> >>> >>Whether the keyboard/mouse input comes from display windows does not make >>a >>difference; the input is the same. So, if your question is about how to >>get >>the input and use it, see the following: >> >>http://www.vrjuggler.org/vrjuggler/2.0/programmer.guide/programmer.guide/ch03s03.html#d0e2931 >> >>Scroll down to "Using gadget::KeyboardMouseInterface." If your question is >>about how to configure display windows to be input sources, then see this >>page instead: >> >>http://www.infiscape.com/~patrick/vrjuggler-config/2.0/configuring_vr_juggler/ch03s05.html >> >> >> >I am more concerned about the stuff that Dan will help me with later today. > > > >> -Patrick >> >> >>-- >>Patrick L. Hartling | VP Engineering, Infiscape Corp. >>PGP: http://tinyurl.com/2msw3 | http://www.infiscape.com/ >> >> >> > > > >------------------------------------------------------- >SF.Net email is Sponsored by the Better Software Conference & EXPO >September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >_______________________________________________ >vrjuggler-info mailing list >vrj...@li... >https://lists.sourceforge.net/lists/listinfo/vrjuggler-info > > > |
Thanks for helping keep SourceForge clean.
X