• Blacklisting a device in HAL

    I have an old Aiptek mini PenCam 1.3 MPixels, identified by USB vendor 1276 and product 20554. I want to use this webcam for videoconferencing in the machine I am setting up for this purpose. This machine carries a Fedora 9 x86_64 installation, as already mentioned in the previous post.Whenever I connect the camera to the machine, HAL detects the new device and then GNOME attempts to "mount" it using gphoto2. The result is that I get a new device on the desktop referring to the camera, which is pretty nice, but it does not work at all: accessing it raises an unexpected error and thus the photos stored in the webcam cannot be seen.Anyway, I do not care about the photo capabilities of this camera, just about its ability to stream video. Hence, I installed the gspca and kmod-gspca packages from the livna repositories and, according to the gspca driver, my camera is, supposedly, fully supported.Unfortunately, I was not able to get the /dev/video device: it didn't exist, even with the kernel modules loaded. After some manual investigation on the console (so that gphoto2 couldn't get in the way), I found that the video device really appears but vanishes as soon as gphoto2 attempts to access the camera. I suspect it is not possible to use the photo and video capabilities of the camera at once with the current drivers.So, how to avoid this problem? I had to tell HAL to omit this device, so that GNOME did not get any notification of its existance and therefore the interface did not attempt to mount the camera using gphoto2. However, there is few documentation on how to do this, so I had to resort to reading the files in /usr/share/hal/fdi/ and guess what to do.I ended up creating a 10-broken-cameras.fdi file in /etc/hal/fdi/preprobe/ with the following contents:<?xml version="1.0" encoding="UTF-8"?><deviceinfo version="0.2"> <device> <match key="usb.vendor_id" int="1276"> <match key="usb.product_id" int="20554"> <merge key="info.ignore" type="bool">true</merge> </match> </match> </device></deviceinfo>What this code snippet does is match the camera device using some of the properties that are attached to it and, once there is a match, appends the info.ignore property to the device description to tell HAL to not use this device any more. In order to set up the matching of a device, you can see the full list of properties of all device descriptors using the hal-device command. [Continue reading]

  • Desktop effects with an nVidia card and Fedora 9

    I'm setting up a machine at home to act as a videoconferencing station so that my family can easily talk to me during the summer, while I'm in NYC. This machine is equipped with an Athlon 64-bit processor and a nVidia GeForce 6200 PCI-Express video card. I decided to install Fedora 9 in this computer because this is the distribution I'm currently using everywhere (well, everywhere except on the Mac ;-). Plus it just works (TM), or mostly.The 3D desktop is not something that is really needed for daily work, but I wanted to try it. Unfortunately, I could not get the desktop effects to work the first time I tried. I enabled the livna repositories, installed the nVidia binary drivers and configured the X server to use them. However, telling the system to enable the Desktop Effects failed, and running glxinfo crashed with a "locking assertion failure" message.Googling a bit, I found a page mentioning that one has to run the livna-config-display command to properly configure the X server. I think I did not do this, so I just ran this manually and later restarted X. No luck.Fortunately, that same page also contained a snippet of the xorg.conf configuration file that was like this:Section "Files" ModulePath "/usr/lib64/xorg/modules/extensions/nvidia" ModulePath "/usr/lib64/xorg/modules"EndSectionEffectively, my configuration file was lacking the path to the nVidia extensions subdirectory. Adding that line fixed the problem: now the server loads the correct GLX plugin, instead of the "generic" one that lives in the modules directory. I guess livna-config-display should have set that up automatically for me, but it didn't...The desktop effects are now working :-) Now I figure out why compiz feels so slow... specially because I have the same problem at work with an Intel 965Q video card. [Continue reading]

  • lib64 problems

    Linux distributions for the x86_64 platform have different approaches when it comes to the installation of 32-bit and 64-bit libraries. In a 64-bit platform, 64-bit libraries are required to run all the standard applications but 32-bit libraries need to be available to provide compatibility with 32-bit binaries. In this post, I consider 64-bit applications to be the native ones and the 32-bit to be foreign.The two major approaches I have seen are:lib32 and lib64 directories, leaving lib to be just a symbolic link to the directory required by the native applications. This is the approach followed by Debian. The advantage of this layout is that the lib directory is the correct one for native applications. However, foreign applications that have built-in paths to lib, if these exist, will fail to work.lib and lib64 directories. This is the approach followed by Fedora. In this layout, the foreign applications which have built-in paths to lib will work just fine, but the native applications have to be configured explicitly to load libraries and plugins from within lib64.I have found so far two instances where the Fedora approach fails because native 64-bit applications hardcode the lib name in some places, instead of using lib64. One of these were the NetworkManager configuration files, which had an incorrect setup for the OpenVPN plugin and it failed to work. This issue has already been fixed in Fedora 9. The other problem was in gnome-compiz-manager where the application tries to load plugins from the lib directory, but as it is a 64-bit binary, it failed due to a bitness mismatch. This has been reported but is not yet fixed upstream. I'm sure several other similar problems remain to be discovered.I personally think that the Debian approach is more appropriate because it seems weird that all standard system directories, such as bin or libexec, contain 64-bit binaries but just one of them, lib, is 32-bit specific.As a side note, NetBSD follows an slightly different approach: lib contains 64-bit libraries and lib32, if installed at all, contains the 32-bit ones. [Continue reading]