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.

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

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

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

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:

1. usb-id 1908:1315, ax203 with firmware version 3.3.x
2. usb-id 1908:1320, ax203 with firmware version 3.4.x
3. 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

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.

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

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!

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