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.

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!

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-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!

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!

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:

1. That you are familiar with building things from source
2. That you are running the 64 bit version a fairly recent Linux distribution
3. 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.
4. 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.

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

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

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.

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.

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.