Yet Another IT-related Blog

Videoconferences have proven to be a pain to me. Some years ago I used netmeeting, which worked fine almost 50% of the times I needed. Afterwards, I made some changes to my network and there was no way of making it work… Besides I’m a Linux user in my workstation, so it was time to change but neither gnomemeeting nor Ekiga gave me good impressions.

Probably Ekiga is nowadays a pretty good videoconference client, but I didn’t manage to configure both my webcam and microphone quite well. And even more difficult was to ask my friends and relatives to install it. So I couldn’t dedicate enough time to enjoy it.

So I remembered I’m also a MacOS X user and many people around me were using Skype… Yes there is also a Linux version but it doesn’t support videoconference. So it was time to give it a chance. The problem was that Apple doesn’t allow third-party manufacturers to add support for OS X in their cameras (generally)… You know, it’s all about hardware control and minimum quality requirements. And I wasn’t going to spend more than 25€.

But there is this project: macam, which is a collection of drivers for hundreds of webcams to work in OS X. There is a compatibility list, so it seems to be an easy task to choose the right one. Well, not that easy. Some webcams have different revisions and the product id is not printed on the box so…

After some time looking in the store I decided myself for the Creative Webcam Vista rev. A, since it was on the compatibility list, but it didn’t work! The problem was that the rev. A printed in the box was the one listed in the list as Webcam Vista (D)… Ovislink 519 chip, which seems to be supported for some cams but simply not that one.

This guys at Creative have a passion for making hundreds of revisions of the same products… There is no way of identifying exactly the model without opening the box so I searched for another brand. There were almost 20 webcams in the store and finally the Hercules Classic webcam was in the list, no revisions, only one version… And the same chip!!! The OV519, but this time it works.

So this time, being an OS X user hasn’t saved me from the hardware incompatibilities which we Linux users have to suffer. Lucky me it has saved me from the software incompatibilities

These days I’ve been doing some upgrading/tuning tasks in my workstation that I had previously postponed because of exams and other projects. One of them being the upgrade of vmware player, which felt more responsive and finally features usb 2.0 support. I really like this virtualization software and the freely available player version joint to the ability of QEMU for creating vmware images allows me to test new OS versions, multiplatform software, etc. Since I cannot afford the workstation version.

The installation was really straightforward, I downloaded the 64-bit version from its website and executed the vmware-install.pl script. It overwrote my previous version and asked only for installation directories, which by default matched the ones of my previous install in /opt. The difficult part in vmware installations usually comes now with the vmware-config.pl script, specially when it comes to the compilation of the kernel modules, but this time everything worked fine! Default options were right, it detected my kernel source libraries and compiled against them.

The previous time I had to install vmware-player there was no way of doing it without patching both configurator and kernel, I’m sure some of you have heard about the vmware-any-any patches So everything felt quite good, I just ran vmware as always, accept the license agreement and…

saburo virtual # /opt/vmware/player/bin/vmplayer
/opt/vmware/player/lib/vmware/bin/vmplayer: symbol lookup error: /opt/vmware/player/lib/vmware/lib/libvmwareui.so.0/libvmwareui.so.0: undefined symbol: _ZN3Gtk13RecentManager11get_defaultEv

Symbol lookup error… cool, time to google a bit. Lucky me, having waited for some time to upgrade let time for others to go around this problem and there are already fixes posted in vmware forums. It’s got something to do with GTK libraries for the user interface and the fix is as easy as adding the following line before the exec command in the /opt/vmware/bin/vmware script:

export VMWARE_USE_SHIPPED_GTK=yes

And that’s all…