synaesthesia

I encountered a bit of trouble using an old Creative Webcam 3 USB with a website that wanted to capture video from it.  This camera uses an OmniVision OV511+ controller and had never been any trouble to use even with Linux.  However, attempting to use it via the browser produced a message that access to the camera was denied.

The first thing to check was permissions on the /dev/video0 device. I found that the user was not in the video group that was required to access the device by default. However, granting this permission and restarting the login session was still not enough.

It turns out that a characteristic of the USB Video Class (UVC) standard is that only video frames with certain pixel encodings can be generated by compliant devices. Whether due to this narrow scope or for other reasons, the WebRTC standard, which provides access to cameras via HTML5-compliant web browsers, only incorporated support for a relatively small number of pixel encodings, and browsers using the WebRTC library therefore only implement support for, at most, that subset of possible pixel encodings.

For example, Chrome (and any other browser which uses the WebRTC library) only supports decoding just a handful of the dozens of raw pixel formats, many vendor-specific, that are supported by the Video4Linux2 API.

Unfortunately, one of those vendor-specific pixel formats that is not supported by the WebRTC layer is the O511 pixel format generated by the OV511+ chip in the Creative Webcam 3 USB. This can be confirmed like so:

$ lsusb
Bus 001 Device 010: ID 05a9:a511 OmniVision Technologies, Inc. OV511+ Webcam
$ v4l2-ctl --all -d /dev/video0
[..]
Format Video Capture:
   Width/Height  : 640/480
   Pixel Format  : 'O511'

Okay, so what can be done? Fortunately, V4L2 developers provided a compatibility wrapper that will convert frames from esoteric pixel formats on-the-fly to the much more widely supported BGR42/YUV420 pixel formats. The wrapper is loaded using LD_PRELOAD before the browser is launched, e.g:

$ LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so firefox
$ LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so chromium-browser

If your distribution is multiarch, the library will be under /usr/lib/x86_64-linux-gnu or similar.

The goal seemed simple enough.  An existing Linux router with a 2.4GHz TP-Link TL-WN822N v2.0 802.11N USB dongle in AP mode was serving a home network consisting of a mix of devices capable of 2.4GHz and 5GHz operation.  Almost two dozen reachable 2.4GHz networks were nearby, a situation that took the blame for a great deal of wireless dropouts and sluggish performance.  Since by comparison only a few 5GHz networks were penetrating the apartment, adding a USB Edimax EW-7822UAC was the goal, to add 5GHz 802.11AC capability to the router in a bridged configuration with the existing connection.  Well, things always sound simple in concept… (more…)

On CentOS 5 (and possibly the corresponding RHEL), the Matrox G200 driver fails when using an embedded G200SE on a SR2600 server.  If you run the X server under gdb or look at the last lines of the Xorg.0.log output, you can see that the X server stopped loading due to the mga_drv.so driver module producing a segmentation fault.  The segmentation fault is due to incorrect probing of the available memory size.

(more…)

The problem:  Older versions of AMD’s APP (Accelerated Parallel Processing) OpenCL SDK are recommended for use with older Radeon chipsets, but produce segmentation faults in string handling code or other inoperability when used with newer Linux distributions.  Version 2.4 through 2.6 exhibit the problem.  However, version 2.8 does not support, probably among others, the RV770 chipset used in the HD 4850.

The solution:  Use version 2.7 of AMD’s APP when using cgminer with an ATI HD 4850 video card on current Linux distributions.