Re: v4l-utils, dvb-utils, xawtv and alevt

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



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


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 ?




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.


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.

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: pushes at v4l-utils tree

[Hans de Goede]

Hi,

On 03/13/2010 02:24 AM, Mauro Carvalho Chehab wrote:

Please, don't upgrade the version yet just due to keytable, as I'm still 
working on
more keytable patches, to handle the new uevent attributes (to match the IR 
core patches
I posted earlier today).



Ok,

Note the main reason for the 0.7.91 release was a small libv4l fix which I 
wanted to get out there.

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: pushes at v4l-utils tree

[Hans de Goede]

Hi,

On 03/12/2010 08:29 PM, Mauro Carvalho Chehab wrote:

Hans de Goede wrote:

Hi,

On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:

Hi Hans,

As we've agreed that the idea is to allow multiple people to commit at
v4l-utils,
today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1
is .gitignore
stuff). One of the reasons were to test the viability for such commits.

I've temporarily enabled the same script that we use for upstream
patches to
generate patches against linuxtv-commits ML.

  From my experiences, I have some notes:
 1) git won't work fine if more than one is committing at the same
tree.
The reason is simple: it won't preserve the same group as the previous
commits. So,
the next committer will have troubles if we allow multiple committers;



I assume you are talking about some issues with permissions on the
server side here ?


Yes. The new objects and the touched files got a different group ownership
after git push. I had to manually fix them at the server.



I'll get you in touch with one of the Fedora infrastructure admins.

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

[Hans de Goede]

Hi,

On 03/12/2010 10:42 PM, Hans Verkuil wrote:

On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:

Hello,

I know some months ago, there was some discussion about a few drivers
which were stragglers and had not been converted from V4L to V4L2.

Do we have a current list of driver which still haven't been converted?




As Hans Verkuil already said I've been working on steadily converting
v4l1 usb device drivers to gspca sub drivers, removing a lot of
redundant code and making them v4l2.


These drivers are still v4l1:

arv
bw-qcam
c-qcam
cpia_pp



cpia_usb


This one has a gspca subdriver now, and has been marked as
deprecated in 2.6.34, and scheduled for removal.


ov511


This one has a gspca subdriver now, and has been marked as
deprecated in 2.6.34, and scheduled for removal.


se401


Hans Verkuil gave me a camera with such a chip, I've been
meaning to work on this for a while. Note that the v4l1 driver
is completely broken (hanhs the machine) which complicates writing
a v4l2 driver, as I either need to first fix the v4l1 driver,
or just copy do a v4l2 driver based on the info in the v4l1 driver,
without having a driver to compare with.


stradis



stv680


This one has a gspca subdriver now, and has been marked as
deprecated in 2.6.34, and scheduled for removal.


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.


w9966

Some of these have counterparts in gspca these days so possibly some drivers
can be removed by now. Hans, can you point those out?



See above. Note in order to finish the conversion of drivers to
v4l1 besides time (which can be made every now and then) I really
really need hardware access, so if anyone has one of the usbvideo supported
devices lying around, and is willing to ship it to me, please drop
me a private mail!



arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
and if no one steps up then they can be dropped altogether.



Ack!


According to my notes I should be able to test cpia_usb. I would have to
verify that, though. I think it is only used in a USB microscope. It is
effectively a webcam. I can also test usbvideo (USB 1 TV capture device).
The latter is probably the most important driver that needs converting,
because I think these are not uncommon.



You gave your cpia1 camera to me, so now I have 2 to test with, 1 from
creative and the brandless one from you. Also note that this indeed is
used in microscopes, but also in regular webcams, Either way the cpia1
is supported in gspca now (for the usb version).


However, I have no time to work on such a driver conversion. But if someone
is seriously willing to put time and effort in that, then I am willing to
mail the hardware.



You already did that, you gave me a cpia1, stv0680 and an se401 camera :)


I started doing some more tvtime work last night, and I would *love*
to drop V4L support (and *only* support V4L2 devices), since it would
make the code much cleaner, more reliable, and easier to test.

If there are only a few obscure webcams remaining, then I'm willing to
tell those users that they have to stick with whatever old version of
tvtime they've been using since the last release four years ago.


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.

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

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: pushes at v4l-utils tree

[Mauro Carvalho Chehab]

Mauro Carvalho Chehab wrote:
> Mauro Carvalho Chehab wrote:
>> Hans de Goede wrote:

>> Yes. The new objects and the touched files got a different group ownership
>> after git push. I had to manually fix them at the server.
> 
> I added a hook that will likely fix it. As I have a few more changes to 
> ir-keytable,
> I'll be sending it directly and see if the permissions are properly fixed.

After some work, it is now working properly. So, it is safe for the others to 
update
on it without breaking the permissions.

> Please, don't upgrade the version yet just due to keytable, as I'm still 
> working on
> more keytable patches, to handle the new uevent attributes (to match the IR 
> core patches
> I posted earlier today).

Added what I have for now. The ir-keytable is now doing a nice job reading the 
new
sysfs stuff from /sys/class/irrcv, with the new IR patches I posted. I'll add 
tomorrow
the ir-core patches at v4l-dvb tree, if no comments received.

The next item on keytable TODO list is to add ir-keytable at Makefile install 
target
and to put it to work together with udev. After those changes, it will be 
possible to
replace an IR table when a device is detected by udev. 

I'll probably write an example script to do a very basic udev setup,but a more 
sophisticated userspace tool would be needed to allow someone to do it
via some gui.

-- 

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

Capturing raw JPEG stream from webcam

[Basil Mohamed Gohar]

I originally posted this to the video4linux mailing list, but I've since
discovered that this is the appropriate place (or so I understand) for
video4linux questions.  My question is how can I capture the raw JPEG
image stream (e.g., MJPEG) from my webcam, which reports through v4l2
that it is capable of.  I am using the gst-launch cli to gstreamer,
which confirms that my webcam has this capability:
> image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
> 30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
And, indeed, I can capture using this capability, but the framerate is
not at the specified rate, but at a much lower value (half or less). 
So, even if I specify 30fps, I get something less.  I can capture the
full 30fps when I use one of the yuv modes, though, so it's clearly
capable of delivering that framerate.

My webcam is a Logitech QuickCam Pro 5000.  The lsusb output is:
> 046d:08ce Logitech, Inc. QuickCam Pro 5000
An example command line I try is as follows:
> gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
> height=480, framerate=30/1' ! jpegdec ! xvimagesink
Thank you in advance for any help!

-- 
  Basil Mohamed Gohar
abu_huray...@hidayahonline.org
http://www.basilgohar.com/blog
basilgohar on irc.freenode.net
GPG Key Fingerprint:  5AF4B362

--
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: pushes at v4l-utils tree

[Mauro Carvalho Chehab]

Mauro Carvalho Chehab wrote:
> Hans de Goede wrote:
>> Hi,
>>
>> On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
>>> Hi Hans,
>>>
>>> As we've agreed that the idea is to allow multiple people to commit at
>>> v4l-utils,
>>> today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1
>>> is .gitignore
>>> stuff). One of the reasons were to test the viability for such commits.
>>>
>>> I've temporarily enabled the same script that we use for upstream
>>> patches to
>>> generate patches against linuxtv-commits ML.
>>>
>>>  From my experiences, I have some notes:
>>> 1) git won't work fine if more than one is committing at the same
>>> tree.
>>> The reason is simple: it won't preserve the same group as the previous
>>> commits. So,
>>> the next committer will have troubles if we allow multiple committers;
>>>
>> I assume you are talking about some issues with permissions on the
>> server side here ?
> 
> Yes. The new objects and the touched files got a different group ownership
> after git push. I had to manually fix them at the server.

I added a hook that will likely fix it. As I have a few more changes to 
ir-keytable,
I'll be sending it directly and see if the permissions are properly fixed.

Please, don't upgrade the version yet just due to keytable, as I'm still 
working on
more keytable patches, to handle the new uevent attributes (to match the IR 
core patches
I posted earlier today).

-- 

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

[PATCH 1/4] V4L/DVB: ir: use a real device instead of a virtual class

[Mauro Carvalho Chehab]

Change the ir-sysfs approach to create irrcv0 as a device, instead of
using class_dev. Also, change the way input is registered, in order
to make its parent to be the irrcv device.

Due to this change, now the event device is created under
/sys/class/ir/irrcv class:

/sys/class/irrcv/irrcv0/
|-- current_protocol
|-- device -> ../../../1-3
|-- input9
|   |-- capabilities
|   |   |-- abs
...

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 0903f53..c9c0a54 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -448,22 +448,15 @@ int ir_input_register(struct input_dev *input_dev,
input_dev->setkeycode = ir_setkeycode;
input_set_drvdata(input_dev, ir_dev);
 
-   rc = input_register_device(input_dev);
-   if (rc < 0)
-   goto err;
-
rc = ir_register_class(input_dev);
-   if (rc < 0) {
-   input_unregister_device(input_dev);
+   if (rc < 0)
goto err;
-   }
 
return 0;
 
 err:
kfree(rc_tab->scan);
kfree(ir_dev);
-   input_set_drvdata(input_dev, NULL);
return rc;
 }
 EXPORT_SYMBOL_GPL(ir_input_register);
@@ -492,7 +485,6 @@ void ir_input_unregister(struct input_dev *dev)
ir_unregister_class(dev);
 
kfree(ir_dev);
-   input_unregister_device(dev);
 }
 EXPORT_SYMBOL_GPL(ir_input_unregister);
 
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index bf5fbcd..1bb011a 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -22,7 +22,15 @@
 static unsigned long ir_core_dev_number;
 
 /* class for /sys/class/irrcv */
-static struct class *ir_input_class;
+static char *ir_devnode(struct device *dev, mode_t *mode)
+{
+   return kasprintf(GFP_KERNEL, "irrcv/%s", dev_name(dev));
+}
+
+struct class ir_input_class = {
+   .name   = "irrcv",
+   .devnode= ir_devnode,
+};
 
 /**
  * show_protocol() - shows the current IR protocol
@@ -128,6 +136,20 @@ static struct attribute *ir_dev_attrs[] = {
NULL,
 };
 
+static struct attribute_group ir_dev_attr_grp = {
+   .attrs  =ir_dev_attrs,
+};
+
+static const struct attribute_group *ir_dev_attr_groups[] = {
+   &ir_dev_attr_grp,
+   NULL
+};
+
+static struct device_type ir_dev_type = {
+   .groups = ir_dev_attr_groups,
+};
+
+
 /**
  * ir_register_class() - creates the sysfs for /sys/class/irrcv/irrcv?
  * @input_dev: the struct input_dev descriptor of the device
@@ -137,7 +159,7 @@ static struct attribute *ir_dev_attrs[] = {
 int ir_register_class(struct input_dev *input_dev)
 {
int rc;
-   struct kobject *kobj;
+   const char *path;
 
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
int devno = find_first_zero_bit(&ir_core_dev_number,
@@ -146,19 +168,31 @@ int ir_register_class(struct input_dev *input_dev)
if (unlikely(devno < 0))
return devno;
 
-   ir_dev->attr.attrs = ir_dev_attrs;
-   ir_dev->class_dev = device_create(ir_input_class, NULL,
- input_dev->dev.devt, ir_dev,
- "irrcv%d", devno);
-   kobj = &ir_dev->class_dev->kobj;
+   ir_dev->dev.type = &ir_dev_type;
+   ir_dev->dev.class = &ir_input_class;
+   ir_dev->dev.parent = input_dev->dev.parent;
+   dev_set_name(&ir_dev->dev, "irrcv%d", devno);
+   rc = device_register(&ir_dev->dev);
+   if (rc)
+   return rc;
 
-   printk(KERN_WARNING "Creating IR device %s\n", kobject_name(kobj));
-   rc = sysfs_create_group(kobj, &ir_dev->attr);
-   if (unlikely(rc < 0)) {
-   device_destroy(ir_input_class, input_dev->dev.devt);
-   return -ENOMEM;
+
+   input_dev->dev.parent = &ir_dev->dev;
+   rc = input_register_device(input_dev);
+   if (rc < 0) {
+   device_del(&ir_dev->dev);
+   return rc;
}
 
+   __module_get(THIS_MODULE);
+
+   path = kobject_get_path(&input_dev->dev.kobj, GFP_KERNEL);
+   printk(KERN_INFO "%s: %s associated with sysfs %s\n",
+   dev_name(&ir_dev->dev),
+   input_dev->name ? input_dev->name : "Unspecified device",
+   path ? path : "N/A");
+   kfree(path);
+
ir_dev->devno = devno;
set_bit(devno, &ir_core_dev_number);
 
@@ -175,16 +209,12 @@ int ir_register_class(struct input_dev *input_dev)
 void ir_unregister_class(struct input_dev *input_dev)
 {
struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
-   struct kobject *kobj;
 
clear_bit(ir_dev->devno, &ir_core_dev_number);
+   input_unregister_device(input_dev);
+   device_del(&ir_dev->dev);
 
-   kobj = &ir_dev->class_dev->kobj;
-
-   sysfs_remove_group(kobj, &ir_dev->attr);
-   device_destroy(ir_input_class, input_dev->dev.devt);
-
-   k

[PATCH 2/4] Add a macro to properly create IR tables

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/IR/ir-keymaps.c b/drivers/media/IR/ir-keymaps.c
index 0efdefe..dfc777b 100644
--- a/drivers/media/IR/ir-keymaps.c
+++ b/drivers/media/IR/ir-keymaps.c
@@ -28,16 +28,28 @@
 #include 
 #include 
 
+
+/*
+ * The usage of tables with just the command part is deprecated.
+ * All new IR keytables should contain address+command and need
+ * to define the proper IR_TYPE (IR_TYPE_RC5/IR_TYPE_NEC).
+ * The deprecated tables should use IR_TYPE_UNKNOWN
+ */
+#define IR_TABLE(irname, type, tabname)\
+struct ir_scancode_table tabname ## _table = { \
+   .scan = tabname,\
+   .size = ARRAY_SIZE(tabname),\
+   .ir_type = type,\
+   .name = #irname,\
+}; \
+EXPORT_SYMBOL_GPL(tabname ## _table)
+
+
 /* empty keytable, can be used as placeholder for not-yet created keytables */
 static struct ir_scancode ir_codes_empty[] = {
{ 0x2a, KEY_COFFEE },
 };
-
-struct ir_scancode_table ir_codes_empty_table = {
-   .scan = ir_codes_empty,
-   .size = ARRAY_SIZE(ir_codes_empty),
-};
-EXPORT_SYMBOL_GPL(ir_codes_empty_table);
+IR_TABLE(empty, IR_TYPE_UNKNOWN, ir_codes_empty);
 
 /* Michal Majchrowicz  */
 static struct ir_scancode ir_codes_proteus_2309[] = {
@@ -68,12 +80,7 @@ static struct ir_scancode ir_codes_proteus_2309[] = {
{ 0x1e, KEY_VOLUMEUP }, /* volume +*/
{ 0x14, KEY_F1 },
 };
-
-struct ir_scancode_table ir_codes_proteus_2309_table = {
-   .scan = ir_codes_proteus_2309,
-   .size = ARRAY_SIZE(ir_codes_proteus_2309),
-};
-EXPORT_SYMBOL_GPL(ir_codes_proteus_2309_table);
+IR_TABLE(proteus_2309, IR_TYPE_UNKNOWN, ir_codes_proteus_2309);
 
 /* Matt Jesson  */
 static struct ir_scancode ir_codes_avermedia_m135a[] = {
@@ -168,12 +170,7 @@ static struct ir_scancode ir_codes_avermedia_m135a[] = {
{ 0x18, KEY_PLAY },
{ 0x1b, KEY_STOP },
 };
-
-struct ir_scancode_table ir_codes_avermedia_m135a_table = {
-   .scan = ir_codes_avermedia_m135a,
-   .size = ARRAY_SIZE(ir_codes_avermedia_m135a),
-};
-EXPORT_SYMBOL_GPL(ir_codes_avermedia_m135a_table);
+IR_TABLE(avermedia_m135a, IR_TYPE_UNKNOWN, ir_codes_avermedia_m135a);
 
 /* Oldrich Jedlicka  */
 static struct ir_scancode ir_codes_avermedia_cardbus[] = {
@@ -232,12 +229,7 @@ static struct ir_scancode ir_codes_avermedia_cardbus[] = {
{ 0x42, KEY_CHANNELDOWN },  /* Channel down */
{ 0x43, KEY_CHANNELUP },/* Channel up */
 };
-
-struct ir_scancode_table ir_codes_avermedia_cardbus_table = {
-   .scan = ir_codes_avermedia_cardbus,
-   .size = ARRAY_SIZE(ir_codes_avermedia_cardbus),
-};
-EXPORT_SYMBOL_GPL(ir_codes_avermedia_cardbus_table);
+IR_TABLE(avermedia_cardbus, IR_TYPE_UNKNOWN, ir_codes_avermedia_cardbus);
 
 /* Attila Kondoros  */
 static struct ir_scancode ir_codes_apac_viewcomp[] = {
@@ -279,12 +271,7 @@ static struct ir_scancode ir_codes_apac_viewcomp[] = {
{ 0x0c, KEY_KPPLUS },   /* fine tune  */
{ 0x18, KEY_KPMINUS },  /* fine tune  */
 };
-
-struct ir_scancode_table ir_codes_apac_viewcomp_table = {
-   .scan = ir_codes_apac_viewcomp,
-   .size = ARRAY_SIZE(ir_codes_apac_viewcomp),
-};
-EXPORT_SYMBOL_GPL(ir_codes_apac_viewcomp_table);
+IR_TABLE(apac_viewcomp, IR_TYPE_UNKNOWN, ir_codes_apac_viewcomp);
 
 /* -- */
 
@@ -331,12 +318,7 @@ static struct ir_scancode ir_codes_pixelview[] = {
{ 0x1d, KEY_REFRESH },  /* reset */
{ 0x18, KEY_MUTE }, /* mute/unmute */
 };
-
-struct ir_scancode_table ir_codes_pixelview_table = {
-   .scan = ir_codes_pixelview,
-   .size = ARRAY_SIZE(ir_codes_pixelview),
-};
-EXPORT_SYMBOL_GPL(ir_codes_pixelview_table);
+IR_TABLE(pixelview, IR_TYPE_UNKNOWN, ir_codes_pixelview);
 
 /*
Mauro Carvalho Chehab 
@@ -381,12 +363,7 @@ static struct ir_scancode ir_codes_pixelview_new[] = {
{ 0x31, KEY_TV },
{ 0x34, KEY_RADIO },
 };
-
-struct ir_scancode_table ir_codes_pixelview_new_table = {
-   .scan = ir_codes_pixelview_new,
-   .size = ARRAY_SIZE(ir_codes_pixelview_new),
-};
-EXPORT_SYMBOL_GPL(ir_codes_pixelview_new_table);
+IR_TABLE(pixelview_new, IR_TYPE_UNKNOWN, ir_codes_pixelview_new);
 
 static struct ir_scancode ir_codes_nebula[] = {
{ 0x00, KEY_0 },
@@ -445,12 +422,7 @@ static struct ir_scancode ir_codes_nebula[] = {
{ 0x35, KEY_PHONE },
{ 0x36, KEY_PC },
 };
-
-struct ir_scancode_table ir_codes_nebula_table = {
-   .scan = ir_codes_nebula,
-   .size = ARRAY_SIZE(ir_codes_nebula),
-};
-EXPORT_SYMBOL_GPL(ir_codes_nebula_table);
+IR_TABLE(nebula, IR_TYPE_UNKNOWN, ir_codes_nebula);
 
 /* DigitalNow DNTV Live D

[PATCH 3/4] V4L/DVB: ir-core: Export IR name via uevent

[Mauro Carvalho Chehab]

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index c9c0a54..31f22ba 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -418,6 +418,7 @@ int ir_input_register(struct input_dev *input_dev,
 
spin_lock_init(&ir_dev->rc_tab.lock);
 
+   ir_dev->rc_tab.name = rc_tab->name;
ir_dev->rc_tab.size = ir_roundup_tablesize(rc_tab->size);
ir_dev->rc_tab.scan = kzalloc(ir_dev->rc_tab.size *
sizeof(struct ir_scancode), GFP_KERNEL);
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index 1bb011a..0f4da05 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -125,6 +125,24 @@ static ssize_t store_protocol(struct device *d,
return len;
 }
 
+
+#define ADD_HOTPLUG_VAR(fmt, val...)   \
+   do {\
+   int err = add_uevent_var(env, fmt, val);\
+   if (err)\
+   return err; \
+   } while (0)
+
+static int ir_dev_uevent(struct device *device, struct kobj_uevent_env *env)
+{
+   struct ir_input_dev *ir_dev = dev_get_drvdata(device);
+
+   if (ir_dev->rc_tab.name)
+   ADD_HOTPLUG_VAR("NAME=\"%s\"", ir_dev->rc_tab.name);
+
+   return 0;
+}
+
 /*
  * Static device attribute struct with the sysfs attributes for IR's
  */
@@ -137,7 +155,7 @@ static struct attribute *ir_dev_attrs[] = {
 };
 
 static struct attribute_group ir_dev_attr_grp = {
-   .attrs  =ir_dev_attrs,
+   .attrs  = ir_dev_attrs,
 };
 
 static const struct attribute_group *ir_dev_attr_groups[] = {
@@ -147,9 +165,9 @@ static const struct attribute_group *ir_dev_attr_groups[] = 
{
 
 static struct device_type ir_dev_type = {
.groups = ir_dev_attr_groups,
+   .uevent = ir_dev_uevent,
 };
 
-
 /**
  * ir_register_class() - creates the sysfs for /sys/class/irrcv/irrcv?
  * @input_dev: the struct input_dev descriptor of the device
@@ -172,6 +190,7 @@ int ir_register_class(struct input_dev *input_dev)
ir_dev->dev.class = &ir_input_class;
ir_dev->dev.parent = input_dev->dev.parent;
dev_set_name(&ir_dev->dev, "irrcv%d", devno);
+   dev_set_drvdata(&ir_dev->dev, ir_dev);
rc = device_register(&ir_dev->dev);
if (rc)
return rc;
@@ -186,8 +205,8 @@ int ir_register_class(struct input_dev *input_dev)
 
__module_get(THIS_MODULE);
 
-   path = kobject_get_path(&input_dev->dev.kobj, GFP_KERNEL);
-   printk(KERN_INFO "%s: %s associated with sysfs %s\n",
+   path = kobject_get_path(&ir_dev->dev.kobj, GFP_KERNEL);
+   printk(KERN_INFO "%s: %s as %s\n",
dev_name(&ir_dev->dev),
input_dev->name ? input_dev->name : "Unspecified device",
path ? path : "N/A");
-- 
1.6.6.1


--
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 4/4] V4L/DVB: ir-core: export driver name used by IR via uevent

[Mauro Carvalho Chehab]

Now, both driver and keytable names are exported to userspace. This
will help userspace to decide when a table need to be replaced
by another one.

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index 31f22ba..2d9ba84 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -403,7 +403,8 @@ EXPORT_SYMBOL_GPL(ir_g_keycode_from_table);
  */
 int ir_input_register(struct input_dev *input_dev,
  const struct ir_scancode_table *rc_tab,
- const struct ir_dev_props *props)
+ const struct ir_dev_props *props,
+ const char *driver_name)
 {
struct ir_input_dev *ir_dev;
struct ir_scancode  *keymap= rc_tab->scan;
@@ -418,6 +419,10 @@ int ir_input_register(struct input_dev *input_dev,
 
spin_lock_init(&ir_dev->rc_tab.lock);
 
+   ir_dev->driver_name = kmalloc(strlen(driver_name) + 1, GFP_KERNEL);
+   if (!ir_dev->driver_name)
+   return -ENOMEM;
+   strcpy(ir_dev->driver_name, driver_name);
ir_dev->rc_tab.name = rc_tab->name;
ir_dev->rc_tab.size = ir_roundup_tablesize(rc_tab->size);
ir_dev->rc_tab.scan = kzalloc(ir_dev->rc_tab.size *
diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c
index 0f4da05..bbddf2f 100644
--- a/drivers/media/IR/ir-sysfs.c
+++ b/drivers/media/IR/ir-sysfs.c
@@ -139,6 +139,8 @@ static int ir_dev_uevent(struct device *device, struct 
kobj_uevent_env *env)
 
if (ir_dev->rc_tab.name)
ADD_HOTPLUG_VAR("NAME=\"%s\"", ir_dev->rc_tab.name);
+   if (ir_dev->driver_name)
+   ADD_HOTPLUG_VAR("DRV_NAME=\"%s\"", ir_dev->driver_name);
 
return 0;
 }
diff --git a/drivers/media/dvb/dm1105/dm1105.c 
b/drivers/media/dvb/dm1105/dm1105.c
index 383cca3..f1721e9 100644
--- a/drivers/media/dvb/dm1105/dm1105.c
+++ b/drivers/media/dvb/dm1105/dm1105.c
@@ -45,6 +45,8 @@
 #include "z0194a.h"
 #include "ds3000.h"
 
+#define MODULE_NAME "dm1105"
+
 #define UNSET (-1U)
 
 #define DM1105_BOARD_NOAUTOUNSET
@@ -627,7 +629,7 @@ int __devinit dm1105_ir_init(struct dm1105_dev *dm1105)
 
INIT_WORK(&dm1105->ir.work, dm1105_emit_key);
 
-   err = ir_input_register(input_dev, ir_codes, NULL);
+   err = ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
 
return err;
 }
diff --git a/drivers/media/dvb/mantis/mantis_input.c 
b/drivers/media/dvb/mantis/mantis_input.c
index 4675a3b..6baf302 100644
--- a/drivers/media/dvb/mantis/mantis_input.c
+++ b/drivers/media/dvb/mantis/mantis_input.c
@@ -32,6 +32,8 @@
 #include "mantis_reg.h"
 #include "mantis_uart.h"
 
+#define MODULE_NAME "mantis_core"
+
 static struct ir_scancode mantis_ir_table[] = {
{ 0x29, KEY_POWER   },
{ 0x28, KEY_FAVORITES   },
@@ -126,7 +128,7 @@ int mantis_input_init(struct mantis_pci *mantis)
rc->id.version  = 1;
rc->dev = mantis->pdev->dev;
 
-   err = ir_input_register(rc, &ir_mantis, NULL);
+   err = ir_input_register(rc, &ir_mantis, NULL, MODULE_NAME);
if (err) {
dprintk(MANTIS_ERROR, 1, "IR device registration failed, ret = 
%d", err);
input_free_device(rc);
diff --git a/drivers/media/dvb/ttpci/budget-ci.c 
b/drivers/media/dvb/ttpci/budget-ci.c
index 49c2a81..ec89afd 100644
--- a/drivers/media/dvb/ttpci/budget-ci.c
+++ b/drivers/media/dvb/ttpci/budget-ci.c
@@ -54,6 +54,8 @@
 #include "tda1002x.h"
 #include "tda827x.h"
 
+#define MODULE_NAME "budget_ci"
+
 /*
  * Regarding DEBIADDR_IR:
  * Some CI modules hang if random addresses are read.
@@ -254,7 +256,7 @@ static int msp430_ir_init(struct budget_ci *budget_ci)
budget_ci->ir.timer_keyup.function = msp430_ir_keyup;
budget_ci->ir.timer_keyup.data = (unsigned long) &budget_ci->ir;
budget_ci->ir.last_raw = 0x; /* An impossible value */
-   error = ir_input_register(input_dev, ir_codes, NULL);
+   error = ir_input_register(input_dev, ir_codes, NULL, MODULE_NAME);
if (error) {
printk(KERN_ERR "budget_ci: could not init driver for IR device 
(code %d)\n", error);
return error;
diff --git a/drivers/media/video/bt8xx/bttv-input.c 
b/drivers/media/video/bt8xx/bttv-input.c
index b320dbd..6c11687 100644
--- a/drivers/media/video/bt8xx/bttv-input.c
+++ b/drivers/media/video/bt8xx/bttv-input.c
@@ -48,6 +48,8 @@ module_param(ir_rc5_key_timeout, int, 0644);
 
 #define DEVNAME "bttv-input"
 
+#define MODULE_NAME "bttv"
+
 /* -- */
 
 static void ir_handle_key(struct bttv *btv)
@@ -389,7 +391,7 @@ int bttv_input_init(struct bttv *btv)
bttv_ir_start(btv, ir);
 
/* all done */
-   err = ir_input_register(btv->remote->dev, ir_codes, NULL);
+   err = ir_input_register(btv->remote->dev, ir_codes, NULL, MODULE_NAME);
if (err

Re: Remaining drivers that aren't V4L2?

[Mauro Carvalho Chehab]

Devin Heitmueller wrote:
> On Fri, Mar 12, 2010 at 5:52 PM, Mauro Carvalho Chehab
>  wrote:

> Yup, I was indeed aware that tvtime doesn't really work with webcams.
> I wanted to see the list of remaining drivers, and now that I see the
> list (and also came to the conclusion that they were all webcams), I
> feel much more comfortable just dropping V4L1 support.

Yep. For its target, V4L1 is not needed anymore.

> I have actually been considering converting tvtime to using libv4l for
> a while now, as I need it to support cards that use the HM12
> pixelformat (such as the HVR-1600).  I wanted to rip out the V4L1
> support first to make the conversion more straightforward.
> 
> It really isn't my goal to make tvtime support webcams, although they
> might just start to work as an unintended side-effect.

If you take the right decisions with tvtime, you'll end to have it allowing
webcams, even unintentionally.

For example, on a quick brainstorming, I see some interesting features for
the tvtime todo list (just my $0,01 cents):

1) alsa support (undergoing/finished work?);

2) allow adjusting frame rate, to better support environments where the bus 
bandwidth is limited;

3) support for other video formats;

4) a generic control interface (a qv4l2 like interface);

5) support to adjust the resolution based on the screen size (as xawtv does);

6) allow tvtime to record programs;

7) direct access to IR event interface, in order to better work with IR's 
without
needing any extra software like lirc;

8) allow changing video standard without needing to restart tvtime. It is very 
common
on some Countries the usage of two or more simultaneous standard - For example, 
almost
all DVD/STB devices in Brazil outputs in NTSC, while TV is broadcasted in 
PAL-M. As far
as I know, the other Countries where Analog TV is still the main/only broadcast 
standard
have similar issues.

For sure the top priority is Alsa, but, at the end of the day, by handling 
(some) of the
above requirements, its usage with webcams will make more sense, and you won't 
need to
spend any time specifically devoted to webcam support.

Also, assuming that analog TV will end broadcasting some day in the world, the 
usage for
a tvtime-like application will likely be for video surveillance and other 
webcam usages.

So, in brief, I think a webcam support side-effect is a good thing.

-- 

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

[Devin Heitmueller]

On Fri, Mar 12, 2010 at 5:52 PM, Mauro Carvalho Chehab
 wrote:
> All the above are webcam drivers. I doubt that those drivers would work
> with tvtime: this software were meant to test the Vector's deinterlacing
> algorithms, so it requires some specific video formats/resolutions found on TV
> and require 25 or 30 fps, as far as I remember. For example, It doesn't 
> support
> QCIF/QVGA cameras.

Yup, I was indeed aware that tvtime doesn't really work with webcams.
I wanted to see the list of remaining drivers, and now that I see the
list (and also came to the conclusion that they were all webcams), I
feel much more comfortable just dropping V4L1 support.

> If you want to extend tvtime to use webcams, some work is needed. Probably 
> the easiest
> way would be to use libv4l, that also does the V4L1 conversion, if needed. 
> This may
> actually make sense even for a few TV cards like em28xx, where you could use 
> a bayer
> format with a lower color depth and/or lower resolution, in order to allow 
> viewing two
> simultaneous streams.
>
> So, I suggest you to just drop V4L1 from tvtime and convert it to use libv4l 
> (the conversion
> is trivial: just replace open/close/ioctl from the V4L2 driver to the libv4l 
> ones). This will
> allow you to drop the old V4L1 driver from it, and, if you decide later to 
> accept other
> resolutions and make it more webcam friendly, you'll just need to allow 
> tvtime to accept
> other video resolutions and disable the de-interlacing setup if a webcam is 
> detected.

I have actually been considering converting tvtime to using libv4l for
a while now, as I need it to support cards that use the HM12
pixelformat (such as the HVR-1600).  I wanted to rip out the V4L1
support first to make the conversion more straightforward.

It really isn't my goal to make tvtime support webcams, although they
might just start to work as an unintended side-effect.

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

Re: Remaining drivers that aren't V4L2?

[Mauro Carvalho Chehab]

Hans Verkuil wrote:
> On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:
>> Hello,
>>
>> I know some months ago, there was some discussion about a few drivers
>> which were stragglers and had not been converted from V4L to V4L2.
>>
>> Do we have a current list of driver which still haven't been converted?
> 
> These drivers are still v4l1:
> 
> arv
> bw-qcam
> c-qcam
> cpia_pp
> cpia_usb
> ov511
> se401
> stradis
> stv680
> usbvideo
> w9966

All the above are webcam drivers. I doubt that those drivers would work
with tvtime: this software were meant to test the Vector's deinterlacing
algorithms, so it requires some specific video formats/resolutions found on TV
and require 25 or 30 fps, as far as I remember. For example, It doesn't support
QCIF/QVGA cameras.

If you want to extend tvtime to use webcams, some work is needed. Probably the 
easiest
way would be to use libv4l, that also does the V4L1 conversion, if needed. This 
may
actually make sense even for a few TV cards like em28xx, where you could use a 
bayer
format with a lower color depth and/or lower resolution, in order to allow 
viewing two 
simultaneous streams.

So, I suggest you to just drop V4L1 from tvtime and convert it to use libv4l 
(the conversion
is trivial: just replace open/close/ioctl from the V4L2 driver to the libv4l 
ones). This will
allow you to drop the old V4L1 driver from it, and, if you decide later to 
accept other
resolutions and make it more webcam friendly, you'll just need to allow tvtime 
to accept
other video resolutions and disable the de-interlacing setup if a webcam is 
detected.

-- 

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: [patch 2/5] drivers/media/video: move dereference after NULL test

[Karicheri, Muralidharan]

For drivers/media/video/davinci/vpif_display.c

Acked-by: Muralidharan Karicheri 

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

>-Original Message-
>From: Julia Lawall [mailto:ju...@diku.dk]
>Sent: Friday, March 12, 2010 4:16 AM
>To: Karicheri, Muralidharan
>Cc: a...@linux-foundation.org; mche...@infradead.org; linux-
>me...@vger.kernel.org
>Subject: RE: [patch 2/5] drivers/media/video: move dereference after NULL
>test
>
>From: Julia Lawall 
>
>In quickcam_messenger.c, if the NULL test on uvd is needed, then the
>dereference should be after the NULL test.
>
>In vpif_display.c, std_info is initialized to the address of a structure
>field.  This seems unlikely to be NULL.  Test std_info->stdid instead.
>
>In saa7134-alsa.c, the function is only called from one place, where the
>chip argument has already been dereferenced.  On the other hand, if it
>should be kept, then card should be initialized after it.
>
>A simplified version of the semantic match that detects this problem is as
>follows (http://coccinelle.lip6.fr/):
>
>// 
>@match exists@
>expression x, E;
>identifier fld;
>@@
>
>* x->fld
>  ... when != \(x = E\|&x\)
>* x == NULL
>// 
>
>Signed-off-by: Julia Lawall 
>
>---
> drivers/media/video/davinci/vpif_display.c|2 +-
> drivers/media/video/saa7134/saa7134-alsa.c|2 --
> drivers/media/video/usbvideo/quickcam_messenger.c |3 ++-
> 3 files changed, 3 insertions(+), 4 deletions(-)
>
>diff --git a/drivers/media/video/usbvideo/quickcam_messenger.c
>b/drivers/media/video/usbvideo/quickcam_messenger.c
>index 803d3e4..f0043d0 100644
>--- a/drivers/media/video/usbvideo/quickcam_messenger.c
>+++ b/drivers/media/video/usbvideo/quickcam_messenger.c
>@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uvd)
>
> static void qcm_stop_data(struct uvd *uvd)
> {
>-  struct qcm *cam = (struct qcm *) uvd->user_data;
>+  struct qcm *cam;
>   int i, j;
>   int ret;
>
>   if ((uvd == NULL) || (!uvd->streaming) || (uvd->dev == NULL))
>   return;
>+  cam = (struct qcm *) uvd->user_data;
>
>   ret = qcm_camera_off(uvd);
>   if (ret)
>diff --git a/drivers/media/video/saa7134/saa7134-alsa.c
>b/drivers/media/video/saa7134/saa7134-alsa.c
>index d48c450..d3bd82a 100644
>--- a/drivers/media/video/saa7134/saa7134-alsa.c
>+++ b/drivers/media/video/saa7134/saa7134-alsa.c
>@@ -1011,8 +1011,6 @@ static int
>snd_card_saa7134_new_mixer(snd_card_saa7134_t * chip)
>   unsigned int idx;
>   int err, addr;
>
>-  if (snd_BUG_ON(!chip))
>-  return -EINVAL;
>   strcpy(card->mixername, "SAA7134 Mixer");
>
>   for (idx = 0; idx < ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
>diff --git a/drivers/media/video/davinci/vpif_display.c
>b/drivers/media/video/davinci/vpif_display.c
>index dfddef7..b2dce78 100644
>--- a/drivers/media/video/davinci/vpif_display.c
>+++ b/drivers/media/video/davinci/vpif_display.c
>@@ -383,7 +383,7 @@ static int vpif_get_std_info(struct channel_obj *ch)
>   int index;
>
>   std_info->stdid = vid_ch->stdid;
>-  if (!std_info)
>+  if (!std_info->stdid)
>   return -1;
>
>   for (index = 0; index < ARRAY_SIZE(ch_params); index++) {
--
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?

[Hans Verkuil]

On Friday 12 March 2010 23:20:44 Michael Akey wrote:
> Hans Verkuil wrote:
> > On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:
> >   
> >> Hello,
> >>
> >> I know some months ago, there was some discussion about a few drivers
> >> which were stragglers and had not been converted from V4L to V4L2.
> >>
> >> Do we have a current list of driver which still haven't been converted?
> >> 
> >
> > These drivers are still v4l1:
> >
> > arv
> > bw-qcam
> > c-qcam
> > cpia_pp
> > cpia_usb
> > ov511
> > se401
> > stradis
> > stv680
> > usbvideo
> > w9966
> >
> > Some of these have counterparts in gspca these days so possibly some drivers
> > can be removed by now. Hans, can you point those out?
> >
> > arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
> > and if no one steps up then they can be dropped altogether.
> >   
> 
> Does this mean that the bw-qcam driver will be removed in future 
> revisions or does this mean it will just never be updated to v4l2?

Removal. At least, that is what I would propose. Greg KH has proposed some time
ago to use the staging tree not only for incoming but also for outgoing drivers.

And drivers that have not seen any development for years and that nobody seems
to be using and where the hardware is obsolete are definitely candidates for
this removal process.

I suspect that the only two drivers that we might need to keep are usbvideo and
cpia_usb. The latter is still used in hardware you can buy today, the same may
also be true of the first, and products supported by the usbvideo driver are
certainly still out there.

If we are indeed left with just two V4L1 drivers that cannot easily be removed,
then we should perhaps try to convert them after all, even though it is hard to
be motivated to do that work.

I definitely agree with Devin that it would be really great to finally remove
the V4L1 support completely from the kernel.

Regards,

Hans

> 
> > According to my notes I should be able to test cpia_usb. I would have to
> > verify that, though. I think it is only used in a USB microscope. It is
> > effectively a webcam. I can also test usbvideo (USB 1 TV capture device).
> > The latter is probably the most important driver that needs converting,
> > because I think these are not uncommon.
> >
> > However, I have no time to work on such a driver conversion. But if someone
> > is seriously willing to put time and effort in that, then I am willing to
> > mail the hardware.
> >
> >   
> >> I started doing some more tvtime work last night, and I would *love*
> >> to drop V4L support (and *only* support V4L2 devices), since it would
> >> make the code much cleaner, more reliable, and easier to test.
> >>
> >> If there are only a few obscure webcams remaining, then I'm willing to
> >> tell those users that they have to stick with whatever old version of
> >> tvtime they've been using since the last release four years ago.
> >> 
> >
> > To my knowledge the usbvideo driver is probably the least obscure device
> > that is still using V4L1.
> >
> > 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: Remaining drivers that aren't V4L2?

[Michael Akey]

Hans Verkuil wrote:

On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:
  

Hello,

I know some months ago, there was some discussion about a few drivers
which were stragglers and had not been converted from V4L to V4L2.

Do we have a current list of driver which still haven't been converted?



These drivers are still v4l1:

arv
bw-qcam
c-qcam
cpia_pp
cpia_usb
ov511
se401
stradis
stv680
usbvideo
w9966

Some of these have counterparts in gspca these days so possibly some drivers
can be removed by now. Hans, can you point those out?

arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
and if no one steps up then they can be dropped altogether.
  


Does this mean that the bw-qcam driver will be removed in future 
revisions or does this mean it will just never be updated to v4l2?



According to my notes I should be able to test cpia_usb. I would have to
verify that, though. I think it is only used in a USB microscope. It is
effectively a webcam. I can also test usbvideo (USB 1 TV capture device).
The latter is probably the most important driver that needs converting,
because I think these are not uncommon.

However, I have no time to work on such a driver conversion. But if someone
is seriously willing to put time and effort in that, then I am willing to
mail the hardware.

  

I started doing some more tvtime work last night, and I would *love*
to drop V4L support (and *only* support V4L2 devices), since it would
make the code much cleaner, more reliable, and easier to test.

If there are only a few obscure webcams remaining, then I'm willing to
tell those users that they have to stick with whatever old version of
tvtime they've been using since the last release four years ago.



To my knowledge the usbvideo driver is probably the least obscure device
that is still using V4L1.

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

[Devin Heitmueller]

On Fri, Mar 12, 2010 at 5:20 PM, Michael Akey  wrote:
> Hans Verkuil wrote:
>> These drivers are still v4l1:
>>
>> arv
>> bw-qcam
>> c-qcam
>> cpia_pp
>> cpia_usb
>> ov511
>> se401
>> stradis
>> stv680
>> usbvideo
>> w9966
>>
>> Some of these have counterparts in gspca these days so possibly some
>> drivers
>> can be removed by now. Hans, can you point those out?
>>
>> arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
>> and if no one steps up then they can be dropped altogether.
>>
>
> Does this mean that the bw-qcam driver will be removed in future revisions
> or does this mean it will just never be updated to v4l2?

Hans is suggesting that support for those devices would be dropped
entirely if no developer steps up to convert them to v4l2.

The problem is that supporting the long deprecated API is a burden
that makes it much harder to extend certain aspects of the internal
code.  If we were able to drop those devices, it would be much easier
to improve all the other drivers (of which the *vast* majority have
been converted to v4l2).

It's been over ten years since v4l2 came out.  If nobody has converted
those drivers to v4l2, then it's safe to say it's probably never going
to happen.

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

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

[Hans Verkuil]

On Friday 12 March 2010 18:57:39 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)?

I see that the Hauppauge PVR-150 is still available (ivtv driver).

These cards certainly work. There are also newer HVR cards from Hauppauge,
but I'm not 100% certain which are fully supported by linux with respect to
MPEG encoding.

Regards,

Hans

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

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

[Hans Verkuil]

On Friday 12 March 2010 21:11:49 Devin Heitmueller wrote:
> Hello,
> 
> I know some months ago, there was some discussion about a few drivers
> which were stragglers and had not been converted from V4L to V4L2.
> 
> Do we have a current list of driver which still haven't been converted?

These drivers are still v4l1:

arv
bw-qcam
c-qcam
cpia_pp
cpia_usb
ov511
se401
stradis
stv680
usbvideo
w9966

Some of these have counterparts in gspca these days so possibly some drivers
can be removed by now. Hans, can you point those out?

arv, bw-qcam, c-qcam, cpia_pp and stradis can probably be moved to staging
and if no one steps up then they can be dropped altogether.

According to my notes I should be able to test cpia_usb. I would have to
verify that, though. I think it is only used in a USB microscope. It is
effectively a webcam. I can also test usbvideo (USB 1 TV capture device).
The latter is probably the most important driver that needs converting,
because I think these are not uncommon.

However, I have no time to work on such a driver conversion. But if someone
is seriously willing to put time and effort in that, then I am willing to
mail the hardware.

> I started doing some more tvtime work last night, and I would *love*
> to drop V4L support (and *only* support V4L2 devices), since it would
> make the code much cleaner, more reliable, and easier to test.
> 
> If there are only a few obscure webcams remaining, then I'm willing to
> tell those users that they have to stick with whatever old version of
> tvtime they've been using since the last release four years ago.

To my knowledge the usbvideo driver is probably the least obscure device
that is still using V4L1.

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: pushes at v4l-utils tree

[Antonio Ospite]

On Fri, 12 Mar 2010 16:29:46 -0300
Mauro Carvalho Chehab  wrote:

> Hans de Goede wrote:
> > Hi,
> > 
> > On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
> >> Hi Hans,
> >>
> >> As we've agreed that the idea is to allow multiple people to commit at
> >> v4l-utils,
> >> today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1
> >> is .gitignore
> >> stuff). One of the reasons were to test the viability for such commits.
> >>
> >> I've temporarily enabled the same script that we use for upstream
> >> patches to
> >> generate patches against linuxtv-commits ML.
> >>
> >>  From my experiences, I have some notes:
> >> 1) git won't work fine if more than one is committing at the same
> >> tree.
> >> The reason is simple: it won't preserve the same group as the previous
> >> commits. So,
> >> the next committer will have troubles if we allow multiple committers;
> >>
> > 
> > I assume you are talking about some issues with permissions on the
> > server side here ?
> 
> Yes. The new objects and the touched files got a different group ownership
> after git push. I had to manually fix them at the server.
> 

The following might be inappropriate, as I didn't follow the discussion
about the linuxtv git infrastructure.

Using gitosis[1,2] these permission issues shouldn't occur, because only
one user (usually "git") actually writes to the filesystem while commit
rights are still handled with ssh pubkeys, and this doesn't even
require creating users on the server.

As I said I don't know if you are using gitosis already, if so then
sorry for the noise.

Regards,
   Antonio

[1] http://eagain.net/gitweb/?p=gitosis.git
[2] http://ao2.it/wiki/How_to_setup_a_GIT_server_with_gitosis_and_gitweb

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


pgpguaTYsTJka.pgp
Description: PGP signature

Re: [linux-dvb] Twinhan dtv 3030 mantis

[Niklas Claesson]

2010/3/12 Manu Abraham :
>
> Can you please load the mantis driver with module option verbose=5 and
> post the details ?
>
> Regards,
> Manu
>

Here you go:

Mar 12 21:49:29 niklas-desktop kernel: [   70.660177] found a VP-3030
PCI DVB-T device on (05:02.0),
Mar 12 21:49:29 niklas-desktop kernel: [   70.660188] Mantis
:05:02.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Mar 12 21:49:29 niklas-desktop kernel: [   70.660207] Mantis Rev 1
[1822:0024], irq: 23, latency: 64
Mar 12 21:49:29 niklas-desktop kernel: [   70.660210] memory: 0x0,
mmio: 0xf86ce000
Mar 12 21:49:29 niklas-desktop kernel: [   70.660218]
mantis_stream_control (0): Set stream to HIF
Mar 12 21:49:29 niklas-desktop kernel: [   70.660245] mantis_i2c_init
(0): Initializing I2C ..
Mar 12 21:49:29 niklas-desktop kernel: [   70.660248] mantis_i2c_init
(0): Disabling I2C interrupt
Mar 12 21:49:29 niklas-desktop kernel: [   70.660252] mantis_i2c_xfer
(0): Messages:2
Mar 12 21:49:29 niklas-desktop kernel: [   70.660254]
mantis_i2c_write: Address=[0x50] [ 08 ]
Mar 12 21:49:29 niklas-desktop kernel: [   70.660474]
mantis_i2c_read:  Address=[0x50] [ 00 08 ca 1a 4d f6 ]
Mar 12 21:49:29 niklas-desktop kernel: [   70.661200] MAC
Address=[00:08:ca:1a:4d:f6]
Mar 12 21:49:29 niklas-desktop kernel: [   70.661202] mantis_dma_init
(0): Mantis DMA init
Mar 12 21:49:29 niklas-desktop kernel: [   70.661219]
mantis_alloc_buffers (0): DMA=0x3630 cpu=0xf630 size=65536
Mar 12 21:49:29 niklas-desktop kernel: [   70.661223]
mantis_alloc_buffers (0): RISC=0x34d99000 cpu=0xf4d99000 size=1000
Mar 12 21:49:29 niklas-desktop kernel: [   70.661226]
mantis_calc_lines (0): Mantis RISC block bytes=[4096], line
bytes=[2048], line count=[32]
Mar 12 21:49:29 niklas-desktop kernel: [   70.661228] mantis_dvb_init
(0): dvb_register_adapter
Mar 12 21:49:29 niklas-desktop kernel: [   70.661230] DVB: registering
new adapter (Mantis DVB adapter)
Mar 12 21:49:29 niklas-desktop kernel: [   70.661232] mantis_dvb_init
(0): dvb_dmx_init
Mar 12 21:49:29 niklas-desktop kernel: [   70.661304] mantis_dvb_init
(0): dvb_dmxdev_init
Mar 12 21:49:29 niklas-desktop kernel: [   70.661434] gpio_set_bits
(0): Set Bit <13> to <0>
Mar 12 21:49:29 niklas-desktop kernel: [   70.661437] gpio_set_bits
(0): GPIO Value <00>
Mar 12 21:49:29 niklas-desktop kernel: [   70.764121]
mantis_frontend_power (0): Power ON
Mar 12 21:49:29 niklas-desktop kernel: [   70.764127] gpio_set_bits
(0): Set Bit <12> to <1>
Mar 12 21:49:29 niklas-desktop kernel: [   70.764131] gpio_set_bits
(0): GPIO Value <1000>
Mar 12 21:49:29 niklas-desktop kernel: [   70.868076] gpio_set_bits
(0): Set Bit <12> to <1>
Mar 12 21:49:29 niklas-desktop kernel: [   70.868081] gpio_set_bits
(0): GPIO Value <1000>
Mar 12 21:49:29 niklas-desktop kernel: [   71.076032] gpio_set_bits
(0): Set Bit <13> to <1>
Mar 12 21:49:29 niklas-desktop kernel: [   71.076037] gpio_set_bits
(0): GPIO Value <3000>
Mar 12 21:49:29 niklas-desktop kernel: [   71.332045]
vp3030_frontend_init (0): Probing for 10353 (DVB-T)
Mar 12 21:49:29 niklas-desktop kernel: [   71.332051] mantis_i2c_xfer
(0): Messages:2
Mar 12 21:49:29 niklas-desktop kernel: [   71.332053] Byte MODE:
Mar 12 21:49:29 niklas-desktop kernel: [   71.332056] Byte <0>
RXD=0x1f7f0080  [00]
Mar 12 21:49:29 niklas-desktop kernel: [   71.332059] mantis_dvb_init
(0): !!! NO Frontends found !!!
Mar 12 21:49:29 niklas-desktop kernel: [   71.334430] mantis_dvb_init
(0): ERROR! Adapter unregistered
Mar 12 21:49:29 niklas-desktop kernel: [   71.334433] mantis_pci_probe
(0): ERROR: Mantis DVB initialization failed <-1>
Mar 12 21:49:29 niklas-desktop kernel: [   71.334448] Mantis: probe of
:05:02.0 failed with error -1

Regards,
Niklas Claesson
--
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] Twinhan dtv 3030 mantis

[Manu Abraham]

On Fri, Mar 12, 2010 at 9:27 PM, Niklas Claesson
 wrote:
> I saw that there has been som recent development on the
> mantis-v4l-dvb-tree. Unfortunately it still doesn't work for my 3030.
> Is there anyway I can help? Is it normal that the IRQ 23 is used with
> more then one card?

That shouldn't be a problem. A shared handler is requested.

> Mar 12 18:19:03 niklas-desktop kernel: [  254.410969] Mantis
> :05:02.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
> Mar 12 18:19:03 niklas-desktop kernel: [  254.411971] DVB: registering
> new adapter (Mantis DVB adapter)
> Mar 12 18:19:04 niklas-desktop kernel: [  255.084297] Mantis: probe of
> :05:02.0 failed with error -1


Can you please load the mantis driver with module option verbose=5 and
post the details ?

Regards,
Manu
--
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

[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:Fri Mar 12 19:00:11 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14420:0d06fd6b500e
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/Friday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Friday.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

Remaining drivers that aren't V4L2?

[Devin Heitmueller]

Hello,

I know some months ago, there was some discussion about a few drivers
which were stragglers and had not been converted from V4L to V4L2.

Do we have a current list of driver which still haven't been converted?

I started doing some more tvtime work last night, and I would *love*
to drop V4L support (and *only* support V4L2 devices), since it would
make the code much cleaner, more reliable, and easier to test.

If there are only a few obscure webcams remaining, then I'm willing to
tell those users that they have to stick with whatever old version of
tvtime they've been using since the last release four years ago.

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

[GIT PATCHES FOR 2.6.34] sn9c20x patches

[Brian Johnson]

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

are available in the git repository at:

  git://gitorious.org/v4l-dvb/v4l-dvb.git devel

Brian Johnson (5):
  gspca - sn9c20x: use gspca's input device handling
  gspca - sn9c20x: Add support for camera LEDs
  gspca - sn9c20x: Add upside down detection
  gspca - sn9c20x: Add support for cameras using the MT9M112 sensor
  gspca - sn9c20x: Fix bug with OV9655 code

 Documentation/video4linux/gspca.txt |4 +
 drivers/media/video/gspca/Kconfig   |6 -
 drivers/media/video/gspca/sn9c20x.c |  311 +--
 3 files changed, 155 insertions(+), 166 deletions(-)

Brian Johnson
--
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: Analog (PAL) PCI or PCIe with MPEG HW encoder

[RoboSK]

i need "only" two analog input = one (dual) or two (single) card :( - 
but i hope that TBS "find" market for this card...


thanks
Robo


On 12. 3. 2010 20:00, Konstantin Dimitrov wrote:

hello Robo,

i know TurboSight (TBS) have PCI-Express MPEG-2 HW encoder card (with RCA
Composite Video Input and RCA Right and Left stereo audio inputs) that works
in Linux, because i made the Linux driver for it.however, it's just a
prototype and if you need only one such card their sales department won't be
interested to produce a single piece, but if you need many you have a change
and you can speak with them on: sa...@tbsdtv.com they don't produce the card
right now exactly, because there is no market for such cards, but it's ready
product that was design especially for use in Linux.

regards,
konstantin

2010/3/12 RoboSK


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

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





--
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: pushes at v4l-utils tree

[Mauro Carvalho Chehab]

Hans de Goede wrote:
> Hi,
> 
> On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:
>> Hi Hans,
>>
>> As we've agreed that the idea is to allow multiple people to commit at
>> v4l-utils,
>> today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1
>> is .gitignore
>> stuff). One of the reasons were to test the viability for such commits.
>>
>> I've temporarily enabled the same script that we use for upstream
>> patches to
>> generate patches against linuxtv-commits ML.
>>
>>  From my experiences, I have some notes:
>> 1) git won't work fine if more than one is committing at the same
>> tree.
>> The reason is simple: it won't preserve the same group as the previous
>> commits. So,
>> the next committer will have troubles if we allow multiple committers;
>>
> 
> I assume you are talking about some issues with permissions on the
> server side here ?

Yes. The new objects and the touched files got a different group ownership
after git push. I had to manually fix them at the server.

>> In summary, for now, I think that the better is to post all patches to
>> v4l-utils at ML
>> and ask Hans to merge them.
>>
> 
> Yes and no, if you've a few patches, sure. If you are doing regular
> development you should
> get commit access. In my experience in various projects multiple people
> pushing to the
> same git tree will work fine.

We need to see how they're fixing the permissions. I suspect that they have
some post-update script that redo the proper file permissions. Do you know
what they use?

-- 

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

v4l-utils, dvb-utils, xawtv and alevt (was: v4l-utils: i2c-id.h and alevt)

[Chicken Shack]

Am Freitag, den 12.03.2010, 20:20 +0400 schrieb Manu Abraham:
> On Fri, Mar 12, 2010 at 7:40 PM, Hans de Goede  wrote:
> > Hi,
> >
> > On 03/11/2010 03:31 PM, Devin Heitmueller wrote:
> >>
> >> On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
> >>   wrote:
> >>>
> >>> On 03/10/2010 02:04 AM, hermann pitton wrote:
> 
>  Hi Hans, both,
> 
>  Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
> >
> > It's nice to see this new tree, that should be make it easier to
> > develop
> > utilities!
> >
> > After a quick check I noticed that the i2c-id.h header was copied from
> > the
> > kernel. This is not necessary. The only utility that includes this is
> > v4l2-dbg
> > and that one no longer needs it. Hans, can you remove this?
> >
> > The second question is whether anyone would object if alevt is moved
> > from
> > dvb-apps to v4l-utils? It is much more appropriate to have that tool in
> > v4l-utils.
> 
>  i wonder that this stays such calm, hopefully a good sign.
> 
>  In fact alevt analog should come with almost every distribution, but the
>  former alevt-dvb, named now only alevt, well, might be ok in some
>  future, is enhanced for doing also dvb-t-s and hence there ATM.
> 
> > Does anyone know of other unmaintained but useful tools that we might
> > merge
> > into v4l-utils? E.g. xawtv perhaps?
> 
>  If for xawtv could be some more care, ships also since close to ever
>  with alevtd, that would be fine, but I'm not sure we are talking about
>  tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
>  example are also there and unmaintained.
> 
> >>>
> >>> I think would be nice to hear a word from Devin, which have been working
> >>> in tvtime. Devin?
> >>
> >> Sorry, I've been sick for the last couple of days and not actively on
> >> email.
> >>
> >> I don't think it's a good idea to consolidate applications like xawtv
> >> and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
> >> nice because it's small and what the packages provides what it says it
> >> does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
> >> applications to be "utilities".
> >>
> >> The apps in question are currently packaged by multiple distros today
> >> as standalone packages.  Today distros can decide whether they want
> >> the "bloat" associated with large GUI applications just to get the
> >> benefits of a couple of command line utilities.  Bundling them
> >> together makes that much harder (and would also result in a package
> >> with lots of external dependencies on third party libraries).
> >>
> >> Adding them into v4l2-utils doesn't really solve the real problem -
> >> that there are very few people willing to put in the effort to
> >> extend/improve these applications (something which, as Douglas pointed
> >> out, I'm trying to improve in the case of tvtime).
> >>
> >
> > Ack,
> 
> 
> ACK
> 
> > What would be good to do IMHO is decide for unmaintained apps like xawtv
> > and alevt if we want to adopt them and if we do, to create separate git
> > trees for them, and become a new upstream including doing regular
> > tarbals releases. Some time ago I did a lot of work on the Fedora xawtv
> > packages and I would be willing to pull such an effort for xawtv.
> 
> 
> Simply creating a tree for an application doesn't really help. At
> least it needs a "commitment" to that app to keep it updated. Unless,
> someone really puts in such an effort, creating a tree doesn't really
> help, it simplyt adds to the confusion for a normal user as to where
> he should download his application for his distro, if such a package
> doesn't exist.
> 
> 
> Regards,
> Manu
> --
> 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

Hi people,

just my 1 Euro as contribution here:

Your merging hysteria and the resulting "discussion" is simply nonsense
IMHO.

In how far?

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.

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!

The usable parts are:

a. mtt: a slave videotext application which is running independently
from the master application tuning the channels.
Its packed size 

Analog (PAL) PCI or PCIe with MPEG HW encoder

[RoboSK]

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


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: Hw capabilities of the HVR-2200

[Devin Heitmueller]

On Fri, Mar 12, 2010 at 12:26 PM, Jed  wrote:
> Considering that in the specs for the reference card it was highlighted
> as part of the silicon... Wouldn't it be safe to assume that it's
> something that'd be unlocked by drivers?
>
> But if that were true, what is their motivation in not wanting to enable
> it? (assuming they still haven't)

The features of a given piece of silicon do not always match what a
company has ultimately licensed.  This is especially true for things
like codec support which can have significant royalties that have to
be paid.  Hence it's possible that while the chip *in theory* could
support some particular codec, that doesn't mean that the firmware
that ultimately got licensed has the necessary support.

Regarding component support, it's entirely possible that although the
chip supports it, it may have been cost prohibitive to put the
supporting hardware on the PCB.  It's ultimately up to the product
vendor to decide what subset of the functionality on the reference
design to ship with.

Of course, everything I said in the above is complete speculation
(based on my own previous experience working for a company that makes
hardware), as I have no actual knowledge of why they chose to take the
approach they did.

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

Re: [linux-dvb] Twinhan dtv 3030 mantis

[Niklas Claesson]

I saw that there has been som recent development on the
mantis-v4l-dvb-tree. Unfortunately it still doesn't work for my 3030.
Is there anyway I can help? Is it normal that the IRQ 23 is used with
more then one card?

Mar 12 18:19:03 niklas-desktop kernel: [  254.410969] Mantis
:05:02.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
Mar 12 18:19:03 niklas-desktop kernel: [  254.411971] DVB: registering
new adapter (Mantis DVB adapter)
Mar 12 18:19:04 niklas-desktop kernel: [  255.084297] Mantis: probe of
:05:02.0 failed with error -1

Regards,
Niklas Claesson


2010/2/11 Manu Abraham 
>
> Can you please try again ?
>
> Regards,
> Manu
> --
> 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
--
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: Hw capabilities of the HVR-2200

[Jed]

19/09/09 Jed wrote:

2) Component input for the A/V-in


Yes, this exists on the HVR2250 product only.


Ah shite, are you sure?
If you look at the specs for the reference card it was there, did they
take it out at the last minute?


It's not feature Hauppauge supports on the HVR2200 today. I have a
suspicion this may change but I'm neither confirming, denying or
announcing anything. It would make sense to officially support
component cables on the HVR2200 since the silicon supports it.
If/when it does I'm sure it will be mentioned in the forums or on the
HVR2200 product packaging.


Hi Steve, when you said this is not a feature Hauppauge supports.
Did you mean it's not fully enabled physically in the PCB...
Or is it just something they need to add support for in the driver?
If the latter do you know if their policy has changed or is about to?


No idea, I have no answer.


Considering that in the specs for the reference card it was highlighted
as part of the silicon... Wouldn't it be safe to assume that it's
something that'd be unlocked by drivers?

But if that were true, what is their motivation in not wanting to enable
it? (assuming they still haven't)


3) Hw encode bypass for A/V-in


No idea. Regardless of whether it does or does not I wouldn't plan to
add basic raw TV support to the driver, without going through the
encoder.


Why do you rule it out unequivocally, is it just because I've annoyed
you? :-(


Raw analog TV isn't a high priority feature on my mental check-list.
Analog TV via the encoder is much more interesting and applicable to
many people.


Assuming that progress has been made on analogue to
h.263/mpeg4/VC-1/DivX/Xvid via the A/V-in encoder.
Is this still considered a low priority?


Raw analog is still very low down any list I have for the HVR22xx driver.



Has progress been made on hw encode via A/V-in?
I'm "finally" putting my entire system together soon, can't wait!
Looking forward to seeing how everything has progressed.
I'll be sure to do some donations once I'm up & running!


The current driver supports DTV only. I have no ETA for analog on the
HVR22xx driver. If you need analog support then the HVR22xx isn't the
right product for you.


--
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: DNTV Dual Hybrid (7164) PCIe

[Jed]

Judging by the silence I'm guessing that's a "negative"  ;-)

I actually had a closer read of this...
http://www.kernellabs.com/blog/?p=1339

So even if I donated a card I guess that's not going to compensate you
nearly enough to get analogue a/v-in at least partially working?

So it seems I went for a "bells & whistles" card which may never be 
fully supported. I seem to recall having the same experience

with a prior card, I wonder if I'll ever learn!

Are there any tuners with similar raw analogue capture/encoding
abilities (ideally component-in) that you do support more completely or
intend to?

Or should I be looking at dedicated video capture devices for better
linux-media support?

Thank-you

Jed wrote:

By "analogue side" I mainly mean A/V-in
Thank-you/Good night

Jed wrote:

Actually I'd be happy to donate...
So long as I knew there'd be some progress on the analogue side.
Already got the HVR-2200 for DVB.

Jed wrote:

Happy to do this, so long as I can get it back eventually?

Steven Toth wrote:

On 3/11/10 11:26 AM, Jed wrote:

Hi Kernellabs,

I'm thinking of getting this:
http://forums.dvbowners.com/index.php?showtopic=11720
It seems very similar to the HVR-2200 yet has component-in.
Do you reckon your module/s might support it?

Thank-you!


Highly likely the drivers will not support it. Each card has unique
firmware identifiers that need to be added manually to the driver.

If you'd like to provide me a card then I'd consider adding support.

- Steve










--
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://kernellabs.com/hg/~mkrufky/dvb-usb

[Douglas Schilling Landgraf]

Hey Michael,

Michael Krufky wrote:

Doug,

If possible, would you pull this changeset from my hg tree rather than
doing a git backport, after Mauro merges this?  If possible, I'd like
to retain the hash value of this changeset so that I don't have to
rebuild all of my development trees.  If you can do this for me, I'd
really appreciate it.  If a more detailed explanation of why I am
making this request is required, please say so and I'll explain in
further detail.


Sure.

Cheers
Douglas



Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/dvb-usb

for:

- dvb-usb: enable specifying a separate generic bulk ctrl response endpoint

 dvb-usb-urb.c |2 ++
 dvb-usb.h |7 +++
 2 files changed, 9 insertions(+)

This opens the door to make the dvb-usb framework more generic to be
able to support a variety of additional new devices.  It also will
allow us to cleanup / remove some redundant code in some existing
dvb-usb drivers.  After this is merged, cleanup patches on existing
drivers will follow.

Thanks & regards,

Mike Krufky


--
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/dvb-usb

[Michael Krufky]

Doug,

If possible, would you pull this changeset from my hg tree rather than
doing a git backport, after Mauro merges this?  If possible, I'd like
to retain the hash value of this changeset so that I don't have to
rebuild all of my development trees.  If you can do this for me, I'd
really appreciate it.  If a more detailed explanation of why I am
making this request is required, please say so and I'll explain in
further detail.

Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/dvb-usb

for:

- dvb-usb: enable specifying a separate generic bulk ctrl response endpoint

 dvb-usb-urb.c |2 ++
 dvb-usb.h |7 +++
 2 files changed, 9 insertions(+)

This opens the door to make the dvb-usb framework more generic to be
able to support a variety of additional new devices.  It also will
allow us to cleanup / remove some redundant code in some existing
dvb-usb drivers.  After this is merged, cleanup patches on existing
drivers will follow.

Thanks & regards,

Mike Krufky
--
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: i2c-id.h and alevt

[Manu Abraham]

On Fri, Mar 12, 2010 at 7:40 PM, Hans de Goede  wrote:
> Hi,
>
> On 03/11/2010 03:31 PM, Devin Heitmueller wrote:
>>
>> On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
>>   wrote:
>>>
>>> On 03/10/2010 02:04 AM, hermann pitton wrote:

 Hi Hans, both,

 Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:
>
> It's nice to see this new tree, that should be make it easier to
> develop
> utilities!
>
> After a quick check I noticed that the i2c-id.h header was copied from
> the
> kernel. This is not necessary. The only utility that includes this is
> v4l2-dbg
> and that one no longer needs it. Hans, can you remove this?
>
> The second question is whether anyone would object if alevt is moved
> from
> dvb-apps to v4l-utils? It is much more appropriate to have that tool in
> v4l-utils.

 i wonder that this stays such calm, hopefully a good sign.

 In fact alevt analog should come with almost every distribution, but the
 former alevt-dvb, named now only alevt, well, might be ok in some
 future, is enhanced for doing also dvb-t-s and hence there ATM.

> Does anyone know of other unmaintained but useful tools that we might
> merge
> into v4l-utils? E.g. xawtv perhaps?

 If for xawtv could be some more care, ships also since close to ever
 with alevtd, that would be fine, but I'm not sure we are talking about
 tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
 example are also there and unmaintained.

>>>
>>> I think would be nice to hear a word from Devin, which have been working
>>> in tvtime. Devin?
>>
>> Sorry, I've been sick for the last couple of days and not actively on
>> email.
>>
>> I don't think it's a good idea to consolidate applications like xawtv
>> and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
>> nice because it's small and what the packages provides what it says it
>> does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
>> applications to be "utilities".
>>
>> The apps in question are currently packaged by multiple distros today
>> as standalone packages.  Today distros can decide whether they want
>> the "bloat" associated with large GUI applications just to get the
>> benefits of a couple of command line utilities.  Bundling them
>> together makes that much harder (and would also result in a package
>> with lots of external dependencies on third party libraries).
>>
>> Adding them into v4l2-utils doesn't really solve the real problem -
>> that there are very few people willing to put in the effort to
>> extend/improve these applications (something which, as Douglas pointed
>> out, I'm trying to improve in the case of tvtime).
>>
>
> Ack,


ACK

> What would be good to do IMHO is decide for unmaintained apps like xawtv
> and alevt if we want to adopt them and if we do, to create separate git
> trees for them, and become a new upstream including doing regular
> tarbals releases. Some time ago I did a lot of work on the Fedora xawtv
> packages and I would be willing to pull such an effort for xawtv.


Simply creating a tree for an application doesn't really help. At
least it needs a "commitment" to that app to keep it updated. Unless,
someone really puts in such an effort, creating a tree doesn't really
help, it simplyt adds to the confusion for a normal user as to where
he should download his application for his distro, if such a package
doesn't exist.


Regards,
Manu
--
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: i2c-id.h and alevt

[Hans de Goede]

Hi,

On 03/11/2010 03:14 PM, Douglas Schilling Landgraf wrote:

On 03/10/2010 02:04 AM, hermann pitton wrote:

Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:

It's nice to see this new tree, that should be make it easier to develop
utilities!

After a quick check I noticed that the i2c-id.h header was copied from the
kernel. This is not necessary. The only utility that includes this is v4l2-dbg
and that one no longer needs it. Hans, can you remove this?




I somehow missed the original mail from Hans Verkuil here, so I'm replying here,
sorry for messing up the threading.

Fixed!

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: pushes at v4l-utils tree

[Hans de Goede]

Hi,

On 03/12/2010 01:21 AM, Mauro Carvalho Chehab wrote:

Hi Hans,

As we've agreed that the idea is to allow multiple people to commit at 
v4l-utils,
today, I've added 3 commits at v4l-utils tree (2 keycode-related and 1 is 
.gitignore
stuff). One of the reasons were to test the viability for such commits.

I've temporarily enabled the same script that we use for upstream patches to
generate patches against linuxtv-commits ML.

 From my experiences, I have some notes:
1) git won't work fine if more than one is committing at the same tree.
The reason is simple: it won't preserve the same group as the previous commits. 
So,
the next committer will have troubles if we allow multiple committers;



I assume you are talking about some issues with permissions on the server side 
here ?


2) people need to pull/rebase before pushing, if we fix the group 
permission
issue above. I've enabled a hook that is meant to avoid rebase upstream, to 
prevent
troubles if people push something with -f. I hope it works fine.



Ack, actually I just did that (rebase my local tree before pushing) as you 
pushed
some changes before I did.


In summary, for now, I think that the better is to post all patches to 
v4l-utils at ML
and ask Hans to merge them.



Yes and no, if you've a few patches, sure. If you are doing regular development 
you should
get commit access. In my experience in various projects multiple people pushing 
to the
same git tree will work fine.

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: v4l-utils: i2c-id.h and alevt

[Hans de Goede]

Hi,

On 03/11/2010 03:31 PM, Devin Heitmueller wrote:

On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
  wrote:

On 03/10/2010 02:04 AM, hermann pitton wrote:

Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:

It's nice to see this new tree, that should be make it easier to develop
utilities!

After a quick check I noticed that the i2c-id.h header was copied from the
kernel. This is not necessary. The only utility that includes this is v4l2-dbg
and that one no longer needs it. Hans, can you remove this?

The second question is whether anyone would object if alevt is moved from
dvb-apps to v4l-utils? It is much more appropriate to have that tool in
v4l-utils.


i wonder that this stays such calm, hopefully a good sign.

In fact alevt analog should come with almost every distribution, but the
former alevt-dvb, named now only alevt, well, might be ok in some
future, is enhanced for doing also dvb-t-s and hence there ATM.


Does anyone know of other unmaintained but useful tools that we might merge
into v4l-utils? E.g. xawtv perhaps?


If for xawtv could be some more care, ships also since close to ever
with alevtd, that would be fine, but I'm not sure we are talking about
tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
example are also there and unmaintained.



I think would be nice to hear a word from Devin, which have been working in 
tvtime. Devin?


Sorry, I've been sick for the last couple of days and not actively on email.

I don't think it's a good idea to consolidate applications like xawtv
and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
nice because it's small and what the packages provides what it says it
does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
applications to be "utilities".

The apps in question are currently packaged by multiple distros today
as standalone packages.  Today distros can decide whether they want
the "bloat" associated with large GUI applications just to get the
benefits of a couple of command line utilities.  Bundling them
together makes that much harder (and would also result in a package
with lots of external dependencies on third party libraries).

Adding them into v4l2-utils doesn't really solve the real problem -
that there are very few people willing to put in the effort to
extend/improve these applications (something which, as Douglas pointed
out, I'm trying to improve in the case of tvtime).



Ack,

What would be good to do IMHO is decide for unmaintained apps like xawtv
and alevt if we want to adopt them and if we do, to create separate git
trees for them, and become a new upstream including doing regular
tarbals releases. Some time ago I did a lot of work on the Fedora xawtv
packages and I would be willing to pull such an effort for xawtv.

If we start doing this we really should start running some sort of
bugtracker on linuxtv.org btw, or ask if we can use bugzilla.kernel.org
for this.

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: v4l-utils: i2c-id.h and alevt

[Hans de Goede]

Hi,

On 03/12/2010 08:27 AM, Hans Verkuil wrote:

On Thursday 11 March 2010 15:31:32 Devin Heitmueller wrote:

On Thu, Mar 11, 2010 at 9:14 AM, Douglas Schilling Landgraf
  wrote:

On 03/10/2010 02:04 AM, hermann pitton wrote:

Hi Hans, both,

Am Dienstag, den 09.03.2010, 08:48 +0100 schrieb Hans Verkuil:

It's nice to see this new tree, that should be make it easier to develop
utilities!

After a quick check I noticed that the i2c-id.h header was copied from the
kernel. This is not necessary. The only utility that includes this is v4l2-dbg
and that one no longer needs it. Hans, can you remove this?

The second question is whether anyone would object if alevt is moved from
dvb-apps to v4l-utils? It is much more appropriate to have that tool in
v4l-utils.


i wonder that this stays such calm, hopefully a good sign.

In fact alevt analog should come with almost every distribution, but the
former alevt-dvb, named now only alevt, well, might be ok in some
future, is enhanced for doing also dvb-t-s and hence there ATM.


Does anyone know of other unmaintained but useful tools that we might merge
into v4l-utils? E.g. xawtv perhaps?


If for xawtv could be some more care, ships also since close to ever
with alevtd, that would be fine, but I'm not sure we are talking about
tools anymore in such case, since xawtv4x, tvtime and mpeg4ip ;) for
example are also there and unmaintained.



I think would be nice to hear a word from Devin, which have been working in 
tvtime. Devin?


Sorry, I've been sick for the last couple of days and not actively on email.

I don't think it's a good idea to consolidate applications like xawtv
and tvtime into the v4l2-utils codebase.  The existing v4l2-utils is
nice because it's small and what the packages provides what it says it
does - v4l2 *utilities*.  I wouldn't consider full blown tv viewing
applications to be "utilities".

The apps in question are currently packaged by multiple distros today
as standalone packages.  Today distros can decide whether they want
the "bloat" associated with large GUI applications just to get the
benefits of a couple of command line utilities.  Bundling them
together makes that much harder (and would also result in a package
with lots of external dependencies on third party libraries).

Adding them into v4l2-utils doesn't really solve the real problem -
that there are very few people willing to put in the effort to
extend/improve these applications (something which, as Douglas pointed
out, I'm trying to improve in the case of tvtime).


For unmaintained applications the problem is that even those people that
have patches for them have no easy way to get them applied, precisely because
they are unmaintained.

We as v4l-dvb developers don't have the time to make TV apps, but perhaps if
we 'adopted' one unmaintained application and just update that whenever we
make new features, then that would be very helpful I think. Or perhaps just
provide a place for such applications where there is someone who can take
community supplied patches and review and apply them.

Such an application does not have to be in v4l2-utils, it can have its own
tree.

Anyway, regarding alevt: I believe that the consensus is that it should be
moved to v4l2-utils? Or am I wrong?



I'm not in favor of moving alevt into v4l-utils, if there are
people who want to pick up its maintenance and host a separate tree for
it at linuxtv.org including doing regular tarbal releases for upstream to 
consume
that would seem a good idea to me.

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: v4l-utils: i2c-id.h and alevt

[Devin Heitmueller]

On Fri, Mar 12, 2010 at 2:27 AM, Hans Verkuil  wrote:
> For unmaintained applications the problem is that even those people that
> have patches for them have no easy way to get them applied, precisely because
> they are unmaintained.
>
> We as v4l-dvb developers don't have the time to make TV apps, but perhaps if
> we 'adopted' one unmaintained application and just update that whenever we
> make new features, then that would be very helpful I think. Or perhaps just
> provide a place for such applications where there is someone who can take
> community supplied patches and review and apply them.

This is the key reason that KernelLabs "adopted" tvtime - the goal being to:

1.  Consolidate all the distro patches floating around
2.  Have a source tree that compiles without patches on modern distributions
3.  Have a channel for people to submit new patches
4.  Make improvements as necessary to make the app "just work" for
most modern tuner cards.

The goal is to get the distros to switch over to treating our tree as
the "official upstream source" so that people will finally have a
lightweight application for analog tv that "just works" and ships with
their Linux distro by default.

> Such an application does not have to be in v4l2-utils, it can have its own
> tree.

If the goal is for the LinuxTV group to adopt some of these
applications, I would definitely recommend it not be in the v4l-utils
tree (for reasons stated in the previous email).  that said, I
certainly have no objection to it in principle.

> Anyway, regarding alevt: I believe that the consensus is that it should be
> moved to v4l2-utils? Or am I wrong?

I haven't looked at the alevt code itself but I believe the answer
should be based on the following questions:

1.  How big is it?  Will distros not want to include the package by
default because along with a few KB of utilities they also end up with
several megabytes of crap that the vast majority of people don't care
about?

2.  What external dependencies does it have?  Right now, v4l-utils is
just a few command line tools with minimal dependencies (meaning it is
trivial to install in pretty much all environments, including those
without X11).  If the result is that you would now have to install
dozens of packages, then that would be a bad thing.

Jamming stuff into v4l-utils should not be seen as some sort of
backdoor way to get Linux distributions to include programs that they
wouldn't have otherwise.  The distributions should see real value in
the additional tool.  If they value the program, they will package the
program if we host it even as a standalone project outside of
v4l-utils.

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

Hybrid Yuan MC770A TV tuner and UVC Video

[Damian Krasowski]

Hello

I'm interresing in analog part (tv/radio) of Hybrid Yuan MC770A TV
tuner from ASUS F3 series notebook and many other newer series.
You could add uvcvideo support for vflip Sonix 1.3M Webcam placed in
ASUS F3 series notebook?

-- 
Damian Krasowski
--
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 1/6] V4L/DVB: tlg2300: remove unused #include

[Huang Weiyi]

Remove unused #include ('s) in
  drivers/media/video/tlg2300/pd-main.c

Signed-off-by: Huang Weiyi 
---
 drivers/media/video/tlg2300/pd-main.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/tlg2300/pd-main.c 
b/drivers/media/video/tlg2300/pd-main.c
index 2cf0ebf..b8b6e3f 100644
--- a/drivers/media/video/tlg2300/pd-main.c
+++ b/drivers/media/video/tlg2300/pd-main.c
@@ -24,7 +24,6 @@
  *  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
-#include 
 #include 
 #include 
 #include 
-- 
1.6.1.3

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

"xc2028 1-0061: error: bandwidth not supported." If anyone could help me ?

[Arnaud Boy]

Hi,

I have 2 differents dongle but the same errors appairs because there's
the same tuner system. I'll use this dongles for dvb-t reception.

The driver i'm using is the mercurial revision "82c3b0033929 tip"

Maybe I forget something, please anyone should help me.

When I'll try to see a dvb-t channel with the card 1 (PCTV 330e) i'll
get this error.
==
[12687.577100] xc2028 1-0061: error: bandwidth not supported.
[12687.636069] xc2028 1-0061: Loading firmware for type=BASE MTS (5),
id .
[12688.768071] xc2028 1-0061: Loading firmware for type=BASE MTS (5),
id .

With the card 2 (USB 2881 Video) I've the same errors
===
[12888.431519] xc2028 1-0061: error: bandwidth not supported.
[12888.488512] xc2028 1-0061: Loading firmware for type=BASE (1), id
.
[12889.589077] xc2028 1-0061: Loading firmware for type=BASE (1), id
.


Card 1 dmesg
==
[12308.004121] usb 1-1: new high speed USB device using ehci_hcd and address 11
[12308.145714] usb 1-1: New USB device found, idVendor=2304, idProduct=0226
[12308.145725] usb 1-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[12308.145733] usb 1-1: Product: PCTV 330e
[12308.145739] usb 1-1: Manufacturer: Pinnacle Systems
[12308.145744] usb 1-1: SerialNumber: 061101027954
[12308.145960] usb 1-1: configuration #1 chosen from 1 choice
[12308.14] em28xx: New device Pinnacle Systems PCTV 330e @ 480
Mbps (2304:0226, interface 0, class 0)
[12308.148053] em28xx #0: chip ID is em2882/em2883
[12308.324566] em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 26 02 d0 12
5c 03 8e 16 a4 1c
[12308.324589] em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00
00 00 00 00 00 00
[12308.324610] em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00
00 00 5b e0 00 00
[12308.324629] em28xx #0: i2c eeprom 30: 00 00 20 40 20 6e 02 20 10 01
00 00 00 00 00 00
[12308.324647] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324665] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324683] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00
24 03 50 00 69 00
[12308.324701] em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00
65 00 20 00 53 00
[12308.324719] em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00
73 00 00 00 16 03
[12308.324737] em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00
33 00 33 00 30 00
[12308.324755] em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00
31 00 31 00 30 00
[12308.324773] em28xx #0: i2c eeprom b0: 31 00 30 00 32 00 37 00 39 00
35 00 34 00 00 00
[12308.324791] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324809] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324827] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324845] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00
[12308.324867] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xb0b3aebf
[12308.324873] em28xx #0: EEPROM info:
[12308.324877] em28xx #0:   AC97 audio (5 sample rates)
[12308.324882] em28xx #0:   500mA max power
[12308.324888] em28xx #0:   Table at 0x27, strings=0x168e, 0x1ca4, 0x246a
[12308.326783] em28xx #0: Identified as Pinnacle Hybrid Pro (330e) (card=56)
[12308.330650] tvp5150 1-005c: chip found @ 0xb8 (em28xx #0)
[12308.336375] tuner 1-0061: chip found @ 0xc2 (em28xx #0)
[12308.336536] xc2028 1-0061: creating new instance
[12308.336543] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
[12308.336558] usb 1-1: firmware: requesting xc3028-v27.fw
[12308.346584] xc2028 1-0061: Loading 80 firmware images from
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
[12308.392088] xc2028 1-0061: Loading firmware for type=BASE MTS (5),
id .
[12309.399125] xc2028 1-0061: Loading firmware for type=MTS (4), id
b700.
[12309.415115] xc2028 1-0061: Loading SCODE for type=MTS LCD NOGD MONO
IF SCODE HAS_IF_4500 (6002b004), id b700.
[12309.540632] input: em28xx IR (em28xx #0) as
/devices/pci:00/:00:12.2/usb1/1-1/input/input22
[12309.540781] Creating IR device irrcv0
[12309.541715] em28xx #0: Config register raw data: 0xd0
[12309.542565] em28xx #0: AC97 vendor ID = 0x
[12309.542933] em28xx #0: AC97 features = 0x6a90
[12309.542941] em28xx #0: Empia 202 AC97 audio processor detected
[12309.673039] tvp5150 1-005c: tvp5150am1 detected.
[12309.777174] em28xx #0: v4l2 driver version 0.1.2
[12309.863427] em28xx #0: V4L2 video device registered as video1
[12309.863432] em28xx #0: V4L2 VBI device registered as vbi0
[12309.863435] em28xx-audio.c: probing for em28x1 non standard usbaudio
[12309.863438] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger
[12309.915259] xc2028 1-0061: attaching existing instance
[12309.915264] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner
[123

terratec hybrid xs fm

[Adriano Gigante]

Devin,
I know I'm boring...
any news about "0072/terratec hybrid xs fm" driver develop progress?
Thanks
Adri
--
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

tzap -r doesn't work on new Swedish DVB-T channels

[Magnus H]

Hi. Since february there are some new h264 SD channels in the Swedish DVB-T
network. I get a lock with tzap, I can watch the channels in VDR but I get
no output on /dev/dvb/adapterX/dvr0 then running tzap -r on 506 MHz. On all
other transponders I get a stream on dvr0. Scan finds some strange channels
that don't provide a name on this frequency:

[04b0]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:1200:3
[0316]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:790:3
[0320]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:800:3
Boxer
Navigator:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:T
RANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:65534:3
[0302]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:770:3
[02ee]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:750:3
BBC World
News:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSM
ISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:560:3
Discovery
T&L:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMI
SSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:570:3
Discovery
Science:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRA
NSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:580:3
Disney
XD:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMIS
SION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:590:3
Showtime:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TR
ANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:600:3
7:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISS
ION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:810:3
Star!:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANS
MISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:960:3

Can anyone point me in the right direction in the tzap code to try to find
the reason for this?

/Magnus H


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

tzap -r doesn't work on new Swedish DVB-T channels

[Hörlin Magnus]

Hi. Since february there are some new h264 SD channels in the Swedish DVB-T 
network. I get a lock with tzap, I can watch the channels in VDR but I get no 
output on /dev/dvb/adapterX/dvr0 then running tzap -r on 506 MHz. On all other 
transponders I get a stream on dvr0. Scan finds some strange channels that 
don't provide a name on this frequency:

[04b0]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:1200:3
[0316]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:790:3
[0320]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:800:3
Boxer 
Navigator:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:65534:3
[0302]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:770:3
[02ee]:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:750:3
BBC World 
News:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:560:3
Discovery 
T&L:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:570:3
Discovery 
Science:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:580:3
Disney 
XD:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:590:3
Showtime:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:600:3
7:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:810:3
Star!:50600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE:0:0:960:3

Can anyone point me in the right direction in the tzap code to try to find the 
reason for this?

/Magnus H


The information contained in this e-mail message is privileged and
confidential and is for the exclusive use of the addressee. The person
who receives this message and who is not the addressee, one of his
employees or an agent entitled to hand it over to the addressee, is
informed that he may not use, disclose or reproduce the contents
thereof, and is kindly asked to notify the sender and delete the e-mail
immediately.


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

Announcing v4l-utils-0.7.91

[Hans de Goede]

Hi,

I'm happy to announce the second release of v4l-utils, nothing
special this time around just a few small bug fixes and cleanups
left and right.
New this release:

v4l-utils-0.7.91

* Utils changes:
  * Improve v4l-keytable to better support IR (mchehab)
  * Rename v4l-keytable to ir-keytable (mchehab)
* libv4l changes (hdegoede):
  * Add more laptop models to the upside down devices table
  * Ignore convert errors in the first few frames of a stream

Go get it here:
http://people.fedoraproject.org/~jwrdegoede/v4l-utils-0.7.91.tar.bz2

You can always find the latest developments here:
http://git.linuxtv.org/v4l-utils.git

Note, it would be good to have some place at linuxtv.org to host the
tarbals, if someone could help me set that up that would be great.

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 v2] V4L/DVB: mx1-camera: compile fix

[Guennadi Liakhovetski]

On Fri, 12 Mar 2010, Uwe Kleine-König wrote:

> >   Or maybe even we shall remap those registers?
> Well, they are remapped, don't they?  Otherwise IO_ADDRESS wouldn't
> work.

Yes, they are (statically, I presume), but not in _this_ driver...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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

Re: [PATCH v2] V4L/DVB: mx1-camera: compile fix

[Uwe Kleine-König]

Hello,

On Fri, Mar 12, 2010 at 10:22:31AM +0100, Guennadi Liakhovetski wrote:
> On Fri, 5 Mar 2010, Uwe Kleine-König wrote:
> > This is a regression of
> > 
> > 7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old 
> > names)
> > 
> > Signed-off-by: Uwe Kleine-König 
> > ---
> >  drivers/media/video/mx1_camera.c |   12 +++-
> >  1 files changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/media/video/mx1_camera.c 
> > b/drivers/media/video/mx1_camera.c
> > index 2ba14fb..29c2833 100644
> > --- a/drivers/media/video/mx1_camera.c
> > +++ b/drivers/media/video/mx1_camera.c
> > @@ -45,11 +45,13 @@
> >  #include 
> >  #include 
> >  
> > +#define __DMAREG(offset)   (MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) + offset)
> > +
> 
> Well, I think, Sascha is right, we have to fix 
> arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h, because that's what actually 
> got broken. The line
> 
> #define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR)
> 
> in it is no longer valid, right? So, we have to either remove it, or fix 
> it, if we think, that other drivers might start using it.
I thought a minimal fix would be a good idea.  I have no problem with a
clean one though.

>   And even if we 
> decide to remove it from the header and implement here, wouldn't it be 
> better to choose a name, not beginning with "__"? Something like 
> MX1_DMA_REG, perhaps?
Then the register definitions should go into the header, too.  I will
prepare a patch later today.
>   Or maybe even we shall remap those registers?
Well, they are remapped, don't they?  Otherwise IO_ADDRESS wouldn't
work.

Best regards
Uwe
-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.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

Re: [PATCH] saa7134: Fix IR support of some ASUS TV-FM 7135 variants

[Jean Delvare]

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.

-- 
Jean Delvare
--
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 v2] V4L/DVB: mx1-camera: compile fix

[Guennadi Liakhovetski]

Hi Uwe

On Fri, 5 Mar 2010, Uwe Kleine-König wrote:

> This is a regression of
> 
>   7d58289 (mx1: prefix SOC specific defines with MX1_ and deprecate old 
> names)
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/media/video/mx1_camera.c |   12 +++-
>  1 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/video/mx1_camera.c 
> b/drivers/media/video/mx1_camera.c
> index 2ba14fb..29c2833 100644
> --- a/drivers/media/video/mx1_camera.c
> +++ b/drivers/media/video/mx1_camera.c
> @@ -45,11 +45,13 @@
>  #include 
>  #include 
>  
> +#define __DMAREG(offset) (MX1_IO_ADDRESS(MX1_DMA_BASE_ADDR) + offset)
> +

Well, I think, Sascha is right, we have to fix 
arch/arm/plat-mxc/include/mach/dma-mx1-mx2.h, because that's what actually 
got broken. The line

#define DMA_BASE IO_ADDRESS(DMA_BASE_ADDR)

in it is no longer valid, right? So, we have to either remove it, or fix 
it, if we think, that other drivers might start using it. And even if we 
decide to remove it from the header and implement here, wouldn't it be 
better to choose a name, not beginning with "__"? Something like 
MX1_DMA_REG, perhaps? Or maybe even we shall remap those registers?

Thanks
Guennadi

>  /*
>   * CSI registers
>   */
> -#define DMA_CCR(x)   (0x8c + ((x) << 6)) /* Control Registers */
> -#define DMA_DIMR 0x08/* Interrupt mask Register */
> +#define DMA_CCR(x)   __DMAREG(0x8c + ((x) << 6)) /* Control Registers */
> +#define DMA_DIMR __DMAREG(0x08)  /* Interrupt mask Register */
>  #define CSICR1   0x00/* CSI Control Register 
> 1 */
>  #define CSISR0x08/* CSI Status Register 
> */
>  #define CSIRXR   0x10/* CSI RxFIFO Register 
> */
> @@ -783,7 +785,7 @@ static int __init mx1_camera_probe(struct platform_device 
> *pdev)
>  pcdev);
>  
>   imx_dma_config_channel(pcdev->dma_chan, IMX_DMA_TYPE_FIFO,
> -IMX_DMA_MEMSIZE_32, DMA_REQ_CSI_R, 0);
> +IMX_DMA_MEMSIZE_32, MX1_DMA_REQ_CSI_R, 0);
>   /* burst length : 16 words = 64 bytes */
>   imx_dma_config_burstlen(pcdev->dma_chan, 0);
>  
> @@ -797,8 +799,8 @@ static int __init mx1_camera_probe(struct platform_device 
> *pdev)
>   set_fiq_handler(&mx1_camera_sof_fiq_start, &mx1_camera_sof_fiq_end -
>  &mx1_camera_sof_fiq_start);
>  
> - regs.ARM_r8 = DMA_BASE + DMA_DIMR;
> - regs.ARM_r9 = DMA_BASE + DMA_CCR(pcdev->dma_chan);
> + regs.ARM_r8 = (long)DMA_DIMR;
> + regs.ARM_r9 = (long)DMA_CCR(pcdev->dma_chan);
>   regs.ARM_r10 = (long)pcdev->base + CSICR1;
>   regs.ARM_fp = (long)pcdev->base + CSISR;
>   regs.ARM_sp = 1 << pcdev->dma_chan;
> -- 
> 1.7.0
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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

RE: [patch 2/5] drivers/media/video: move dereference after NULL test

[Julia Lawall]

From: Julia Lawall 

In quickcam_messenger.c, if the NULL test on uvd is needed, then the
dereference should be after the NULL test.

In vpif_display.c, std_info is initialized to the address of a structure
field.  This seems unlikely to be NULL.  Test std_info->stdid instead.

In saa7134-alsa.c, the function is only called from one place, where the
chip argument has already been dereferenced.  On the other hand, if it
should be kept, then card should be initialized after it.

A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):

// 
@match exists@
expression x, E;
identifier fld;
@@

* x->fld
  ... when != \(x = E\|&x\)
* x == NULL
// 

Signed-off-by: Julia Lawall 

---
 drivers/media/video/davinci/vpif_display.c|2 +-
 drivers/media/video/saa7134/saa7134-alsa.c|2 --
 drivers/media/video/usbvideo/quickcam_messenger.c |3 ++-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/media/video/usbvideo/quickcam_messenger.c 
b/drivers/media/video/usbvideo/quickcam_messenger.c
index 803d3e4..f0043d0 100644
--- a/drivers/media/video/usbvideo/quickcam_messenger.c
+++ b/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -692,12 +692,13 @@ static int qcm_start_data(struct uvd *uvd)
 
 static void qcm_stop_data(struct uvd *uvd)
 {
-   struct qcm *cam = (struct qcm *) uvd->user_data;
+   struct qcm *cam;
int i, j;
int ret;
 
if ((uvd == NULL) || (!uvd->streaming) || (uvd->dev == NULL))
return;
+   cam = (struct qcm *) uvd->user_data;
 
ret = qcm_camera_off(uvd);
if (ret)
diff --git a/drivers/media/video/saa7134/saa7134-alsa.c 
b/drivers/media/video/saa7134/saa7134-alsa.c
index d48c450..d3bd82a 100644
--- a/drivers/media/video/saa7134/saa7134-alsa.c
+++ b/drivers/media/video/saa7134/saa7134-alsa.c
@@ -1011,8 +1011,6 @@ static int snd_card_saa7134_new_mixer(snd_card_saa7134_t 
* chip)
unsigned int idx;
int err, addr;
 
-   if (snd_BUG_ON(!chip))
-   return -EINVAL;
strcpy(card->mixername, "SAA7134 Mixer");
 
for (idx = 0; idx < ARRAY_SIZE(snd_saa7134_volume_controls); idx++) {
diff --git a/drivers/media/video/davinci/vpif_display.c 
b/drivers/media/video/davinci/vpif_display.c
index dfddef7..b2dce78 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -383,7 +383,7 @@ static int vpif_get_std_info(struct channel_obj *ch)
int index;
 
std_info->stdid = vid_ch->stdid;
-   if (!std_info)
+   if (!std_info->stdid)
return -1;
 
for (index = 0; index < ARRAY_SIZE(ch_params); index++) {
--
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: Status of the patches under review (45 patches)

[Jean-Francois Moine]

Hi Mauro,

On Tue, 09 Mar 2010 16:05:44 -0300
Mauro Carvalho Chehab  wrote:

>   == Gspca patches - Waiting Jean-Francois Moine
>  submission/review == 
> 
> Jan,14 2010: Problem with gspca and zc3xx
> http://patchwork.kernel.org/patch/72895

This is not the right way to fix the problem.

[snip]
> Feb,28 2010: [1/3] add feedback LED control
> http://patchwork.kernel.org/patch/82773
> Feb,28 2010: [2/3] gspca pac7302: add LED control
> http://patchwork.kernel.org/patch/82774
> Feb,28 2010: [3/3] gspca pac7302: remove LED blinking when switching
> stream on and http://patchwork.kernel.org/patch/82775

It is not sure yet that using the LED system is the right way...

Regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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: Status of the patches under review (45 patches)

[Jean-Francois Moine]

Hi Hans,

On Fri, 12 Mar 2010 09:07:22 +0100
Hans de Goede  wrote:
> > == Gspca patches - Waiting Hans de
> > Goede  submission/review ==
> >
> > Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown
> > packet received   http://patchwork.kernel.org/patch/75837
> 
> I nacked this one, as the zc3xx sends many non button press interrupt
> packets per second which this patch would all log to dmesg as being
> unknown.

Agree.

> > Mar, 8 2010: [1/1] gspca-stv06xx: Remove the 046d:08da usb id from
> > linking to the   http://patchwork.kernel.org/patch/84145
> >
> 
> I acked this one, this should go in through Erik Andren's own tree.

I already sent a pull request for this one.

Cheers.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
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: Status of the patches under review (45 patches)

[Hans de Goede]

Hi,


== Gspca patches - Waiting Hans de Goede  
submission/review ==

Jan,29 2010: [gspca_jf,tree] gspca zc3xx: signal when unknown packet received   
http://patchwork.kernel.org/patch/75837


I nacked this one, as the zc3xx sends many non button press interrupt packets 
per second which this patch would all
log to dmesg as being unknown.


Mar, 8 2010: [1/1] gspca-stv06xx: Remove the 046d:08da usb id from linking to 
the   http://patchwork.kernel.org/patch/84145



I acked this one, this should go in through Erik Andren's own tree.

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