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

Hi All,

So a kernel update, updating the kernel to 2.6.27 has hit F-9, and with it come the new gspca webcam drivers adding support for many new cams. However people trying to use this new support sofar have found that it doesn't work. So here is an explanation why it does not work, and how to get it to work.

Most cams supported by the new gspca drivers deliver data compressed with various
different custom proprietary compression algorithms, which no apps know how to
handle. The zc3xx driver delivers JPEG data, so it will work with some apps (try
ekiga) but not with others, such as cheese, which do not know how to handle JPEG sources.

The old gspca driver solved this by doing format conversion inside the kernel.
Which is a very bad thing to do and thus has been removed in the new version.

As most apps / libraries do not know how to handle the multitude of video
formats webcams can produce, I've written libv4l:
http://hansdegoede.livejournal.com/3636.html

I've just done a build of the latest libv4l for F-9, so it should be available
through "yum install libv4l" soon. In the mean time you can download the rpm
from here: http://koji.fedoraproject.org/koji/buildinfo?buildID=70038

As no applications in F-9 have been patched to use libv4l (most apps are
patched in F-10), you will need to use the libv4l C-libary wrapper to tunnel
the v4l calls the apps make through libv4l.

Todo this you need to launch the applications from a terminal and instead of
typing just <app-name> you type:
"LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so <app-name>"

Note that for 64 bit applications this becomes:
"LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so <app-name>"

So for example to launch cheese you type:
"LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so cheese"


One last note the use of LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so only
applies to 64 bit *applications*, 32 bit applications on 64 bit installations,
such as skype, still must use the version without the "64" in it, so:
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so. To get the 32 bit libv4l installed on
a 64 bit system do: "yum install libv4l.i386"

So I was just thinking about all the software development projects which I would want to do, but where I can not find the time for. So I thought that maybe it would be a good idea to post this as a list so that if there are any doss contributers looking for a project out there, they can maybe get inspired by that list :)

Maybe we can even make a fedoraplanet meme out of this, I'm sure other devs have similar lists in the back of their head.

• Hardware monitoring (lm_sensors) kernel work:
  • Lots of people are trying to contribute new drivers, but those are not getting in due to lack of manpower for reviewing (and tutoring).
  • We have quite a list of not support hwmon IC's for which datasheets are available, so the main reason for not having drivers for these is lack of manpower (and reviewers)
  • There are some system management frameworks used on servers which we would like to support, for which out of tree work has been done:
    
    • ipmi: http://bmcsensors-26.sourceforge.net/
    • amt: http://www.openamt.org/
  • Adding support for hardware monitoring (temperature, fan speeds) of graphics cards
• Hardware monitoring (lm_sensors) userspace work:
  • Motherboard hwmon autoconfiguration tool (discussion and design done, just needs to be implemented)
• Webcam kernel work:
  
  • Cleanup (and port to v4l2) various out of tree and old v4l1 in tree webcam drivers and get them in to the mainline kernel
• Webcam userspace work:
  
  • Design and write a videodevice multiplexing daemon (think pulseaudio for video input devices)
  • Add support for software image enhancements (whitebalance, normalize, etc). To libv4l, various people are interested in this, I need to make some time to do some design work here
• Fedora packaging work:
  
  • Package stuff from the Games SIG wishlist: http://fedoraproject.org/wiki/SIGs/Games/WishList
  • Get packages from planet ccrma http://ccrma.stanford.edu/planetccrma/software/ reviewed and added to Fedora, do an Audio Spin

Well thats it (I think) so if you're interested in doing something from this list, don't hesitate to contact me I will gladly help / sponsor / coach / mentor anyone willing to work on this.

Hi All,

Besides leading a hackfest session on becoming a Fedora Package Maintainer, I also want to try and spend some time talking about my BetterWebcamSupport feature. I will probably pitch a session about it on Saturday. More over I would like to use this moment to ask everyone who will attend FudCon and has an old webcam gathering dust somewhere to take it with them to FudCon and kindly donate it to the the better webcam support project (aka me).

While asking for donations, is there anyone out there who is willing to donate some time to the better webcam support project? I've come a long way all by meself, but there is so much more that could be done!


Last a quick status update, look at the BetterWebcamSupport webpage for a list of webcams which I already own and I'm doing testing with. gspcav2 is in 2.6.27 now and improvements are being made to it every day. libv4l is in rawhide and is used by gstreamer and xawtv, and ekiga support is on its way. My main focus for the next few days will be getting more applications to use libv4l. Last but not least I've spend the last full week on reverse engineering Pixart 7311 and 7302 cams (standing on the reverse engineering giants shoulders of those who worked on this before me) and now have those working, both on the kernel side, as the Pixart custom JPEG format decompression in libv4l.

Hi all,

First of all some very good news: gspca has been merged into the mainline for 2.6.27 (yes!), but in order for it to be acceptable there the decoding of many cam specific custom video formats had to be ripped out (and rightfully so!).

As blogged before I've written a userspace conversion library for this, which offers transparent conversion to more normal formats fully mimicking the /dev/video API (just replace open with v4l2_open, ioctl with v4l2_ioctl, etc) and this library has been merged as part of the v4l-dvb project (yes again). But now I need to write patches for all v4l using applications in Fedora, which since the API is the same isn't hard, but does take some work, and all of that work then also needs to be send upstream.

So if you maintain a v4l using application / lib in Fedora, expect a bugzilla ticket with a patch from me soon, and yes I'll be sending all these upstream. But I'll stop babbling and make myself useful and start packaging libv4l itself :)

Hi all,

I currently have the following score with my testing cams (I've been buying every cam I can find which costs less then 20 euros):

• 2 are untested (-ENOTIME)
• 2 do not have a driver available in the kernel or in gspca (but do have some initial attemps located at sourceforge, I plan on working on those later)
• 1 does not work even though it has a driver, I need to make usbsnoop dumps of  this one under windows, but I haven't had windows on any machines in a long long time <ugh>
  
• 2 work, but do not have any exposure setting, which is a show stopper, as without modifiable exposure either they don't work in daylight or not with artifical light.
• 5 work good

Yesterday and most of today I've been working on finding out howto do exposure on the 2 cams without exposure setting. I've figured that out now and found out where the average lumination is found in the frameheader, so I'm busy adding autoexposure to these 2 now. As an added bonus I've also figured out howto activate the 50hz artificial light filter on one of them, killing the annoying flicker when using it with artificial light.

When that is done (hopefully tonight) I still need to take a good look at the locking in the gspca core and fix a few issues there, then I'll prepare a patch against the latest kernel in rawhide and add gspca to the rawhide kernel!

Regards,

Hans

p.s.

I still want more webcams and lots of them, if you have a webcam collecting dust somewhere, please contact me for my snailmail address.

Hi All,

As some of you already know, I'm planning on leaving my current employer and thus looking for a new challenge. To be specific I'm looking for a paid job working on Free / OS software. Before my mailbox gets filled with all kind of exotic offers:

• I'm a C/C++ application and kernel developer thus:
  
• I do not do web application development
• I do not do systemadministration
• I love to write device drivers
• I do not want to relocate, thus I'm looking for a job in the Netherlands (or maybe Belgium), remote working for a company located elsewhere is no problem
  

In other news in the light of the "Better Webcam Support" F-10 feature I've been working hard on libv4l, so I'm proud to announce version 0.3.1, highlights of this release:

• multi-thread safe
• works with gstreamer v4l1 and v4l2 plugins

Also it looks like libv4l will become officially endorsed / advised by the v4l-dbv project as the library to access v4l2 devices. Currently it has been merged into Thierry Merle's mercurial tree and from there it should find its way into the main v4l-dvb mercurial tree.


Other good news on the "Better Webcam Support" F-10 feature is that gspcav2 is now also on its way to the mainline, thanks to the hard work of Jean-François Moine, the latest version is available from his mercurial tree, and it has been pulled into the official v4l-dvb tree for wider testing.

Hi All,

In the light of the Better Webcam Support F-10 feature I've been working on a userspace library which can be used to (very) easily add support for all kind of pixelformats to v4l2 applications.

Just replace open("dev/video0", ...) with v4l2_open("dev/video0", ...), ioctl with v4l2_ioctl, etc. libv4l2 will then do conversion of any known (webcam) pixelformats to bgr24 or yuv420.

Also included is libv4l1, which offer v4l1_open, v4l1_ioctl, etc. which can be used to make v4l1 applications work with v4l2 devices, including the necessary format conversion.

The functionality provided by libv4l1 for v4l1 apps and libv4l2 for v4l2 apps
can also be used by existing apps without modifying them. For this purpose  
2 wrapper libraries are provided which can be preloaded before starting the 
application using the LD_PRELOAD environment variable.

For those interested you can get libv4l1 here, below is the full README of libv4l-0.1 :


Introduction
------------

libv4l is a collection of libraries which adds a thin abstraction layer on
top of video4linux2 devices. The purpose of this (thin) layer is to make it
easy for application writers to support a wide variety of devices without
having to write seperate code for different devices in the same class.

All libv4l components are licensed under the GNU Library General Publishing
License version 2 or (at your option) any later version.

libv4l consists of 3 different libraries:


libv4lconvert
-------------

libv4lconvert offers functions to convert from any (known) pixelformat
to V4l2_PIX_FMT_BGR24 or V4l2_PIX_FMT_YUV420.

Currently the following source formats are supported:
jpeg, mjpeg, bayer (all 4 variants: bggr, rggb, gbrg, grbg),
spca501 (chip specific yuv 420 with interlaced components),
spca561 (chip specific compressed gbrg bayer)
For more details on the v4lconvert_ functions see libv4lconvert.h .


libv4l1
-------

This offers functions like v4l1_open, v4l1_ioctl, etc. which can by used to
quickly make v4l1 applications work with v4l2 devices. These functions work
exactly like the normal open/close/etc, except that libv4l1 does full emulation
of the v4l1 api on top of v4l2 drivers, in case of v4l1 drivers it will just
pass calls through. For more details on the v4l1_ functions see libv4l1.h .


libv4l2
-------

This offers functions like v4l2_open, v4l2_ioctl, etc. which can by used to
quickly make v4l2 applications work with v4l2 devices with weird formats.
libv4l2 mostly passes calls directly through to the v4l2 driver. When the
app does a TRY_FMT / S_FMT with a not supported format libv4l2 will get in
the middle and emulate the format (if an app wants to know which formats the
hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of
S_FMT's). For more details on the v4l2_ functions see libv4l2.h .


wrappers
--------

The functionality provided by libv4l1 for v4l1 apps and libv4l2 for v4l2 apps
can also be used by existing apps without modifying them. For this purpose
2 wrapper libraries are provided which can be preloaded before starting the
application using the LD_PRELOAD environment variable. These wrappers will
then intercept calls to open/close/ioctl/etc. and if these calls directed
towards a video device the wrapper will redirect the call to the libv4lX
counterparts.

The preloadable libv4l1 wrapper which adds v4l2 device compatibility to v4l1
applications is called v4l1compat.so. The preloadable libv4l1 wrapper which
adds v4l2 device compatibility to v4l1 applications is called v4l2convert.so

Example usage:
$ export LD_LIBRARY_PATH=`pwd`/lib
$ export LD_PRELOAD=`pwd`/lib/v4l1compat.so
$ camorama


FAQ
---

Q: Why libv4l, whats wrong with directly accessing v4l2 devices ?
Q: Do we really need yet another library ?
A: Current webcam using applications like ekiga contain code to handle many
different specific pixelformats webcam's use, but that code only supports a
small subset of all native webcam (compressed) pixelformats. Other current
v4l2 applications do not support anything but rgb pixelformats (xawtv for
example) and this will not work with most webcams at all.

With gspca being ported to v4l2 and thus decoding to normal formats being
removed from the device driver as this really belongs in userspace, ekiga
would need to be extended with many more often chip dependent formats, like
the bayer compression used by the spca561 and the (different) compression used
by the pac207 and the (again different) compression used by the sn9c102. Adding
support for all these formats should not be done at the application level, as
then it needs to be written for each application seperately. Licensing issues
with the decompressors will then also become a problem as just cut and pasting
from one application to another is bound to hit license incompatibilities.

So clearly this belongs in a library, and in a library with a license which
allows this code to be used from as many different applications as possible.
Hence libv4l was born.

Q: Under which license may I use and distribute libv4l?
A: All libv4l components are licensed under the GNU Library General Publishing
License version 2 or (at your option) any later version. See the included
COPYING.LIB file.

Q: Okay so I get the use of having a libv4lconvert, but why libv4l1 ?
A: Many v4l2 drivers do not offer full v4l1 compatibility. They often do not
implemented the CGMBUF ioctl and v4l1 style mmap call. Adding support to all
these drivers for this is a lot of work and more importantly unnecessary
adds code to kernel space.

Also even if the CGMBUF ioctl and v4l1 style mmap are supported, then most
cams still deliver pixelformats which v4l1 applications do not understand.

This libv4l1 was born as an easy way to get v4l1 applications to work with
v4l2 devices without requiring full v4l1 emulation (including format
conversion) in the kernel, and without requiring major changes to the
applications.


Q: Why should I use libv4l2 in my app instead of direct device access
combined with libv4lconvert?

libv4l2 is mainly meant for quickly and easily adding support for more
pixelformats to existing v4l2 applications. So if you feel better directly
accessing the device in combination with libv4lconvert thats fine too.

Notice that libv4l2 also does emulation of the read() call on devices which
do not support it in the driver. In the background this uses mmap buffers
(even on devices which do support the read call). This mmap gives libv4lconvert
zero-copy access to the captured frame, and then it can write the converted
data directly to the buffer the application provided to v4l2_read(). Thus
another reason to use liv4l2 is to get the no memcpy advantage of the mmap
capture method combined with the simplicity of making a simple read() call.


Regards,

Hans

Hi All,

Do you have a HP multi function printer? And does it have a cardreader? And does it not work when you insert an sdcard, or have you never tried? Then this blogpost is for you!

The story starts quite some time ago, I just never got around to writing about it before. After encountering this bug in RH bugzilla while doing bug triaging. I thought hey, that reminds me the reader in my PSC has troubles too, lets see if I can fix this.

So after 3 long evenings of debugging, I finally have my cardreader working "properly" (what a piece of <beep>).

At first I tried and succeeded with US_FL_FIX_CAPACITY, that worked but gave me warnings that the partition was larger then the device, and read access beyond the end of device errors. But it worked now!

Further debugging has lead me to the following conclusion: The HP PSC 1350 reader will "crash" and from that moment on no longer communicate in any sane way, if you try to read the last sector of an sdcard * in a read that is more then 1 sector, so trying to read 8 sectors starting at sector capacity-8 will crash it, as will reading 2 sectors starting at sector capacity-2, however reading the last sector in a one 1 sector read will succeed! (* xdcards seem to be fine).

With this knowledge I wrote a patch introducing a new unusual device flag, and modifying usb-storage behavior to not cause the crash condition when this flag is said. This was 6 months ago, there was some discussion about my patch on the usb-storage list, but in the form it had then it wasn't accepted and no consensus was reached on in which form it would be acceptable. A few days ago I got a mail from an HP PSC 1610 owner, who had the same problem, found my patch in the mailinglist archive, and it fixed things for him too. So now I'm trying to get some form of fix into the kernel once more.

Which brings me to the reason for writing this blog post, when a fix gets in the kernel it would be nice to have a complete list of usb id's of all HP printers needing this workaround. So if you have such a beast please try feeding it sdcards and if they don't work, try again with my patch. In order to make testing as easy as possible I've prepared an out of tree compilable version of the usb-storage driver. Here are simple testing instructions:

• Download this tarbal
• untar
• make sure you have the kernel-devel package for your currently running kernel installed
• cd usb-storage2
• make
• make sure you do not have any usb storage devices mounted
• sudo rmmod usb-storage
• sudo insmod usb-storage.ko
• insert sdcard
• it should work now

Note the tarbal is for a 2.6.23 kernel, your milage with other kernels may vary.

Everyone with a HP printer with cardreader, please test, your feedback is much appreciated.