Hans' hacking log

Linux Packaging Workshop in the Netherlands (only 10 days left!)

Thu, 07 Jun 2012 14:42:44 GMT

Only 10 days left till the Linux Packaging Workshop on Saturday June 16th in The Hague, The Netherlands. For more
details see: https://revspace.nl/Debrpm (warning Dutch). So if you live in the vicinity and you've ever considered becoming a Fedora packager, this is an excellent opportunity for taking the first steps!

If you plan to attend please send an email to debrpm@echtehackers.nl.

Fedora moving to libusbx and announcing libusbx

Tue, 22 May 2012 12:00:24 GMT

I'm happy to announce the existence of libusbx, a fork of libusb,. a bit late I must admit, as libusbx has been available for a while now, but as one of the people behind it I still wanted to mention it on my blog.

The libusbx fork was started by various libusb-1.0 developers (almost all of them), because the official maintainer of libusb-1.0 refused to do any stable / tarbal releases for over 18 months and in general was very slow with merging new developments and fixes.

Anyways, lets not look backwards, but forwards towards what looks to be a bright new future with libusbx :)

For more info on libusbx see the libusbx wiki.

I'm currently working on moving Fedora over to libusbx, you can find the Rename Review Request here.

Linux Packaging Workshop in the Netherlands

Sun, 13 May 2012 05:19:25 GMT

I'm co-organizing a Linux Packaging Workshop on Saturday June 16th in The Hague, The Netherlands. For more
details see: https://revspace.nl/Debrpm (warning Dutch). So if you live in the vicinity and you've ever considered becoming a Fedora packager, this is an excellent opportunity for taking the first steps!

New USB redirection features, USB redirection talk @FOSDEM

Wed, 01 Feb 2012 10:34:06 GMT

usbredir-0.3.3, spice-0.10.1, spice-gtk-0.9 have been recently released upstream and are available in Fedora-16 updates[-testing] and are chock-full of new USB redirection features & fixes:

Improved compatibility various usb mass storages devices which would not work before are working now
You no longer need to run spicy as root to use USB redirection, when running as a normal user you will now get a PolicyKit dialog asking you for the root password. You can change this by editing: /usr/share/polkit-1/actions/org.spice-space.lowlevelusbaccess.policy and setting <allow_active> to "yes". Note that this will give any local users of your machine FULL access to any USB devices plugged in!
You can now redirect already plugged in devices / un-redirect devices without unplugging them, go to the
Input menu and click "Select USB Devices for redirection".
Filtering for auto-redirection, you can now specify a filter for auto redirection using --spice-usbredir-auto-redirect-filter=<filter-string>. Standard a filter is in place to avoid redirection of HID devices, so that if you've a glitch on your USB bus, or plug a mouse into a laptop it no longer gets swallowed by the vm making it unavailable to the client.

I'll be at FOSDEM this weekend, and I'll give a talk about Spice, sheets here. As well as a talk about USB redirection, sheets here. Besides me there will be 4 other people from the Spice team there, be sure to also watch their talks about XSpice and Boxes. If you have any question about Spice, or just want talk to us, FOSDEM is an excellent opportunity to do so!

While I'm plugging talks @FOSDEM, there will also be lots of other talks from Red Hat speakers.

Enjoy, and be sure to send any feedback you may have my way!

Using spice from the qemu cmdline

Tue, 13 Sep 2011 13:52:40 GMT

Various people have been asking how to run qemu with spice when launching qemu directly, rather then through libvirt + virt-manager. So here is a quick howto.

*** The basics ***

Besides adding the usual qemu cmdline options to make it find the harddisk to boot from, have a NIC, soundcard, etc. in order to add spice add the following to the cmdline:
-vga qxl -spice port=5932,disable-ticketing

After launching qemu with this, you can connect to it with spicy (new gtk based client) or spicec (old libX11 client), like this
(their cmdline syntax is compatible):
spicy -h localhost -p 5932

*** Enabling the agent channel ***

To really enjoy spice, with all its features like copy paste between client and guest, and client mouse mode (mouse cursor drawn by client, so 0 mouse lag), you need to install the qxl graphics driver and spice-agent in the guest, *and* enable the agent channel between the guest and the client, to do this add the following options to the qemu cmdline:
-device virtio-serial \
-chardev spicevmc,id=vdagent,name=vdagent \
-device virtserialport,chardev=vdagent,name=com.redhat.spice.0

*** Enabling support for usb redirection ***

If you're running qemu under Fedora-16 (or newer), or have build it from source with usbredirection support as explained in my previous blog post, then you can also let spice redirect usb devices from your client to the vm, to enable this you will first need to enable usb2 emulation in qemu, download this file, and drop it in /etc/qemu. And at the following to the qemu cmdline:
-readconfig /etc/qemu/ich9-ehci-uhci.cfg

Then to create 3 usbredir ports into which the client can then "plug" redirected devices add the following:
-chardev spicevmc,name=usbredir,id=usbredirchardev1 \
-device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,debug=3 \
-chardev spicevmc,name=usbredir,id=usbredirchardev2 \
-device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,debug=3 \
-chardev spicevmc,name=usbredir,id=usbredirchardev3 \
-device usb-redir,chardev=usbredirchardev3,id=usbredirdev3,debug=3 \

The debug=3 is not strictly necessary, but it gives some useful messages without flooding the qemu console with messages. Note that you can also create more / less then 3 usbredirection usb "ports", how to do this is left as an
excercise to the reader :)

To use the usb redirection connect to the vm with spicy running as root, so that it can access the device nodes under /dev/bus/usb.

Select the options menu entry and make sure that the "auto redirect newly plugged in USB devices" option is checked. After this make sure the vm has keyboard focus (so close the options menu), plug in a new USB device and watch it show up in your vm :) Feel free to yank it out again at any time :)

If you plug in a device while the vm does not have keyboard focus, it will not get redirected, so you can use usb devices
normally as long as you don't have the vm focussed when you plug them in.

Enjoy, and be sure to send any feedback you may have my way!

Howto build qemu + spice with usbredirection from source

Tue, 13 Sep 2011 13:37:27 GMT

Hi,

Here is a little howto for building qemu + spice with usbredirection from source, for those of you who are not running Fedora 16.

The below instructions assume:

That you are familiar with building things from source
That you are running the 64 bit version a fairly recent Linux distribution
That you want to override you distro installed version of various bits with the bits build from source, this is necessary to ensure that everything builds and runs linked against the correct version of various libs.
That using a distribution with a multilib setup where 64 bit libraries go into /usr/lib64. If you are using a distro which puts 64 bits libraries under /usr/lib rather then /usr/lib64 (for example Debian or ubuntu), you need to replace /usr/lib64 with /usr/lib in all commands below

*** Step 1 Building libusb ***

First of all you will need libusb from git for now, hopefully there will soon be an offfical 1.0.9 release you can use instead. To build libusb from git do:

git clone git://libusbx.git.sourceforge.net/gitroot/libusbx/libusbx
cd libusbx
./autogen.sh --prefix=/usr --libdir=/lib64
make
sudo make install

*** Step 2 building usbredir ***

Next you will need to build usbredir itself for the usbredirparser and usbredirhost libraries, download it here, then do:

tar xvfj usbredir-0.4.3.tar.bz2
cd usbredir-0.4.3
make -j2 PREFIX=/usr LIBDIR=/usr/lib64
sudo make PREFIX=/usr LIBDIR=/usr/lib64 install

*** step 3 building spice-protocol ***

For usbredir support we need version >= 0.10 of spice-protocol, download it here, then do:

tar xvfj spice-protocol-0.10.1.tar.bz2
cd spice-protocol-0.10.1
./configure.sh --prefix=/usr --libdir=/usr/lib64
make -j2
sudo make install

*** step 4 building spice[-server] ***

For usbredir support we need version >= 0.10 of spice, download it here, then do:

tar xvfj spice-0.10.1.tar.bz2
cd spice-0.10.1
./configure --prefix=/usr --libdir=/usr/lib64 --enable-smartcard
make -j2
sudo make install

*** Step 5 building qemu ***

The core usbredir code is already in the qemu-0.15.0 upstream release, but some bits needed for integrating it
with spice are missing. Besided that it is also good to get a version with some recent spice fixes included, so
we will again use a git tree for this:

git clone git://people.freedesktop.org/~jwrdegoede/qemu
cd qemu
git checkout -B qemu-kvm-1.0-usbredir qemu-kvm-1.0-usbredir
./configure --prefix=/usr --enable-smartcard-nss --enable-smartcard --enable-spice --target-list=x86_64-softmmu
make -j2
# do not do make install, this will replace the versions of seabios & friends installed by your distro with (quite old non
# working) versions of seabios which are still part of the qemu git tree (someone ought to fix this one of these days)
sudo install -m0755 -p x86_64-softmmu/qemu-system-x86_64 /usr/bin

*** Step 6 building spice-gtk with usbredir support ***

Get spice-gtk version 0.11 or newer here.

tar xvfj spice-gtk-0.11.tar.bz2
cd spice-gtk-0.11
./configure --prefix=/usr --libdir=/usr/lib64
make -j2
sudo make install

*** All done ***

All done, to enjoy the usbredir support you need to pass some extra qemu options on the qemu cmdline, see my next blogpost for details.

USB redirection integrated into SPICE now available in Fedora-16

Fri, 09 Sep 2011 11:39:28 GMT

I'm happy to announce the availability of USB redirection support in SPICE in Fedora 16. Unfortunately the virtmanager bits are not there yet. So if you want to try this you need to configure it manually. This howto assumes
a fully up2date F-16 with spice-gtk from updates-testing installed.

First create a virtual machine as usual, using virt-manager, select spice as display type and qxl as video card model,
when asked if you want to enable the agent channel, say yes.

When done, close virt-manager and edit the relevant /etc/libvirt/qemu/foo.xml file and add the following lines at the end, above the "</devices>" line:

    <controller type='usb' index='0' model='ich9-ehci1'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x7'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci1'>
      <master startport='0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0' multifunction='on'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci2'>
      <master startport='2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x1'/>
    </controller>
    <controller type='usb' index='0' model='ich9-uhci3'>
      <master startport='4'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x2'/>
    </controller>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='4'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='5'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='6'/>
    </redirdev>

Note that the slot='0x08' needs to be one higher then the higest pci slot already in use, so if you've more
pci devices in your config then me you may need to make this higher.

Then close down any virtual machines you may have open, and restart libvirt:
service libvirtd restart

Now start the vm with virt-manager, open it, select the details view, click on Display Spice and lookup and remember the port mentioned there (this will be 5900 if it is the only running vm).

Close virt-manager, and connect to the vm with spicy, like this:
spicy -h localhost -p 5900

Where 5900 should be replaced by the port the vm is actually running on.

Select the options menu entry and make sure that the "auto redirect newly plugged in USB devices" option is checked. After this make sure the vm has keyboard focus (so close the options menu), and plug in a new USB device. You will now
get a PolicyKit dialog asking you for your root password, this is needed since redirecting USB devices requires access the device nodes under /dev/bus/usb. Once you've (correctly) typed your root password, watch the USB device show up in your vm :) Feel free to yank it out again at any time :)

If you plug in a device while the vm does not have keyboard focus, it will not get redirected, so you can use usb devices
normally as long as you don't have the vm focussed when you plug them in.

If you want to redirect already plugged in devices, or un-redirect redirected devices without unplugging them go to the
Input menu and click "Select USB Devices for redirection".

Enjoy, and be sure to send any feedback you may have my way!

Note (Feb 1 2012): this blog post has been updated to:

Use the new usbredir support in libvirt, rather then to directly inject qemu cmdline from the libvirt xml file using the qemu:commandline syntax.
Reflect the use of PolicyKit rather then needing to run the client as root
The new USB device selection widget

First official release of usbredir code

Mon, 18 Jul 2011 06:54:05 GMT

I'm very happy to announce the first official release of the usbredir code: usbredir-0.3.tar.bz2.

usbredir is a protocol for redirection USB traffic from a single USB device,
to a different (virtual) machine then the one to which the USB device is
attached. See usb-redirection-protocol.txt for the description / definition
of this protocol.

With the official 0.3 release the protocol is now frozen (only extensions
advertised through capabilities can be added from now on).

This package contains a number of libraries to help implementing support
for usbredir and a few simple usbredir applications:

usbredirparser:
A library containing the parser for the usbredir protocol

usbredirhost:
A library implementing the usb-host (*) side of a usbredir connection.
All that an application wishing to implement an usb-host needs to do is:
* Provide a libusb device handle for the device
* Provide write and read callbacks for the actual transport of usbredir data
* Monitor for usbredir and libusb read/write events and call their handlers

*) The side to which the actual USB device is attached, also see the
definitions section in usb-redirection-protocol.txt

usbredirserver:
A simple tcp server usb-host, using usbredirhost

usbredirtestclient:
A small testclient for the usbredir protocol over tcp, using usbredirparser

Note that the usb-guest side is missing from this, this will be part of qemu. I've all my qemu usb changes except for the actual usbredir usbdevice itself queued up for merging upstream. You can find a version of qemu with usbredir support in my git repo here. See previous posts for compilation and usage instructions

USB redirection update

Thu, 30 Jun 2011 12:14:10 GMT

I've pushed an updated version of my usb-redirection code to my git repo. The biggest change is that the usbredir device now is a chardev frontend. Which means that the way to use it has changed. Also there now is proper emulation of companion controllers for the ehci code. Here is an example cmdline for using both:

-device usb-ehci,addr=0b.2,multifunction=on,id=ehci0 -device piix3-usb-uhci,addr=0b.0,multifunction=on,masterbus=ehci0.0,firstport=0
-device piix3-usb-uhci,addr=0b.1,multifunction=on,masterbus=ehci0.0,firstport=2
-chardev socket,id=usbredirchardev,host=localhost,port=4000
-device usb-redir,chardev=usbredirchardev,id=usbredirdev

There have also been some usbredir protocol changes, so you need to update and rebuild your usbredir clone too. I hope to release a usbredir-0.1.0 with a frozen protocol soon.

USB protocol reverse engineering workship The Hague, Friday July 22 19:30

Thu, 23 Jun 2011 18:02:52 GMT

Friday July 22 we're organizing a workshop on reverse engineering
USB protocols of devices with proprietary protocols.

Reverse engineering protocols is fun! It's like a puzzle, and if there's
software out there that can solve the puzzle, your brain can do it too.

We'll be taking a look at reverse engineering the protocols on USB-connected
devices. Too many of these devices still come with windows drivers only, and
use an undocumented protocol. Figuring out those protocols is often a lot
easier than you might think, and so is writing a simple driver.

If you want to participate in this workshop, bring a Linux laptop,
preferably with a virtual machine with a Windows guest OS. If you have an
exotic USB device that only has a Windows driver, please bring that too.

This workshop will be given by Bert Vermeulen and Hans de Goede. Bert has
reverse engineered and written drivers for various USB logic analyzers for
sigrok: http://sigrok.org . Hans has reverse engineered and written drivers
for various USB webcams for the Linux kernel and for digital photoframes
for libgphoto2.

Program:
19:00 Welcome, drinks
19:30 Start of the workshop Bert & Hans give a short intro on USB protocol
      principles and a short demo of sniffing and interpreting usb traffic
20:15 Time to get your hands dirty, start reverse engineering your own USB
      device, or one of the devices provided. Your hosts will be walking
      around to answer questions and help you pass any speedbumps you
      encounter.
late: Time to go home?
really late: Chances are your hosts will want to go home at this time, hint
             hint.

Location:

This workshop will be held in the hackerspace Revelation Space in The Hague:
http://revspace.nl/

Registration:

Registration is not mandatory, but in order to have an idea of how many
people will be coming we kindly request you to send an email to
hdegoede@redhat.com if you're going to attend.

New libgphoto2 camlib for tp6801 based keychain digital photo frames

Thu, 23 Jun 2011 18:00:39 GMT

After not working on drivers for keychain digital photo frames with proprietary picture uploading protocols for a while I got contacted by Per Jessen who had a model with a chipset I had never seen before. Luckily I managed to find the exact same model picframe on ebay and ordered one. So libgphoto2 now also supports uploading pictures to keychain picture frames like this one:
http://www.insigniaproducts.com/products/cameras-camcorders-photo-frames/NS-DKEYBK10.html

Unfortunately I have been unable to find out how to probe the display resolution, so currently the driver keeps a list of model strings and if your model is not in that list it won't work. So if you happen to have one of these frames, your help would be appreciated. Apparently xeos also makes frames with these chips, ie:
http://www.xeos-labs.com/product.php?c=1&p=4

So if you have a xeos frame please contact me, if you know a way to xeos frames in Europe (in The Netherlands to be precise) please let me know.

Announcing v4l-utils-0.8.4

Wed, 01 Jun 2011 13:22:10 GMT

Hi all,

I'm happy to announce the release of v4l-utils-0.8.4. After some
somewhat boring releases, this release contains some interesting
improvements:
* Various enhancements to libv4l which should result in
significantly less cpu usage with uvc HD cameras in several
scenarios
* A library for associating video, audio, vbi and other devices with each
other. This will allow apps to automatically do things like figure out
which alsa input devices has the sound for the analog tv show you are
watching. Note atm this lib does not have a stable API yet, and thus
does not get installed by make install.

Full changelog:

v4l-utils-0.8.4
---------------
* Utils changes
* Various small fixes (hverkuil, mchehab)
* qv4l2: Add support for configuring the framerate for devices which support
    this like uvc cams (hdegoede)
* parse_tcpdump_log.pl: new parser for tcpdump / wireshark made usbmon
    dumps (mchehab)
* New lib_media_dev lib, to pair audio devices with video devices
    (and other combinations) for now this lives in utils and does not get
    installed systemwide, as the API is not stable (mchehab)
* libv4l changes
* Add many more laptop models to the upside down devices table (hdegoede)
* Some small bugfixes (hdegoede)
* Add vicam cameras to list of cameras need sw auto gain + whitebalance
    (hdegoede)
* Add support for M420 pixelformat (hdegoede)
* Add support for Y10B pixelformat (Antonio Ospite)
* Add support for JPGL pixelformat (jfmoine)
* Modified (rewrote) jpeg decompression code to use libjpeg[-turbo], for
    much lower cpu load when doing jpeg decompression (hdegoede)
* Detect usb connection speed of devices (hdegoede)
* Rewrite src format selection algorithm, taking bandwidth into account and
    choosing the format which will give us the lowest CPU load while still
    allowing 30 fps (hdegoede)
* Intercept S_PARM and redo src format selection based on new fps setting,
    potentially switching from JPG to YUYV / M420 when the app lowers the
    fps, resulting in a significant lower cpu load (hdegoede)

Go get it here:
http://linuxtv.org/downloads/v4l-utils/v4l-utils-0.8.4.tar.bz2

You can always find the latest developments here:
http://git.linuxtv.org/v4l-utils.git

Hans

USB2 support and USB redirection over the network with qemu

Tue, 31 May 2011 13:44:42 GMT

Hi All,

I've been working on USB redirection over the network for qemu / spice for a while now. And I'm happy to report I've something which is good enough to invite others to test it. In the mean time Gert Hoffmann (kraxel) has been working on cleaning up the EHCI support which was submitted to the qemu-devel list about a year ago, making it suitable to get merged. My qemu git tree is based on Gert's tree, so it has prelimary USB2 support too. Note that the USB2 support works best when used together with the network redirection code over localhost, that seems to be more reliable at the moment then using qemu's direct usb host redirection code.

So if you want to play around with this here are some installation instructions. These instructions assume a 64 bit Red Hat or Fedora installation, with libusb-1.0.so.0 in /lib64. If you've a 32 bit installation or are using a distribution which does not use /[usr/]lib64 for 64 bit installations (such as Debian and Ubuntu) replace /lib64 with /lib in the below instructions.

First of all you will need my version of libusb, which is has a new libusb_get_device_speed function, this is intended
to go upstream sometime soon. But first upstream needs to get to long awaited 1.0.9 out the door. To install my (fully compatible) libusb version do:
git clone git://anongit.freedesktop.org/~jwrdegoede/libusb
cd libusb
git checkout usbredir
./autogen.sh
./configure --prefix=/usr --libdir=/lib64
make
sudo make install

With the new libusb in place, it is time to build the non qemu parts of the usbredir code
(a standalone server, as well as the usbredir protocol parser and host libraries):
git clone git://anongit.freedesktop.org/~jwrdegoede/usbredir
cd usbredir
make PREFIX=/usr LIBDIR=/usr/lib64
sudo make PREFIX=/usr LIBDIR=/usr/lib64 install

And now lets build qemu with usbredir support (note I enable spice + spices smartcard support here, since that is
what I use in my day to day testing, this is not strictly needed).
git clone git://anongit.freedesktop.org/~jwrdegoede/qemu
cd qemu
git checkout usbredir
./configure --prefix=/usr --enable-smartcard-nss --enable-smartcard --enable-spice --target-list=x86_64-softmmu
make
sudo install -m0755 -p x86_64-softmmu/qemu-system-x86_64 "/usr/bin"

Note do not use make install, this will also install the BIOS roms from qemu git which are outdated, this assumes that you already have a recent qemu installed and will be using the BIOS roms from that version.

Now start qemu with all the options you use normally and "-usb" or "-usb -device usb-ehci" for USB2 support. To test the network redirection, start the usbredirserver in another terminal, lets say you want to redirect a usb device with vid:pid
045e:0772, then start usbredirserver like this:
usbredirserver 045e:0772

And then in the qemu monitor cmdline type:
usb_add tcp-redir:localhost:4000

Notes:
1) replace localhost with the ip or hostname of the other machine if you're actually testing this over the network
2) you can start multiple servers to redirect multiple devices on the same machine, add " -p 4001" to start a second
server on port 4001, and make the 4000 4001 in the usb_add command
3) To unplug a device do a usb_del with the exact same arguments as you passed to the usb_add command

If you're interested in the network protocol used for the usb redirection, see:
http://cgit.freedesktop.org/~jwrdegoede/usbredir/tree/usb-redirection-protocol.txt

Regards,

Hans

Gnome 3 launch party 7 april in Den Haag

Sat, 26 Mar 2011 12:18:11 GMT

Gnome 3 will be officially released April 6th 2011. To celebrate this there will be a Gnome 3 release party in The Hague on April 7th. Free entrance, but we would appreciate it if you register so that we know aprox. how many people will come. For details and registration see: http://revspace.nl/RevelationSpace/Gnome3ReleaseParty

Location:
Revelation Space
Binckhorstlaan 172
2516 BG Den Haag
Routebeschrijving / directions

Programme:
19u00: Doors open
20u00: Short demo of Gnome 3
all the time: drinks and friendly nerds
late: The End

Using mini (keychain) digital picture frames under Linux (part 2)

Wed, 31 Mar 2010 12:18:27 GMT

Hi all,

As explained in my previous blog post I've been working on getting small digital picture frames to work under Linux. With small digital picture frames I mean 1.1, 1.5, 1.8 and 2.4 inch (often keychain) models, with build in flash memory.

In my previous post I talked about my adventures in getting Sitronix st2205 based frames working, and I mentioned that I (accidentally) also bought some other frames which were based on the Appotech ax203 chipset. In the mean time I've also added support to libgphoto2 for uploading / downloading pictures to ax203 based devices. So if you have a picture frame with one of the following usb ID's:

USB-ID	Chipset	Support status in libgphoto2
1403:0001	st2205	supported in svn libgphoto2-2_4 branch and trunk
1908:1315	ax203 with firmware ver 3.3.x	supported in svn libgphoto2-2_4 branch and trunk (*)
1908:1320	ax203 with firmware ver 3.4.x	supported in svn libgphoto2-2_4 branch and trunk
1908:0102	ax206 with firmware ver 3.5.x	supported in svn libgphoto2-2_4 branch and trunk

You can use it with Linux now, see here for instructions how to install libgphoto2 from svn and start uploading your pictures today :)

As with the st2205 frames in case of the ax206 (1908:0102) based frames the picture (de)compression algorithm was a problem and I once more owe a big thanks to Bertrik Sikken for helping me out with it. We (again) followed a clean room procedure, were he wrote a description based on disassembling the windows code, which I then coded.

See ya,

Hans

Using mini (keychain) digital picture frames under Linux

Mon, 22 Mar 2010 21:21:25 GMT

Hi all,

I've been working on getting small digital picture frames to work under Linux. With small digital picture frames I mean 1.1, 1.5, 1.8 and 2.4 inch (often keychain) models, with build in flash memory.

This turns out to be a non trivial task, as all these small devices use custom protocols and custom image compression. It all started with me buying a 1.5 inch 128x128 pixel keychain picture frame for 5 euros for fun. Through googling I quickly learned this frame has an st2205 chipset and also found me this website from people who had already been hacking on this device to use it as a "second monitor" (to display cpu usage stats for example). The person behind this website had already uncovered lots of useful details, such as how to read from / write to the flash on the picture frame.

The picture frame shows up as a 2 MB harddisk through a usb mass storage interface, but you cannot simple read from or write to this disk. Instead a very interesting protocol is used where you communicate with the device by reading / writing sectors at specific magic offsets (sick). This protocol basically allows raw access to the flash chip on the picture frame, for example you need to do separate erase and program commands, and as an erase block is larger then what you program in a single program command you must make sure to always reprogram the entire range the single erase command cleared (and read the entire range before clearing, so you can write it back).

So how to access the device was already known, next step figuring out the image compression. After some failed attempts, I asked help from Bertrik Sikken with reverse engineering the st2205 compression. He went the route of disassembling the windows binaries for uploading pictures, and wrote an algorithm description of the decompression on the picframe wiki.

I used this description to write decompression code. The first version used header files with the lookup tables as C-code arrays and these header files were made by and given to me by Bertrik. I also wrote compression code by "simply" reversing the decompression algorithm. The lookup tables were a problem, as Bertrik copied them out of the windows code, and one could argue that they are copyrightable. Luckily the same tables are also present in the firmware of the picture frame, and we can read them from the frame. So I modified my code to follow this approach to avoid any copyright issues.

So now I had all the necessary ingredients to write software to upload pictures to these devices under Linux. Next question, do I write a standalone app, a library, or extend something existing ? I quickly ruled out a stand alone app, clearly this sort of code belongs in a library so that it can be used by multiple front ends. After some deliberation I came to the conclusion that the best solution was to write a driver (a so called camlib) for libgphoto2, and that is what I've done. My libgphoto2 driver for accessing st2205 based picture frames now is in libgphoto svn. If you have such a picture frame (usb-id 1403:0001) and want to use it under Linux, instructions are here.

As I wanted to have some different models (esp with different display sizes) to test my libgphoto2 driver, I've bought some more keychain picture frames, and of course the second and third and fifth one I bought have different chipsets:

usb-id 1908:1315, ax203 with firmware version 3.3.x
usb-id 1908:1320, ax203 with firmware version 3.4.x
usb-id 1908:0102, ax203 with firmware version 3.5.x

These too have a very interesting protocol to talk to them, and this means that now I'm working on another libgphoto2 driver for these devices, support for the 3.3.x and 3.4.x devices is coming along well. The 3.5.x devices have a nasty image compression algorithm and are currently blocked on that :(

Regards,

Hans

libv4l-0.6.2: The 3th upside down release

Fri, 09 Oct 2009 09:14:15 GMT

Hi All,

I'm very happy to announce libv4l-0.6.2

This release features the following familiar new features from 0.6.0 release:

Software whitebalancing
Software automatic gain and exposure for cams which lack this in hardware
Software gamma control
Fake v4l2 controls to control all these
Software flipping controls

The big new feature (again) is a lot of additions of laptop models to the list of laptops whose
camera modules (mostly uvc) are known to be mounted upside down in the frame.

To give this version a try on F-10 or F-11 do:
yum --enablerepo=updates-testing install libv4l v4l2ucp

If you've a laptop with an upside down webcam, after this the image should hopefully be the right way up in
cheese and most other apps. For skype use:
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype

If the image is not the right way up, then your laptop needs to be added to libv4l's upside down devices list, in that case
please do:
lsusb > lsusb.log
dmidecode > dmi.log

And mail me the 2 log files, it is important to use redirects (">") and to not copy paste as the dmi.log file can contain
lines with trailing whitespace which I need.

If you're interesting in testing the new whitebalance or gamma correction code, see my previous blog post.

Enjoy!

libv4l-0.6.1: The 2nd upside down release

Tue, 01 Sep 2009 08:30:38 GMT

Hi All,

I'm very happy to announce libv4l-0.6.1

This release features the following familiar new features from 0.6.0 release:

Software whitebalancing
Software automatic gain and exposure for cams which lack this in hardware
Software gamma control
Fake v4l2 controls to control all these
Software flipping controls

The big new feature is a lot of additions of laptop models to the list of laptops whose
camera modules (mostly uvc) are known to be mounted upside down in the frame.

To give this version a try on F-10 or F-11 do:
yum --enablerepo=updates-testing install libv4l v4l2ucp

If you've a laptop with an upside down webcam, after this the image should hopefully be the right way up in
cheese and most other apps. For skype use:
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype

If the image is not the right way up, then your laptop needs to be added to libv4l's upside down devices list, in that case
please do:
lsusb > lsusb.log
dmidecode > dmi.log

And mail me the 2 log files, it is important to use redirects (">") and to not copy paste as the dmi.log file can contain
lines with trailing whitespace which I need.

If you're interesting in testing the new whitebalance or gamma correction code, see my previous blog post:
http://hansdegoede.livejournal.com/6661.html

Enjoy!

libv4l release: 0.6.0: the upside down release

Fri, 10 Jul 2009 08:10:53 GMT

Hi All,

I'm very happy to announce the first release of the next
stable series: libv4l-0.6.0

This release features the following familiar features from
previous 0.5.9x test releases:

Software whitebalancing
Software automatic gain and exposure for cams which lack this in hardware
Software gamma control
Fake v4l2 controls to control all these
Software flipping controls

And as a new feature it now has an extended list of laptops
whose camera modules (mostly uvc) are known to be mounted
upside down in the frame and it will automatically correct
the image for this.

To give this version a try on F-10 or F-11 do:
yum --enablerepo=updates-testing install libv4l v4l2ucp

If you've a laptop with an upside down webcam, after this the image should hopefully be the right way up in
cheese and most other apps. For skype use:
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype

If the image is not the right way up, then your laptop needs to be added to libv4l's upside down devices list, in that case
please do:
lsusb > lsusb.log
dmidecode > dmi.log

And mail me the 2 log files, it is important to use redirects (">") and to not copy paste as the dmi.log file can contain
lines with trailing whitespace which I need.

If you're interesting in testing the new whitebalance or gamma correction code, see my previous blog post:
http://hansdegoede.livejournal.com/6661.html

Enjoy!

FAQ: Why did my sensors stop working in F-11 / with kernel 2.6.31 ?

Thu, 02 Jul 2009 08:08:15 GMT

Hi all,

In the 2.6.29 kernel in F-11 and in the mainline 2.6.31 kernel, there is a change which causes hardware monitoring (also called sensors) to no longer work on some motherboards. If this is happening for your motherboard, then when the lm_sensors service is starting you are probably getting an error like this:

FATAL: Error inserting it87
(/lib/modules/2.6.29-15.fc11.x86_64/kernel/drivers/hwmon/it87.ko): Device or
resource busy

And if you look at the kernel messages (using the dmesg command in a terminal for example) you will probably see something like this:

ACPI: I/O resource it87 [0x295-0x296] conflicts with ACPI region IP__
[0x295-0x296]
ACPI: Device needs an ACPI driver

With previous kernels hwmon drivers used to drive IO ranges which were potentially used by the ACPI code in your BIOS (which is active not only during but also after boot), we now explicitly check for this and if the ACPI code claims the IO-ports used by the hwmon chip, we no longer allow the hwmon driver to load.

Banging IO-ports of a chip from 2 different drivers, the Linux hwmon driver and the ACPI code is a *really* bad idea and can cause all sort of issues (including things like changing CPU / RAM voltage or clock speed). So the old behaviour was a really bad idea.

So even though this change in behaviour makes some people unhappy as to old behaviour happened to work without problems in their case (by sheer luck really), this change is really for the best!

If you want to restore the old behaviour (which might be dangerous) add: "acpi_enforce_resources=lax" to the kernel cmdline when booting (or add it in grub.conf to make this permanent).

p.s.

Note that this change actually first appeared in the mainline 2.6.30 kernel, but due to a bug in 2.6.30, it didn't take effect until 2.6.31, see:
http://bugzilla.kernel.org/show_bug.cgi?id=13967

libv4l testing instructions

Mon, 22 Jun 2009 10:33:58 GMT

Hi all,

Every now and then I need to ask people to test the latest libv4l, so I decided it would be a good idea to post some generic testing instructions here to have a place to point people to:

1. Install
=======

libv4l needs make, a working C-compiler (gcc), and libjpeg +
its header files to build. If you don't have these you need to install them
first. See your distributions documentation on how to install make and
the compiler (often called development tools / chain). For libjpeg,
you need to install the libjpeg62-dev under Debian/Ubuntu and the
libjpeg-devel package under Fedora / RHEL.

Howto install and test libv4l depends on your system. There are
different instructions for if you have a 32 bit system or a 64 bit system.
which is using multilib. A 64 bit system without multilib is the same as
a 32 bit system.

To find out what you have do:
ls -d /usr/lib64

If this command gives a "No such file or directory" error, use the
Non multilib instructions, if this command is successfull, you likely have multilib.

Note: I've received some reports that there us a /usr/lib64 directory on some 32
bit installs of Ubuntu. If you're quite sure you are running a normal (32 bit) version
of Ubuntu you likely are and you should follow the Non multilib instructions.

Ok, so you have a multilib system, to find out which (dubbed Fedora and Ubuntu
multilib, because those are the most well known examples, do):

ls -d /usr/lib32
If this command gives a "No such file or directory" error, use the Fedora multilib
instructions. If this command succeeds use the Ubuntu multilib instructions. Note
the ubuntu multilib instructions also apply to gentoo and the Fedora multilib instructions
also apply to [open]Suse.

Non multilib instructions:
-------------------------------
tar xvfj v4l-utils-<version>.tar.bz2
cd v4l-utils-<version>/lib
make PREFIX=/usr
sudo make install PREFIX=/usr

Fedora Multilib instructions:
-----------------------------------
Basic 64 bit install:
tar xvfj v4l-utils-<version>.tar.bz2
cd v4l-utils-<version>/lib
make PREFIX=/usr LIBDIR=/usr/lib64
sudo make install PREFIX=/usr LIBDIR=/usr/lib64

If you also want to use 32 bit apps (such as skype), you
will need to have the 32 bit libc headers installed, on Fedora
this can be done like this:
Fedora 10-: "sudo yum install glibc-devel.i386"
Fedora 11: "sudo yum install glibc-devel.i586"
Fedora 12+: "sudo yum install glibc-devel.i686"
[open]Suse: install glibc-devel-32bit and gcc-32bit

Then do:
make clean
make PREFIX=/usr CFLAGS=-m32 LDFLAGS=-m32
sudo make install PREFIX=/usr

Ubuntu Multilib instructions:
-----------------------------------
tar xvfj v4l-utils-<version>.tar.bz2
cd v4l-utils-<version>/lib
make PREFIX=/usr
sudo make install PREFIX=/usr

If you also want to use 32 bit apps (such as skype), you
will need to have the 32 bit libc headers installed, on Ubuntu
this can be done like this:
sudo apt-get install libc6-dev-i386
On gentoo this can be done like this:
sudo emerge -v app-emulation/emul-linux-x86-compat
Then do:
make clean
make PREFIX=/usr CFLAGS=-m32 LDFLAGS=-m32 LIBDIR=/usr/lib32
sudo make install PREFIX=/usr LIBDIR=/usr/lib32

2. Testing
========
You have a chance that your webcam app use libv4l or have an appropriate
script starting it. In that case you don't have to do anything. Just run
the application. This is the most common situation with Ubuntu and Fedora
packages. If your problem remains unsolved, then your app might not use libv4l.
In that case start the application from a terminal like this:

Non multilib:
----------------
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so <your favorite webcam app>

Note on Ubuntu sometimes skype is using a wrapper script, so if skype
does not work try:
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype.real

Fedora multilib:
--------------------
For 64 bit applications (allmost all apps):
LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so <your favorite webcam app>

For 32 bit applications (you only need it for proprietary softwares, which
don't have a 64 bit version, like skype):
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so skype

Ubuntu multilib:
--------------------
For 64 bit applications (allmost all apps):
LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so skype

For 32 bit applications (you only need it for proprietary softwares, which
don't have a 64 bit version, like skype):
LD_PRELOAD=/usr/lib32/libv4l/v4l1compat.so skype

Note on Ubuntu sometimes skype is using a wrapper script, so if skype
does not work try:
LD_PRELOAD=/usr/lib32/libv4l/v4l1compat.so skype.real

New webcam drivers heading upstream

Fri, 19 Jun 2009 12:24:29 GMT

Hi All,

I'm happy to report that I've managed to free some time, to work on getting more webcam drivers into the mainline kernel. I've just finished adding support for ov511 / ov518 and st6422 drivers to my gspca tree:
http://linuxtv.org/hg/~hgoede/gspca

Covering all the cams previously supported by the out of tree ov51x-jpeg and qc-usb-messenger drivers. These drivers
will appear in the mainline kernel in 2.6.31 .

Note to people who want to give this a try (see previous blog post for compile instructions) the ov51x cams also require the use of the latest libv4l:
http://linuxtv.org/hg/~hgoede/libv4l

Time to update:
http://fedoraproject.org/wiki/Features/BetterWebcamSupport#Test_Plan
And mark a number of cams as working now :)

Linuxtag & Webcams

Mon, 15 Jun 2009 21:47:01 GMT

Hi all,

I'll be going to Linuxtag, or rather to the Fudcon which is held partially overlapping and after Linuxtag. Recently I've been able to make some more time free to work on v4l / webcams and I've been making some nice progress with some things I've wanted to fix for a long time now. so I'm going to do another Better Webcam Support as a Feature during the F-12 cycle, see the updated Feature page:
https://fedoraproject.org/wiki/Features/BetterWebcamSupport

As such I'm planning on doing a (one man?) hack session for webcam support during Fudcon, and I would like to invite everyone to bring their webcams! Esp once which are not working, or are working poorly. Preferably to donate them so
I have some more different models to test with, but I'll also be very happy to just play a bit with them during the Fudcon.

So for those who looked at the feature page and noticed I already have 37 cams, why do I need so much cams ? Well thats quite simple a cam consists of a sensor which captures the actual image and a separate bridge which compresses it and transfers it over usb. And each combination of these 2 often requires totally different register writes for both the
bridge and the sensor to get the combination to work. So lets say we have 15 different bridges and 15 different sensors, then in total we've 225 different combinations, in my experience sofar the real number of existing webcams which need their own peculiar way of driving them isn't all that far away from this number.

So given that each bridge / sensor combo is unique, the easiest way for me to reproduce and fix problems is actually holding a cam, or one which is very much alike in my hands.

libv4l: Now with whitebalance and gamma correction

Tue, 26 May 2009 18:35:44 GMT

Hi all,

I'm happy to announce a new libv4l which adds support for video processing / filters to improve the image quality with some webcams. With certain cheap webcams this makes the image quality a lot better!

Please give it a try, to try it out do:
yum install--enablerepo=updates-testing libv4l v4l2ucp

This probably will not work yet for those of you already running F-11, in that case download the rpms from here and install them manually:
http://koji.fedoraproject.org/koji/buildinfo?buildID=103619
http://koji.fedoraproject.org/koji/buildinfo?buildID=103616

Then run v4l2ucp, you should now amongst other controls see 2 controls labelled: "Whitebalance (software)" and "Gamma (software)". If you do not see these 2 controls, you've a cam which does not need conversion (delivers frame data in plain YUV or RGB all by itself), most likely a UVC based webcam, where doing this in software is not needed.

For most cams the Whitebalance control is disabled by default and the Gamma defaults to 1000 (1.0), which means it is also effectively disabled. libv4l already recognizes some cams which get a significant better picture with Whitebalance and or gamma correction active, and will enable it be default on these cams.

This is where I need your help, start a webcam appplication, cheese for example and then try enabling the whitebalance and try playing with the Gamma slider. If either of them significantly improves the picture quality please drop me a mail which setting is best for your cam and don't forget to include the USB-ID's then I'll include those settings as default settings for cams with that ID.

Howto use / try the latest development gspca version

Mon, 24 Nov 2008 12:04:06 GMT

Hi All,

So I've been getting several reports about cams which used to work with the old gspca no longer working with the in kernel gspca, even when using libv4l. The first thing to do when debugging this is try the latest gspca devel version from git (well mercurial actually). So I thought it would be good to write a little blog post on how to use gspca from mercurial so I have a single place to point people to when I want them to do this.

First of all you need to make sure you have the kernel headers for the kernel you are running installed, and also gcc, make and mercurial. Under Fedora this can be done with the following command:
"yum install kernel kernel-devel gcc make mercurial"

Note if this command installs a new kernel, first reboot into this new kernel before continuing.

Now do:
hg clone http://linuxtv.org/hg/~jfrancois/gspca/
cd gspca
sudo make menuconfig
make
sudo make install
reboot

Notes:
1) There is no need to make any changes in make menuconfig
2) make menuconfig needs sudo as it wants to write .o files for the menuconfig executable to /usr/src/kernel/.....
3) The reboot is needed as this will also replace videodev.ko and that might already be loaded (and in use) on your
system.

Now plug in your webcam, start some app to test it and hopefully it will work :)