Comment 8 for bug 286070

So, I didn't come to upload this SRU due to various distractions and also because libv4l kept rolling stable updates to libv4l handling more and more issues. In particular, last release fixes two quite annoying bugs:
- linux uvcvideo driver issue (this is pending a fix in intrepid's kernel)
- cheese slowness (takes a minute or more to show the webcam's picture because of the way it negociates formats)

The upstream changelog looks like this:
libv4l-0.5.6
------------
* Always do a s_fmt on uvc cams even if this changes nothing, as not doing
  the s_fmt triggers a bug in the uvcvideo driver in kernel <= 2.6.28
  (with certain cams)

libv4l-0.5.5
------------
* Avoid the use of try_fmt as much as possible on UVC cams, instead use the
  results of the enum_framesizes ioctl. This is because:
  1) try_fmt actually causes IO with UVC cams making apps which do lot of
     querrying of device capabilities slow (cheese)
  2) some buggy cams don't like getting lots of UVC video probes and crash
     when they do

libv4l-0.5.4
------------
* Don't report DQBUF errors when errno is EAGAIN, this fixes flooding the
  screen with errors when applications use non blocking mode
* Add support for downscaling to make apps which want low resolutions
  (skype, spcaview) happy when used with cams which can only do high
  resolutions (by Lukáš Karas <email address hidden>).
* Add support for converting to YV12 planar (next to the already supported
  YU12 / I420)
* Implement RGB/BGR24 -> YU/YV12 conversion

libv4l-0.5.3
------------
* When conversion requires multiple passes don't alloc the needed temporary
  buffer on the stack, as some apps (ekiga) use so much stack themselves
  this causes us to run out of stack space

libv4l-0.5.2
------------
* Add Philips SPC210NC to list of cams with upside down sensor, reported by
  Rieker Flaik
* Work around some drivers (pwc) not properly reflecting what one gets after a
  s_fmt in their try_fmt answer
* Check that s_fmt atleast gives us the width, height and pixelformat try_fmt
  promised us, and if not disable conversion
* Only check width, height and pixelformat when checking if we are doing
  conversion, instead of doing a memcmp, as that are the only things which
  the convert code checks
* Take into account that the buffers only contain half of the lines when
  field is V4L2_FIELD_ALTERNATE

libv4l-0.5.1
------------
* Add support for software cropping from 352x288 -> 320x240 / 176x144 ->
  160x120, so that apps which will only work with vga resolutions like
  320x240 (Skype!) will work with cams/drivers which do not support cropping
  CIF resolutions to VGA resolutions in hardware. This makes all 2.6.27 gspca
  supported cams, except for the pac7302 which only does 640x480 (and skype
  wants 320x240), work with skype
* The v4lconvert_convert function was becoming a bit of a mess, so split the
  functionailiy into separate v4lconvert_convert_pixfmt, v4lconvert_rotate and
  v4lconvert_crop functions, and make v4lconvert_convert a frontend to
  these
* Do not link the wrapper libs against libpthread (patch from Gregor Jasny)

In my opinion, these changes are sane, make sense, and are an useful update to intrepid; however they do pile up to a large stack. That said, since we pushed libv4l in quite a hurry before the release and ended up shipping 0.5.0, I think it's really deserved, and it does affect a lot of people; see bug #290506 for another group of affected people (first group being bug #260918).

I'm a happy user of 0.5.6 which is landing in jaunty and Debian sid, tested with cheese and camorama. I've pushed it to my ppa and have asked the above two bugs for some testers. Will attach an updated 0.5.0 -> 0.5.6 upstream diff.