Re: [PATCH 0/11 - v3] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver

[Hans Verkuil]

On Friday 19 June 2009 22:49:07 Kevin Hilman wrote:
 m-kariche...@ti.com writes:
  From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
 
  Big Thanks to all reviewers who have contributed to this driver
  by reviewing and offering valuable comments.
 
  VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446
 
  This is the version v3 of the patch series. This is the reworked
  version of the driver based on comments received against the last
  version (v2) of the patch and is expected to be final version
  candidate for merge to upstream kernel

 FYI...

 I've updated the staging/vpfe branch of davinci git with this series
 and the tvp514x v3 patch.

 Also, I'll be pushing the arch/arm/* patches of this series to DaVinci
 git master and queueing them for upstream merge.

Hi Kevin,

It's better to leave that to Mauro (the v4l-dvb maintainer): that will 
ensure that the v4l driver changes and the arch/arm changes go into the 
mainline in the correct order. If you prefer to do this yourself, then you 
should contact Mauro first.

Also note that my pull request for this driver contains one additional patch 
fixing some missing newlines and a wrong error code.

Here is the link to that diff in my repository:

http://linuxtv.org/hg/%7Ehverkuil/v4l-dvb-vpfe-cap/raw-diff/ae2ca5c20d85/linux/drivers/media/video/davinci/vpfe_capture.c

Regards,

Hans

 Kevin

  +++
  These patches add support for VPFE (Video Processing Front End) based
  video capture on DM355 and DM6446 EVMs. For more details on the
  hardware configuration and capabilities, please refer the
  vpfe_capture.c header. This patch set consists of following:-
 
  Patch 1: VPFE Capture bridge driver
  Patch 2: CCDC hw device header file
  Patch 3: DM355 CCDC hw module
  Patch 4: DM644x CCDC hw module
  Patch 5: ccdc types used across CCDC modules
  Patch 6: Makefile and config files for the driver
  Patch 7: DM355 platform and board setup
  Patch 8: DM644x platform and board setup
  Patch 9: common vpss hw module for video drivers
  Patch 10: Remove outdated driver files from davinci git tree
  Patch 11: Makefile and config files for the davinci git tree (New
  from v2)
 
  NOTE:
 
  1. Patches 10-11 are only for DaVinci GIT tree. Others applies to
  DaVinci GIT and v4l-dvb
 
  2. Dependent on the TVP514x decoder driver patch for migrating the
  driver to sub device model from Vaibhav Hiremath. I am sending the
  reworked version of this patch instead of Vaibhav.
 
  Following tests are performed.
  1) Capture and display video (PAL  NTSC) from tvp5146 decoder.
 Displayed using fbdev device driver available on davinci git tree
  2) Tested with driver built statically and dynamically
 
  Muralidhara Karicheri
 
  Reviewed by: Hans Verkuil hverk...@xs4all.nl
  Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
  Reviewed by: Alexey Klimov klimov.li...@gmail.com
  Reviewed by: Kevin Hilman khil...@deeprootsystems.com
  Reviewed by: David Brownell davi...@pacbell.net
 
  Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
  ___
  Davinci-linux-open-source mailing list
  davinci-linux-open-sou...@linux.davincidsp.com
  http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source

 ___
 Davinci-linux-open-source mailing list
 davinci-linux-open-sou...@linux.davincidsp.com
 http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.

[Manu Abraham]

On Fri, Jun 19, 2009 at 5:55 AM, Yufei Yuanyfy...@gmail.com wrote:
 Not sure how to make it look right in gmail, but the inline patch does
 not look right to my eyes. I have the patch attached behind as a
 backup.

You can attach the patch, no worries.

I have applied the patch, but the CodingStyle is not very nice, mostly
the wrapping to 80 cols is done in a bad way. It makes the code not
easy to read.

Also have made some comments inline from your patch. Please do fix the
mentioned ones against the dvb-apps head




diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
dvb-apps_new/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c   1969-12-31 18:00:00.0 -0600
+++ dvb-apps_new/util/atsc_epg/atsc_epg.c   2009-06-18 20:17:24.527925142 
-0500
@@ -0,0 +1,1249 @@
+/*
+ * atsc_epg utility
+ *
+ * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include stdio.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include time.h
+#include signal.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include sys/ioctl.h
+#include sys/poll.h
+#include errno.h
+#include getopt.h
+#include stdarg.h
+#include libdvbapi/dvbfe.h
+#include libdvbapi/dvbdemux.h
+#include libucsi/dvb/section.h
+#include libucsi/atsc/section.h
+#include libucsi/atsc/types.h
+
+#define TIMEOUT60
+#define RRT_TIMEOUT60
+#define MAX_NUM_EVENT_TABLES   128
+#define TITLE_BUFFER_LEN   4096
+#define MESSAGE_BUFFER_LEN (16 * 1024)
+#define MAX_NUM_CHANNELS   16
+#define MAX_NUM_EVENTS_PER_CHANNEL (4 * 24 * 7)
+
+static int atsc_scan_table(int dmxfd, uint16_t pid, enum atsc_section_tag tag,
+   void **table_section);
+
+static const char *program;
+static int adapter = 0;
+static int period = 12; /* hours */
+static int frequency;
+static int enable_ett = 0;
+static int ctrl_c = 0;
+static const char *modulation = NULL;
+static char separator[80];
+void (*old_handler)(int);
+
+struct atsc_string_buffer {
+   int buf_len;
+   int buf_pos;
+   char *string;
+};
+
+struct atsc_event_info {
+   uint16_t id;
+   struct tm start;
+   struct tm end;
+   int title_pos;
+   int title_len;
+   int msg_pos;
+   int msg_len;
+};
+
+struct atsc_eit_section_info {
+   uint8_t section_num;
+   uint8_t num_events;
+   uint8_t num_etms;
+   uint8_t num_received_etms;
+   struct atsc_event_info **events;
+};
+
+struct atsc_eit_info {
+   int num_eit_sections;
+   struct atsc_eit_section_info *section;
+};
+
+struct atsc_channel_info {
+   uint8_t num_eits;
+   uint8_t service_type;
+   char short_name[8];
+   uint16_t major_num;
+   uint16_t minor_num;
+   uint16_t tsid;
+   uint16_t prog_num;
+   uint16_t src_id;
+   struct atsc_eit_info *eit;
+   struct atsc_event_info *last_event;
+   int event_info_index;
+   struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
+   struct atsc_string_buffer title_buf;
+   struct atsc_string_buffer msg_buf;
+};
+
+struct atsc_virtual_channels_info {
+   int num_channels;
+   uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
+   uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
+   struct atsc_channel_info ch[MAX_NUM_CHANNELS];
+} guide;
+
+struct mgt_table_name {
+   uint16_t range;
+   const char *string;
+};
+
+struct mgt_table_name mgt_tab_name_array[] = {
+   {0x, terrestrial VCT with current_next_indictor=1},
+   {0x0001, terrestrial VCT with current_next_indictor=0},
+   {0x0002, cable VCT with current_next_indictor=1},
+   {0x0003, cable VCT with current_next_indictor=0},
+   {0x0004, channel ETT},
+   {0x0005, DCCSCT},
+   {0x00FF, reserved for future ATSC use},
+   {0x017F, EIT},
+   {0x01FF, reserved for future ATSC use},
+   {0x027F, event ETT},
+   {0x02FF, reserved for future ATSC use}, /* FIXME */
+   {0x03FF, RRT with rating region},
+   {0x0FFF, user private},
+   {0x13FF, reserved for future ATSC use},
+   {0x14FF, DCCT with dcc_id},
+   {0x, reserved for future ATSC use}
+};
+
+const char *channel_modulation_mode[] = {
+   ,
+   analog,
+   SCTE mode 1,
+   

Re: ivtv Radio Data System (RDS) - is there something planned/already available

[wk]

Hans Verkuil schrieb:

On Friday 19 June 2009 13:36:49 wk wrote:
  

Is there anything planned/ongoing to support Radio Data System (RDS)
with ivtv supported cards?
Would be quite helpful for analogue radio channel scanning and finding
the matching channel names.
Is there something out to be tested?



As far as I know there are no ivtv-based cards with RDS functionality. 


Ok, if the hardware doesnt support it, further questions are meaningless..

thanks,
Winfried
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ivtv Radio Data System (RDS) - is there something planned/already available

[wk]

Edouard Lafargue wrote:

On Fri, Jun 19, 2009 at 1:43 PM, Hans Verkuilhverk...@xs4all.nl wrote:
  

On Friday 19 June 2009 13:36:49 wk wrote:


Is there anything planned/ongoing to support Radio Data System (RDS)
with ivtv supported cards?
Would be quite helpful for analogue radio channel scanning and finding
the matching channel names.
Is there something out to be tested?
  

As far as I know there are no ivtv-based cards with RDS functionality. If
you have one that can do RDS under Windows, then please let me know and I
can take a look.



  A workaround can be to use a 10$ USB radio with RDS support and use
it as a secondary (silent) tuner for doing the scanning operations in
the background, so that you can have a fully up to date radio stations
list all the time without impacting the listening of your main radio
tuner - works very well!

  
Well, the idea was to integrate this into a channel scanning tool. So 
this wouldnt be an option.


Winfried
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3 ISP and camera drivers (update 2)

[Dongsoo, Nathaniel Kim]

Hello Sakari,

2009/6/19 Sakari Ailus sakari.ai...@maxwell.research.nokia.com:
 Hi,

 I've again updated the patchset in Gitorious after a long break. It's
 here. The base is fairly recent linux-omap (May) but I wouldn't expect
 problems in rebasing on top of newer updates either.

 URL:http://www.gitorious.org/projects/omap3camera

 The amount of changes is more or less huge but I'll try to summarise
 them. The base branch is no longer needed, the patch has been integrated
 to linux-omap. The v4l2_subdev transition hasn't begun yet, however.

 - Many ISP subdrivers have been rewritten or refactored. The new code
 should be easier to understand.

 - VIDIOC_TRY_FMT has no longer have side effects except perhaps to the
 resizer. This is being worked on.

 - Crop has been mostly rewritten.

 - Locking has been corrected, although probably not definitely fixed.

 - A separate ispstat module for handling the H3A, AF and HIST statistics.
 H3A and AF are using it already.

 - Lots of redundant code has been removed.

 - Most busy-locked register are should be no longer updated when
 corresponding modules are busy. There are still some cases this is
 happening, though.

 - Configuration of the modules in the interrupt handler is done so that the
 module is disabled first or used in oneshot mode.

 - Lots of things I can't remember now. The individual changes can be seen in
 the omap3isp and omap34xxcam branches. The branches just contain the patches
 in order so git diff doesn't help, unfortunately.

 I won't be available for questions for a month or so (holidays). In the
 meantime you can contact Tuukka Toivonen, David Cohen and Sergio Aguirre for
 questions.

 --
 Sakari Ailus
 sakari.ai...@maxwell.research.nokia.com




By the way, it's quite tough doing a code review without a patch
in-lined with e-mail.
Anyway, I took a quick look at the gitorious repository and found
something strange.
Following patch.
http://www.gitorious.org/omap3camera/mainline/commit/d92c96406296310a977b00f45b209523929b15b5
What happens to the capability when the int device is dummy? (does it
mean that there is no int device?)

And the most thing that makes me cautious to review the patch is all
about v4l2 subdev thing. Because most device drivers in V4L2
repository already got started moving to subdev framework.

And one more thing. If I want to test how the ISP driver is working,
is there any target board that I can buy also a sensor device already
attached on it? If anybody knows that, please let me know.
Cheers,

Nate




-- 
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media  Communications RD Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
  dongsoo45@samsung.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PULL request - http://linuxtv.org/hg/~hgoede/gspca

[Mauro Carvalho Chehab]

Jean-Francois 
Moine 
escreveu:

On Thu, 18 Jun 2009 19:44:05 +0200
Hans de Goede hdego...@redhat.com wrote:


I've rebased my tree on your latest and fixed the coding style issues,
so please pull from:
http://linuxtv.org/hg/~hgoede/gspca

For:
-ov511(+) support
-st6422 support
-ov519/ov518 fixes
-sonixj 0c45:613e support
-sonixj fixes
-mark v4l1 ov511 driver deprecated
-mark v4l1 quickcam_messenger driver deprecated


Hi Mauro,

The most important change is the one which fixes the NULL pointer
dereference in query_ctrl (changeset 56e0ab00180f). As the bug will
generate oops, it must be applied to the new 2.6.31 GIT repository.


Should 
it 
be 
backported 
to 
older 
kernels 
as 
well? 
If 
so, 
for 
what 
kernels?


Thanks.



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PULL request - http://linuxtv.org/hg/~hgoede/gspca

[Mauro Carvalho Chehab]

Em Wed, 17 Jun 2009 23:54:40 +0200
Hans de Goede hdego...@redhat.com escreveu:

  Support for the st6422 bridge + sensor !
 Give it a try, I know now you have a cam which uses this bridge :)
 When you try it be sure to use the latest (just updated my
 libv4l tree) libv4l, this enables (software) automatic control of
 the gain and exposure, for a decent image in most lighting
 conditions.

Didn't work :( See the logs bellow. 

$ export LD_PRELOAD=/usr/local/lib/libv4l/v4l1compat.so
$ mplayer /dev/video0
MPlayer dev-SVN-r27514-4.1.2 (C) 2000-2008 MPlayer Team
CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (Family: 6, Model: 23, 
Stepping: 6)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.

Playing /dev/video0.
libv4l2: error turning on stream: Input/output error
libv4l2: error dequeuing buf: Invalid argument
...

$ dmesg
STV06xx: Probing for a stv06xx device
gspca: probing 046d:08f6
usbcore: registered new interface driver STV06xx
STV06xx: registered
gspca: usb_submit_urb [0] err -28
gspca: no transfer endpoint found

PS.: I tried also to use the mmap() mode, but mplayer fails complaining about
the video format, like if libv4l were not properly working.

This is the full logs of my mplayer using tv:// (rpmfusion version of
mplayer-1.0-0.101.20080903svn.el5.1, on a RHEL5.3).

$ mplayer tv://
MPlayer dev-SVN-r27514-4.1.2 (C) 2000-2008 MPlayer Team
CPU: Intel(R) Xeon(R) CPU   E5420  @ 2.50GHz (Family: 6, Model: 23, 
Stepping: 6)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.

Playing tv://.
TV file format detected.
Selected driver: v4l2
 name: Video 4 Linux 2 input
 author: Martin Olschewski olschew...@zpr.uni-koeln.de
 comment: first try, more to come ;-)
Selected device: Camera
 Capabilites:  video capture  read/write  streaming
 supported norms:
 inputs: 0 = STV06xx;
 Current input: 0
 Current format: RGB24
tv.c: norm_from_string(PAL-M): Bogus norm parameter, setting default.
v4l2: ioctl enum norm failed: Invalid argument
Error: Cannot set norm!
Selected input hasn't got a tuner!
v4l2: Cannot get fps
v4l2: ioctl set mute failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
v4l2: ioctl query control failed: Invalid argument
[VO_SDL] Using driver: x11.
Opening video filter: [pp=lb]
Opening video filter: [crop w=628 h=470 x=6 y=10]
Crop: 628 x 470, 6 ; 10
==
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12)
[PP] Using external postprocessing filter, max q = 6.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
[CROP] Bad position/width/height - cropped area outside of the original!
FATAL: Cannot initialize video driver.
VDecoder init failed :(
Cannot find codec matching selected -vo and video format 0x32315659.
Read DOCS/HTML/en/codecs.html!
==

v4l2: ioctl set mute failed: Invalid argument
v4l2: 0 frames successfully processed, 0 frames dropped.

Exiting... (End of file)



Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

[Hans Verkuil]

Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc for the 
following:

- ivtv/cx18: fix regression: class controls are no longer seen
- v4l2-ctl: add modulator get/set options.
- v4l2-spec: update VIDIOC_G/S_MODULATOR section.
- compat: fix __fls check for the arm architecture.
- smscoreapi: fix compile warning
- v4l2-i2c-drv.h: add comment describing when not to use this header.
- radio-tea5764: fix incorrect rxsubchans value
- v4l2-spec: add missing documentation for the OV518 pixel format.
- tcm825x: remove incorrect __exit_p wrapper
- cx231xx: fix uninitialized variable.

This replaces my previous v4l-dvb-misc pull request. The 
video_register_device patch in that older pull request is no longer present 
in this tree (instead I've posted a separate review request for that 
yesterday). I did add a few other trivial patches.

Note that the first patch is a high prio bug as it is a 2.6.30 regression. 
Mike, once this is merged in the git tree this one can be queued for the 
2.6.30 stable series.

Thanks,

Hans

diffstat:
 linux/drivers/media/dvb/siano/smscoreapi.c |4 -
 linux/drivers/media/radio/radio-tea5764.c  |4 -
 linux/drivers/media/video/cx18/cx18-controls.c |2
 linux/drivers/media/video/cx231xx/cx231xx-avcore.c |2
 linux/drivers/media/video/cx2341x.c|2
 linux/drivers/media/video/ivtv/ivtv-controls.c |2
 linux/drivers/media/video/tcm825x.c|4 -
 linux/include/media/v4l2-i2c-drv.h |5 +
 v4l/compat.h   |3
 v4l2-apps/util/v4l2-ctl.cpp|   78 
+
 v4l2-spec/pixfmt.sgml  |5 +
 v4l2-spec/vidioc-g-modulator.sgml  |   13 +--
 12 files changed, 110 insertions(+), 14 deletions(-)

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds

[Hans Verkuil]

Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-rds for the 
following:

- v4l2: add RDS API to videodev2.h
- v4l2-spec: finalize the RDS specification.
- bttv: set RDS capability if applicable.
- saa6588: conform to the final RDS spec.
- saa7134: set RDS capability if applicable.
- radio-cadet: conform to the RDS spec.
- radio-si470x: conform to the RDS spec.
- v4l2-ctl: update to the latest RDS spec.

This finalizes the RDS decoder specification. The only difference compared 
to my original RFC (1) is that I dropped the MMBS (or 'E block') support. 
As far as I can tell this service is discontinued in the US. I've added a 
note in the spec that if anyone needs this they should contact the list.

Thanks,

Hans

(1) http://www.mail-archive.com/linux-media%40vger.kernel.org/msg02498.html

diffstat:
 linux/drivers/media/radio/radio-cadet.c   |6
 linux/drivers/media/radio/radio-si470x.c  |9 -
 linux/drivers/media/video/bt8xx/bttv-driver.c |2
 linux/drivers/media/video/saa6588.c   |   60 ++-
 linux/drivers/media/video/saa7134/saa7134-core.c  |4
 linux/drivers/media/video/saa7134/saa7134-video.c |2
 linux/drivers/media/video/saa7134/saa7134.h   |1
 linux/include/linux/videodev2.h   |   23 ++
 v4l2-apps/util/v4l2-ctl.cpp   |4
 v4l2-spec/biblio.sgml |   53 +-
 v4l2-spec/compat.sgml |   14 +
 v4l2-spec/dev-rds.sgml|  170 
++
 v4l2-spec/v4l2.sgml   |7
 v4l2-spec/vidioc-g-tuner.sgml |   17 +-
 v4l2-spec/vidioc-querycap.sgml|2
 15 files changed, 280 insertions(+), 94 deletions(-)

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RFC: FM modulator and RDS encoder V4L2 API additions

[Hans Verkuil]

Hi all,

Besides the new RDS controls implemented by Eduardo we also need a few 
additions to the V4L2 API.

First of all we need two new capabilities for struct v4l2_capability:

#define V4L2_CAP_RDS_OUTPUT 0x800 /* Is an RDS encoder */
#define V4L2_CAP_MODULATOR  0x0008000 /* has a modulator */

The current V4L2 spec says in section 1.6.2 that you should set 
V4L2_CAP_TUNER when you have a modulator. I see absolutely no reason why we 
shouldn't add a proper CAP_MODULATOR instead. Almost all caps already come 
in an input and output variant, so it also makes sense to have a tuner and 
a separate modulator capability. Since Eduardo's FM transmitter is the 
first driver with a modulator that will go into the tree we do not have to 
worry about backwards compatibility, so I think we should fix this weird 
rule.

For the same reason we should add an RDS_OUTPUT capability since not all FM 
transmitters might have a RDS encoder. Again, this is also consistent with 
the V4L2_CAP_RDS_CAPTURE capability that we already have.

The RDS decoder API adds a new v4l2_tuner RDS capability and RDS subchannel 
flag. These are reused in v4l2_modulator. If the RDS capability is set, 
then the modulator can encode RDS. If the V4L2_TUNER_SUB_RDS channel is 
specified in txsubchans, then the transmitter will turn on the RDS encoder, 
otherwise it is turned off. This is consistent with the way txsubchans is 
used for the audio modulation.

Eduardo, this will replace the RDS_TX_ENABLED control, so if this goes in 
then that control has to be removed.

I've made a first implementation of these changes in this tree: 
http://linuxtv.org/hg/~hverkuil/v4l-dvb-rds-enc

This tree also contains the RDS decoder changes from my v4l-dvb-rds tree 
since it needs to build on those.

Comments?

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2

[Hans Verkuil]

On Tuesday 09 June 2009 22:40:35 Hans Verkuil wrote:
 Hi Mauro,

 Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-subdev2 for
 the following:

 - v4l2: add new s_config subdev ops and v4l2_i2c_new_subdev_cfg/board
 calls - v4l2-device: fix incorrect kernel check
 - v4l-compat: add I2C_ADDRS macro.
 - v4l2: update framework documentation.
 - v4l2-subdev: remove unnecessary check

 This time I've only added new functions and left the existing ones in
 place. I did add a bit of code to the existing
 v4l2_i2c_new_(probed_)subdev functions to call the new s_config op if it
 is available. Existing subdev drivers never set this new op, so this code
 will not effect current behavior. But for new drivers that do set
 s_config it is important that it is called no matter what flavor of these
 functions is used.

 At the end of the 2.6.31 cycle we can replace the current
 v4l2_i2c_new_(probed_)subdev calls with the new one I had in my earlier
 patches.

Hi Mauro,

I've posted these changes as an RFC more than a week ago, but since there 
were no comments I hope you can pull from this tree for 2.6.31.

I would really, really like to get this into 2.6.31. It will help anyone who 
is working with subdevs on embedded platforms.

Regards,

Hans


 Thanks,

 Hans

 diffstat:
  linux/Documentation/video4linux/v4l2-framework.txt |   24 +++
  linux/drivers/media/video/v4l2-common.c|  166
 +
  linux/drivers/media/video/v4l2-device.c|2
  linux/include/media/v4l2-common.h  |   18 ++
  linux/include/media/v4l2-subdev.h  |9 -
  v4l/compat.h   |6
  6 files changed, 222 insertions(+), 3 deletions(-)



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv8 7/9] FMTx: si4713: Add files to handle si4713 i2c device

[Hans Verkuil]

On Thursday 18 June 2009 15:55:49 Eduardo Valentin wrote:
 This patch adds files to control si4713 devices.
 Internal functions to control device properties
 and initialization procedures are into these files.
 Also, a v4l2 subdev interface is also exported.
 This way other drivers can use this as v4l2 i2c subdevice.

 Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
 ---
  linux/drivers/media/radio/si4713-i2c.c | 2015
  linux/drivers/media/radio/si4713-i2c.h |
  226 
  linux/include/media/si4713.h   |   40 +
  3 files changed, 2281 insertions(+), 0 deletions(-)
  create mode 100644 linux/drivers/media/radio/si4713-i2c.c
  create mode 100644 linux/drivers/media/radio/si4713-i2c.h
  create mode 100644 linux/include/media/si4713.h


snip

 diff --git a/linux/include/media/si4713.h b/linux/include/media/si4713.h
 new file mode 100644
 index 000..d0960e2
 --- /dev/null
 +++ b/linux/include/media/si4713.h
 @@ -0,0 +1,40 @@
 +/*
 + * include/media/si4713.h
 + *
 + * Board related data definitions for Si4713 i2c device driver.
 + *
 + * Copyright (c) 2009 Nokia Corporation
 + * Contact: Eduardo Valentin eduardo.valen...@nokia.com
 + *
 + * This file is licensed under the terms of the GNU General Public
 License + * version 2. This program is licensed as is without any
 warranty of any + * kind, whether express or implied.
 + *
 + */
 +
 +#ifndef SI4713_H
 +#define SI4713_H
 +
 +/* The SI4713 I2C sensor chip has a fixed slave address of 0xc6 or 0x22.
 */ +#define SI4713_I2C_ADDR_BUSEN_HIGH0x63
 +#define SI4713_I2C_ADDR_BUSEN_LOW0x11
 +
 +/*
 + * Platform dependent definition
 + */
 +struct si4713_platform_data {
 + /* Set power state, zero is off, non-zero is on. */
 + int (*set_power)(int power);
 +};
 +
 +/*
 + * structure to query for RSSI.
 + */
 +struct si4713_rssi {
 + unsigned int frequency;
 + int rssi;
 +};

I propose to change this struct a bit:

struct si4713_rssi {
__u32 index;/* modulator index */
__u32 frequency;/* frequency */
__s32 rssi; /* result */
__u32 reserved[4];  /* drivers and apps must init this to 0 */
};

The idea is that in the future this might become a regular ioctl and in that 
case it would be nice if we can just copy this struct to videodev2.h and 
rename it. In that case the si4713 has to support both private and public 
ioctls, but since the struct pointer passed to ioctl is the same for the 
private and public ioctls it is very easy to implement that.

The rssi field needs to be documented better in this header: what is the 
meaning of the returned value and what is the unit? Does it have to be a 
signed value, or should it be unsigned instead?

 +#define SI4713_IO_MEASURE_RSSI   _IOWR('V', BASE_VIDIOC_PRIVATE + 0, \
 + struct si4713_rssi)

This needs to be documented as well: what exactly does it do? It is 
important to have that information in this header for future reference.

Can you also rename it to SI4713_IOC_MEASURE_RSSI? 'IOC' seems to be 
preferred above 'IO'.

Regards,

Hans

 +
 +#endif /* ifndef SI4713_H*/



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-dvb] Support for Compro VideoMate S350

[Igor M. Liplianin]

On 20 June 2009 04:45:49 OM Ugarcina wrote:
 Hello Guys,

 I have one of these paper weights - that is a S350 , it has been
 sitting on the shelf for the past 2 years . And I would really like to
 use it . We have a driver for it here :
 http://article.gmane.org/gmane.linux.drivers.dvb/38163  . Please what
 needs to be done to get this driver merged into the tree ? C'mon guys
 lets get this one in .

 Best Regards
 Milorad
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patches (hg export) against recent linuxtv tree.
Feel free to test.
It includes TeVii S630 as well, which already tested by me.
As for Compro, I have report about successfully working one.

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
# HG changeset patch
# User Igor M. Liplianin liplia...@me.by
# Date 1245502308 -10800
# Node ID 9da94d6ff07d13481c15c756c4802eb15d923d16
# Parent  2899ad868fc69dd57310f1833fb67155060b06f0
Add ce5039(zl10039) tuner support.

From: Igor M. Liplianin liplia...@me.by

The code from Jan D. Louw with some minor changes.
http://article.gmane.org/gmane.linux.drivers.dvb/38163
Tested with TeVii S630 DVB-S USB card by me (Igor)

Signed-off-by: Igor M. Liplianin liplia...@me.by

diff -r 2899ad868fc6 -r 9da94d6ff07d linux/drivers/media/dvb/frontends/Kconfig
--- a/linux/drivers/media/dvb/frontends/Kconfig	Thu Jun 18 19:31:36 2009 +0200
+++ b/linux/drivers/media/dvb/frontends/Kconfig	Sat Jun 20 15:51:48 2009 +0300
@@ -81,6 +81,13 @@
 	help
 	  A DVB-S tuner module. Say Y when you want to support this frontend.
 
+config DVB_ZL10039
+	tristate Zarlink ZL10039 silicon tuner
+	depends on DVB_CORE  I2C
+	default m if DVB_FE_CUSTOMISE
+	help
+	  A DVB-S tuner module. Say Y when you want to support this frontend.
+
 config DVB_S5H1420
 	tristate Samsung S5H1420 based
 	depends on DVB_CORE  I2C
diff -r 2899ad868fc6 -r 9da94d6ff07d linux/drivers/media/dvb/frontends/Makefile
--- a/linux/drivers/media/dvb/frontends/Makefile	Thu Jun 18 19:31:36 2009 +0200
+++ b/linux/drivers/media/dvb/frontends/Makefile	Sat Jun 20 15:51:48 2009 +0300
@@ -31,6 +31,7 @@
 obj-$(CONFIG_DVB_NXT6000) += nxt6000.o
 obj-$(CONFIG_DVB_MT352) += mt352.o
 obj-$(CONFIG_DVB_ZL10036) += zl10036.o
+obj-$(CONFIG_DVB_ZL10039) += zl10039.o
 obj-$(CONFIG_DVB_ZL10353) += zl10353.o
 obj-$(CONFIG_DVB_CX22702) += cx22702.o
 obj-$(CONFIG_DVB_DRX397XD) += drx397xD.o
diff -r 2899ad868fc6 -r 9da94d6ff07d linux/drivers/media/dvb/frontends/zl10039.c
--- /dev/null	Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/frontends/zl10039.c	Sat Jun 20 15:51:48 2009 +0300
@@ -0,0 +1,308 @@
+/*
+ *  Driver for Zarlink ZL10039 DVB-S tuner
+ *
+ *  Copyright 2007 Jan D. Louw jd.l...@mweb.co.za
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/string.h
+#include linux/slab.h
+#include linux/dvb/frontend.h
+
+#include dvb_frontend.h
+#include zl10039.h
+
+static int debug;
+
+#define dprintk(args...) \
+	do { \
+		if (debug) \
+			printk(KERN_DEBUG args); \
+	} while (0)
+
+enum zl10039_model_id {
+	ID_ZL10039 = 1
+};
+
+struct zl10039_state {
+	struct i2c_adapter *i2c;
+	u8 i2c_addr;
+	u8 id;
+};
+
+enum zl10039_reg_addr {
+	PLL0 = 0,
+	PLL1,
+	PLL2,
+	PLL3,
+	RFFE,
+	BASE0,
+	BASE1,
+	BASE2,
+	LO0,
+	LO1,
+	LO2,
+	LO3,
+	LO4,
+	LO5,
+	LO6,
+	GENERAL
+};
+
+static int zl10039_read(const struct zl10039_state *state,
+			const enum zl10039_reg_addr reg, u8 *buf,
+			const size_t count)
+{
+	u8 regbuf[] = { reg };
+	struct i2c_msg msg[] = {
+		{/* Write register address */
+			.addr = state-i2c_addr,
+			.flags = 0,
+			.buf = regbuf,
+			.len = 1,
+		}, {/* Read count bytes */
+			.addr = state-i2c_addr,
+			.flags = I2C_M_RD,
+			.buf = buf,
+			.len = count,
+		},
+	};
+
+	dprintk(%s\n, __func__);
+
+	if (i2c_transfer(state-i2c, msg, 2) != 2) {
+		dprintk(%s: i2c read error\n, __func__);
+		return -EREMOTEIO;
+	}
+
+	return 0; /* Success */
+}
+
+static int zl10039_write(struct zl10039_state *state,
+			const enum zl10039_reg_addr reg, const u8 *src,
+			const size_t count)
+{
+	u8 buf[count + 1];
+	struct i2c_msg msg = {
+		.addr = state-i2c_addr,
+		.flags 

Re: [Patch] New utility program atsc_epg added to dvb-apps utility suite.

[Yufei Yuan]

Thanks for the feedback. Will fix the coding style, and send in a new one 
against the tip.

Regards,

On Sat, 2009-06-20 at 11:30 +0400, Manu Abraham wrote:
 On Fri, Jun 19, 2009 at 5:55 AM, Yufei Yuanyfy...@gmail.com wrote:
  Not sure how to make it look right in gmail, but the inline patch does
  not look right to my eyes. I have the patch attached behind as a
  backup.
 
 You can attach the patch, no worries.
 
 I have applied the patch, but the CodingStyle is not very nice, mostly
 the wrapping to 80 cols is done in a bad way. It makes the code not
 easy to read.
 
 Also have made some comments inline from your patch. Please do fix the
 mentioned ones against the dvb-apps head
 
 
 
 
 diff -uprN dvb-apps/util/atsc_epg/atsc_epg.c
 dvb-apps_new/util/atsc_epg/atsc_epg.c
 --- dvb-apps/util/atsc_epg/atsc_epg.c 1969-12-31 18:00:00.0 -0600
 +++ dvb-apps_new/util/atsc_epg/atsc_epg.c 2009-06-18 20:17:24.527925142 
 -0500
 @@ -0,0 +1,1249 @@
 +/*
 + * atsc_epg utility
 + *
 + * Copyright (C) 2009 Yufei Yuan yfy...@gmail.com
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + *
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 + */
 +
 +#include stdio.h
 +#include stdlib.h
 +#include unistd.h
 +#include string.h
 +#include time.h
 +#include signal.h
 +#include sys/types.h
 +#include sys/stat.h
 +#include fcntl.h
 +#include sys/ioctl.h
 +#include sys/poll.h
 +#include errno.h
 +#include getopt.h
 +#include stdarg.h
 +#include libdvbapi/dvbfe.h
 +#include libdvbapi/dvbdemux.h
 +#include libucsi/dvb/section.h
 +#include libucsi/atsc/section.h
 +#include libucsi/atsc/types.h
 +
 +#define TIMEOUT  60
 +#define RRT_TIMEOUT  60
 +#define MAX_NUM_EVENT_TABLES 128
 +#define TITLE_BUFFER_LEN 4096
 +#define MESSAGE_BUFFER_LEN   (16 * 1024)
 +#define MAX_NUM_CHANNELS 16
 +#define MAX_NUM_EVENTS_PER_CHANNEL   (4 * 24 * 7)
 +
 +static int atsc_scan_table(int dmxfd, uint16_t pid, enum atsc_section_tag 
 tag,
 + void **table_section);
 +
 +static const char *program;
 +static int adapter = 0;
 +static int period = 12; /* hours */
 +static int frequency;
 +static int enable_ett = 0;
 +static int ctrl_c = 0;
 +static const char *modulation = NULL;
 +static char separator[80];
 +void (*old_handler)(int);
 +
 +struct atsc_string_buffer {
 + int buf_len;
 + int buf_pos;
 + char *string;
 +};
 +
 +struct atsc_event_info {
 + uint16_t id;
 + struct tm start;
 + struct tm end;
 + int title_pos;
 + int title_len;
 + int msg_pos;
 + int msg_len;
 +};
 +
 +struct atsc_eit_section_info {
 + uint8_t section_num;
 + uint8_t num_events;
 + uint8_t num_etms;
 + uint8_t num_received_etms;
 + struct atsc_event_info **events;
 +};
 +
 +struct atsc_eit_info {
 + int num_eit_sections;
 + struct atsc_eit_section_info *section;
 +};
 +
 +struct atsc_channel_info {
 + uint8_t num_eits;
 + uint8_t service_type;
 + char short_name[8];
 + uint16_t major_num;
 + uint16_t minor_num;
 + uint16_t tsid;
 + uint16_t prog_num;
 + uint16_t src_id;
 + struct atsc_eit_info *eit;
 + struct atsc_event_info *last_event;
 + int event_info_index;
 + struct atsc_event_info e[MAX_NUM_EVENTS_PER_CHANNEL];
 + struct atsc_string_buffer title_buf;
 + struct atsc_string_buffer msg_buf;
 +};
 +
 +struct atsc_virtual_channels_info {
 + int num_channels;
 + uint16_t eit_pid[MAX_NUM_EVENT_TABLES];
 + uint16_t ett_pid[MAX_NUM_EVENT_TABLES];
 + struct atsc_channel_info ch[MAX_NUM_CHANNELS];
 +} guide;
 +
 +struct mgt_table_name {
 + uint16_t range;
 + const char *string;
 +};
 +
 +struct mgt_table_name mgt_tab_name_array[] = {
 + {0x, terrestrial VCT with current_next_indictor=1},
 + {0x0001, terrestrial VCT with current_next_indictor=0},
 + {0x0002, cable VCT with current_next_indictor=1},
 + {0x0003, cable VCT with current_next_indictor=0},
 + {0x0004, channel ETT},
 + {0x0005, DCCSCT},
 + {0x00FF, reserved for future ATSC use},
 + {0x017F, EIT},
 + {0x01FF, reserved for future ATSC use},
 + {0x027F, event ETT},
 + {0x02FF, reserved for future ATSC use}, /* FIXME */
 + {0x03FF, RRT with rating region},
 + {0x0FFF, user private},
 + {0x13FF, reserved for future 

Re: RFC: FM modulator and RDS encoder V4L2 API additions

[Eduardo Valentin]

Hi Hans,

On Sat, Jun 20, 2009 at 03:05:24PM +0200, ext Hans Verkuil wrote:
 Hi all,
 
 Besides the new RDS controls implemented by Eduardo we also need a few 
 additions to the V4L2 API.
 
 First of all we need two new capabilities for struct v4l2_capability:
 
 #define V4L2_CAP_RDS_OUTPUT 0x800 /* Is an RDS encoder */
 #define V4L2_CAP_MODULATOR0x0008000 /* has a modulator */
 
 The current V4L2 spec says in section 1.6.2 that you should set 
 V4L2_CAP_TUNER when you have a modulator. I see absolutely no reason why we 
 shouldn't add a proper CAP_MODULATOR instead. Almost all caps already come 
 in an input and output variant, so it also makes sense to have a tuner and 
 a separate modulator capability. Since Eduardo's FM transmitter is the 
 first driver with a modulator that will go into the tree we do not have to 
 worry about backwards compatibility, so I think we should fix this weird 
 rule.
 
 For the same reason we should add an RDS_OUTPUT capability since not all FM 
 transmitters might have a RDS encoder. Again, this is also consistent with 
 the V4L2_CAP_RDS_CAPTURE capability that we already have.
 
 The RDS decoder API adds a new v4l2_tuner RDS capability and RDS subchannel 
 flag. These are reused in v4l2_modulator. If the RDS capability is set, 
 then the modulator can encode RDS. If the V4L2_TUNER_SUB_RDS channel is 
 specified in txsubchans, then the transmitter will turn on the RDS encoder, 
 otherwise it is turned off. This is consistent with the way txsubchans is 
 used for the audio modulation.
 
 Eduardo, this will replace the RDS_TX_ENABLED control, so if this goes in 
 then that control has to be removed.

I like this approach. Looks cleaner. How about moving some of the *_ENABLED 
features
from FM TX class to a CAP flag? As you are proposing for RDS? I mean, some of 
them
are consistent with audio modulation (copying from my patch):

+#define V4L2_CID_RDS_TX_ENABLED
(V4L2_CID_FM_TX_CLASS_BASE + 1)

This one you are already proposing to move to a CAP flag.

+#define V4L2_CID_AUDIO_LIMITER_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 6)
This is relevant to modulators which apply some sort of dynamic audio control to
maximize audio volume and minimize receiver-generated distortion. Also important
to prevent audio over-modulation.

+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 9)
Enables or disables the audio compression feature.
This feature amplifies signals below the threshold by a fixed gain and 
compresses audio
signals above the threshold by the ratio of Threshold/(Gain + Threshold).

+
+#define V4L2_CID_PILOT_TONE_ENABLED(V4L2_CID_FM_TX_CLASS_BASE + 14)
Some modulator generates pilot tone in audio channel.

I mean, what do you think to have those as a flag in txsubchans instead of
a separated ext control ?

 
 I've made a first implementation of these changes in this tree: 
 http://linuxtv.org/hg/~hverkuil/v4l-dvb-rds-enc
 
 This tree also contains the RDS decoder changes from my v4l-dvb-rds tree 
 since it needs to build on those.
 
 Comments?
 
 Regards,
 
   Hans
 
 -- 
 Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

-- 
Eduardo Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc

[Trent Piepho]

On Sat, 20 Jun 2009, Hans Verkuil wrote:
 - compat: fix __fls check for the arm architecture.

This one isn't quite right.  The __fls defined for arm in 2.6.27 (between
v2.6.26-7260-g0c65f45 and v2.6.28-rc6-187-g94fc733) isn't the same as the
__fls() used everwhere else in the kernel.  This alternate fix should
work.

01/01: compat: Fix __fls for certain ARM kernels
http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=518b7754cd3d
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch] dvb-apps: code cleanup and bug fix.

[Yufei Yuan]

This patch is against dvb-apps 1281. Following is what has been done:

1. atsc_epg bug fix: when ETM message gets longer than 256 characters, the last
character was chopped, due to incorrect calling to snprintf().
2. atsc_epg code cleanup:
  - white space added after keywords;
  - hard wrap around column 80 removed;
  - one-line conditional statement now w/o brackets.
3. scan Makefile workaround for building in gcc4.4/kernel 2.6.30 was not picked 
up in 1279, include again.

Regards,

Signed-off-by: Yufei Yuan yfy...@gmail.com

diff -upr dvb-apps/util/atsc_epg/atsc_epg.c 
dvb-apps_local/util/atsc_epg/atsc_epg.c
--- dvb-apps/util/atsc_epg/atsc_epg.c   2009-06-20 11:54:20.393986790 -0500
+++ dvb-apps_local/util/atsc_epg/atsc_epg.c 2009-06-20 12:09:08.0 
-0500
@@ -168,9 +168,8 @@ void *(*table_callback[16])(struct atsc_
 
 static void int_handler(int sig_num)
 {
-   if(SIGINT != sig_num) {
+   if (SIGINT != sig_num)
return;
-   }
ctrl_c = 1;
 }
 
@@ -219,8 +218,9 @@ static void help(void)
 
 static int close_frontend(struct dvbfe_handle *fe)
 {
-   if(NULL == fe) {
+   if (NULL == fe) {
fprintf(stderr, %s(): NULL pointer detected\n, __FUNCTION__);
+   return -1;
}
 
dvbfe_close(fe);
@@ -232,22 +232,20 @@ static int open_frontend(struct dvbfe_ha
 {
struct dvbfe_info fe_info;
 
-   if(NULL == (*fe = dvbfe_open(adapter, 0, 0))) {
-   fprintf(stderr, %s(): error calling dvbfe_open()\n,
-   __FUNCTION__);
+   if (NULL == (*fe = dvbfe_open(adapter, 0, 0))) {
+   fprintf(stderr, %s(): error calling dvbfe_open()\n, 
__FUNCTION__);
return -1;
}
dvbfe_get_info(*fe, 0, fe_info, DVBFE_INFO_QUERYTYPE_IMMEDIATE, 0);
-   if(DVBFE_TYPE_ATSC != fe_info.type) {
-   fprintf(stderr, %s(): only ATSC frontend supported 
currently\n,
-   __FUNCTION__);
+   if (DVBFE_TYPE_ATSC != fe_info.type) {
+   fprintf(stderr, %s(): only ATSC frontend supported 
currently\n, __FUNCTION__);
return -1;
}
fe_info.feparams.frequency = frequency;
fe_info.feparams.inversion = DVBFE_INVERSION_AUTO;
fe_info.feparams.u.atsc.modulation = DVBFE_ATSC_MOD_VSB_8;
fprintf(stdout, tuning to %d Hz, please wait...\n, frequency);
-   if(dvbfe_set(*fe, fe_info.feparams, TIMEOUT * 1000)) {
+   if (dvbfe_set(*fe, fe_info.feparams, TIMEOUT * 1000)) {
fprintf(stderr, %s(): cannot lock to %d Hz in %d seconds\n,
__FUNCTION__, frequency, TIMEOUT);
return -1;
@@ -257,7 +255,7 @@ static int open_frontend(struct dvbfe_ha
return 0;
 }
 
-#if ENABLE_RRT
+#ifdef ENABLE_RRT
 /* this is untested as since this part of the library is broken */
 static int parse_rrt(int dmxfd)
 {
@@ -270,20 +268,18 @@ static int parse_rrt(int dmxfd)
i = 0;
fprintf(stdout, waiting for RRT: );
fflush(stdout);
-   while(i  RRT_TIMEOUT) {
+   while (i  RRT_TIMEOUT) {
ret = atsc_scan_table(dmxfd, ATSC_BASE_PID, tag, (void **)rrt);
-   if(0  ret) {
-   fprintf(stderr, %s(): error calling 
atsc_scan_table()\n,
-   __FUNCTION__);
+   if (0  ret) {
+   fprintf(stderr, %s(): error calling 
atsc_scan_table()\n, __FUNCTION__);
return -1;
}
-   if(0 == ret) {
-   if(RRT_TIMEOUT  i) {
+   if (0 == ret) {
+   if (RRT_TIMEOUT  i) {
fprintf(stdout, .);
fflush(stdout);
} else {
-   fprintf(stdout, \nno RRT in %d seconds\n,
-   RRT_TIMEOUT);
+   fprintf(stdout, \nno RRT in %d seconds\n, 
RRT_TIMEOUT);
return 0;
}
i += TIMEOUT;
@@ -301,14 +297,13 @@ static int parse_rrt(int dmxfd)
atsc_text_string_segments_for_each(atsc_str, seg, j) {
const char *c;
int k;
-   if(seg-mode  0x3E) {
-   fprintf(stderr, %s(): text mode of 0x%02X 
-   not supported yet\n,
-   __FUNCTION__, seg-mode);
+
+   if (seg-mode  0x3E) {
+   fprintf(stderr, %s(): text mode of 0x%02X not 
supported yet\n, __FUNCTION__, seg-mode);
return -1;
}
c = (const char *)atsc_text_string_segment_bytes(seg);
-   for(k = 0; k  seg-number_bytes; k++) {
+   

Re: [Patch] dvb-apps: code cleanup and bug fix.

[Yufei Yuan]

The Makefile part of the last patch was not correct. Please use this one, sorry.

--- dvb-apps/util/scan/Makefile 2009-06-20 12:28:52.544986677 -0500
+++ dvb-apps_local/util/scan/Makefile   2009-06-20 12:27:08.597924784 -0500
@@ -14,7 +14,7 @@ inst_bin = $(binaries)
 
 removing = atsc_psip_section.c atsc_psip_section.h
 
-CPPFLAGS += -DDATADIR=\$(prefix)/share\
+CPPFLAGS += -Wno-packed-bitfield-compat -D__KERNEL_STRICT_NAMES 
-DDATADIR=\$(prefix)/share\
 
 .PHONY: all
 

On Sat, 2009-06-20 at 12:16 -0500, Yufei Yuan wrote:
 This patch is against dvb-apps 1281. Following is what has been done:
 
 1. atsc_epg bug fix: when ETM message gets longer than 256 characters, the 
 last
 character was chopped, due to incorrect calling to snprintf().
 2. atsc_epg code cleanup:
   - white space added after keywords;
   - hard wrap around column 80 removed;
   - one-line conditional statement now w/o brackets.
 3. scan Makefile workaround for building in gcc4.4/kernel 2.6.30 was not 
 picked up in 1279, include again.
 
 Regards,
 
 Signed-off-by: Yufei Yuan yfy...@gmail.com
 


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://kernellabs.com/hg/~mkrufky/bug-fix

[Michael Krufky]

Mauro,

Please note that there are two pull requests in this email.

Please pull from:

http://kernellabs.com/hg/~mkrufky/bug-fix

for the following bug fixes, which should be sent to Linus for 2.6.31.

- tda10048: add missing entry to pll_tab for 3.8 MHz IF
- cx23885: ensure correct IF freq is used on HVR1200  HVR1700

 dvb/frontends/tda10048.c|1 +
 video/cx23885/cx23885-dvb.c |   10 ++
 2 files changed, 11 insertions(+)


Please also note that a previous pull request is still pending -- I'd
like to see the following change sent to Linus for 2.6.31.  Please
pull from:

http://kernellabs.com/hg/~mkrufky/k2c2

for:

- cx23885: override set_frontend to allow rf input path switching on the HVR1275
- cx23885: add FIXME comment above set_frontend override

 cx23885-dvb.c |   30 ++
 cx23885.h |4 
 2 files changed, 34 insertions(+)

Thanks,

Mike
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-dev

[Mike Isely]

[sorry, reposted with corrected subject tag]

Mauro:

Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-dev for a
number of pvrusb2 driver fixes.  The first two in particular are
high-priority critical fixes that clean up a nasty regression
involving analog capture on the HVR-1950 and the older 24xxx model
series.  It would be good to see those at least backported to a
2.6.30.x release.

- pvrusb2: Fix hardware scaling when used with cx25840
- pvrusb2: Re-fix hardware scaling on video standard change
- pvrusb2: Change initial default frequency setting
- pvrusb2: Improve handling of routing schemes
- pvrusb2: De-obfuscate code which handles routing schemes

 pvrusb2-audio.c   |   14 ++-
 pvrusb2-cs53l32a.c|   26 +++--
 pvrusb2-cx2584x-v4l.c |   39 +---
 pvrusb2-hdw.c |   60 --
 pvrusb2-video-v4l.c   |   37 +-
 5 files changed, 98 insertions(+), 78 deletions(-)


  -Mike

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sakar 57379 USB Digital Video Camera...

[Andy Walls]

On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote:

 
  Now it is using the other pair of endpoints, 0x03 and 0x84.
 
  H.  I wonder if we can use them anyway, without being connected in
  webcam mode.
 
 Nope. That was the previously mentioned bug in the Linux mass storage 
 driver. Namely the spec calls for using the first pair of endpoints 
 encountered. The bug consisted of the mass storage driver looking for the 
 last pair of endpoints encountered, instead. This was back around kernel 
 2.6.18 or so when the problem got fixed.
 
 The second pair of endpoints appears to be very much disconnected in mass 
 storage mode. The attempt to use them will result only in a string of 
 error messages. How well I remember. As to whether the first pair can be 
 used in webcam mode, I clearly have not tried to use them, but I would 
 have strong doubts whether it is even worth trying. Even if they would 
 work, what on earth would they be good for?

Just not having to disconnect the cam to get at the files on it.  It'll
probably be too much for the cheap device to deal with though.


It is interesting to note that the transfer logic of the the device
seems to be oriented around a 512 byte block size - the defacto disk
block size. 


  There is a sequence of init commands
 
   : 71 81
   : 70 05
   : 95 70
   : 00  (all the 00 are responses)
   : 71 81
   : 70 04
   : 95 70
   : 00
   : 71 00
   : 70 08
   : 95 70
   : 00
   : 94 02
   : de 24
   : 94 02
   : dd f0
   : 94 02
   : e3 2c
   : 94 02
   : e4 00
   : 94 02
   : e5 00
   : e5 00
   : 94 02
   : e6 2c
   : 94 03
   : aa 00
   : 71 1e
   : 70 06
   : 71 80
   : 70 07
 
  and then it starts to stream. The stream downloads 0x200 (512) bytes at a
  time. It appears that there is an SOF marker consisting of
 
  ff ff ff ff
 
  followed by at least two zeroes. These seem to occur only at the
  beginnings of some of the downloaded 0x200-sized blocks.
 
  Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the
  streaming mode uses something similar.
 
  Assuming 6 bit RGB values at 320x240 @ 20 fps:
 
  (320*240) * 24 bpp * 20 fps = 36.864 Mbps
 
  Since this USB 1.1, I'm guessing the stream has to be compressed.
 
 Sure looks that way. I took a closer look at the lines starting with ff ff 
 ff ff strings, and I found a couple more things. Here are several lines 
 from an extract from that snoop, consisting of what appear to be 
 consecutive SOF lines.
 
  : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
  : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
  : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
  : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
  : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
 
 The last non-zero byte is a frame counter. Presumably, the gap between the 
 01 and the 06 occurs because the camera was just then starting up and 
 things were a bit chaotic. The rest of the lines in the file are 
 completely consistent, counting consecutively from 09 to 49 (hex, of 
 course) at which point I killed the stream.
 
 The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives 
 the number of 0x200-byte blocks in that frame, before the next marker 
 comes along. So if we start from the frame labeled 06 then from there on 
 the frames are approximately the same size, but not identical. For example 
 the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
 
 I am not sure what the other numbers mean. Perhaps you have better guesses 
 than I do.

The first few become easy given your observations.  They are the actaul
payload size:

ceil(0x1c70/0x200) = ceil(0x0e.380) = 0x0f
ceil(0x3549/0x200) = ceil(0x1a.a48) = 0x1b
ceil(0x3689/0x200) = ceil(0x1b.448) = 0x1c
ceil(0x35fc/0x200) = ceil(0x1a.fe0) = 0x1b
ceil(0x3584/0x200) = ceil(0x1a.c20) = 0x1b

The lone 0x3c and the 0x1e's are not so easy:

0x3c = 60
0x1e = 30

Maybe an inidcation of frame rate?

I'll try and think about them a little more.

 
   : 71 00
   : 70 09
   : 71 80
   : 70 05
 
  It would be interesting to see your log file and to compare. I could also
  send you this one if you are curious, but it is 5,760,902 bytes so I
  should ask that if you want to see it then how to send it? Me, I suspect
  that if you have one of similar size and bz2 it and send it to me as an
  attachment, then it is not any problem.
 
  You could send it to me via email (my ISP bounces *really* big incoming
  emails but at least 6 MB email can make it through).  However, without
  the 

Dual DVB-S2 Card

[Jens Krehbiel-Gräther]

Hi!



Does anyone know something about this card?



http://www.media-pointer.de/index.php?page=shop.product_detailsflypage=flypage.tplproduct_id=6category_id=3option=com_virtuemartItemid=1



I think this card is a type of the reference design from micronas (think of

the year 2006??).



http://www.computerbase.de/news/hardware/multimedia/2006/august/micronas_pci_express_dual-dvb-s2-tuner/



(Sorry, all in german)



I send a request to the manufacturer and asked what chips are used on the

card. When I get an answer I will post it here.



If this card hast the STB0899/6100 chip, i think it should work with S2-API

repository of Igor Liplianin or Manu Abraham???

Do you think I can use both tuner out of the box with these drivers??



Thanks for your information!



Jens
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cx23885, new hardware revision found

[Michael Kutyna]

Hi, I just purchased a Dvico FusionHDTV7 Dual Express and intend on
using it with MythTV.  Unfortunately, the dvb-apps aren't working with
it just yet and I think I've narrowed down why.

I've used mercurial to get the latest v4l-dvb source, compiled and
installed the modules.  I downloaded the firmware from Steven Toth's
website, extracted and installed it.  This all seems to run fine.

Running scan against the us-ATSC-center-frequencies file returns no
channels and running femon -a 0 returns the following output:

status S | signal  | snr  | ber  | unc  |

After examining dmesg output, I noticed the following bit:

cx23885_dev_checkrevision() New hardware revision found 0x0
cx23885_dev_checkrevision() Hardware revision unknown 0x0
cx23885[0]/0: found at :02:00.0, rev: 4, irq: 17, latency: 0,
mmio: 0xfd80
cx23885 :02:00.0: setting latency timer to 64

I'm pretty sure that is the problem but I don't know how to fix it.  I
also tried using mercurial to get the v4l tree from
http://linuxtv.org/hg/~stoth/v4l-dvb/ with the same results as above.

Thanks in advance for any assistance you can offer.

mkutyna
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Sakar 57379 USB Digital Video Camera...

[Theodore Kilgore]

On Sat, 20 Jun 2009, Andy Walls wrote:


On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote:



Now it is using the other pair of endpoints, 0x03 and 0x84.


H.  I wonder if we can use them anyway, without being connected in
webcam mode.


Nope. That was the previously mentioned bug in the Linux mass storage
driver. Namely the spec calls for using the first pair of endpoints
encountered. The bug consisted of the mass storage driver looking for the
last pair of endpoints encountered, instead. This was back around kernel
2.6.18 or so when the problem got fixed.

The second pair of endpoints appears to be very much disconnected in mass
storage mode. The attempt to use them will result only in a string of
error messages. How well I remember. As to whether the first pair can be
used in webcam mode, I clearly have not tried to use them, but I would
have strong doubts whether it is even worth trying. Even if they would
work, what on earth would they be good for?


Just not having to disconnect the cam to get at the files on it.  It'll
probably be too much for the cheap device to deal with though.



Well, I do not see any way around that. If you want to use it as a webcam, 
it needs a webcam support module. If you want to use it as a still cam, 
then it needs the mass storage module. Even if it were possible for the 
hardware to come up set in the webcam mode and use those two endpoints for 
something or other, then just how would it be possible to do the mass 
storage stuff? Actually, the producers of the camera were being very good 
citizens about that. They have the camera come up with two different 
Product numbers and two different Class-subclass-protocol IDs, depending 
on the way the camera has been set. One cannot ask for more. And the 
devices which do not act thus are a real pain in the neck.


This brings up another topic, not immediately relevant to the question of 
supporting your/my camera, but extremely relevant for this list:



Think about a camera which needs, say, libgphoto2 for stillcam support but 
needs a module in order to emit a stream. Then there is the issue of a 
userspace program to access the camera through libusb, and a kernel module 
to access it for streaming. Until something recently was done for a 
partial solution of this problem, then this implied the kernel module must 
be blacklisted, else the camera could never be used as a still camera.


The current solution to this userspace-kernelspace conundrum is only a 
halfway solution. Nowadays, libusb disables the kernel module if called, 
and if you want to use the camera as a webcam after that, you must replug. 
This causes problems, too, because of some distros which have the 
too-bright idea of associating the camera, through libusb, to HAL and 
fixing it so that a program pops up immediately for the purpose of 
downloading the pictures on it. Those distros want to make things easy 
for their users. But then, what happens? Well, as soon as the camera is 
plugged in, its module gets loaded automatically, so that it can stream. 
Then immediately the module has been disabled, because the camera is 
automatically accessed from userspace. If the user wants to stream instead 
of downloading pictures from it, then the user is screwed. To replug the 
camera is no solution, because then the cycle merely gets repeated. 
Therefore, I submit that this problem is still not solved. The great 
difficulty is, of course, that the problem raises some very difficult 
issues, which strike at the heart of the Linux security model. A better 
solution needs to be sought.


Returning to the issue on the table, I would say simply to be glad that 
the camera comes up as two different devices, depending on its switch 
settings, and does not use the same pair of endpoints for its two 
different functionalities, either.




It is interesting to note that the transfer logic of the the device
seems to be oriented around a 512 byte block size - the defacto disk
block size.



Yes, but in view of the mass-storage nature of the camera's alter ego, 
that seems to me natural. Also, all the other Jeilin cameras I know of, 
both supported and unsupported, count the allocation for the photos in 
blocks. Some of them use a smaller blocksize, but many of their purely 
proprietary cameras do also use this standard blocksize. In other words, 
this approach seems to me to be somewhat standard for Jeilin.


snip



Sure looks that way. I took a closer look at the lines starting with ff ff
ff ff strings, and I found a couple more things. Here are several lines
from an extract from that snoop, consisting of what appear to be
consecutive SOF lines.

 : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
 : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00

Re: Sakar 57379 USB Digital Video Camera...

[Andy Walls]

On Sat, 2009-06-20 at 15:23 -0400, Andy Walls wrote:
 On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote:
 
  
   Now it is using the other pair of endpoints, 0x03 and 0x84.
  
   H.  I wonder if we can use them anyway, without being connected in
   webcam mode.
  
  Nope. That was the previously mentioned bug in the Linux mass storage 
  driver. Namely the spec calls for using the first pair of endpoints 
  encountered. The bug consisted of the mass storage driver looking for the 
  last pair of endpoints encountered, instead. This was back around kernel 
  2.6.18 or so when the problem got fixed.
  
  The second pair of endpoints appears to be very much disconnected in mass 
  storage mode. The attempt to use them will result only in a string of 
  error messages. How well I remember. As to whether the first pair can be 
  used in webcam mode, I clearly have not tried to use them, but I would 
  have strong doubts whether it is even worth trying. Even if they would 
  work, what on earth would they be good for?
 
 Just not having to disconnect the cam to get at the files on it.  It'll
 probably be too much for the cheap device to deal with though.
 
 
 It is interesting to note that the transfer logic of the the device
 seems to be oriented around a 512 byte block size - the defacto disk
 block size. 
 
 
   There is a sequence of init commands
  
: 71 81
: 70 05
: 95 70
: 00(all the 00 are responses)
: 71 81
: 70 04
: 95 70
: 00
: 71 00
: 70 08
: 95 70
: 00
: 94 02
: de 24
: 94 02
: dd f0
: 94 02
: e3 2c
: 94 02
: e4 00
: 94 02
: e5 00
: e5 00
: 94 02
: e6 2c
: 94 03
: aa 00
: 71 1e
: 70 06
: 71 80
: 70 07
  
   and then it starts to stream. The stream downloads 0x200 (512) bytes at a
   time. It appears that there is an SOF marker consisting of
  
   ff ff ff ff
  
   followed by at least two zeroes. These seem to occur only at the
   beginnings of some of the downloaded 0x200-sized blocks.
  
   Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the
   streaming mode uses something similar.
  
   Assuming 6 bit RGB values at 320x240 @ 20 fps:
  
 (320*240) * 24 bpp * 20 fps = 36.864 Mbps
  
   Since this USB 1.1, I'm guessing the stream has to be compressed.
  
  Sure looks that way. I took a closer look at the lines starting with ff ff 
  ff ff strings, and I found a couple more things. Here are several lines 
  from an extract from that snoop, consisting of what appear to be 
  consecutive SOF lines.
  
   : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
   : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
   : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
   : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
   : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
  
  The last non-zero byte is a frame counter. Presumably, the gap between the 
  01 and the 06 occurs because the camera was just then starting up and 
  things were a bit chaotic. The rest of the lines in the file are 
  completely consistent, counting consecutively from 09 to 49 (hex, of 
  course) at which point I killed the stream.
  
  The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives 
  the number of 0x200-byte blocks in that frame, before the next marker 
  comes along. So if we start from the frame labeled 06 then from there on 
  the frames are approximately the same size, but not identical. For example 
  the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
  
  I am not sure what the other numbers mean. Perhaps you have better guesses 
  than I do.
 
 The first few become easy given your observations.  They are the actaul
 payload size:
 
 ceil(0x1c70/0x200) = ceil(0x0e.380) = 0x0f
 ceil(0x3549/0x200) = ceil(0x1a.a48) = 0x1b
 ceil(0x3689/0x200) = ceil(0x1b.448) = 0x1c
 ceil(0x35fc/0x200) = ceil(0x1a.fe0) = 0x1b
 ceil(0x3584/0x200) = ceil(0x1a.c20) = 0x1b
 
 The lone 0x3c and the 0x1e's are not so easy:
 
 0x3c = 60
 0x1e = 30
 
 Maybe an inidcation of frame rate?
 
 I'll try and think about them a little more.

For your camera, these numbers appear to indicate a frequency and can be
decoded into a time period like this:

1000/0x1e00 = 130 ms
1000/0x3c00 =  65 ms

I'm assuming it's some sort of presentation frame rate.



  
: 71 00
: 70 09
: 71 80
: 70 05
  
   It would be interesting to see your log file and to compare. I could also
   send you this one 

Re: [linux-dvb] Can't use my Pinnacle PCTV HD Pro st ick - what am I doing wrong?‏

[Devin Heitmueller]

2009/6/20 George Adams g_adam...@hotmail.com:

 Hello.  I'm having problems getting my (USB) PCTV HD Pro Stick (800e,

 the old style) to work under V4L.  Could anyone spot the problem in

 what I'm doing?



 I'm running Ubuntu 8.04.2 LTS (the 2.6.24-24-server kernel), and am

 following this procedure (based on

 http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers).

 I intend to use this to tune to USA NTSC channel 3 (to capture a

 close-captioned feed inside our building)



 1) Extract and copy the firmware file I need

   (xc3028-v27.fw) to /lib/firmware



 2) cd /usr/local/src



 3) hg clone http://linuxtv.org/hg/v4l-dvb



 4) cd v4l-dvb



 5) make rminstall; make distclean; make; make install



 These seems to do what it's supposed to - installs the drivers into

 /lib/modules/2.6.24-24-server .  My PCTV HD Pro Stick uses the em28xx

 drivers.



 find /lib/modules/ -type f -name em28* -mtime -1

    /lib/modules/2.6.24-24-server/kernel/drivers/media/video/em28xx/em28xx.ko

    
 /lib/modules/2.6.24-24-server/kernel/drivers/media/video/em28xx/em28xx-dvb.ko



 6) Reboot with the USB capture device plugged in



 7) Examine dmesg for details related to the capture device



 - em28xx: New device Pinnacle Systems PCTV 800e @ 480 Mbps (2304:0227, 
 interface 0, class 0)

 - em28xx #0: Identified as Pinnacle PCTV HD Pro Stick (card=17)

 - em28xx #0: chip ID is em2882/em2883

 - - - GSI 22 (level, low) - IRQ 22

 - PCI: Setting latency timer of device :00:1b.0 to 64

 - em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 27 02 d0 12 5c 03 8e 16 a4 1c

 - em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00

 - em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 1c 00 00

 - em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00

 - em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 - em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 - em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00

 - em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00

 - em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 00 16 03

 - em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 38 00 30 00 30 00

 - em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00 31 00 30 00 30 00

 - em28xx #0: i2c eeprom b0: 31 00 30 00 33 00 39 00 34 00 34 00 32 00 00 00

 - em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 - em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 - em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 - em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

 - em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x2de5abbf

 - em28xx #0: EEPROM info:

 - em28xx #0:       AC97 audio (5 sample rates)

 - em28xx #0:       500mA max power

 - em28xx #0:       Table at 0x27, strings=0x168e, 0x1ca4, 0x246a

 - hda_codec: Unknown model for ALC882, trying auto-probe from BIOS...

 - input: em28xx IR (em28xx #0) as 
 /devices/pci:00/:00:1a.7/usb4/4-3/input/input6

 - - - GSI 20 (level, low) - IRQ 23

 - Vortex: init em28xx #0: Config register raw data: 0xd0

 - em28xx #0: AC97 vendor ID = 0x

 - em28xx #0: AC97 features = 0x6a90

 - em28xx #0: Empia 202 AC97 audio processor detected

 - em28xx #0: v4l2 driver version 0.1.2

 - em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0

 - usbcore: registered new interface driver em28xx

 - em28xx driver loaded

 - xc2028 0-0061: creating new instance

 - xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner

 - em28xx #0/2: xc3028 attached

 - DVB: registering new adapter (em28xx #0)

 - DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3303 VSB/QAM 
 Frontend)...

 - Successfully loaded em28xx-dvb

 - Em28xx: Initialized (Em28xx dvb Extension) extension

 - done.



 Everything looks good - the drivers are getting called and the card is

 recognized.  However, all my attempts to get something out of it

 aren't working.  I tried firing up tvtime, but it just launches a

 blank, black screen and hanges.  The menu won't come up, the channel

 won't change, right-clicking isn't responsive, it won't close, and I

 have to kill it.



 I also tried mencoder, but I get this:



 mencoder -nosound -tv driver=v4l2:width=640:height=480 tv://3 -o /tmp/tv.avi 
 -ovc raw -endpos 5



 MEncoder 2:1.0~rc2-0ubuntu13.1+medibuntu1 (C) 2000-2007 MPlayer Team

 CPU: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz

  (Family: 6, Model: 23, Stepping: 10)

 CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1

 Compiled with runtime CPU detection.

 success: format: 9  data: 0x0 - 0x0

 TV file format detected.

 Selected driver: v4l2

  name: Video 4 Linux 2 input

  author: Martin Olschewski

  comment: first try, more to come ;-)

 Selected device: 

Re: Sakar 57379 USB Digital Video Camera...

[Theodore Kilgore]

On Sat, 20 Jun 2009, Andy Walls wrote:


On Sat, 2009-06-20 at 15:23 -0400, Andy Walls wrote:

On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote:



Now it is using the other pair of endpoints, 0x03 and 0x84.


H.  I wonder if we can use them anyway, without being connected in
webcam mode.


Nope. That was the previously mentioned bug in the Linux mass storage
driver. Namely the spec calls for using the first pair of endpoints
encountered. The bug consisted of the mass storage driver looking for the
last pair of endpoints encountered, instead. This was back around kernel
2.6.18 or so when the problem got fixed.

The second pair of endpoints appears to be very much disconnected in mass
storage mode. The attempt to use them will result only in a string of
error messages. How well I remember. As to whether the first pair can be
used in webcam mode, I clearly have not tried to use them, but I would
have strong doubts whether it is even worth trying. Even if they would
work, what on earth would they be good for?


Just not having to disconnect the cam to get at the files on it.  It'll
probably be too much for the cheap device to deal with though.


It is interesting to note that the transfer logic of the the device
seems to be oriented around a 512 byte block size - the defacto disk
block size.



There is a sequence of init commands

 : 71 81
 : 70 05
 : 95 70
 : 00   (all the 00 are responses)
 : 71 81
 : 70 04
 : 95 70
 : 00
 : 71 00
 : 70 08
 : 95 70
 : 00
 : 94 02
 : de 24
 : 94 02
 : dd f0
 : 94 02
 : e3 2c
 : 94 02
 : e4 00
 : 94 02
 : e5 00
 : e5 00
 : 94 02
 : e6 2c
 : 94 03
 : aa 00
 : 71 1e
 : 70 06
 : 71 80
 : 70 07

and then it starts to stream. The stream downloads 0x200 (512) bytes at a
time. It appears that there is an SOF marker consisting of

ff ff ff ff

followed by at least two zeroes. These seem to occur only at the
beginnings of some of the downloaded 0x200-sized blocks.


Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the
streaming mode uses something similar.

Assuming 6 bit RGB values at 320x240 @ 20 fps:

(320*240) * 24 bpp * 20 fps = 36.864 Mbps

Since this USB 1.1, I'm guessing the stream has to be compressed.


Sure looks that way. I took a closer look at the lines starting with ff ff
ff ff strings, and I found a couple more things. Here are several lines
from an extract from that snoop, consisting of what appear to be
consecutive SOF lines.

 : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
 : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00

The last non-zero byte is a frame counter. Presumably, the gap between the
01 and the 06 occurs because the camera was just then starting up and
things were a bit chaotic. The rest of the lines in the file are
completely consistent, counting consecutively from 09 to 49 (hex, of
course) at which point I killed the stream.

The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
the number of 0x200-byte blocks in that frame, before the next marker
comes along. So if we start from the frame labeled 06 then from there on
the frames are approximately the same size, but not identical. For example
the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.

I am not sure what the other numbers mean. Perhaps you have better guesses
than I do.


The first few become easy given your observations.  They are the actaul
payload size:

ceil(0x1c70/0x200) = ceil(0x0e.380) = 0x0f
ceil(0x3549/0x200) = ceil(0x1a.a48) = 0x1b
ceil(0x3689/0x200) = ceil(0x1b.448) = 0x1c
ceil(0x35fc/0x200) = ceil(0x1a.fe0) = 0x1b
ceil(0x3584/0x200) = ceil(0x1a.c20) = 0x1b

The lone 0x3c and the 0x1e's are not so easy:

0x3c = 60
0x1e = 30

Maybe an inidcation of frame rate?

I'll try and think about them a little more.


For your camera, these numbers appear to indicate a frequency and can be
decoded into a time period like this:

1000/0x1e00 = 130 ms
1000/0x3c00 =  65 ms

I'm assuming it's some sort of presentation frame rate.





 : 71 00
 : 70 09
 : 71 80
 : 70 05

It would be interesting to see your log file and to compare. I could also
send you this one if you are curious, but it is 5,760,902 bytes so I
should ask that if you want to see it then how to send it? Me, I suspect
that if you have one of similar size and bz2 it and send it to me as an
attachment, then it is not any problem.


You 

Re: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)

[Devin Heitmueller]

On Fri, Jun 19, 2009 at 12:41 PM, Hans Verkuilhverk...@xs4all.nl wrote:
 On Friday 19 June 2009 18:11:11 Devin Heitmueller wrote:
 On Fri, Jun 19, 2009 at 12:04 PM, Hans Verkuilhverk...@xs4all.nl wrote:
  Hmm, I discovered that firedtv-1394.c isn't compiled in the daily build
  even though ieee1394 is enabled in the kernel. I can manually enable
  it, though: make menuconfig, disable and enable the firedtv driver, and
  then it magically works. But even then it still compiles fine against
  the vanilla 2.6.30 kernel.

 Well, I'm obviously kicking myself for not having captured the output
 last night when I was at home.

 So, you're saying that firedvt-1394.c is being compiled?

 Let me rephrase the question:  Take a look at firedtv-1394.c, line 22,
 and tell me where the file csr1212.h can be found either in your
 kernel source tree or your v4l-dvb tree.

 Devin

 It's here:

 /usr/src/linux/drivers/ieee1394/csr1212.h

 Regards,

        Hans

 --
 Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom


Ok, I see what is going on:  the header files in question are
available if you have the full Linux source installed, but they are
not part of the kernel-headers package, at least on Ubuntu.
Combined with the fact that the file now gets built with 2.6.30 causes
the compile failures:

  CC [M]  /home/devin/800e_test/v4l/firedtv-1394.o
/home/devin/800e_test/v4l/firedtv-1394.c:21:17: error: dma.h: No such
file or directory
/home/devin/800e_test/v4l/firedtv-1394.c:22:21: error: csr1212.h: No
such file or directory
/home/devin/800e_test/v4l/firedtv-1394.c:23:23: error: highlevel.h: No
such file or directory
/home/devin/800e_test/v4l/firedtv-1394.c:24:19: error: hosts.h: No
such file or directory
/home/devin/800e_test/v4l/firedtv-1394.c:25:22: error: ieee1394.h: No
such file or directory
/home/devin/800e_test/v4l/firedtv-1394.c:26:17: error: iso.h: No such
file or directory
/home/devin/800e_test/v4l/firedtv-1394.c:27:21: error: nodemgr.h: No
such file or directory

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?

[George Adams]

Hello.  I'm having problems getting my (USB) PCTV HD Pro Stick (800e,
the old style) to work under V4L.  Could anyone spot the problem in
what I'm doing?

I'm running Ubuntu 8.04.2 LTS (the 2.6.24-24-server kernel), and am
following this procedure (based on
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers).
 
I intend to use this to tune to USA NTSC channel 3 (to capture a
close-captioned feed inside our building)

1) Copy the firmware I need (xc3028-v27.fw) to /lib/firmware

2) cd /usr/local/src

3) hg clone http://linuxtv.org/hg/v4l-dvb

4) cd v4l-dvb

5) make rminstall; make distclean; make; make install

These seems to do what it's supposed to - installs the drivers into
/lib/modules/2.6.24-24-server .  My PCTV HD Pro Stick uses the em28xx
drivers.

 find /lib/modules/ -type f -name em28* -mtime -1
/lib/modules/2.6.24-24-server/kernel/drivers/media/video/em28xx/em28xx.ko

/lib/modules/2.6.24-24-server/kernel/drivers/media/video/em28xx/em28xx-dvb.ko

6) Reboot with the USB capture device plugged in

7) Examine dmesg for details related to the capture device

- em28xx: New device Pinnacle Systems PCTV 800e @ 480 Mbps (2304:0227, 
interface 0, class 0)
- em28xx #0: Identified as Pinnacle PCTV HD Pro Stick (card=17)
- em28xx #0: chip ID is em2882/em2883
- - - GSI 22 (level, low) - IRQ 22
- PCI: Setting latency timer of device :00:1b.0 to 64
- em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 27 02 d0 12 5c 03 8e 16 a4 1c
- em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00
- em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 1c 00 00
- em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00
- em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00
- em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00
- em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 00 16 03
- em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 38 00 30 00 30 00
- em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00 31 00 30 00 30 00
- em28xx #0: i2c eeprom b0: 31 00 30 00 33 00 39 00 34 00 34 00 32 00 00 00
- em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
- em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x2de5abbf
- em28xx #0: EEPROM info:
- em28xx #0:   AC97 audio (5 sample rates)
- em28xx #0:   500mA max power
- em28xx #0:   Table at 0x27, strings=0x168e, 0x1ca4, 0x246a
- hda_codec: Unknown model for ALC882, trying auto-probe from BIOS...
- input: em28xx IR (em28xx #0) as 
/devices/pci:00/:00:1a.7/usb4/4-3/input/input6
- - - GSI 20 (level, low) - IRQ 23
- Vortex: init em28xx #0: Config register raw data: 0xd0
- em28xx #0: AC97 vendor ID = 0x
- em28xx #0: AC97 features = 0x6a90
- em28xx #0: Empia 202 AC97 audio processor detected
- em28xx #0: v4l2 driver version 0.1.2
- em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0
- usbcore: registered new interface driver em28xx
- em28xx driver loaded
- xc2028 0-0061: creating new instance
- xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner
- em28xx #0/2: xc3028 attached
- DVB: registering new adapter (em28xx #0)
- DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3303 VSB/QAM 
Frontend)...
- Successfully loaded em28xx-dvb
- Em28xx: Initialized (Em28xx dvb Extension) extension
- done.

Everything looks good - the drivers are getting called and the card is
recognized.  However, all my attempts to get something out of it
aren't working.  I tried firing up tvtime, but it just launches a
blank, black screen and hanges.  The menu won't come up, the channel
won't change, right-clicking isn't responsive, it won't close, and I
have to kill it.

I also tried mencoder, but I get this:

 mencoder -nosound -tv driver=v4l2:width=640:height=480 tv://3 -o /tmp/tv.avi 
 -ovc raw -endpos 5

MEncoder 2:1.0~rc2-0ubuntu13.1+medibuntu1 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Core(TM)2 Quad CPUQ9550  @ 2.83GHz
  (Family: 6, Model: 23, Stepping: 10)
CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
success: format: 9  data: 0x0 - 0x0
TV file format detected.
Selected driver: v4l2
 name: Video 4 Linux 2 input
 author: Martin Olschewski 
 comment: first try, more to come ;-)
Selected device: Pinnacle PCTV HD Pro Stick
 Tuner cap:
 Tuner rxs:
 Capabilites:  video capture  tuner  audio  read/write  streaming
 supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4
   = NTSC-443; 5 = PAL; 6 = PAL-BG; 7 = PAL-H; 8 = PAL-I; 9 = 

Re: Sakar 57379 USB Digital Video Camera...

[Andy Walls]

On Sat, 2009-06-20 at 20:04 -0500, Theodore Kilgore wrote:
 

  Sure looks that way. I took a closer look at the lines starting with ff ff
  ff ff strings, and I found a couple more things. Here are several lines
  from an extract from that snoop, consisting of what appear to be
  consecutive SOF lines.
 
   : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
   : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
   : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
   : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
   : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
 
  The last non-zero byte is a frame counter. Presumably, the gap between the
  01 and the 06 occurs because the camera was just then starting up and
  things were a bit chaotic. The rest of the lines in the file are
  completely consistent, counting consecutively from 09 to 49 (hex, of
  course) at which point I killed the stream.
 
  The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
  the number of 0x200-byte blocks in that frame, before the next marker
  comes along. So if we start from the frame labeled 06 then from there on
  the frames are approximately the same size, but not identical. For example
  the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
 
  Here's the init for my camera:
 
  : 71 81
  : 70 05
  : 95 70
  : 00
  : 71 81
  : 70 04
  : 95 70
  : 00
  : 71 00
  : 70 08
  : 95 70
  : 00
  : 94 02
  : de 24
  : 94 02
  : dd f0
  : 94 02
  : e3 22 --- different
  : 94 02
  : e4 00
  : 94 02
  : e5 00 --- not repeated like in the sequence above
  : 94 02
  : e6 22 --- different
  : 94 03
  : aa 01 --- different
  : 71 1e
  : 70 06
  : 71 80
  : 70 07
 
  And here's the terminal sequence:
 
  : 71 00
  : 70 09
  : 71 80
  : 70 05
 
  They look amazingly similar to yours.
 
  Here are the buffers with the supposed SOF marker:
 
  : ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00
  : ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00
  : ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00
  : ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00
  : ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00
  : ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00
  : ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00
  : ff ff ff ff 00 00 18 8a 1e 00 0d 06 00 00 00 00
 
  Again very similar.  I had the camera pointed at a mostly white test
  target with some large blue numbers printed on it, so the sammler
  buffers probably just indicate how simple the test target was.
 
  The frames from my camera were coming at 100 ms intervals instead of 130
  ms intervals.  So maybe some scaling constant has changed with my
  supposed frame presentation frequency field that contains 0x1e00.

 
 This looks quite similar. The differences in the init sequence may be 
 significant, but more likely I would speculate that they are 
 insubstantial. Probably the little differences are due to who actually 
 wrote the camera driver. Those guys over there also put their pants on one 
 leg at a time just like the rest of us, after all. I think they do things 
 like hiring students to write their drivers. If so, they might possibly 
 get the same kind of results that could be expected over here from similar 
 arrangements.

Agree.

The more I dig into this, the more I think (hope or wish?) the stuff in
the usb snoop logs looks MJPEG.

I started looking at an AVI file that I recorded with the camera.  It
looks like a DV AVI Type-2 file.

In the AVI file header, my camera reports:

0d0:   7374 7264 ac00  4a65 696c  strdJeil
0e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043  in  Technology C
0f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632  o., Ltd.JL2008V2
100: 4330 3037 3030 3130 2020 2020 2020 2020  C0070010

So looking up the JL2008A datasheet, my camera's capabilities match the
data sheet very well.

http://jeilin.com.tw/eng/product_detail.php?p_id=5
http://jeilin.com.tw/mana_php/Download/File/JL2008A%20v1.3.pdf

The only video compression that is mentioned on the webpage and in the
datasheet is JPEG.

Trying to learn about DV AVI Type 2 files I've found roughly how
individual chunk headers look.  They each have a stream fourcc that
starts 'nnxx' in ASCII, where nn is the stream number and xx is

db - uncompressed video frame
dc - compressed video frame
wb - audio data

$ xxd 4.avi  | grep -E ' 303[0-2] ((646)|(776))' 

1f0: 14fe 0c00 6d6f 7669 3031 7762 401f   movi0...@...  -- audio
0002140: 3032 6462 0041  ffe2 55aa 0500   02db.AU.  -- video
0006250: 3032 6462 0041  ffe2 55aa 0500 0001  02db.AU.  -- video
000a360: 3032 6462 0041  ffe2 55aa 0500 0002  02db.AU.  -- video
000e470: 3032 6462 0041  ffe2 55aa 0500 0003  02db.AU.  --