Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Jim Chiang connected via his Macbook running Lion which seemed to work, only issue was having to update the audio so that the microphone was not muted (this was an issue for all the Mac users present).  Meanwhile on RHEL5-64 SeeVogh window came up but complains about not loading the video module. Jim was unable to hear or speak or select audio devices. His SeeVogh log is available here .  During our first attempt for one of our software meetings , Jim was able to connect via his Fedora 12 box just fine.

Panel
bgColoryellow
titleResponse
borderStylesolid

Regarding this issue with RHEL5 64 bit machine which log you attached. This is not related to graphics card. This graphics card is pretty good and support opengl 3.0+. The problem with this machine is that it is missing SDL package. Perhaps it is because it uses 32 bit java virtual machine. Please ask this person to check and install both 32 and 64 bit version of SDL package. Usually you can check the availability with
yum list SDL
and install all both 32 bit (i586 or i686 prefix) and 64 bit (x86_64 if it was not already installed).

After that you should be able to run SeeVogh on this machine.

We are using SDL for Timer, but right now we are working on it and next release will not have this dependency.

Tom Stephens connected via his ScientificLinux6-64 laptop and Windows 7-32 netbook.  When trying to use DesktopShare on SL6, it did not work at all and his SeeVogh client locked up when trying to turn off DesktopShare. When turning it on, nothing happened, no frame appeared and no desktop images appeared on other clients.  When turning off DesktopShare the UI became unresponsive and quit updating.  He could continue to hear, but was unable to interact with the client to make any adjustments including killing the window.  He went to the process table to kill the client manually.  Initially he tried to kill javaws SeeVogh, but that just respawned itself, so Tom killed another process instead.  The experience on Windows7 seems to have been without incident.

...