Re: [PATCH] V4L/DVB: ir: Add a link to associate /sys/class/ir/irrcv with the input device

2010-03-13 Thread Dmitry Torokhov
On Fri, Mar 12, 2010 at 01:32:23AM -0300, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
  Hi Mauro,
  
  On Thu, Mar 11, 2010 at 12:46:19PM -0300, Mauro Carvalho Chehab wrote:
  In order to allow userspace programs to autoload an IR table, a link is
  needed to point to the corresponding input device.
 
  $ tree /sys/class/irrcv/irrcv0
  /sys/class/irrcv/irrcv0
  |-- current_protocol
  |-- input - ../../../pci:00/:00:0b.1/usb1/1-3/input/input22
  |-- power
  |   `-- wakeup
  |-- subsystem - ../../../../class/irrcv
  `-- uevent
 
  It is now easy to associate an irrcv device with the corresponding
  device node, at the input interface.
 
  
  I guess the question is why don't you make input device a child of your
  irrcvX device? Then I believe driver core will link them properly. It
  will also ensure proper power management hierarchy.
  
  That probably will require you changing from class_dev into device but
  that's the direction kernel is going to anyway.
 
 Done, see enclosed. It is now using class_register/device_register. The
 newly created device for irrcv is used as the parent for input_dev-dev.
 
 The resulting code looked cleaner after the change ;)


It is indeed better, however I wonder if current hierarchy expresses the
hardware in best way. You currently have irrcv devices grow in parallel
with input devices whereas I would expect input devices be children of
irrcv devices:


parent (PCI board, USB) - irrcvX - input1
  - input2
 ...

This way your PM sequence as follows - input core does its thing and
releases all pressed keys, etc, then you can shut off the receiver and
then board driver can shut doen the main piece. Otherwise irrcv0 suspend
may be racing with input suspend and so forth.

Thanks.

-- 
Dmitry
--
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: Remaining drivers that aren't V4L2?

2010-03-13 Thread Hans Verkuil
On Saturday 13 March 2010 07:33:57 Hans de Goede wrote:
  To my knowledge the usbvideo driver is probably the least obscure device
  that is still using V4L1.
 
 I think you are confusing the usbvideo driver with the v4l2 usbvision
 driver, which indeed gets used a lot in usb tv devices.

You are correct. I confused those two. Sorry about that.

 
 I think it is ok to drop v4l1 support from tvtime.

I agree.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: v4l-utils, dvb-utils, xawtv and alevt

2010-03-13 Thread Chicken Shack
Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
 Hi,
 
 On 03/12/2010 08:10 PM, Chicken Shack wrote:
  1. Alevt 1.7.0 is not just another tool, but it is instead a
  self-contained videotext application consisting of three parts:
  a. alevt, b. alevt-date c. alevt-cap
 
  While the packed size of alevt is 78770 the complete size of the
  dvb-apps as a whole ranges around 35.
 
  I am not against hosting this program at linuxtv.org, but if this
  decision is made the decision should be an intelligent one: alevt is a
  separate tree, and any other choice is simply a dumb one.
  Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
  only need the libc6.

Good morning Hans,

 
 
 Seems we agree here, becoming a new upstream for alevt is good, merging
 it into another package is not good :)

Yeah, exactly, as we're NOT talking about just another 200-liner

  2. Xawtv-4.0 pre is not usable as a whole. Thus you cannot treat it as a
  whole. And that's exactly why you cannot discuss it as a whole!
 
 
 Actually when I was talking about doing a tree to collect distro packages
 and serve as a new upstream for xawtv I was talking about xawtv version
 3.95, is that the same as which you call xawtv-4.0 pre ?

Definitely not.
3.95 is analogue only and thus is discontinued as version.
4.0 pre is the alpha-state tarball that you can get here:

http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz

Inofficial end of development somewhere in 2005 or 2006, last external
contribution from October 2008.

4.0 pre introduced DVB support for mtt (videotext) and the main program
xawtv.
It also introduced this disgusting slow channel scanner called alexplore
(DVB only) and dvbrowse as a complete new EPG solution for DVB only.
And it introduced dvbradio which would be excellent after some
investigation (- learn to interpret channels.conf files).

  The usable parts are:
 
  a. mtt: a slave videotext application which is running independently
  from the master application tuning the channels.
  Its packed size amounts to 107744.
 
  b. dvbrowse: a slave EPG application which is running independently from
  the master application tuning the channels.
  Packed Size: 101267.
 
  c. dvbradio: a fast and rather stable running application for watching
  DVB radio streams.
  Packed Size: 119957.
  Problem: dvbradio would need investigation to understand channel lists
  in vdr channels.conf format.
  As long as this is not the case, the insane slow homebrew scanner called
  alexplore is necessary to produce a channels list.
  Gerd implied some vdr modules into thew package, but they are
  ca. unfinished work
  cb. for debug purposes only
 
 
  The unusable parts are:
 
  a. xawtv itself, the main program.
  It never ran stable and it is unfinished work.
  Its graphical capabilities are pure rubbish compared to todays
  standards.
 
 
 ??
 
 Its UI is not a brilliant piece of work but it is usable and certainly
 is stable. Actually it still is my preffered app for tvcard testing / usage.

Hmmm. I'm not talking about the UI because I avoid discussions about
taste.
If you take a close critical look at the overlay capabilities you must
admit that they are technically reactionary. Not worth to be discussed
at all.
And I really do not know where the reason for the technical limitation
lies. Athena Widgets?
When I am looking TV through a monitor or modern flatscreen I expect a
full screen overlay picture covering the whole monitor's / sreen's size.
xawtv is not capable to offer that. Mplayer offers that f. ex.

The recording function of xawtv is tricky, while tvtime does not offer
any recording function. Thus it's not that easy to say: This one or that
one is best choice for testing / using.

TVtime is the best compromise for analogue TV, Kaffeine is the best
compromise for DVB TV.
Note that I am stressing compromise - I do not say choice.

  b. Lots of aged tools like scantv or radio who just have survived
  somehow but weren't modified.

 If these are really useless we could certainly drop them, as we could
 drop say v4l-ctl once we've got rid of the last v4l1 drivers.

Sure. There is also some obscure webcam tool for adressing USB webcams
via xawtv.
Streamer is exposed to be a quite flexible crossover recording tool for
command line usage, DVB and analogue.

Xawtv as main program runs stable as version 3.95 for analogue usage.
But I was not mentioning outdated analogue stuff.
Xawtv as main program runs highly unstable as version 4.0 pre for DVB
usage. Besides the overlay problem mentioned above I have had many
broken recordings due to its incomplete state.

 Regards,

 Hans

Best Regards

Uwe


--
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: v4l-utils, dvb-utils, xawtv and alevt

2010-03-13 Thread Hans de Goede

Hi,

On 03/13/2010 11:15 AM, Chicken Shack wrote:

Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:

Hi,

On 03/12/2010 08:10 PM, Chicken Shack wrote:

1. Alevt 1.7.0 is not just another tool, but it is instead a
self-contained videotext application consisting of three parts:
a. alevt, b. alevt-date c. alevt-cap

While the packed size of alevt is 78770 the complete size of the
dvb-apps as a whole ranges around 35.

I am not against hosting this program at linuxtv.org, but if this
decision is made the decision should be an intelligent one: alevt is a
separate tree, and any other choice is simply a dumb one.
Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
only need the libc6.


Good morning Hans,



Good afternoon :)


Definitely not.
3.95 is analogue only and thus is discontinued as version.
4.0 pre is the alpha-state tarball that you can get here:



Ah, ok. Well I must honestly say I've no interest in that I'm doing
package maintenance for the 3.95 release in Fedora and I know it
needs a lot of patching, AFAIK other distros are doing the same,
so it would be good to have / become a new upstream for xawtv 3.95,
to have a place to gather all the distro patches mostly and release
that, and where new patches if needed can accumulate and new
releases can be done from.



http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz

Inofficial end of development somewhere in 2005 or 2006, last external
contribution from October 2008.

4.0 pre introduced DVB support for mtt (videotext) and the main program
xawtv.
It also introduced this disgusting slow channel scanner called alexplore
(DVB only) and dvbrowse as a complete new EPG solution for DVB only.
And it introduced dvbradio which would be excellent after some
investigation (-  learn to interpret channels.conf files).



I see, well if there is an interest in bits of the 4.0 code base, then
grabbing those bits and having a tree with them and doing regular
tarbal releases for distro's to consume might be in interesting project
for some one. I would like to advocate to not call this xawtv, as AFAIK
all distros are still shipping 3.95, and as you said the xawtv part of 4.0
is broken so likely would not be included, at which point it
would be good to no longer call the resulting project xawtv.

Regards,

Hans
--
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 1/5] drivers/media/video/cx23885 needs kfifo conversion

2010-03-13 Thread Stefani Seibold
Am Donnerstag, den 11.03.2010, 14:02 -0800 schrieb
a...@linux-foundation.org:
 From: Andrew Morton a...@linux-foundation.org
 
 linux-next:
 
 drivers/media/video/cx23885/cx23888-ir.c: In function 
 'cx23888_ir_irq_handler':
 drivers/media/video/cx23885/cx23888-ir.c:597: error: implicit declaration of 
 function 'kfifo_put'
 drivers/media/video/cx23885/cx23888-ir.c: In function 'cx23888_ir_rx_read':
 drivers/media/video/cx23885/cx23888-ir.c:660: error: implicit declaration of 
 function 'kfifo_get'
 drivers/media/video/cx23885/cx23888-ir.c: In function 'cx23888_ir_probe':
 drivers/media/video/cx23885/cx23888-ir.c:1172: warning: passing argument 1 of 
 'kfifo_alloc' makes pointer from integer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1172: warning: passing argument 3 of 
 'kfifo_alloc' makes integer from pointer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1172: warning: assignment makes 
 pointer from integer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1178: warning: passing argument 1 of 
 'kfifo_alloc' makes pointer from integer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1178: warning: passing argument 3 of 
 'kfifo_alloc' makes integer from pointer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1178: warning: assignment makes 
 pointer from integer without a cast
 

This looks fine in 2.6.33. I don't know who reverted it in linux-next.


--
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: v4l-utils, dvb-utils, xawtv and alevt

2010-03-13 Thread Chicken Shack
Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede:
 Hi,
 
 On 03/13/2010 11:15 AM, Chicken Shack wrote:
  Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
  Hi,
 
  On 03/12/2010 08:10 PM, Chicken Shack wrote:
  1. Alevt 1.7.0 is not just another tool, but it is instead a
  self-contained videotext application consisting of three parts:
  a. alevt, b. alevt-date c. alevt-cap
 
  While the packed size of alevt is 78770 the complete size of the
  dvb-apps as a whole ranges around 35.
 
  I am not against hosting this program at linuxtv.org, but if this
  decision is made the decision should be an intelligent one: alevt is a
  separate tree, and any other choice is simply a dumb one.
  Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
  only need the libc6.
 
  Good morning Hans,
 
 
 Good afternoon :)
 
  Definitely not.
  3.95 is analogue only and thus is discontinued as version.
  4.0 pre is the alpha-state tarball that you can get here:
 
 
 Ah, ok. Well I must honestly say I've no interest in that I'm doing
 package maintenance for the 3.95 release in Fedora and I know it
 needs a lot of patching, AFAIK other distros are doing the same,
 so it would be good to have / become a new upstream for xawtv 3.95,
 to have a place to gather all the distro patches mostly and release
 that, and where new patches if needed can accumulate and new
 releases can be done from.
 
 
  http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz
 
  Inofficial end of development somewhere in 2005 or 2006, last external
  contribution from October 2008.
 
  4.0 pre introduced DVB support for mtt (videotext) and the main program
  xawtv.
  It also introduced this disgusting slow channel scanner called alexplore
  (DVB only) and dvbrowse as a complete new EPG solution for DVB only.
  And it introduced dvbradio which would be excellent after some
  investigation (-  learn to interpret channels.conf files).
 
 
 I see, well if there is an interest in bits of the 4.0 code base, then
 grabbing those bits and having a tree with them and doing regular
 tarbal releases for distro's to consume might be in interesting project
 for some one. I would like to advocate to not call this xawtv, as AFAIK
 all distros are still shipping 3.95, and as you said the xawtv part of 4.0
 is broken so likely would not be included, at which point it
 would be good to no longer call the resulting project xawtv.
 
 Regards,
 
 Hans
 --
 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

Good afternoon Hans :)

and as you said the xawtv part of 4.0 is broken so likely would not be
included, at which point it would be good to no longer call the
resulting project xawtv.

Pooh! Guess you got me wrong again.

You can watch TV with xawtv 4.0 pre in analogue mode.
But if you want to record a film parallely you need
to execute streamer on the command line, as the graphical support
for starting the recording session will not work at all.

In DVB mode parallel tasking works.
The fact that I had many broken recordings can also be due to a
former bad kernel / bad DVB driver. This happened years ago and
thus I lost interest in xawtv as a common.
In the meantime the kernel drivers have become more mature and
I do not work with the same DVB card any longer.
Got a better card now and better drivers (Flexcop Technisat).
In spite of all changes the overlay capabilities of xawtv still remain a mess.

There should be a separate tree for alevt plus one separate tree called
hybrid tools combining all the orphaned software that does not fit into the
200-liner-scheme of v4l-utils and / or dvb-utils.

Linuxtv.org should not be a cemetery for orphaned software and it shouldn't
be reduced to a highly specialized milk farm for kernel drivers only where
the cows go Mauro, please pull

There should be enough appropriate people to establish a functionable service
mode in which discussed issues also are being put into practice.

Cheers

Uwe


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


[REPORT] Brainstorm meeting on V4L2 memory handling

2010-03-13 Thread Hans Verkuil
Introduction


A meeting was held from March 10-12 at the Tandberg offices in Lysaker,
Norway, between developers from Nokia, Samsung, Intel and Tandberg to
informally discuss any V4L2 memory handling issues.

This was in preparation of a v4l-dvb mini-summit that will hopefully
happen in early May in Norway (I plan to have more definitive information
available next week).

The main purpose was to gain a better understanding of the problems that
SoC developers face when dealing with video4linux and in particular the way
it handles the video buffers and the streaming API.


Location:

Tandberg office, Lysaker, Norway
March 10-12, 2010

Attendees:

Sakari Ailus (Nokia)
Morten Hestnes (Tandberg)
Pawel Osciak (Samsung)
Laurent Pinchart (Nokia)
Marek Szyprowski (Samsung)
Hans Verkuil (Tandberg)
Xiaolin Zhang (Intel)


Summary of the meeting
--


1) Memory-to-memory devices

Original thread with the proposal from Samsung:

http://www.mail-archive.com/linux-samsung-...@vger.kernel.org/msg00391.html

Depending on the hardware/driver there can be two methods of doing this:

a) Separate capture and output video nodes. This already works, but has the
   limitation that only one capture and one output file handle can be streaming,
   just as is the case right now with capture and output nodes.

b) Provide a single video node that can do both capture and output. This is
   what the Samsung patch provides. Here the videobuf queues are placed in the
   file handle struct. This allows multiplexing (must be possible to add
   priority queue support later, but use fifo for now). STREAMON must be called
   for both capture and output queue before the hardware starts processing.
   Such nodes will set both capture and output capabilities.
   Drivers will have to store the hardware configuration (e.g. capture/output
   formats) in the file handle struct as well, since this is now completely 
local
   to the file handle.


2) videobuf framework and the V4L2 streaming API

The videobuf framework and the streaming API received a lot of attention during
this meeting. Many shortcomings and bugs were found. We even discussed the idea
whether a new videobuf framework should be created from scratch, but this was
abandoned. The general opinion was that while there are many, many problems with
videobuf, they are also relatively easy to fix.

We identified the following issues in the streaming API and videobuf:

a) REQBUFS with count == 0

Currently both the spec and drivers handle this inconsistently. Our proposal
is this (and RFC will be posted in the near future):

- Returns -EBUSY if the device is still streaming or if buffers are still
  mapped.
- Remove the implicit STREAMOFF behavior from the spec.
- Must return an error if the memory mode is not supported.
- Must release all buffers otherwise.
- On return the count field in the struct remains 0.

b) DQBUF handling of buffer errors

If a DMA error occurs while capturing a buffer the buffer status is set to
VIDEOBUF_ERROR. However, in the current implementation VIDIOC_DQBUF will
return -EIO and the v4l2_buffer struct will not be copied back to userspace,
so while the buffer is dequeued internally, the userspace application has no
idea which buffer that was. From the point of view of the application this
buffer has been effectively lost.

Proposed fix:

- Never return an error if the buffer has been dequeued, otherwise that buffer
  will be lost to the application.
- Need a new error flag to tell the application that the buffer had an error
  status.

c) videobuf framework

Many bugs and confusing constructs were identified. Note that proposed name
changes are only that: proposals. When the actual implementation is made the
name may turn out to be completely different from what is suggested here.

- Fix poll behavior for output: POLLIN|POLLRDNORM is set for output devices
  instead of POLLOUT|POLLWRNORM as is specified in the spec. This must be fixed
  for mem-to-mem devices.
- Run checkpatch.pl over all videobuf sources + headers and post cleanup 
patches.
- Propose to remove the magic fields in the ops. Seems to be absolutely no
  reason for those. All the magic checks just pollute the code.
- Rename confusing variable, function and macro names.
- Add support for REQBUFS calls with count = 0.
- Split videobuf_queue_cancel into cancel and free operations. Do not free the
  buffers on streamoff, that's really wrong.
- Rename buf_setup to queue_negotiate.
- Split buf_prepare() into buf_init() (only called once on first QBUF) and
  buf_prepare().
- Move actual buffer allocation to REQBUFS as per spec. Currently the buffers 
are
  allocated during mmap, which is unexpected. The application should be able to
  rely on the 'count' that REQBUFS returns.
- Split buf_release() into buf_cleanup() (only called once) and queue_cancel().
- Move wait queue per buffer to a wait queue per videobuf_queue. This makes it
  possible to dequeue buffers in a different 

[GIT FIXES FOR 2.6.34] Fixes for vpfe capture driver

2010-03-13 Thread Muralidharan Karicheri
Mauro,

The following changes since commit 9178a7c062ff0c43e95d826419f9e9454c52ef15:
  Mauro Carvalho Chehab (1):
V4L/DVB: Fix bad whitespacing

are available in the git repository at:

  git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git fixes_for_upstream

Murali Karicheri (1):
  V4L: vpfe_capture - free ccdc_lock when memory allocation fails

Vaibhav Hiremath (1):
  V4L - Makfile:Removed duplicate entry of davinci

 drivers/media/video/Makefile   |2 --
 drivers/media/video/davinci/vpfe_capture.c |5 +++--
 2 files changed, 3 insertions(+), 4 deletions(-)


-- 
Murali Karicheri
mkarich...@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


Re: Remaining drivers that aren't V4L2?

2010-03-13 Thread Devin Heitmueller
On Sat, Mar 13, 2010 at 1:33 AM, Hans de Goede hdego...@redhat.com wrote:
 usbvideo

 This actually is a framework for usb video devices a bit like
 gspca one could say. It supports the following devices:

 USB 3com HomeConnect (aka vicam)
 USB IBM (Xirlink) C-it Camera
 USB Konica Webcam support
 USB Logitech Quickcam Messenger

 Of which the Logitech Quickcam Messenger has a gspca subdriver
 now, and is scheduled for removal.

Now that I see the product list, I realize that I actually have a 3com
HomeConnect kicking around in a box.  So if nobody gets around to it,
I could probably kill a few hours and do the conversion (given that
was a fairly popular product at the time).

Or would it be better to convert the products to gpsca (I don't
actually know/understand if that's possible at this point)?

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


[PATCH] support for Hama DVB-T Hybrid (147f:2758)

2010-03-13 Thread Piotr Oleszczyk
Hello,
i made a patch that adds support for digital part of Hama DVB-T Hybrid
USB Stick. This card is identical as Terratec Cinergy HT USB XE so it
needed only adding USB IDs.
It'd be great if anybody could test it too.
Piotr

Signed-off-by: Piotr Oleszczyk patac...@gmail.com
--- a/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Thu Mar 11
09:10:14 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c Sat Mar 13
15:25:08 2010 +
@@ -2053,6 +2053,7 @@
 /* 65 */{ USB_DEVICE(USB_VID_PINNACLE, USB_PID_PINNACLE_PCTV73ESE) },
{ USB_DEVICE(USB_VID_PINNACLE,  USB_PID_PINNACLE_PCTV282E) },
{ USB_DEVICE(USB_VID_DIBCOM,USB_PID_DIBCOM_STK8096GP) },
+   { USB_DEVICE(USB_VID_HAMA,  USB_PID_HAMA_DVBT_HYBRID) },
{ 0 }   /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -2448,7 +2449,7 @@
},
},

-   .num_device_descs = 9,
+   .num_device_descs = 10,
.devices = {
{   Terratec Cinergy HT USB XE,
{ dib0700_usb_id_table[27], NULL },
@@ -2486,6 +2487,10 @@
{ dib0700_usb_id_table[54], NULL },
{ NULL },
},
+   {   Hama DVB-T Hybrid USB Stick,
+   { dib0700_usb_id_table[68], NULL },
+   { NULL },
+   },
},
.rc_interval  = DEFAULT_RC_INTERVAL,
.rc_key_map   = dib0700_rc_keys,
diff -r 0d06fd6b500e linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Thu Mar 11
09:10:14 2010 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sat Mar 13
15:25:08 2010 +
@@ -66,6 +66,7 @@
 #define USB_VID_EVOLUTEPC  0x1e59
 #define USB_VID_AZUREWAVE  0x13d3
 #define USB_VID_TECHNISAT  0x14f7
+#define USB_VID_HAMA   0x147f

 /* Product IDs */
 #define USB_PID_ADSTECH_USB2_COLD  0xa333
@@ -298,4 +299,5 @@
 #define USB_PID_AZUREWAVE_AZ6027   0x3275
 #define USB_PID_TERRATEC_DVBS2CI   0x3275
 #define USB_PID_TECHNISAT_USB2_HDCI0x0002
+#define USB_PID_HAMA_DVBT_HYBRID   0x2758
 #endif
--
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: changeset 14351:2eda2bcc8d6f

2010-03-13 Thread Hans Verkuil
Hi Hartmut,

After reviewing your patch I realized that more needed to be done to get this
to work properly. The core problem is that the probe function does not have a
counterpart that can do a cleanup.

So if the probe fails, then v4l2_device_unregister will never be called, which
is a particular problem on mxb.

I've made a new patch that basically reverts my original patch and instead
modifies the mxb driver. I realized that mxb doesn't need to do a separate
probe. Instead attach can just call probe and return an error if it fails.

This way I can avoid the devinit and the cleanup is also much more 
straightforward.

If there are no further comments, then I'll post a pull request in a few days.

Tested with the mxb board. It would be nice if you can verify this with the
av7110.

Regards,

Hans

diff --git a/drivers/media/common/saa7146_fops.c 
b/drivers/media/common/saa7146_fops.c
index fd8e1f4..7364b96 100644
--- a/drivers/media/common/saa7146_fops.c
+++ b/drivers/media/common/saa7146_fops.c
@@ -423,15 +423,14 @@ static void vv_callback(struct saa7146_dev *dev, unsigned 
long status)
}
 }
 
-int saa7146_vv_devinit(struct saa7146_dev *dev)
-{
-   return v4l2_device_register(dev-pci-dev, dev-v4l2_dev);
-}
-EXPORT_SYMBOL_GPL(saa7146_vv_devinit);
-
 int saa7146_vv_init(struct saa7146_dev* dev, struct saa7146_ext_vv *ext_vv)
 {
struct saa7146_vv *vv;
+   int err;
+
+   err = v4l2_device_register(dev-pci-dev, dev-v4l2_dev);
+   if (err)
+   return err;
 
vv = kzalloc(sizeof(struct saa7146_vv), GFP_KERNEL);
if (vv == NULL) {
diff --git a/drivers/media/video/hexium_gemini.c 
b/drivers/media/video/hexium_gemini.c
index e620a3a..ad2c232 100644
--- a/drivers/media/video/hexium_gemini.c
+++ b/drivers/media/video/hexium_gemini.c
@@ -356,9 +356,6 @@ static int hexium_attach(struct saa7146_dev *dev, struct 
saa7146_pci_extension_d
 
DEB_EE((.\n));
 
-   ret = saa7146_vv_devinit(dev);
-   if (ret)
-   return ret;
hexium = kzalloc(sizeof(struct hexium), GFP_KERNEL);
if (NULL == hexium) {
printk(hexium_gemini: not enough kernel memory in 
hexium_attach().\n);
diff --git a/drivers/media/video/hexium_orion.c 
b/drivers/media/video/hexium_orion.c
index fe596a1..938a1f8 100644
--- a/drivers/media/video/hexium_orion.c
+++ b/drivers/media/video/hexium_orion.c
@@ -216,10 +216,6 @@ static int hexium_probe(struct saa7146_dev *dev)
return -EFAULT;
}
 
-   err = saa7146_vv_devinit(dev);
-   if (err)
-   return err;
-
hexium = kzalloc(sizeof(struct hexium), GFP_KERNEL);
if (NULL == hexium) {
printk(hexium_orion: hexium_probe: not enough kernel 
memory.\n);
diff --git a/drivers/media/video/mxb.c b/drivers/media/video/mxb.c
index 9f01f14..ef0c817 100644
--- a/drivers/media/video/mxb.c
+++ b/drivers/media/video/mxb.c
@@ -169,11 +169,7 @@ static struct saa7146_extension extension;
 static int mxb_probe(struct saa7146_dev *dev)
 {
struct mxb *mxb = NULL;
-   int err;
 
-   err = saa7146_vv_devinit(dev);
-   if (err)
-   return err;
mxb = kzalloc(sizeof(struct mxb), GFP_KERNEL);
if (mxb == NULL) {
DEB_D((not enough kernel memory.\n));
@@ -699,14 +695,17 @@ static struct saa7146_ext_vv vv_data;
 /* this function only gets called when the probing was successful */
 static int mxb_attach(struct saa7146_dev *dev, struct 
saa7146_pci_extension_data *info)
 {
-   struct mxb *mxb = (struct mxb *)dev-ext_priv;
+   struct mxb *mxb;
 
DEB_EE((dev:%p\n, dev));
 
-   /* checking for i2c-devices can be omitted here, because we
-  already did this in mxb_vl42_probe */
-
saa7146_vv_init(dev, vv_data);
+   if (mxb_probe(dev)) {
+   saa7146_vv_release(dev);
+   return -1;
+   }
+   mxb = (struct mxb *)dev-ext_priv;
+
vv_data.ops.vidioc_queryctrl = vidioc_queryctrl;
vv_data.ops.vidioc_g_ctrl = vidioc_g_ctrl;
vv_data.ops.vidioc_s_ctrl = vidioc_s_ctrl;
@@ -726,6 +725,7 @@ static int mxb_attach(struct saa7146_dev *dev, struct 
saa7146_pci_extension_data
vv_data.ops.vidioc_default = vidioc_default;
if (saa7146_register_device(mxb-video_dev, dev, mxb, 
VFL_TYPE_GRABBER)) {
ERR((cannot register capture v4l2 device. skipping.\n));
+   saa7146_vv_release(dev);
return -1;
}
 
@@ -846,7 +846,6 @@ static struct saa7146_extension extension = {
.pci_tbl= pci_tbl[0],
.module = THIS_MODULE,
 
-   .probe  = mxb_probe,
.attach = mxb_attach,
.detach = mxb_detach,
 
diff --git a/include/media/saa7146_vv.h b/include/media/saa7146_vv.h
index b9da1f5..4aeff96 100644
--- a/include/media/saa7146_vv.h
+++ b/include/media/saa7146_vv.h
@@ -188,7 +188,6 @@ void 

Re: Analog (PAL) PCI or PCIe with MPEG HW encoder

2010-03-13 Thread Andy Walls
On Fri, 2010-03-12 at 18:57 +0100, RoboSK wrote:
 Hi, exist Analog (PAL) PCI or PCIe with MPEG HW encoder card that is 
 supported into linux and is still possible purchase this card into shop 
 (as new)?

Hans already mentioned the PVR-150 as a CX23416 PCI based card supported
by ivtv.

For CX23418 PCI based cards, you may want to check if the 

1. Hauppauge HVR-1600
2. LeadTek WinFast DVR3100 H
3. LeadTek WinFast PVR2100
4. Compro VideoMate H900
5. Yuan MPC-718 (mini-PCI)
6. Yuan PG-718 (this may need some tweaks in the linux driver)

are available and meet your needs.


For PCIe based cards, there are a few cards with an CX23417 MPEG encoder
connected to a CX2388[578] bridge, supported by the cx23885 driver.
However, as I understand it, analog TV support in the cx23885 driver is
minimal and works only for a few cards.

Regards,
Andy

 thanks
 
 Robo


--
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 1/5] drivers/media/video/cx23885 needs kfifo conversion

2010-03-13 Thread Andy Walls
On Sat, 2010-03-13 at 13:59 +0100, Stefani Seibold wrote:
 Am Donnerstag, den 11.03.2010, 14:02 -0800 schrieb
 a...@linux-foundation.org:
  From: Andrew Morton a...@linux-foundation.org
  
  linux-next:
  
  drivers/media/video/cx23885/cx23888-ir.c: In function 
  'cx23888_ir_irq_handler':
  drivers/media/video/cx23885/cx23888-ir.c:597: error: implicit declaration 
  of function 'kfifo_put'
  drivers/media/video/cx23885/cx23888-ir.c: In function 'cx23888_ir_rx_read':
  drivers/media/video/cx23885/cx23888-ir.c:660: error: implicit declaration 
  of function 'kfifo_get'
  drivers/media/video/cx23885/cx23888-ir.c: In function 'cx23888_ir_probe':
  drivers/media/video/cx23885/cx23888-ir.c:1172: warning: passing argument 1 
  of 'kfifo_alloc' makes pointer from integer without a cast
  drivers/media/video/cx23885/cx23888-ir.c:1172: warning: passing argument 3 
  of 'kfifo_alloc' makes integer from pointer without a cast
  drivers/media/video/cx23885/cx23888-ir.c:1172: warning: assignment makes 
  pointer from integer without a cast
  drivers/media/video/cx23885/cx23888-ir.c:1178: warning: passing argument 1 
  of 'kfifo_alloc' makes pointer from integer without a cast
  drivers/media/video/cx23885/cx23888-ir.c:1178: warning: passing argument 3 
  of 'kfifo_alloc' makes integer from pointer without a cast
  drivers/media/video/cx23885/cx23888-ir.c:1178: warning: assignment makes 
  pointer from integer without a cast
  
 
 This looks fine in 2.6.33. I don't know who reverted it in linux-next.
 

Things also look OK at the v4l-dvb GIT repositories:

http://git.linuxtv.org/v4l-dvb.git?a=blob;f=drivers/media/video/cx23885/cx23888-ir.c;hb=HEAD

http://git.linuxtv.org/linux-2.6.git?a=blob;f=drivers/media/video/cx23885/cx23888-ir.c;hb=HEAD

As far as I recall, this file should not have changed since the original
changes for the new kfifo implementation.

Regards,
Andy


--
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 1/5] drivers/media/video/cx23885 needs kfifo conversion

2010-03-13 Thread Andy Walls
On Thu, 2010-03-11 at 14:02 -0800, a...@linux-foundation.org wrote:
 From: Andrew Morton a...@linux-foundation.org
 
 linux-next:
 
 drivers/media/video/cx23885/cx23888-ir.c: In function 
 'cx23888_ir_irq_handler':
 drivers/media/video/cx23885/cx23888-ir.c:597: error: implicit declaration of 
 function 'kfifo_put'
 drivers/media/video/cx23885/cx23888-ir.c: In function 'cx23888_ir_rx_read':
 drivers/media/video/cx23885/cx23888-ir.c:660: error: implicit declaration of 
 function 'kfifo_get'
 drivers/media/video/cx23885/cx23888-ir.c: In function 'cx23888_ir_probe':
 drivers/media/video/cx23885/cx23888-ir.c:1172: warning: passing argument 1 of 
 'kfifo_alloc' makes pointer from integer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1172: warning: passing argument 3 of 
 'kfifo_alloc' makes integer from pointer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1172: warning: assignment makes 
 pointer from integer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1178: warning: passing argument 1 of 
 'kfifo_alloc' makes pointer from integer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1178: warning: passing argument 3 of 
 'kfifo_alloc' makes integer from pointer without a cast
 drivers/media/video/cx23885/cx23888-ir.c:1178: warning: assignment makes 
 pointer from integer without a cast
 
 Cc: Stefani Seibold stef...@seibold.net
 DESC
 drivers/media/video/cx23885: needs kfifo updates
 EDESC
 From: Andrew Morton a...@linux-foundation.org
 
 linux-next again.
 
 Cc: Stefani Seibold stef...@seibold.net
 Signed-off-by: Andrew Morton a...@linux-foundation.org
 ---
 
  drivers/media/video/cx231xx/Kconfig |1 +
  drivers/media/video/cx23885/Kconfig |1 +
  2 files changed, 2 insertions(+)
 
 diff -puN 
 drivers/media/video/cx231xx/Kconfig~drivers-media-video-cx23885-needs-kfifo-conversion
  drivers/media/video/cx231xx/Kconfig
 --- 
 a/drivers/media/video/cx231xx/Kconfig~drivers-media-video-cx23885-needs-kfifo-conversion
 +++ a/drivers/media/video/cx231xx/Kconfig
 @@ -1,6 +1,7 @@
  config VIDEO_CX231XX
   tristate Conexant cx231xx USB video capture support
   depends on VIDEO_DEV  I2C  INPUT
 + depends on BROKEN
   select VIDEO_TUNER
   select VIDEO_TVEEPROM
   select VIDEO_IR

NAck.

What does the cx231xx driver have to do with a cx23885 driver build
problem?


 diff -puN 
 drivers/media/video/cx23885/Kconfig~drivers-media-video-cx23885-needs-kfifo-conversion
  drivers/media/video/cx23885/Kconfig
 --- 
 a/drivers/media/video/cx23885/Kconfig~drivers-media-video-cx23885-needs-kfifo-conversion
 +++ a/drivers/media/video/cx23885/Kconfig
 @@ -1,6 +1,7 @@
  config VIDEO_CX23885
   tristate Conexant cx23885 (2388x successor) support
   depends on DVB_CORE  VIDEO_DEV  PCI  I2C  INPUT
 + depends on BROKEN
   select I2C_ALGOBIT
   select VIDEO_BTCX
   select VIDEO_TUNER
 _

You should also Cc: Steve Toth if you are proposing disabling the
cx23885 driver.


Steve,

To bring you up to speed, it looks like someone errantly reverted some
cx23888-ir.c changes for kfifo from linux-next, when the code in 2.6.33
was correct.

Regards,
Andy

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


STB0899 multiple transport stream

2010-03-13 Thread Giuseppe Cannarella

I try to demodulate an DVBS-2 8PSK signal. It's a multiple MPEG TS.
The STB0899 driver support multiple transport stream?
I read matype 1 and 2. I have two stream with ISI 1 and 2.
Now ,what is the procedure to forward the transport stream 1 or 2 to TS 
output?


Thanks
Giuseppe





__ Informazioni da ESET Smart Security, versione del database delle 
firme digitali 4941 (20100313) __

Il messaggio รจ stato controllato da ESET Smart Security.

www.nod32.it



--
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: Remaining drivers that aren't V4L2?

2010-03-13 Thread Hans de Goede

Hi,

On 03/13/2010 03:23 PM, Devin Heitmueller wrote:

On Sat, Mar 13, 2010 at 1:33 AM, Hans de Goedehdego...@redhat.com  wrote:

usbvideo


This actually is a framework for usb video devices a bit like
gspca one could say. It supports the following devices:

USB 3com HomeConnect (aka vicam)
USB IBM (Xirlink) C-it Camera
USB Konica Webcam support
USB Logitech Quickcam Messenger

Of which the Logitech Quickcam Messenger has a gspca subdriver
now, and is scheduled for removal.


Now that I see the product list, I realize that I actually have a 3com
HomeConnect kicking around in a box.  So if nobody gets around to it,
I could probably kill a few hours and do the conversion (given that
was a fairly popular product at the time).

Or would it be better to convert the products to gpsca (I don't
actually know/understand if that's possible at this point)?



It would be much better to change it into a gspca subdriver, gspca is
a generic framework for usb webcams, and as such has a lot of code
which all these devices need shared in place, making the subdrivers
quite small, and nice to write as you can focus on the actual
camera specifics instead of on things like getting locking in case of
hot unplug while an app is streaming right.

Regards,

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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2010-03-13 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Sat Mar 13 19:00:32 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14435:85a2d6034e20
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-armv5: OK
linux-2.6.34-rc1-armv5: OK
linux-2.6.32.6-armv5-davinci: OK
linux-2.6.33-armv5-davinci: OK
linux-2.6.34-rc1-armv5-davinci: OK
linux-2.6.32.6-armv5-ixp: OK
linux-2.6.33-armv5-ixp: OK
linux-2.6.34-rc1-armv5-ixp: OK
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-armv5-omap2: OK
linux-2.6.34-rc1-armv5-omap2: OK
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.17-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.20-i686: WARNINGS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-rc1-i686: WARNINGS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-rc1-m32r: OK
linux-2.6.32.6-mips: OK
linux-2.6.33-mips: OK
linux-2.6.34-rc1-mips: OK
linux-2.6.32.6-powerpc64: WARNINGS
linux-2.6.33-powerpc64: WARNINGS
linux-2.6.34-rc1-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.17-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.20-x86_64: WARNINGS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-rc1-x86_64: WARNINGS
linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec: ERRORS
spec-git: OK
sparse: ERRORS
linux-2.6.16.62-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.7-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: OK
linux-2.6.16.62-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.7-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: OK

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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


[HG PULL] http://linuxtv.org/hg/~awalls/cx18-changes

2010-03-13 Thread Andy Walls
Mauro,

Please pull from http://linuxtv.org/hg/~awalls/cx18-changes

for the following 2 changesets:

01/02: cx18: Add support for component video inputs
http://linuxtv.org/hg/~awalls/cx18-changes?cmd=changeset;node=e253c7ba11c0

02/02: cx18: Add a component video input to the PVR2100 and DVR3200H card 
entries
http://linuxtv.org/hg/~awalls/cx18-changes?cmd=changeset;node=145b18b20689


 cx18-av-core.c |   33 +
 cx18-av-core.h |   19 +++
 cx18-cards.c   |4 +++-
 cx18-cards.h   |4 ++--
 4 files changed, 53 insertions(+), 7 deletions(-)

Thanks,
Andy


--
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] V4L/DVB: ir: Add a link to associate /sys/class/ir/irrcv with the input device

2010-03-13 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote:
 On Fri, Mar 12, 2010 at 01:32:23AM -0300, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
 Hi Mauro,

 On Thu, Mar 11, 2010 at 12:46:19PM -0300, Mauro Carvalho Chehab wrote:
 In order to allow userspace programs to autoload an IR table, a link is
 needed to point to the corresponding input device.

 $ tree /sys/class/irrcv/irrcv0
 /sys/class/irrcv/irrcv0
 |-- current_protocol
 |-- input - ../../../pci:00/:00:0b.1/usb1/1-3/input/input22
 |-- power
 |   `-- wakeup
 |-- subsystem - ../../../../class/irrcv
 `-- uevent

 It is now easy to associate an irrcv device with the corresponding
 device node, at the input interface.

 I guess the question is why don't you make input device a child of your
 irrcvX device? Then I believe driver core will link them properly. It
 will also ensure proper power management hierarchy.

 That probably will require you changing from class_dev into device but
 that's the direction kernel is going to anyway.
 Done, see enclosed. It is now using class_register/device_register. The
 newly created device for irrcv is used as the parent for input_dev-dev.

 The resulting code looked cleaner after the change ;)

 
 It is indeed better, however I wonder if current hierarchy expresses the
 hardware in best way. You currently have irrcv devices grow in parallel
 with input devices whereas I would expect input devices be children of
 irrcv devices:
 
 
   parent (PCI board, USB) - irrcvX - input1
   - input2
...
 

It is representing it right:

usb1/1-3 - irrcv - irrcv0 - input7 - event7

The only extra attribute there is the class name irrcv, but this seems
coherent with the other classes on this device (dvb, sound, power, video4linux).

The created tree is:

$ tree /sys/class/irrcv/
/sys/class/irrcv/
`-- irrcv0 - ../../devices/pci:00/:00:0b.1/usb1/1-3/irrcv/irrcv0

$ tree /sys/devices/pci:00/:00:0b.1/usb1/1-3/
/sys/devices/pci:00/:00:0b.1/usb1/1-3/
|-- 1-3:1.0
|   |-- bAlternateSetting
|   |-- bInterfaceClass
|   |-- bInterfaceNumber
|   |-- bInterfaceProtocol
|   |-- bInterfaceSubClass
|   |-- bNumEndpoints
|   |-- driver - ../../../../../../bus/usb/drivers/em28xx
|   |-- ep_81
|   |   |-- bEndpointAddress
|   |   |-- bInterval
|   |   |-- bLength
|   |   |-- bmAttributes
|   |   |-- direction
|   |   |-- interval
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- type
|   |   |-- uevent
|   |   `-- wMaxPacketSize
|   |-- ep_82
|   |   |-- bEndpointAddress
|   |   |-- bInterval
|   |   |-- bLength
|   |   |-- bmAttributes
|   |   |-- direction
|   |   |-- interval
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- type
|   |   |-- uevent
|   |   `-- wMaxPacketSize
|   |-- ep_83
|   |   |-- bEndpointAddress
|   |   |-- bInterval
|   |   |-- bLength
|   |   |-- bmAttributes
|   |   |-- direction
|   |   |-- interval
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- type
|   |   |-- uevent
|   |   `-- wMaxPacketSize
|   |-- ep_84
|   |   |-- bEndpointAddress
|   |   |-- bInterval
|   |   |-- bLength
|   |   |-- bmAttributes
|   |   |-- direction
|   |   |-- interval
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- type
|   |   |-- uevent
|   |   `-- wMaxPacketSize
|   |-- modalias
|   |-- power
|   |   `-- wakeup
|   |-- subsystem - ../../../../../../bus/usb
|   |-- supports_autosuspend
|   |-- uevent
|   `-- video4linux
|   |-- vbi2
|   |   |-- dev
|   |   |-- device - ../../../1-3:1.0
|   |   |-- index
|   |   |-- name
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- subsystem - ../../../../../../../../class/video4linux
|   |   `-- uevent
|   `-- video2
|   |-- dev
|   |-- device - ../../../1-3:1.0
|   |-- index
|   |-- name
|   |-- power
|   |   `-- wakeup
|   |-- subsystem - ../../../../../../../../class/video4linux
|   `-- uevent
|-- authorized
|-- bcdDevice
|-- bConfigurationValue
|-- bDeviceClass
|-- bDeviceProtocol
|-- bDeviceSubClass
|-- bmAttributes
|-- bMaxPacketSize0
|-- bMaxPower
|-- bNumConfigurations
|-- bNumInterfaces
|-- busnum
|-- configuration
|-- descriptors
|-- dev
|-- devnum
|-- devpath
|-- driver - ../../../../../bus/usb/drivers/usb
|-- dvb
|   |-- dvb0.demux0
|   |   |-- dev
|   |   |-- device - ../../../1-3
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- subsystem - ../../../../../../../class/dvb
|   |   `-- uevent
|   |-- dvb0.dvr0
|   |   |-- dev
|   |   |-- device - ../../../1-3
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- subsystem - ../../../../../../../class/dvb
|   |   `-- uevent
|   |-- dvb0.frontend0
|   |   |-- dev
|   |   |-- device - ../../../1-3
|   |   |-- power
|   |   |   `-- wakeup
|   |   |-- subsystem - ../../../../../../../class/dvb
|   |   `-- uevent
|   `-- dvb0.net0
|   |-- dev
|   |-- device - ../../../1-3
|   |-- power
|   |   `-- wakeup
|   |-- 

[PATCH for v4l-utils] qv4l2: fix UVC support

2010-03-13 Thread Hans Verkuil
Hans,

Can you apply this to v4l-utils?

Thanks!

Hans

From 977eb253a3e7a5257a2051da240314e2dac385bf Mon Sep 17 00:00:00 2001
From: Hans Verkuil hverk...@xs4all.nl
Date: Sat, 13 Mar 2010 23:19:48 +0100
Subject: [PATCH] qv4l2: fix UVC support

The workaround for drivers using videobuf broke the UVC support.
Fix this.

Signed-off-by: Hans Verkuil hverk...@xs4all.nl
---
 utils/qv4l2-qt4/general-tab.cpp |   18 +++---
 utils/qv4l2-qt4/qv4l2.cpp   |4 +++-
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/utils/qv4l2-qt4/general-tab.cpp b/utils/qv4l2-qt4/general-tab.cpp
index 50a3edc..706b15d 100644
--- a/utils/qv4l2-qt4/general-tab.cpp
+++ b/utils/qv4l2-qt4/general-tab.cpp
@@ -198,11 +198,23 @@ GeneralTab::GeneralTab(const QString device, v4l2 fd, 
int n, QWidget *parent)
if (m_querycap.capabilities  V4L2_CAP_STREAMING) {
v4l2_requestbuffers reqbuf;
 
-   if (reqbufs_user_cap(reqbuf, 1))
+   // Yuck. The videobuf framework does not accept a count of 0.
+   // This is out-of-spec, but it means that the only way to test 
which
+   // method is supported is to give it a non-zero count. But 
non-videobuf
+   // drivers like uvc do not allow e.g. S_FMT calls after a 
REQBUFS call
+   // with non-zero counts unless there is a REQBUFS call with 
count == 0
+   // in between. This is actual proper behavior, although somewhat
+   // unexpected. So the only way at the moment to do this that 
works
+   // everywhere is to call REQBUFS with a count of 1, and then 
again with
+   // a count of 0.
+   if (reqbufs_user_cap(reqbuf, 1)) {
m_capMethods-addItem(User pointer I/O, 
QVariant(methodUser));
-
-   if (reqbufs_mmap_cap(reqbuf, 1))
+   reqbufs_user_cap(reqbuf, 0);
+   }
+   if (reqbufs_mmap_cap(reqbuf, 1)) {
m_capMethods-addItem(Memory mapped I/O, 
QVariant(methodMmap));
+   reqbufs_mmap_cap(reqbuf, 0);
+   }
}
if (m_querycap.capabilities  V4L2_CAP_READWRITE) {
m_capMethods-addItem(read(), QVariant(methodRead));
diff --git a/utils/qv4l2-qt4/qv4l2.cpp b/utils/qv4l2-qt4/qv4l2.cpp
index 96cb4d7..63881be 100644
--- a/utils/qv4l2-qt4/qv4l2.cpp
+++ b/utils/qv4l2-qt4/qv4l2.cpp
@@ -352,7 +352,7 @@ void ApplicationWindow::stopCapture()
if (-1 == munmap(m_buffers[i].start, 
m_buffers[i].length))
perror(munmap);
// Free all buffers.
-   reqbufs_mmap_out(reqbufs, 0);
+   reqbufs_mmap_cap(reqbufs, 0);
break;
 
case methodUser:
@@ -360,6 +360,8 @@ void ApplicationWindow::stopCapture()
perror(VIDIOC_STREAMOFF);
for (i = 0; i  m_nbuffers; ++i)
free(m_buffers[i].start);
+   // Free all buffers.
+   reqbufs_user_cap(reqbufs, 0);
break;
}
free(m_buffers);
-- 
1.6.4.2


-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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 for v4l-utils] qv4l2: fix UVC support

2010-03-13 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 Hans,
 
 Can you apply this to v4l-utils?

Hans V.,

You have access to v4l-utils. It would be nice if you could try to
apply it directly, for us to double check if the server is properly
working with a shared repository.

-- 

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


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-03-13 Thread Andy Walls
On Fri, 2010-03-12 at 21:34 +1100, Vincent McIntyre wrote:
 On 2/20/10, Mauro Carvalho Chehab mche...@redhat.com wrote:
  Robert Lowery wrote:
  Mauro,
 
  I had to make 2 changes to get the patch to work for me
 
  Ok. Please test this (hopefully) final revision.
 
  --
 
  commit bd8bb8798bb96136b6898186d505c9e154334b5d
  Author: Mauro Carvalho Chehab mche...@redhat.com
  Date:   Fri Feb 19 02:45:00 2010 -0200
 
 I finally found time to test carefully and if anyone still cares, the
 patch works fine for me too.
 I pulled it in from the hg tree, by the time it got there it had
 morphed a little...
 Many thanks for your (and Rob's) patient work on this.
 
 I've attached a test log that shows what happens with signaltest.pl,
 on each tuner.
 The first two adapters are the Dual Digital 4 rev1, the next two
 belong to a FusionHDTV Dual Digital Express.
 
 The errors are nice and small now, compared with the values I got
 before the patch.
 I noticed something a little odd - the UNC error value always
 increases, even though
 signaltest.pl does a fresh invocation for each station in the sequence.

This is proper behavior for the frontend.  The UNC count should not be
reset when it is read (think of what would happen when more than one app
was trying to monitor the frontend status).

What matters is the slope of the UNC curve over a measurement interval:
== 0 is good,  0 is bad.


 Switching to a different tuner seems to reset the UNC error counters.

The zl10353 driver will maintain the UNC block count for each paticular
ZL10353 chip in the system.  It will only go back to 0 for a particular
ZL10353 chip when the the driver's 32 bit state-ucblocks variable for
that chip rolls over.

Regards,
Andy

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


[HG PULL] http://linuxtv.org/hg/~awalls/ivtv-changes

2010-03-13 Thread Andy Walls
Mauro,

Please pull from http://linuxtv.org/hg/~awalls/ivtv-changes

for the following 2 changesets:

01/02: ivtv: Avoid hard system lock on decoder output mode change
http://linuxtv.org/hg/~awalls/ivtv-changes?cmd=changeset;node=129f5ef593d2

02/02: ivtv, ivtvfb: Use a define for the output line and field register address
http://linuxtv.org/hg/~awalls/ivtv-changes?cmd=changeset;node=62473be834dc


 ivtv-driver.c |5 -
 ivtv-driver.h |3 +++
 ivtv-ioctl.c  |   23 ++-
 ivtv-irq.c|8 +---
 ivtvfb.c  |2 +-
 5 files changed, 35 insertions(+), 6 deletions(-)

Thanks,
Andy

--
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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants

2010-03-13 Thread Daro

Hi Jean,

I am back and ready to go :)
As I am not much experienced Linux user I would apprieciate some more 
details:


I have few linux kernels installed; which one should I test or it does 
not matter?

2.6.31-14-generic
2.6.31-16-generic
2.6.31-17-generic
2.6.31-19-generic
2.6.31-20-generic

and one I compiled myself
2.6.32.2

I assume that to proceed with a test I should patch the certain version 
of kernel and compile it or could it be done other way?


Best regards
Daro



W dniu 12.03.2010 10:38, Jean Delvare pisze:

Hi Daro,

On Fri, 26 Feb 2010 17:19:38 +0100, Daro wrote:
   

I did not forget I had offered to test the patch however I am now on vacation 
skiing so I will get back to you as soon I am back home.
 

Are you back home by now? We are still waiting for your test results.
We can't push the patch upstream without it, and if it takes too long,
I'll probably just discard the patch and move to other tasks.

   


--
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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants

2010-03-13 Thread hermann pitton

Am Sonntag, den 14.03.2010, 03:38 +0100 schrieb Daro:
 Hi Jean,
 
 I am back and ready to go :)
 As I am not much experienced Linux user I would apprieciate some more 
 details:
 
 I have few linux kernels installed; which one should I test or it does 
 not matter?
 2.6.31-14-generic
 2.6.31-16-generic
 2.6.31-17-generic
 2.6.31-19-generic
 2.6.31-20-generic
 
 and one I compiled myself
 2.6.32.2
 
 I assume that to proceed with a test I should patch the certain version 
 of kernel and compile it or could it be done other way?
 
 Best regards
 Daro
 
 
 
 W dniu 12.03.2010 10:38, Jean Delvare pisze:
  Hi Daro,
 
  On Fri, 26 Feb 2010 17:19:38 +0100, Daro wrote:
 
  I did not forget I had offered to test the patch however I am now on 
  vacation skiing so I will get back to you as soon I am back home.
   
  Are you back home by now? We are still waiting for your test results.
  We can't push the patch upstream without it, and if it takes too long,
  I'll probably just discard the patch and move to other tasks.
 
 


Hi Daro,

thanks for being back on it.

Damned jokes aside, and not made. Sorry, let know if you have any
problems to get Jeans patch stuff applied.

Jean's review is good and valuable and we might to have to come back to
it, if stuff with the same PCI subsystem and different remotes is
validated to be out. (The LNA hell is even much more burning ;)

It very much looks like that is already the case.

It is a little confusing these days, patch p0, p1, hg or git patches.

I let it to Jean, how to test best for now, but will help to prepare you
with stuff you can test easily under any conditions.

Cheers,
Hermann







--
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: v4l-utils, dvb-utils, xawtv and alevt

2010-03-13 Thread hermann pitton

Am Samstag, den 13.03.2010, 14:43 +0100 schrieb Chicken Shack:
 Am Samstag, den 13.03.2010, 13:34 +0100 schrieb Hans de Goede:
  Hi,
  
  On 03/13/2010 11:15 AM, Chicken Shack wrote:
   Am Samstag, den 13.03.2010, 07:51 +0100 schrieb Hans de Goede:
   Hi,
  
   On 03/12/2010 08:10 PM, Chicken Shack wrote:
   1. Alevt 1.7.0 is not just another tool, but it is instead a
   self-contained videotext application consisting of three parts:
   a. alevt, b. alevt-date c. alevt-cap
  
   While the packed size of alevt is 78770 the complete size of the
   dvb-apps as a whole ranges around 35.
  
   I am not against hosting this program at linuxtv.org, but if this
   decision is made the decision should be an intelligent one: alevt is a
   separate tree, and any other choice is simply a dumb one.
   Alevt-1.7.0 needs a lot of external dependencies, while the dvb-apps
   only need the libc6.

More clever would have been never to rename it from alevt-dvb to alevt.
On the prior you don't have any rights and I seriously doubt you have
any on the later.

   Good morning Hans,
  
  
  Good afternoon :)
  
   Definitely not.
   3.95 is analogue only and thus is discontinued as version.
   4.0 pre is the alpha-state tarball that you can get here:

No, 3.95 is official and right for patching and 4x was never released.

I pointed to mpeg4ip only as a joke.

  Ah, ok. Well I must honestly say I've no interest in that I'm doing
  package maintenance for the 3.95 release in Fedora and I know it
  needs a lot of patching, AFAIK other distros are doing the same,
  so it would be good to have / become a new upstream for xawtv 3.95,
  to have a place to gather all the distro patches mostly and release
  that, and where new patches if needed can accumulate and new
  releases can be done from.
  
  
   http://dl.bytesex.org/cvs-snapshots/xawtv-20081014-100645.tar.gz
  
   Inofficial end of development somewhere in 2005 or 2006, last external
   contribution from October 2008.

It was on March 08 2005. You even don't know that?

http://linux.bytesex.org/v4l2/maintainer.txt

Maybe improve your Pinnacle stuff first, I can point you to a lot on the
TODO list.

Hermann






--
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] V4L/DVB: ir: Add a link to associate /sys/class/ir/irrcv with the input device

2010-03-13 Thread Dmitry Torokhov
On Sat, Mar 13, 2010 at 05:59:34PM -0300, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
  On Fri, Mar 12, 2010 at 01:32:23AM -0300, Mauro Carvalho Chehab wrote:
  Dmitry Torokhov wrote:
  Hi Mauro,
 
  On Thu, Mar 11, 2010 at 12:46:19PM -0300, Mauro Carvalho Chehab wrote:
  In order to allow userspace programs to autoload an IR table, a link is
  needed to point to the corresponding input device.
 
  $ tree /sys/class/irrcv/irrcv0
  /sys/class/irrcv/irrcv0
  |-- current_protocol
  |-- input - ../../../pci:00/:00:0b.1/usb1/1-3/input/input22
  |-- power
  |   `-- wakeup
  |-- subsystem - ../../../../class/irrcv
  `-- uevent
 
  It is now easy to associate an irrcv device with the corresponding
  device node, at the input interface.
 
  I guess the question is why don't you make input device a child of your
  irrcvX device? Then I believe driver core will link them properly. It
  will also ensure proper power management hierarchy.
 
  That probably will require you changing from class_dev into device but
  that's the direction kernel is going to anyway.
  Done, see enclosed. It is now using class_register/device_register. The
  newly created device for irrcv is used as the parent for input_dev-dev.
 
  The resulting code looked cleaner after the change ;)
 
  
  It is indeed better, however I wonder if current hierarchy expresses the
  hardware in best way. You currently have irrcv devices grow in parallel
  with input devices whereas I would expect input devices be children of
  irrcv devices:
  
  
  parent (PCI board, USB) - irrcvX - input1
- input2
   ...
  
 
 It is representing it right:
 
 usb1/1-3 - irrcv - irrcv0 - input7 - event7
 
 The only extra attribute there is the class name irrcv, but this seems
 coherent with the other classes on this device (dvb, sound, power, 
 video4linux).
 

Ah, yes, I saw where you take input device's parent and use it as
irrcv's parent but missed the piece where you substitute original
input device's parent with irrcv. I bit sneaky to my taste but I guess
can be cleaned up later.

-- 
Dmitry
--
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] tm6000: add new hybrid-stick

2010-03-13 Thread Stefan Ringel
Mauro,

you have accepted my patch, but it's not applied.

best regards

Stefan Ringel

-- 
Stefan Ringel stefan.rin...@arcor.de

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