[PATCH] gspca main: reorganize loop
From: Márton Németh
Eliminate redundant code by reorganizing the loop.
Signed-off-by: Márton Németh
---
diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Thu Nov 26 19:36:40 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Sun Nov 29 11:09:33 2009 +0100
@@ -623,12 +623,12 @@
if (ret < 0)
goto out;
}
- ep = get_ep(gspca_dev);
- if (ep == NULL) {
- ret = -EIO;
- goto out;
- }
for (;;) {
+ ep = get_ep(gspca_dev);
+ if (ep == NULL) {
+ ret = -EIO;
+ goto out;
+ }
PDEBUG(D_STREAM, "init transfer alt %d", gspca_dev->alt);
ret = create_urbs(gspca_dev, ep);
if (ret < 0)
@@ -677,12 +677,6 @@
ret = gspca_dev->sd_desc->isoc_nego(gspca_dev);
if (ret < 0)
goto out;
- } else {
- ep = get_ep(gspca_dev);
- if (ep == NULL) {
- ret = -EIO;
- goto out;
- }
}
}
out:
--
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] gspca main: remove unnecessary set to alternate 0
From: Márton Németh Calling gspca_set_alt0() in gspca_dev_probe() is not needed as gspca_set_alt0() will do nothing because gspca_dev->alt is always zero at that time. Signed-off-by: Márton Németh --- diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c --- a/linux/drivers/media/video/gspca/gspca.c Thu Nov 26 19:36:40 2009 +0100 +++ b/linux/drivers/media/video/gspca/gspca.c Sun Nov 29 11:14:23 2009 +0100 @@ -2066,9 +2060,6 @@ ret = sd_desc->init(gspca_dev); if (ret < 0) goto out; - ret = gspca_set_alt0(gspca_dev); - if (ret < 0) - goto out; gspca_set_default_mode(gspca_dev); mutex_init(&gspca_dev->usb_lock); -- 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] gspca main: reorganize loop
On Sun, 29 Nov 2009 11:24:31 +0100
Németh Márton wrote:
> From: Márton Németh
>
> Eliminate redundant code by reorganizing the loop.
>
> Signed-off-by: Márton Németh
> ---
> diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
> --- a/linux/drivers/media/video/gspca/gspca.c Thu Nov 26
> 19:36:40 2009 +0100 +++
> b/linux/drivers/media/video/gspca/gspca.c Sun Nov 29 11:09:33
> 2009 +0100 @@ -623,12 +623,12 @@ if (ret < 0)
> goto out;
> }
> - ep = get_ep(gspca_dev);
> - if (ep == NULL) {
> - ret = -EIO;
> - goto out;
> - }
> for (;;) {
> + ep = get_ep(gspca_dev);
> + if (ep == NULL) {
> + ret = -EIO;
> + goto out;
> + }
> PDEBUG(D_STREAM, "init transfer alt %d",
> gspca_dev->alt); ret = create_urbs(gspca_dev, ep);
> if (ret < 0)
> @@ -677,12 +677,6 @@
> ret =
> gspca_dev->sd_desc->isoc_nego(gspca_dev); if (ret < 0)
> goto out;
> - } else {
> - ep = get_ep(gspca_dev);
> - if (ep == NULL) {
> - ret = -EIO;
> - goto out;
> - }
> }
> }
> out:
Hello Márton,
As you may see, in the loop, get_ep() is called only when isoc_nego()
is not called. So, your patch does not work.
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: [PATCH] gspca main: reorganize loop
Jean-Francois Moine wrote:
> On Sun, 29 Nov 2009 11:24:31 +0100
> Németh Márton wrote:
>
>> From: Márton Németh
>>
>> Eliminate redundant code by reorganizing the loop.
>>
>> Signed-off-by: Márton Németh
>> ---
>> diff -r 064a82aa2daa linux/drivers/media/video/gspca/gspca.c
>> --- a/linux/drivers/media/video/gspca/gspca.cThu Nov 26
>> 19:36:40 2009 +0100 +++
>> b/linux/drivers/media/video/gspca/gspca.cSun Nov 29 11:09:33
>> 2009 +0100 @@ -623,12 +623,12 @@ if (ret < 0)
>> goto out;
>> }
>> -ep = get_ep(gspca_dev);
>> -if (ep == NULL) {
>> -ret = -EIO;
>> -goto out;
>> -}
>> for (;;) {
>> +ep = get_ep(gspca_dev);
>> +if (ep == NULL) {
>> +ret = -EIO;
>> +goto out;
>> +}
>> PDEBUG(D_STREAM, "init transfer alt %d",
>> gspca_dev->alt); ret = create_urbs(gspca_dev, ep);
>> if (ret < 0)
>> @@ -677,12 +677,6 @@
>> ret =
>> gspca_dev->sd_desc->isoc_nego(gspca_dev); if (ret < 0)
>> goto out;
>> -} else {
>> -ep = get_ep(gspca_dev);
>> -if (ep == NULL) {
>> -ret = -EIO;
>> -goto out;
>> -}
>> }
>> }
>> out:
>
> Hello Márton,
>
> As you may see, in the loop, get_ep() is called only when isoc_nego()
> is not called. So, your patch does not work.
You are right, I overseen that.
Is there any subdriver where the isoc_nego() is implemented? I couldn't find
one. What would be the task of the isoc_nego() function? Should it set
the interface by calling usb_set_interface() as the get_ep() does? Should
it create URBs for the endpoint?
Although I found the patch where the isoc_nego() was introduced
( http://linuxtv.org/hg/v4l-dvb/rev/5a5b23605bdb56aec86c9a89de8ca8b8ae9cb925 )
it is not clear how the "ep" pointer is updated when not the isoc_nego() is
called instead of get_ep() in the current implementation.
Regards,
Márton Németh
--
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
Skystar HD2 and s2-liplianin/mantis driver.
Hello list I try to build latest s2-liplianin drivers but make shows severals warnings and module not load after build driver: WARNING: "ir_input_keydown" [s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_codes_mantis_vp1041_table" [s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_input_nokey" [s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_input_init" [s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_codes_mantis_vp2040_table" [s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_codes_mantis_vp2033_table" [s2-liplianin/v4l/mantis.ko] undefined! My kernel is 2.6.31.4. The attached is full driver build log. Any idea to fix this problem ? /usr/local/src/s2-liplianin|status:0|jobs:0|# make -j 2 make -C /usr/local/src/s2-liplianin/v4l make[1]: se ingresa al directorio `/usr/local/src/s2-liplianin/v4l' perl scripts/make_config_compat.pl /lib/modules/2.6.31.4/source ./.myconfig ./config-compat.h creating symbolic links... make -C firmware prep make[2]: Entering directory `/usr/local/src/s2-liplianin/v4l/firmware' make[2]: Leaving directory `/usr/local/src/s2-liplianin/v4l/firmware' make -C firmware make[2]: Entering directory `/usr/local/src/s2-liplianin/v4l/firmware' CC ihex2fw Generating vicam/firmware.fw Generating dabusb/firmware.fw Generating dabusb/bitstream.bin Generating ttusb-budget/dspbootcode.bin Generating cpia2/stv0672_vp4.bin Generating av7110/bootcode.bin make[2]: Leaving directory `/usr/local/src/s2-liplianin/v4l/firmware' Kernel build directory is /lib/modules/2.6.31.4/build make -C /lib/modules/2.6.31.4/build SUBDIRS=/usr/local/src/s2-liplianin/v4l modules make[2]: Entering directory `/usr/src/linux-2.6.31.4' CC [M] /usr/local/src/s2-liplianin/v4l/tuner-xc2028.o CC [M] /usr/local/src/s2-liplianin/v4l/tuner-simple.o CC [M] /usr/local/src/s2-liplianin/v4l/tuner-types.o CC [M] /usr/local/src/s2-liplianin/v4l/mt20xx.o CC [M] /usr/local/src/s2-liplianin/v4l/tda8290.o CC [M] /usr/local/src/s2-liplianin/v4l/tea5767.o CC [M] /usr/local/src/s2-liplianin/v4l/tea5761.o CC [M] /usr/local/src/s2-liplianin/v4l/tda9887.o CC [M] /usr/local/src/s2-liplianin/v4l/xc5000.o CC [M] /usr/local/src/s2-liplianin/v4l/mc44s803.o CC [M] /usr/local/src/s2-liplianin/v4l/dvbdev.o CC [M] /usr/local/src/s2-liplianin/v4l/dmxdev.o CC [M] /usr/local/src/s2-liplianin/v4l/dvb_demux.o CC [M] /usr/local/src/s2-liplianin/v4l/dvb_filter.o CC [M] /usr/local/src/s2-liplianin/v4l/dvb_ca_en50221.o CC [M] /usr/local/src/s2-liplianin/v4l/dvb_frontend.o CC [M] /usr/local/src/s2-liplianin/v4l/dvb_net.o CC [M] /usr/local/src/s2-liplianin/v4l/dvb_ringbuffer.o CC [M] /usr/local/src/s2-liplianin/v4l/dvb_math.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_core.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_dma.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_pci.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_i2c.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_dvb.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_evm.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_hif.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_ca.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_pcmcia.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_vp1033.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_vp1034.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_vp1041.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_vp2033.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_vp2040.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_vp3030.o CC [M] /usr/local/src/s2-liplianin/v4l/mantis_rc.o CC [M] /usr/local/src/s2-liplianin/v4l/dvb-pll.o CC [M] /usr/local/src/s2-liplianin/v4l/stv0299.o CC [M] /usr/local/src/s2-liplianin/v4l/zl10353.o CC [M] /usr/local/src/s2-liplianin/v4l/mb86a16.o CC [M] /usr/local/src/s2-liplianin/v4l/cu1216.o /usr/local/src/s2-liplianin/v4l/cu1216.c:395: warning: 'cu1216_read_quality' defined but not used LD [M] /usr/local/src/s2-liplianin/v4l/mantis.o LD [M] /usr/local/src/s2-liplianin/v4l/dvb-core.o /usr/local/src/s2-liplianin/v4l/mb86a16.c:1885: warning: initialization from incompatible pointer type Building modules, stage 2. MODPOST 17 modules WARNING: "ir_input_keydown" [/usr/local/src/s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_codes_mantis_vp1041_table" [/usr/local/src/s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_input_nokey" [/usr/local/src/s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_input_init" [/usr/local/src/s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_codes_mantis_vp2040_table" [/usr/local/src/s2-liplianin/v4l/mantis.ko] undefined! WARNING: "ir_codes_mantis_vp2033_table" [/usr/local/src/s2-liplianin/v4l/mantis.ko] undefined! CC /usr/local/src/s2-liplianin/v4l/cu1216.mod.o CC /usr/local/src/s2-liplianin/v4l/dvb-core.mod.o CC /usr/local/src/s2-liplianin/v4l/dvb-pll.mod.o CC /usr/local/src/s2-liplianin/v4l/mantis.mod.o CC
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Jon, on 27 Nov 09 at 12:49, Jon Smirl wrote: [...] > Christoph, take what you know from all of the years of working on LIRC > and design the perfect in-kernel system. This is the big chance to > redesign IR support and get rid of any past mistakes. Incorporate any > useful chunks of code and knowledge from the existing LIRC into the > new design. Drop legacy APIs, get rid of daemons, etc. You can do this > redesign in parallel with existing LIRC. Everyone can continue using > the existing code while the new scheme is being built. Think of it as > LIRC 2.0. You can lead this design effort, you're the most experience > developer in the IR area. This is a very difficult thing for me to do. I must admit that I'm very biased. Because lircd is the only userspace application that uses the LIRC kernel interface, we never had any problems changing the interface when needed. I can't say there's much legacy stuff inside. I'm quite happy with the interface. The other thing is that I can't really move the decoder from userspace to kernel because there are way too many userspace drivers that do require a userspace decoder. LIRC also is running on FreeBSD, MacOS and even Cygwin. So letting the userspace drivers take advantage of a potential Linux in- kernel decoder is not an option for me either. I'm having my 'LIRC maintainer' hat on mostly during this discussion and I do understand that from Linux kernel perspective things look different. > Take advantage of this window to make a > design that is fully integrated with Linux - put IR on equal footing > with the keyboard and mouse as it should be. That's a question that I have not answered for myself concludingly. Is a remote control really on exactly the same level as a keyboard or mouse? Christoph -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Mauro, on 28 Nov 09 at 09:21, Mauro Carvalho Chehab wrote: > Hi Christoph, > > Christoph Bartelmus wrote: >>> Maybe we decide to take the existing LIRC system as is and not >>> integrate it into the input subsystem. But I think there is a window >>> here to update the LIRC design to use the latest kernel features. >> >> If it ain't broke, don't fix it. [...] > So, even not being broken, the subsystem internal media API's changed > a lot during the last years, and there are still several new changes > on our TODO list. > > So, I'd say that if we can do it better, then let's do it. I'm not against improving things. If there are feature request that cannot be handled with an interface, it has to be extended or redesigned. But currently the LIRC interface supports all features that came up until now since many years. I just don't want to change a working interface just because it could be also implemented in a different way, but having no other visible advantage than using more recent kernel features. [...] >> For devices that do the decoding in hardware, the only thing that I don't >> like about the current kernel implementation is the fact that there are >> mapping tables in the kernel source. I'm not aware of any tools that let >> you change them without writing some keymaps manually. [...] > Still, I prefer first to migrate all drivers to use the full scancode and > re-generate the keymaps before such step. Good to see that this is in the works. [...] >> With the approach that you >> suggested for the in-kernel decoder, this device simply will not work for >> anything but RC-5. The devil is in all the details. > I haven't seen such limitations on his proposal. We currently have in-kernel > decoders for NEC, pulse-distance, RC4 protocols, and some variants. If > non-RC5 decoders are missing, we need for sure to add them. That was not my point. If you point a NEC remote at the Igor USB device, you won't be able to use a NEC decoder because the device will swallow half of the bits. LIRC won't care unless the resulting scancodes are identical. Granted, this is an esoteric arguement, because this device is utter garbage. [...] >> If we decide to do the >> decoding in-kernel, how long do you think this solution will need to >> become really stable and mainline? Currently I don't even see any >> consensus on the interface yet. But maybe you will prove me wrong and it's >> just that easy to get it all working. > The timeframe to go to mainline will basically depend on taking a decision > about the API and on people having time to work on it. > > Providing that we agree on what we'll do, I don't see why not > adding it on staging for 2.6.33 and targeting to have > everything done for 2.6.34 or 2.6.35. The problem that I see here is just that even when we have very talented people working on this, that put together all resources, we won't be able to cover all the corner cases with all the different receivers and remote control protocols out there. It will still require lots of fine-tuning which was done in LIRC over the years. >> I also understand that people want to avoid dependency on external >> userspace tools. All I can tell you is that the lirc tools already do >> support everything you need for IR control. And as it includes a lot of >> drivers that are implemented in userspace already, LIRC will just continue >> to do it's work even when there is an alternative in-kernel. > The point is that for simple usage, like an user plugging his new USB stick > he just bought, he should be able to use the shipped IR without needing to > configure anything or manually calling any daemon. This currently works > with the existing drivers and it is a feature that needs to be kept. Admittedly, LIRC is way behind when it comes to plug'n'play. Christoph -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Krzysztof, on 28 Nov 09 at 18:21, Krzysztof Halasa wrote: [...] >> This remote uses RC-5. But some of the developers must have thought that >> it may be a smart idea to use 14 bits instead the standard 13 bits for >> this remote. In LIRC you won't care, because this is configurable and >> irrecord will figure it out automatically for you. In the proposed kernel >> decoders I have seen until now, you will have to treat this case specially >> in the decoder because you expect 13 bits for RC-5, not 14. > Well, the 14-bit RC5 is de-facto standard for some time now. One of the > start bits, inverted, now functions as the MSB of the command code. > 13-bit receiver implementations (at least these aimed at "foreign" > remotes) are obsolete. Ah, sorry. I didn't mean the extension of the command code by inverting one of the start bits. The Streamzap really uses one more bit. In the LIRC world the RC5 start bit which is fixed to "1" is not counted as individual bit. So translated to your notation, the Streamzap uses 15 bits, not 14 like the extended RC-5 or 13 like the original RC-5... Christoph -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi Stefan, on 28 Nov 09 at 21:29, Stefan Richter wrote: > Jon Smirl wrote: >> On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter >> wrote: >>> Jon Smirl wrote: Also, how do you create the devices for each remote? You would need to create these devices before being able to do EVIOCSKEYCODE to them. >>> The input subsystem creates devices on behalf of input drivers. (Kernel >>> drivers, that is. Userspace drivers are per se not affected.) >> >> We have one IR receiver device and multiple remotes. How does the >> input system know how many devices to create corresponding to how many >> remotes you have? > If several remotes are to be used on the same receiver, then they > necessarily need to generate different scancodes, don't they? Otherwise > the input driver wouldn't be able to route their events to the > respective subdevice. Consider this case: Two remotes use different protocols. The scancodes after decoding happen to overlap. Just using the scancodes you cannot distinguish between the remotes. You'll need to add the protocol information to be able to solve this which complicates the setup. In LIRC this is solved by having protocol parameters and scancode mapping in one place. Christoph -- 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] gspca main: reorganize loop
On Sun, 29 Nov 2009 12:19:46 +0100 Németh Márton wrote: > Is there any subdriver where the isoc_nego() is implemented? I > couldn't find one. What would be the task of the isoc_nego() > function? Should it set the interface by calling usb_set_interface() > as the get_ep() does? Should it create URBs for the endpoint? > > Although I found the patch where the isoc_nego() was introduced > ( http://linuxtv.org/hg/v4l-dvb/rev/5a5b23605bdb56aec86c9a89de8ca8b8ae9cb925 ) > it is not clear how the "ep" pointer is updated when not the > isoc_nego() is called instead of get_ep() in the current > implementation. Hello Hans, This function (isoc_nego) was added to fix the Mauro's problem with the st6422. Was this problem solved in some other way, or is the fix still waiting to be pulled? Best 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: [PATCH] gspca sunplus: propagate error for higher level
Jean-Francois Moine wrote: > On Sat, 28 Nov 2009 08:13:05 +0100 > Németh Márton wrote: > >> what do you think about this patch? > > Hi Márton, > > There are many other drivers where the usb_control_msg() errors are not > tested nor propagated to higher levels. Generally, this does not matter: > the errors are signalled at the lowest level, and they seldom occur. > Thus, I don't think your patch is useful... I think that the return value of the usb_control_msg() is to be evaluated. If other drivers also not evaluating the usb_control_msg() *they* has to be fixed. The benefit would be that the userspace program can recognise error condition faster and react accordingly. For example the USB device can be unplugged any time. In this case there is no use to continue sending URBs. Otherwise the user program thinks that everything went on correctly and the user will be surprised how come that he or she unplugged a device and it is still working. Regards, Márton Németh -- 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
Winfast PxDVR3200 with ubuntu 9.10
Hi All, I am trying to configure a Winfast PxDVR3200 H on Ubuntu 9.10 (Karmic). Although the card seems to be detected, there is no signal when I try to scan for channels either using scan or a variety of software interfaces (me tv, kaffeine, myth tv). All give a signal strength of 0. Any help at all would be appreciated, is there something simple I am missing. Details follow. I have installed v4l-dvb and obtained and extracted the designated firmware (http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware). I manually selected the card type (12) via insmod, resulting in the card being detected and /dev/dvb/ having a adapter0 present. dmesg: [ 14.984019] cx23885 driver version 0.0.2 loaded [ 14.984409] cx23885 :03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 14.984498] CORE cx23885[0]: subsystem: 107d:6f39, board: Leadtek Winfast PxDVR3200 H [card=12,insmod option] [ 15.231871] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [ 15.231875] Disabling lock debugging due to kernel taint [ 15.245281] [fglrx] Maximum main memory to use for locked dma buffers: 3799 MBytes. [ 15.245483] [fglrx] vendor: 1002 device: 9442 count: 1 [ 15.245855] [fglrx] ioport: bar 4, base 0xa000, size: 0x100 [ 15.245867] pci :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 15.245871] pci :01:00.0: setting latency timer to 64Hi All, I am trying to configure a Winfast PxDVR3200 H on Ubuntu 9.10 (Karmic). Although the card seems to be detected, there is no signal when I try to scan for channels either using scan or a variety of software interfaces (me tv, kaffeine, myth tv). All give a signal strength of 0. Any help at all would be appreciated, is there something simple I am missing. Details follow. I have installed v4l-dvb and obtained and extracted the designated firmware (http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028#How_to_Obtain_the_Firmware). I manually selected the card type (12) via insmod, resulting in the card being detected and /dev/dvb/ having a adapter0 present. dmesg: [ 14.984019] cx23885 driver version 0.0.2 loaded [ 14.984409] cx23885 :03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 14.984498] CORE cx23885[0]: subsystem: 107d:6f39, board: Leadtek Winfast PxDVR3200 H [card=12,insmod option] [ 15.231871] fglrx: module license 'Proprietary. (C) 2002 - ATI Technologies, Starnberg, GERMANY' taints kernel. [ 15.231875] Disabling lock debugging due to kernel taint [ 15.245281] [fglrx] Maximum main memory to use for locked dma buffers: 3799 MBytes. [ 15.245483] [fglrx] vendor: 1002 device: 9442 count: 1 [ 15.245855] [fglrx] ioport: bar 4, base 0xa000, size: 0x100 [ 15.245867] pci :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 15.245871] pci :01:00.0: setting latency timer to 64 [ 15.246071] [fglrx] Kernel PAT support is enabled [ 15.246090] [fglrx] module loaded - fglrx 8.66.10 [Sep 3 2009] with 1 minors [ 15.251862] cx25840 2-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) [ 15.256893] cx25840 2-0044: firmware: requesting v4l-cx23885-avcore-01.fw [ 15.319795] lp: driver loaded but no devices found [ 15.668482] alloc irq_desc for 22 on node 0 [ 15.668485] alloc kstat_irqs on node 0 [ 15.668490] HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 [ 15.668549] HDA Intel :00:1b.0: setting latency timer to 64 [ 16.171154] cx25840 2-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 16.177442] cx23885_dvb_register() allocating 1 frontend(s) [ 16.177445] cx23885[0]: cx23885 based dvb card [ 16.345371] hda_codec: Unknown model for ALC889A, trying auto-probe from BIOS... [ 16.345540] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input6 [ 16.349123] HDA Intel :01:00.1: PCI INT B -> GSI 17 (level, low) -> IRQ 17 [ 16.349163] HDA Intel :01:00.1: setting latency timer to 64 [ 16.464242] xc2028 1-0061: creating new instance [ 16.464245] xc2028 1-0061: type set to XCeive xc2028/xc3028 tuner [ 16.464249] DVB: registering new adapter (cx23885[0]) [ 16.464252] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)... [ 16.464462] cx23885_dev_checkrevision() Hardware revision = 0xa4 [ 16.464469] cx23885[0]/0: found at :03:00.0, rev: 3, irq: 17, latency: 0, mmio: 0xe800 [ 16.464476] cx23885 :03:00.0: setting latency timer to 64 lsmod: cx23885 135144 0 cx2341x15108 1 cx23885 v4l2_common20512 3 cx25840,cx23885,cx2341x videodev 43552 3 cx25840,cx23885,v4l2_common v4l1_compat16644 1 videodev v4l2_compat_ioctl3212416 1 videodev videobuf_dma_sg14372 1 cx23885 videobuf_dvb8452 1 cx23885 dvb_core 107700 2 cx23885,videobuf_dvb videobuf_core 20964 3 cx23885,videobuf_dma_sg,videobuf_dvb ir_com
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
> BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around Correct X11 just talked to the serial ports. In fact that is still the way to configure it if you want any sanity in life. > and serial connected IRs. It's also too convenient to access USB IR > hardware from existing userspace drivers to bother porting into the > kernel. Userspace needs a way to identify IR hardware and to interface with it using the right protocol. It's not clear the kernel needs to provide anything more than minimal hardware interfaces in most case - be that serial, libusb, ... -- 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: IR Receiver on an Tevii S470
On Thu, 2009-11-26 at 17:43 +0100, Matthias Fechner wrote: > Hi Andy, > > Andy Walls wrote: > > I will inspect and test these with my HVR-1850 (CX23888) loaner board > > this weekend (hopefully). > > > > if you want me to test something on the Tevii S470 card, please let me know. MAtthias, Not right now. I'll let you know. If you wish, you can monitor http://linuxtv.org/hg/~awalls/cx23885-ir Right now that repository has Jean's patches which I have minimally tested. They do fix the i2cdetect problems. There are not TeVii S470 patches there, so I'm not sure how easy it will be for you to test. In the v4l2_subdev_ir_parameters and cx23888-ir.c, I need to improve a minor point about carrier sense inversion (configuring if a carrier burst means mark or space) and IO pin level inversion. After that, I can port cx23888-ir.c to a cx25840-ir.c implementation. I also have to implement NEC decoding in cx23885-input.c. I found a remote in my house that implements the NEC protocol with Extended addresses (although its timing is about 100 microseconds short for every mark & space pair and the header pulse is almost 1 ms shorter than it should be :P ). I should be able to get NEC decoding worked out with that remote and the HVR-1850 I have in hand. Merging TeVii S470 fixes from Igor will then be a final step before I ask you to correct my guess at the v4l2_subdev_ir_parameters setup in cx23885-input.c for your card. Regards, Andy > Bye, > Matthias -- 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
bttv locking problem
Hello, I did a smatch static checker run and found a double unlock in bttv-driver.c. drivers/media/video/bt8xx/bttv-driver.c +3203 bttv_poll() error: double unlock '&fh->cap.vb_lock' I would fix it myself, but I don't know if the poll_wait() is supposed to be protected by mutex_unlock(&fh->cap.vb_lock) or not. drivers/media/video/bt8xx/bttv-driver.c 3192 mutex_unlock(&fh->cap.vb_lock); 3193 buf = (struct bttv_buffer*)fh->cap.read_buf; 3194 } 3195 3196 poll_wait(file, &buf->vb.done, wait); 3197 if (buf->vb.state == VIDEOBUF_DONE || 3198 buf->vb.state == VIDEOBUF_ERROR) 3199 rc = POLLIN|POLLRDNORM; 3200 else 3201 rc = 0; 3202 err: 3203 mutex_unlock(&fh->cap.vb_lock); regards, dan carpenter -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl wrote: > On Sat, Nov 28, 2009 at 2:45 PM, Stefan Richter > wrote: >> Jon Smirl wrote: >>> Also, how do you create the devices for each remote? You would need to >>> create these devices before being able to do EVIOCSKEYCODE to them. >> The input subsystem creates devices on behalf of input drivers. (Kernel >> drivers, that is. Userspace drivers are per se not affected.) > > We have one IR receiver device and multiple remotes. How does the > input system know how many devices to create corresponding to how many > remotes you have? There is no current mechanism to do that. You need > an input device for each remote so that you can do the EVIOCSKEYCODE > against it. Some type of "create subdevice" IOCTL will need to be > built. > > I handled that in configds like this: > /configfs - mount the basic configfs > /configfs/remotes (created by loading IR support) > mkdir /configfs/remotes/remote_A - this causes the input subdevice to > be created, the name of it appears in the created directory. > mkdir /configfs/remotes/remote_A/... - now build the mapping entires. > > This "create subdevice" IOCTL will need to take a name so that it can > be identified. You will probably another IOCTL to enumerate which > subdevices belong to the root device, etc... > > Keyboards don't have subdevices. There is a 1:1 mapping between the > keyboard and the device driver. The above struct doesn't fit for the already existing in-kernel drivers, since you may have more than one IR driver on kernel. I have some machines here with 3 or 4 different input cards, each with their own IR hardware. How are you supposing to associate a created Remote Controller with the corresponding driver? With EVIOSKEYCODE, it is as simple as directing the ioctl to the corresponding evdev interface. 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl wrote: > I'm looking at a Sony multi-function remote right now. It has five > devices and forty keys. Each of the five devices can transmit 0-9, > power, volume, etc. It transmits 5*40 = 200 unique scancodes. > > I want the five devices to correspond to five apps. What's the plan > for splitting those 200 scancodes into the five apps? > > I did it by creating five evdev devices each mapping 40 scancodes. > That's lets me reuse KP_1 for each of the five apps. > > In this case, the evdev interface won't solve the issue alone. Some sort of userspace tool will need to identify what application is expecting that code and redirect it to that application. IMO, the biggest LIRC benefit over a pure evdev interface, from user's perspective, is that it can redirect a keycode to a specific application. Yet, I don't see why your configfs proposal will solve this issue, as userspace will keep receiving duplicated KET_ -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
Jon Smirl wrote: > On Sat, Nov 28, 2009 at 4:46 PM, Stefan Richter > wrote: >> Jon Smirl wrote: >>> On Sat, Nov 28, 2009 at 3:29 PM, Stefan Richter >>> wrote: Jon Smirl wrote: > We have one IR receiver device and multiple remotes. How does the > input system know how many devices to create corresponding to how many > remotes you have? If several remotes are to be used on the same receiver, then they necessarily need to generate different scancodes, don't they? Otherwise >> ^ >> I referred to scancodes, not keycodes. >> the input driver wouldn't be able to route their events to the respective subdevice. But if they do generate different scancodes, there is no need to create subdevices just for EVIOCSKEYCODE's sake. (It might still be desirable to have subdevices for other reasons perhaps.) >>> Multiple remotes will have duplicate buttons (1, 2 ,3, power, mute, >>> etc) these should get mapped into the standard keycodes. You need to >>> devices to key things straight. >>> >>> Push button 1 on Remote A. That should generate a KP_1 on the evdev >>> interface for that remote. >>> Push button 1 on Remote B. That should generate a KP_1 on the evdev >>> interface for that remote. >>> >>> Scenario for this - a mutifunction remote that is controlling two >>> different devices/apps. In one mode the 1 might be a channel number, >>> in the other mode it might be a telephone number. >>> >>> The user may chose to make button 1 on both remote A/B map to KP_1 on >>> a single interface. >>> >>> Scenario for this - I want to use two different remotes to control a >>> single device. >>> >>> - >>> >>> I handled that in configds like this: >>> /configfs - mount the basic configfs >>> /configfs/remotes (created by loading IR support) >>> mkdir /configfs/remotes/remote_A - this causes the input subdevice to >>> be created, the name of it appears in the created directory. >> [...] >> >> I'm lost. If there are two remotes sending to a single receiver, and >> their sets of scancodes do not overlap, then all is fine. You can map >> either set of scancodes to keycodes independently. But if their ranges > > You can do this, but now the events from both remotes are occurring on > a single evdev device. If I assign Remote_A_1 to KP_1 what am I going > to assign to Remote_B_1? > >> of scancodes do overlap, then even the creation of subdevices does not >> help --- the driver has no way to tell which of the remotes sent the >> signal in order to select the corresponding input subdevice, does it? > > The scancodes are always unique even among different remotes. > > I have three apps: mythtv, voip and home automation. How can I use a > remote(s) to control these three apps? The concept of keyboard focus > doesn't map very well to remote controls. > > My idea was to create an evdev device for each app: > mythtv - Remote_A_1 mapped KP_1, etc > voip - Remote_B_1 mapped KP_1, etc > home automation - etc > > Note that there probably aren't really three remotes (A,B,C), it a > multi-function remote. Picking a different context on a multi-function > remote doesn't generate an event. In this case, the evdev interface won't solve the issue alone. Some sort of userspace tool will need to identify what application is expecting that code and should redirect it to that application. So, you'll basically need a table like: scancode -> application PID | keycode And, IMO, such mapping schema is better handled at userspace. Yet, I don't see how your configfs proposal will solve this issue, as userspace will keep receiving duplicated events (in different evdev interfaces, but still the same keycode will be sent to userspace). You might be considering that each application will open a different set of evdev interfaces, and getting exclusive locks, but this will require a setup per-application, or to have some proxy program that will open all different evdev interfaces and do the keycode redirects. On a scenario that different scancodes will produce the same KEY events, but each duplicated scancode will be sent to a different application, the better would be to have an evdev interface that will output directly the scancode and let an userspace program to "focus" the keystroke to the corresponding application. IMHO, the biggest LIRC benefit over a pure evdev interface, from user's perspective, is that it can redirect a keycode to a specific application. 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] gspca main: reorganize loop
Hi, On 11/29/2009 01:15 PM, Jean-Francois Moine wrote: On Sun, 29 Nov 2009 12:19:46 +0100 Németh Márton wrote: Is there any subdriver where the isoc_nego() is implemented? I couldn't find one. What would be the task of the isoc_nego() function? Should it set the interface by calling usb_set_interface() as the get_ep() does? Should it create URBs for the endpoint? Although I found the patch where the isoc_nego() was introduced ( http://linuxtv.org/hg/v4l-dvb/rev/5a5b23605bdb56aec86c9a89de8ca8b8ae9cb925 ) it is not clear how the "ep" pointer is updated when not the isoc_nego() is called instead of get_ep() in the current implementation. Hello Hans, This function (isoc_nego) was added to fix the Mauro's problem with the st6422. Was this problem solved in some other way, or is the fix still waiting to be pulled? The fix is still waiting to be pulled, or actually to be made working :| First a quick summary of the need for the isoc_nego() function (and to only call get_ep() once). Some cams, at least those based on stv06xx bridges, have only 1 alt setting, but they have a register which allows one to tell it to send isoc frames which are never bigger then the value set in the register. I've tested this and it works as advertised, when you create isoc urbs with a size < wMaxPacketSize, then normally you will get -EMSGSIZE errors (iirc) as the camera sends isoc frames, larger then the buffers in the isoc urbs created, but if you then write the size you created the isoc urbs with to the register in question, things will work. So this works as expected. The problem is that the usb "scheduler" which checks the bandwidth constrains will always use wMaxPacketSize to check if there is enough bandwidth instead of the actual packet size of the isoc packets. So although I have a patch implementing the isoc_neg call for stv06xx cams, it does not actually help as although it is scaling back the bandwidth needed, the usb core does not see this and keeps returning -ENOSPC. After finding out about this I ran out of time. This reminds me that I need to send a message about this to the usb mailing list. I will do so now, and then we will see what will come from 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
[patch] ov511.c typo: lock => unlock
This was found with a static checker and has not been tested, but it seems pretty clear that the mutex_lock() was supposed to be mutex_unlock() This is a 2.6.32 candidate. Signed-off-by: Dan Carpenter --- orig/drivers/media/video/ov511.c2009-11-29 14:44:46.0 +0200 +++ devel/drivers/media/video/ov511.c 2009-11-29 14:44:57.0 +0200 @@ -5878,7 +5878,7 @@ ov51x_probe(struct usb_interface *intf, goto error; } - mutex_lock(&ov->lock); + mutex_unlock(&ov->lock); return 0; -- 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] gspca sunplus: propagate error for higher level
On Sun, 29 Nov 2009 13:15:37 +0100 Németh Márton wrote: > I think that the return value of the usb_control_msg() is to be > evaluated. If other drivers also not evaluating the usb_control_msg() > *they* has to be fixed. > > The benefit would be that the userspace program can recognise error > condition faster and react accordingly. For example the USB device > can be unplugged any time. In this case there is no use to continue > sending URBs. Otherwise the user program thinks that everything went > on correctly and the user will be surprised how come that he or she > unplugged a device and it is still working. I see 2 cases for getting errors in usb control messages: - there are permanent problems in the USB subsystem - device disconnection The first case is detected immediately at probe time and the device will not run (/dev/video not created) On device disconnection, if streaming is active, it is be stopped and the device is marked for deletion. The only way to get errors in usb control message is to change some control value at the same time the device disconnects (i.e. disconnection while the ioctl runs in the subdriver). The probability for this to occur is surely less than 10**-9. Otherwise, once the disconnection is seen, no IO may be performed. If you want absolutely to propagate the errors at higher level, the simplest way is to have an 'error' variable in the gspca descriptor. You set it to 0 in gspca.c before calling the subdriver (i.e. just after getting the usb_lock), you check it before calling usb_control_msg (in the low level routines reg_r, reg_w..) , you set it if this last function returns an error, and you get its value before releasing the usb_lock. In this way, there are less changes and less code overhead. 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: [IR-RFC PATCH v4 2/6] Core IR module
On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote: > Changes to core input subsystem to allow send and receive of IR messages. > Encode and decode state machines are provided for common IR porotocols such > as Sony, JVC, NEC, Philips, etc. > > Received IR messages generate event in the input queue. > IR messages are sent using an input IOCTL. As you are creating new sysfs files here, please document them in Documentation/ABI/ thanks, greg k-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
Re: [IR-RFC PATCH v4 2/6] Core IR module
> +static ssize_t ir_raw_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct input_dev *input_dev = to_input_dev(dev);
> + unsigned int i, count = 0;
> +
> + for (i = input_dev->ir->raw.tail; i != input_dev->ir->raw.head; ) {
> +
> + count += snprintf(&buf[count], PAGE_SIZE - 1, "%i\n",
> input_dev->ir->raw.buffer[i++]);
> + if (i > ARRAY_SIZE(input_dev->ir->raw.buffer))
> + i = 0;
> + if (count >= PAGE_SIZE - 1) {
> + input_dev->ir->raw.tail = i;
> + return PAGE_SIZE - 1;
> + }
> + }
> + input_dev->ir->raw.tail = i;
> + return count;
> +}
This looks like it violates the "one value per sysfs file" rule that we
have. What exactly are you outputting here? It does not look like this
belongs in sysfs at all.
> +static ssize_t ir_raw_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + struct ir_device *ir = to_input_dev(dev)->ir;
> + long delta;
> + int i = count;
> + int first = 0;
> +
> + if (!ir->xmit)
> + return count;
> + ir->send.count = 0;
> +
> + while (i > 0) {
> + i -= strict_strtoul(&buf[i], i, &delta);
> + while ((buf[i] != '\n') && (i > 0))
> + i--;
> + i--;
> + /* skip leading zeros */
> + if ((delta > 0) && !first)
> + continue;
> +
> + ir->send.buffer[ir->send.count++] = abs(delta);
> + }
> +
> + ir->xmit(ir->private, ir->send.buffer, ir->send.count, ir->raw.carrier,
> ir->raw.xmitter);
> +
> + return count;
> +}
What type of data are you expecting here? More than one value?
thanks,
greg k-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
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, 2009-11-29 at 12:40 +, Alan Cox wrote: > > BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around > > Correct X11 just talked to the serial ports. In fact that is still the > way to configure it if you want any sanity in life. > > > and serial connected IRs. It's also too convenient to access USB IR > > hardware from existing userspace drivers to bother porting into the > > kernel. > > Userspace needs a way to identify IR hardware and to interface with it > using the right protocol. It's not clear the kernel needs to provide > anything more than minimal hardware interfaces in most case - be that > serial, libusb, ... Exactly. As it currently stands, kernel provides lircd the pulse/space timing, lirc parses that, and sends input events via uinput. lircd behaves just like an userspace driver, and the biggest advantage is that it can access its configuration directly, unlike kernel solution that will have to use some configfs hack. It can use its own older interface, but that is now optional. Also its not that hard to make lirc scan is database and adapt to the remote that is used. This should give the user absolutely zero configuration. Instead, there is strong push to put lircd, the userspace daemon's functionality into kernel. This has zero advantages besides good developer feeling that "My system has one less daemon..." Best regards, Maxim Levitsky -- 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: [IR-RFC PATCH v4 2/6] Core IR module
On Sun, Nov 29, 2009 at 12:14 PM, Greg KH wrote: > On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote: >> Changes to core input subsystem to allow send and receive of IR messages. >> Encode and decode state machines are provided for common IR porotocols such >> as Sony, JVC, NEC, Philips, etc. >> >> Received IR messages generate event in the input queue. >> IR messages are sent using an input IOCTL. > > As you are creating new sysfs files here, please document them in > Documentation/ABI/ This code is not going to get merged as is. It's just a starting point to get a discussion started about designing an IR subsystem. I expect the final design will look a lot different. I'm trying to demonstrate that IR is an input device and that it can be supported by the Linux input subsystem without the need to create a special IR device. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IR-RFC PATCH v4 2/6] Core IR module
On Sun, Nov 29, 2009 at 12:17 PM, Greg KH wrote:
>> +static ssize_t ir_raw_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct input_dev *input_dev = to_input_dev(dev);
>> + unsigned int i, count = 0;
>> +
>> + for (i = input_dev->ir->raw.tail; i != input_dev->ir->raw.head; ) {
>> +
>> + count += snprintf(&buf[count], PAGE_SIZE - 1, "%i\n",
>> input_dev->ir->raw.buffer[i++]);
>> + if (i > ARRAY_SIZE(input_dev->ir->raw.buffer))
>> + i = 0;
>> + if (count >= PAGE_SIZE - 1) {
>> + input_dev->ir->raw.tail = i;
>> + return PAGE_SIZE - 1;
>> + }
>> + }
>> + input_dev->ir->raw.tail = i;
>> + return count;
>> +}
>
> This looks like it violates the "one value per sysfs file" rule that we
> have. What exactly are you outputting here? It does not look like this
> belongs in sysfs at all.
It should be on a debug switch or maybe a debug device. If the rest of
the system is working right you shouldn't need this data.
>
>> +static ssize_t ir_raw_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf,
>> + size_t count)
>> +{
>> + struct ir_device *ir = to_input_dev(dev)->ir;
>> + long delta;
>> + int i = count;
>> + int first = 0;
>> +
>> + if (!ir->xmit)
>> + return count;
>> + ir->send.count = 0;
>> +
>> + while (i > 0) {
>> + i -= strict_strtoul(&buf[i], i, &delta);
>> + while ((buf[i] != '\n') && (i > 0))
>> + i--;
>> + i--;
>> + /* skip leading zeros */
>> + if ((delta > 0) && !first)
>> + continue;
>> +
>> + ir->send.buffer[ir->send.count++] = abs(delta);
>> + }
>> +
>> + ir->xmit(ir->private, ir->send.buffer, ir->send.count,
>> ir->raw.carrier, ir->raw.xmitter);
>> +
>> + return count;
>> +}
>
> What type of data are you expecting here? More than one value?
>
> thanks,
>
> greg k-h
>
--
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky wrote: > This has zero advantages besides good developer feeling that "My system > has one less daemon..." Surely it's clear that having an unnecessary daemon is introducing another point of failure? Reducing complexity is not just its own reward in a 'Developer Feel Good' way. If decoding can *only* be sanely handled in user-space, that's one thing. If it can be handled in kernel, then that would be better. -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
> If decoding can *only* be sanely handled in user-space, that's one > thing. If it can be handled in kernel, then that would be better. Why ? I can compute fast fourier transforms in the kernel but that doesn't make it better than doing it in user space. I can write web servers in the kernel and the same applies. Alan -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Nov 29, 2009 at 7:40 AM, Alan Cox wrote: >> BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around > > Correct X11 just talked to the serial ports. In fact that is still the > way to configure it if you want any sanity in life. > >> and serial connected IRs. It's also too convenient to access USB IR >> hardware from existing userspace drivers to bother porting into the >> kernel. > > Userspace needs a way to identify IR hardware and to interface with it > using the right protocol. It's not clear the kernel needs to provide > anything more than minimal hardware interfaces in most case - be that > serial, libusb, ... That's a description of the current system and it is driver chaos. Half of the drivers are in user space and there are two different classes of kernel driver - LIRC and V4L. A lot of the hardware doesn't identify itself. There are two types of IR data in use - pulse timing and decoded protocol. IR is an input device. We have a nice evdev input subsystem and it has been demonstrated that IR can work with it. Everybody keeps complaining that they want IR to "just work". Consolidating all of this (under 50K of code) driver support in the kernel is the way to make it "just work". For example. Some IR devices only record pulse timing data. There are various protocols - RC5, RC6, etc for turning these pulse timing into a decode IR command. This is about 20K of code. Does it really make sense to create a device, push this data out into user space, decode it there, then inject the results back into the kernel (uinput) for further processing by the input subsystem? This decoding is getting done in user space because half of the IR drivers are in user space. But the other half of them aren't in user space and that set can't work in user space. Most of the user space drivers can be pushed into the kernel where they'll automatically load when the device is detected. Some of the drivers can't be moved like the IR over ALSA. But is attaching an IR diode to the mic input of your sound card really a device or is it a hack that should be dealt with in user space? Another type is IR hardware that toggles the DTR output of a serial port at 40Khz to make a signal. Same thing is done with parallel ports. Those force the system into a bit-banging timing loop for 1/10th second. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Nov 29, 2009 at 10:13 AM, Alan Cox wrote: >> If decoding can *only* be sanely handled in user-space, that's one >> thing. If it can be handled in kernel, then that would be better. > > Why ? > > I can compute fast fourier transforms in the kernel but that doesn't make > it better than doing it in user space. Of course not. > I can write web servers in the kernel and the same applies. I'm not so young as to not recall Tux. That was again a bad idea, for the same reason. It introduced unnecessary complexity. Enabling userspace to be able to service web requests faster improved all user-space code. Yay. The question is which solution is more complex, the current one that requires userspace to be an active participant in the decoding, so that we can handle bare diodes hooked up to a sound-card, or having the kernel do decode for the sane devices and providing some fall-back for broken hardware. The former has the advantage of being flexible at the cost of increased fragility and surface area for security, and latency in responding to events, the latter has the problem of requiring two different decoding paths to be maintained, at least if you want to support odd-ball hardware. Jon is asking for an architecture discussion, y'know, with use cases. Maxim seems to be saying it's obvious that what we have today works fine. Except it doesn't appear that we have a consensus that everything is fine, nor an obvious winner for how to reduce the complexity here and keep the kernel in a happy, maintainable state for the long haul. Who knows, perhaps I misunderstood the dozens of messages up-thread -- wouldn't be the first time, in which case I'll shut up and let you get back to work. -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
> Half of the drivers are in user space and there are two different > classes of kernel driver - LIRC and V4L. > A lot of the hardware doesn't identify itself. > There are two types of IR data in use - pulse timing and decoded protocol. > > IR is an input device. We have a nice evdev input subsystem and it has > been demonstrated that IR can work with it. Evdev allows userspace to feed events into the kernel. > Everybody keeps complaining that they want IR to "just work". > Consolidating all of this (under 50K of code) driver support in the > kernel is the way to make it "just work". We have things called "Libraries" that unlike kernel code run out of a secure context, can be paged and shared by applications dynamically. Also the data rate of IR controllers puts it into the realm where the kernel doesn't need to be involved, in fact you could turn them into evdev events via user space quite acceptably, or even into meaningful actions and onto dbus. > For example. Some IR devices only record pulse timing data. There are > various protocols - RC5, RC6, etc for turning these pulse timing into > a decode IR command. This is about 20K of code. Does it really make > sense to create a device, push this data out into user space, decode > it there, then inject the results back into the kernel (uinput) for > further processing by the input subsystem? Does it really make sense to put big chunks of protocol decoding crap for an interface which runs at about 1 character per second on a good day into the kernel ? Does it really make sense ot move 50K of code from user context to kernel context where it must meet strict security requirements, be extensively audited and cannot be paged. For embedded users will also have to be highly modular so no unused bits are loaded. > This decoding is getting done in user space because half of the IR > drivers are in user space. But the other half of them aren't in user > space and that set can't work in user space. Most of the user space > drivers can be pushed into the kernel where they'll automatically load > when the device is detected. So you proposed to write another ton of new drivers in kernel space for these only devices supported by user space, portably and to test and submit them all. If you can't persuade the maintainera of all those drivers to do so you don't appear to have a credible proposal. > attaching an IR diode to the mic input of your sound card really a > device or is it a hack that should be dealt with in user space? It's a device. There is no divide between "hack" and "device", as anyone who ever worked on the Mac68K can assure you ;) > Another type is IR hardware that toggles the DTR output of a serial > port at 40Khz to make a signal. Same thing is done with parallel > ports. Those force the system into a bit-banging timing loop for > 1/10th second. We have people who run wireless like that, people who ran SCSI and IDE like that. In the embedded world its the norm. If you sell 100,000 devices then saving that part, wiring and board space is often the right choice. That kind of stuff needs doing in user space not kernel. You stated the real problem at the start - devices don't identify themselves well. That doesn't seem to be a kernel problem other than for kernel drivers perhaps exposing more information on themselves via sysfs. -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
> Jon is asking for an architecture discussion, y'know, with use cases. > Maxim seems to be saying it's obvious that what we have today works > fine. Except it doesn't appear that we have a consensus that > everything is fine, nor an obvious winner for how to reduce the > complexity here and keep the kernel in a happy, maintainable state for > the long haul. The important point is that this is not an A or B discussion. There are lots of ways to tackle it that are neither. If you look at things like complex video format handling it is done in user space but with an infrastructure to handle it. I don't believe putting it in the kernel is the alternative to the current setup. Cleaning up the way what we have today is presented to applications is perfectly possible without a whole new pile of kernel crap, because evdev was designed sensibly in the first place to allow userspace added events. -- 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: [IR-RFC PATCH v4 2/6] Core IR module
On Sun, Nov 29, 2009 at 12:37:36PM -0500, Jon Smirl wrote: > On Sun, Nov 29, 2009 at 12:14 PM, Greg KH wrote: > > On Thu, Nov 26, 2009 at 08:34:23PM -0500, Jon Smirl wrote: > >> Changes to core input subsystem to allow send and receive of IR messages. > >> Encode and decode state machines are provided for common IR porotocols > >> such as Sony, JVC, NEC, Philips, etc. > >> > >> Received IR messages generate event in the input queue. > >> IR messages are sent using an input IOCTL. > > > > As you are creating new sysfs files here, please document them in > > Documentation/ABI/ > > This code is not going to get merged as is. It's just a starting point > to get a discussion started about designing an IR subsystem. I expect > the final design will look a lot different. Then show the design by adding the documentation for new sysfs files, to make it easier to understand by everyone please. thanks, greg k-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
Re: [IR-RFC PATCH v4 2/6] Core IR module
On Sun, Nov 29, 2009 at 12:41:22PM -0500, Jon Smirl wrote:
> On Sun, Nov 29, 2009 at 12:17 PM, Greg KH wrote:
> >> +static ssize_t ir_raw_show(struct device *dev,
> >> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct device_attribute *attr, char *buf)
> >> +{
> >> + ? ? struct input_dev *input_dev = to_input_dev(dev);
> >> + ? ? unsigned int i, count = 0;
> >> +
> >> + ? ? for (i = input_dev->ir->raw.tail; i != input_dev->ir->raw.head; ) {
> >> +
> >> + ? ? ? ? ? ? count += snprintf(&buf[count], PAGE_SIZE - 1, "%i\n",
> >> input_dev->ir->raw.buffer[i++]);
> >> + ? ? ? ? ? ? if (i > ARRAY_SIZE(input_dev->ir->raw.buffer))
> >> + ? ? ? ? ? ? ? ? ? ? i = 0;
> >> + ? ? ? ? ? ? if (count >= PAGE_SIZE - 1) {
> >> + ? ? ? ? ? ? ? ? ? ? input_dev->ir->raw.tail = i;
> >> + ? ? ? ? ? ? ? ? ? ? return PAGE_SIZE - 1;
> >> + ? ? ? ? ? ? }
> >> + ? ? }
> >> + ? ? input_dev->ir->raw.tail = i;
> >> + ? ? return count;
> >> +}
> >
> > This looks like it violates the "one value per sysfs file" rule that we
> > have. ?What exactly are you outputting here? ?It does not look like this
> > belongs in sysfs at all.
>
> It should be on a debug switch or maybe a debug device. If the rest of
> the system is working right you shouldn't need this data.
Then why export it at all?
If it's debug stuff, please use debugfs, that is what it is there for.
thanks,
greg k-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
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox wrote: >> Jon is asking for an architecture discussion, y'know, with use cases. >> Maxim seems to be saying it's obvious that what we have today works >> fine. Except it doesn't appear that we have a consensus that >> everything is fine, nor an obvious winner for how to reduce the >> complexity here and keep the kernel in a happy, maintainable state for >> the long haul. > > The important point is that this is not an A or B discussion. There are > lots of ways to tackle it that are neither. If you look at things like > complex video format handling it is done in user space but with an > infrastructure to handle it. > > I don't believe putting it in the kernel is the alternative to the > current setup. Cleaning up the way what we have today is presented to > applications is perfectly possible without a whole new pile of kernel > crap, because evdev was designed sensibly in the first place to allow > userspace added events. So we're just back to the status quo of last year which is to do nothing except some minor clean up. We'll be back here again next year repeating this until IR gets redesigned into something fairly invisible like keyboard and mouse drivers. -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
> So we're just back to the status quo of last year which is to do > nothing except some minor clean up. Which in itself is vastly preferable to some grandiose scheme that turns out to be wrong. And no it's not a back to the status quo, it's a request to discuss the actual problems and options not to simply try and force your chosen solution down the throats of everyone else. -- 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: WARNINGS, 2.6.16-2.6.21: WARNINGS
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:Sun Nov 29 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13538:e0cd9a337600 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-rc8-armv5: OK linux-2.6.32-rc8-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-rc8-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-rc8-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-rc8-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc8-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-rc8-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-rc8-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-rc8-x86_64: OK spec: OK sparse (linux-2.6.31): ERRORS sparse (linux-2.6.32-rc8): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Hi, on 29 Nov 09 at 14:16, Jon Smirl wrote: > On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox wrote: >>> Jon is asking for an architecture discussion, y'know, with use cases. [...] > So we're just back to the status quo of last year which is to do > nothing except some minor clean up. > > We'll be back here again next year repeating this until IR gets > redesigned into something fairly invisible like keyboard and mouse > drivers. Last year everyone complained that LIRC does not support evdev - so I added support for evdev. This year everyone complains that LIRC is not plug'n'play - we'll fix that 'til next year. There's progress. ;-) Christoph -- 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] cpia2: use __stringify macro.
Signed-off-by: Thiago Farina
---
drivers/media/video/cpia2/cpia2_v4l.c | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/media/video/cpia2/cpia2_v4l.c
b/drivers/media/video/cpia2/cpia2_v4l.c
index 0b4a8f3..6c5fcd8 100644
--- a/drivers/media/video/cpia2/cpia2_v4l.c
+++ b/drivers/media/video/cpia2/cpia2_v4l.c
@@ -38,17 +38,12 @@
#include
#include
#include
+#include
#include
#include "cpia2.h"
#include "cpia2dev.h"
-
-//#define _CPIA2_DEBUG_
-
-#define MAKE_STRING_1(x) #x
-#define MAKE_STRING(x) MAKE_STRING_1(x)
-
static int video_nr = -1;
module_param(video_nr, int, 0);
MODULE_PARM_DESC(video_nr,"video device to register (0=/dev/video0, etc)");
@@ -60,26 +55,26 @@ MODULE_PARM_DESC(buffer_size, "Size for each frame buffer
in bytes (default 68k)
static int num_buffers = 3;
module_param(num_buffers, int, 0);
MODULE_PARM_DESC(num_buffers, "Number of frame buffers (1-"
-MAKE_STRING(VIDEO_MAX_FRAME) ", default 3)");
+__stringify(VIDEO_MAX_FRAME) ", default 3)");
static int alternate = DEFAULT_ALT;
module_param(alternate, int, 0);
-MODULE_PARM_DESC(alternate, "USB Alternate (" MAKE_STRING(USBIF_ISO_1) "-"
-MAKE_STRING(USBIF_ISO_6) ", default "
-MAKE_STRING(DEFAULT_ALT) ")");
+MODULE_PARM_DESC(alternate, "USB Alternate (" __stringify(USBIF_ISO_1) "-"
+__stringify(USBIF_ISO_6) ", default "
+__stringify(DEFAULT_ALT) ")");
static int flicker_freq = 60;
module_param(flicker_freq, int, 0);
-MODULE_PARM_DESC(flicker_freq, "Flicker frequency (" MAKE_STRING(50) "or"
-MAKE_STRING(60) ", default "
-MAKE_STRING(60) ")");
+MODULE_PARM_DESC(flicker_freq, "Flicker frequency (" __stringify(50) "or"
+__stringify(60) ", default "
+__stringify(60) ")");
static int flicker_mode = NEVER_FLICKER;
module_param(flicker_mode, int, 0);
MODULE_PARM_DESC(flicker_mode,
-"Flicker supression (" MAKE_STRING(NEVER_FLICKER) "or"
-MAKE_STRING(ANTI_FLICKER_ON) ", default "
-MAKE_STRING(NEVER_FLICKER) ")");
+"Flicker supression (" __stringify(NEVER_FLICKER) "or"
+__stringify(ANTI_FLICKER_ON) ", default "
+__stringify(NEVER_FLICKER) ")");
MODULE_AUTHOR("Steve Miller (STMicroelectronics) ");
MODULE_DESCRIPTION("V4L-driver for STMicroelectronics CPiA2 based cameras");
--
1.6.6.rc0.61.g41d5b
--
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
HVR-1300: kernel NULL pointer dereference in ir_common
Hi, since I've been having problems with not seeing my IR remote in recent kernelsx any more (starting at least with 2.6.30) I tried the current version of the v4l-dvb tree (revision 13538) and 2.6.32-rc7 on my amd64 with a Hauppauge HVR1300. With that version I get a kernel bug upon module load. Here's the relevant section of dmesg: [3.701212] ohci_hcd :00:04.0: suspend root hub [4.015041] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded [4.015577] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 18 [4.015583] alloc irq_desc for 18 on node 0 [4.015586] alloc kstat_irqs on node 0 [4.015597] cx8800 :01:07.0: PCI INT A -> Link[LNKB] -> GSI 18 (level, low) -> IRQ 18 [4.016130] cx88[0]: subsystem: 0070:9601, board: Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [card=56,autodetected], frontend(s): 1 [4.016133] cx88[0]: TV tuner type 63, Radio tuner type -1 [4.016569] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded [4.019290] cx2388x alsa driver version 0.0.7 loaded [4.130200] cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner [4.182512] tuner 0-0043: chip found @ 0x86 (cx88[0]) [4.186181] tda9887 0-0043: creating new instance [4.186185] tda9887 0-0043: tda988[5/6/7] found [4.189759] tuner 0-0061: chip found @ 0xc2 (cx88[0]) [4.228066] tveeprom 0-0050: Hauppauge model 96019, rev D6D3, serial# 3106328 [4.228070] tveeprom 0-0050: MAC address is 00-0D-FE-2F-66-18 [4.228073] tveeprom 0-0050: tuner model is Philips FMD1216MEX (idx 133, type 78) [4.228078] tveeprom 0-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [4.228082] tveeprom 0-0050: audio processor is CX882 (idx 33) [4.228084] tveeprom 0-0050: decoder processor is CX882 (idx 25) [4.228087] tveeprom 0-0050: has radio, has IR receiver, has IR transmitter [4.228090] cx88[0]: hauppauge eeprom: model=96019 [4.233553] tuner-simple 0-0061: creating new instance [4.233559] tuner-simple 0-0061: type set to 78 (Philips FMD1216MEX MK3 Hybrid Tuner) [4.237571] BUG: unable to handle kernel NULL pointer dereference at (null) [4.237646] IP: [] ir_input_free+0x2f/0x49 [ir_common] [4.237707] PGD 76319067 PUD 762f5067 PMD 0 [4.237796] Oops: [#1] SMP [4.237863] last sysfs file: /sys/module/tuner/initstate [4.237892] CPU 0 [4.237936] Modules linked in: tuner_simple tuner_types tda9887 tda8290 tuner cx88_alsa(+) cx8802(+) cx8800(+) cx88xx v4l2_common videodev ir_common tveeprom v4l1_compat v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc [4.238004] Pid: 2445, comm: work_for_cpu Not tainted 2.6.32-rc7 #5 System Product Name [4.238004] RIP: 0010:[] [] ir_input_free+0x2f/0x49 [ir_common] [4.238004] RSP: 0018:880075ffbce0 EFLAGS: 00010246 [4.238004] RAX: RBX: RCX: [4.238004] RDX: 880074f64000 RSI: 8171a170 RDI: 880074c0b828 [4.238004] RBP: 880075ffbcf0 R08: a00b68e9 R09: 880074f64018 [4.238004] R10: 88007616dde8 R11: 880074f64000 R12: ffed [4.238004] R13: 0200 R14: 880074c0b000 R15: 880075ffbdd0 [4.238004] FS: 7f9e7b5a2760() GS:880001a0() knlGS: [4.238004] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [4.238004] CR2: CR3: 763cf000 CR4: 06f0 [4.238004] DR0: DR1: DR2: [4.238004] DR3: DR6: 0ff0 DR7: 0400 [4.238004] Process work_for_cpu (pid: 2445, threadinfo 880075ffa000, task 880077bbf260) [4.238004] Stack: [4.238004] 880074f64000 880076b26000 880075ffbd40 a006401e [4.238004] <0> 880077158800 880074f64000 880075ffbd20 880074f64428 [4.238004] <0> 880074f64000 880074f64428 880074f64018 880075ffbdd0 [4.238004] Call Trace: [4.238004] [] cx88_ir_init+0x4a0/0x532 [cx88xx] [4.238004] [] cx88_core_create+0x106c/0x1085 [cx88xx] [4.238004] [] ? cx88_tuner_callback+0x0/0x507 [cx88xx] [4.238004] [] cx88_core_get+0x89/0xc7 [cx88xx] [4.238004] [] cx8800_initdev+0x5e/0x5ad [cx8800] [4.238004] [] ? __wake_up_common+0x46/0x75 [4.238004] [] ? do_work_for_cpu+0x0/0x25 [4.238004] [] local_pci_probe+0x12/0x16 [4.238004] [] do_work_for_cpu+0x13/0x25 [4.238004] [] ? do_work_for_cpu+0x0/0x25 [4.238004] [] kthread+0x7d/0x85 [4.238004] [] child_rip+0xa/0x20 [4.238004] [] ? kthread+0x0/0x85 [4.238004] [] ? child_rip+0x0/0x20 [4.238004] Code: 28 08 00 00 48 89 e5 53 48 83 ec 08 e8 d5 e8 27 e1 83 3d fc 5c 00 00 00 48 89 c3 7e 0e 48 c7 c7 ba 2b 03 a0 31 c0 e8 e7 95 4e e1 <48> 8b 3b c7 43 08 00 00 00 00 e8 e9 a2 0a e1 48 c7 03 00 00 00 [4
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
1. Do we agree that a lirc (-style) kernel-user interface is needed at least? 2. Is there any problem with lirc kernel-user interface? If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge the Jarod's lirc patches (at least the core) so at least the non-controversial part is done? Doing so doesn't block improving input layer IR interface, does it? -- Krzysztof Halasa -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa wrote: > 1. Do we agree that a lirc (-style) kernel-user interface is needed at > least? > > 2. Is there any problem with lirc kernel-user interface? Can you consider sending the raw IR data as a new evdev message type instead of creating a new device protocol? evdev protects the messages in a transaction to stop incomplete messages from being read. You might also want to use evdev capabilities to describe what the hardware can do. These were the capabilities I had made up: #define IR_CAP_RECEIVE_BASEBAND 0 #define IR_CAP_RECEIVE_36K 1 #define IR_CAP_RECEIVE_38K 2 #define IR_CAP_RECEIVE_40K 3 #define IR_CAP_RECEIVE_56K 4 #define IR_CAP_SEND_BASEBAND 5 #define IR_CAP_SEND_36K 6 #define IR_CAP_SEND_38K 7 #define IR_CAP_SEND_40K 8 #define IR_CAP_SEND_56K 9 #define IR_CAP_XMITTER_1 10 #define IR_CAP_XMITTER_2 11 #define IR_CAP_XMITTER_3 12 #define IR_CAP_XMITTER_4 13 #define IR_CAP_RECEIVE_RAW 14 #define IR_CAP_SEND_RAW 15 > If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge > the Jarod's lirc patches (at least the core) so at least the > non-controversial part is done? > > Doing so doesn't block improving input layer IR interface, does it? > -- > Krzysztof Halasa > -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote: On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa wrote: 1. Do we agree that a lirc (-style) kernel-user interface is needed at least? 2. Is there any problem with lirc kernel-user interface? Can you consider sending the raw IR data as a new evdev message type instead of creating a new device protocol? No, I think it would be wrong. Such events are ill-suited for consumption by regular applications and would introduce the "looping" interface I described in my other email. evdev protects the messages in a transaction to stop incomplete messages from being read. If such property is desired we can add it to the new lirc-like interface, can't we? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa wrote: 1. Do we agree that a lirc (-style) kernel-user interface is needed at least? 2. Is there any problem with lirc kernel-user interface? If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge the Jarod's lirc patches (at least the core) so at least the non-controversial part is done? Isn't the meat of Jarod's patch the lirc interface? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov wrote: > On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote: > >> On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa wrote: >>> >>> 1. Do we agree that a lirc (-style) kernel-user interface is needed at >>> least? >>> >>> 2. Is there any problem with lirc kernel-user interface? >> >> Can you consider sending the raw IR data as a new evdev message type >> instead of creating a new device protocol? > > No, I think it would be wrong. Such events are ill-suited for consumption by > regular applications and would introduce the "looping" interface I described > in my other email. Regular applications are going to ignore these messages. The only consumer for them is the LIRC daemon. Which is just going to process them and re-inject the events back into evdev again in a different form. IR is an input device, what make it so special that it needs to by pass this subsystem and implement its own private communications scheme? >> evdev protects the messages in a transaction to stop incomplete >> messages from being read. > > If such property is desired we can add it to the new lirc-like interface, > can't we? Why do you want to redesign evdev instead of using it? > > -- >> > Dmitry > -- Jon Smirl jonsm...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup/
Mauro, Please pull from http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup/ for the following 9 changesets: v4l: Add video_device_node_name function v4l: Use the new video_device_node_name function v4l: Remove video_device::num usage from device drivers v4l: Replace video_is_unregistered with video_is_registered v4l: Use the video_is_registered function in device drivers v4l: Use the video_drvdata function in drivers v4l: Use video_device_node_name() instead of the minor number v4l: Remove unneeded video_device::minor assignments v4l: Remove unneeded video_device::minor usage in drivers The patches include fixes for the problem reported by Devin Heitmueller. Documentation/video4linux/v4l2-framework.txt| 16 - drivers/media/common/saa7146_fops.c | 66 -- drivers/media/radio/radio-tea5764.c |4 - drivers/media/video/arv.c |5 - drivers/media/video/au0828/au0828-video.c | 34 ++- drivers/media/video/au0828/au0828.h |1 drivers/media/video/bt8xx/bttv-driver.c | 51 +++-- drivers/media/video/c-qcam.c|4 - drivers/media/video/cafe_ccic.c |1 drivers/media/video/cpia.c | 13 +--- drivers/media/video/cpia2/cpia2_v4l.c |7 +- drivers/media/video/cx18/cx18-fileops.c |4 - drivers/media/video/cx18/cx18-streams.c | 20 +++--- drivers/media/video/cx231xx/cx231xx-cards.c |5 + drivers/media/video/cx231xx/cx231xx-core.c | 26 drivers/media/video/cx231xx/cx231xx-video.c | 58 +++ drivers/media/video/cx231xx/cx231xx.h |2 drivers/media/video/cx23885/cx23885-417.c | 29 ++--- drivers/media/video/cx23885/cx23885-core.c | 11 --- drivers/media/video/cx23885/cx23885-video.c | 70 +--- drivers/media/video/cx23885/cx23885.h |3 - drivers/media/video/cx88/cx88-blackbird.c | 26 ++-- drivers/media/video/cx88/cx88-mpeg.c| 15 - drivers/media/video/cx88/cx88-video.c | 68 +-- drivers/media/video/cx88/cx88.h |2 drivers/media/video/davinci/vpfe_capture.c |3 - drivers/media/video/davinci/vpif_display.c |1 drivers/media/video/em28xx/em28xx-cards.c |8 -- drivers/media/video/em28xx/em28xx-core.c| 28 - drivers/media/video/em28xx/em28xx-video.c | 59 ++-- drivers/media/video/em28xx/em28xx.h |3 - drivers/media/video/et61x251/et61x251_core.c| 45 --- drivers/media/video/gspca/gl860/gl860.c |4 - drivers/media/video/gspca/gspca.c |9 +-- drivers/media/video/gspca/sn9c20x.c |5 + drivers/media/video/hdpvr/hdpvr-core.c | 10 +-- drivers/media/video/hdpvr/hdpvr-video.c |2 drivers/media/video/ivtv/ivtv-fileops.c |4 - drivers/media/video/ivtv/ivtv-streams.c | 19 +++--- drivers/media/video/meye.c |1 drivers/media/video/omap24xxcam.c | 10 +-- drivers/media/video/ov511.c |7 +- drivers/media/video/pvrusb2/pvrusb2-v4l2.c | 21 +-- drivers/media/video/pwc/pwc-if.c|3 - drivers/media/video/s2255drv.c | 55 ++ drivers/media/video/saa5246a.c |1 drivers/media/video/saa7134/saa7134-core.c | 19 +++--- drivers/media/video/saa7134/saa7134-empress.c | 20 ++ drivers/media/video/saa7134/saa7134-video.c | 39 + drivers/media/video/se401.c |4 - drivers/media/video/sn9c102/sn9c102_core.c | 47 drivers/media/video/soc_camera.c|4 - drivers/media/video/stk-webcam.c|9 +-- drivers/media/video/stradi
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mike Lampard wrote: > an example I have a VDR instance running in the background on my desktop > machine outputting to a TV in another room via a pci mpeg decoder - I > certainly don't want the VDR remote control interacting with my X11 desktop > in > any way unless I go out of my way to set it up to do so, nor do I want it > interacting with other applications (such as MPD piping music around the > house) that are controlled via other remotes in other rooms unless specified. > > Setting this up with Lircd was easy, how would a kernel-based proposal handle > this? eg EV="/dev/input/"$( cd "/sys/class/input" && ( grep -l 'X10' event*/device/name || grep -l 'X10' event*/device/manufacturer ) | sed -e 's,/.*,,' ) ./vdr [...] -P "remote -i $EV" This is how it has worked for years, so there's no reason it wouldn't work w/ any future scheme. The remote buttons normally arrive as normal kbd keys; once an app grabs the input device corresponding to a remote, it receives the events exclusively. artur -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Nov 29, 2009, at 1:47 PM, Jon Smirl wrote: On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov wrote: On Nov 29, 2009, at 12:44 PM, Jon Smirl wrote: On Sun, Nov 29, 2009 at 3:27 PM, Krzysztof Halasa wrote: 1. Do we agree that a lirc (-style) kernel-user interface is needed at least? 2. Is there any problem with lirc kernel-user interface? Can you consider sending the raw IR data as a new evdev message type instead of creating a new device protocol? No, I think it would be wrong. Such events are ill-suited for consumption by regular applications and would introduce the "looping" interface I described in my other email. Regular applications are going to ignore these messages. The only consumer for them is the LIRC daemon. Which is just going to process them and re-inject the events back into evdev again in a different form. IR is an input device, what make it so special that it needs to by pass this subsystem and implement its own private communications scheme? So are HID devices (both USB and BT), PS/2 and so on. You are not arguing for sending unprocessed data from these devices through evdev. evdev protects the messages in a transaction to stop incomplete messages from being read. If such property is desired we can add it to the new lirc-like interface, can't we? Why do you want to redesign evdev instead of using it? I just said why in my previous email: looping is a mark of badly designed interface. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote: > On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky > wrote: > > This has zero advantages besides good developer feeling that "My system > > has one less daemon..." > > Surely it's clear that having an unnecessary daemon is introducing > another point of failure? A failure in a userspace IR daemon is worst case loss of IR functionality. A failure in kernel space can oops or panic the machine. > Reducing complexity is not just its own > reward in a 'Developer Feel Good' way. No complexity is being reduced here. It's being shoved from one side of a fence to another. A bad part about the proposed move is that in user space, user address space is fairly isolated from other applications and separate from kernel space. Partitioning reduces complexity and the impact of failures. Moving things into kernel space just adds more to the pile of code; it should have a good reason for being there. > If decoding can *only* be sanely handled in user-space, that's one > thing. If it can be handled in kernel, then that would be better. Why does the address space in which decoding is performed make the decoding process better or worse? The in kernel infrastructre and restrictions add constraints to a decoding implementation. Userspace is much more flexible. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, 2009-11-29 at 20:49 +0100, Christoph Bartelmus wrote: > Hi, > > on 29 Nov 09 at 14:16, Jon Smirl wrote: > > On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox wrote: > >>> Jon is asking for an architecture discussion, y'know, with use cases. > [...] > > So we're just back to the status quo of last year which is to do > > nothing except some minor clean up. > > > > We'll be back here again next year repeating this until IR gets > > redesigned into something fairly invisible like keyboard and mouse > > drivers. > > Last year everyone complained that LIRC does not support evdev - so I > added support for evdev. > > This year everyone complains that LIRC is not plug'n'play - we'll fix that > 'til next year. V4L-DVB is also making progress on the enumeration front. At least for V4L devices a new media controller device node will be able to enumerate all devices associated with a video card (or embedded system or SoC). >From one device node, an app should be able to discover all video, alsa, dvb, and framebuffer device nodes on a video card, find out about entities on the card, and set up the reconfigurable connections between entities on the card. One should be able to discover subdevices on cards like IR controllers. The RFC before the mini-summit at the 2009 LPC is here: http://lwn.net/Articles/352623/ The V4L media controller entity discover mechanism won't completely solve the general discovery problem for IR. It will be one way to discover IR devices associated with V4L supported peripherals. I assume discovering USB IR-only devices by USB Id is not a problem. That leaves serial port, parallel port and sound jack connected devices as the difficult ones to "discover". Regards, Andy > Christoph > -- -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, 2009-11-29 at 21:27 +0100, Krzysztof Halasa wrote: > 1. Do we agree that a lirc (-style) kernel-user interface is needed at >least? Yes. Honestly, I'm just waiting on lirc_dev for the IR devices I work with. With that I can get those new devices supported for both IR Rx and Tx right now. I was holding off building a lirc_v4l module to see if lirc_dev makes it in kernel. However, because of the desire by V4L supporters wanting IR to just work for remotes bundled with video capture cards, I have already added: 1. cx23885-input.c support with RC-5, and soon NEC support, in kernel. 2. new configurations for ir-kbd-i2c.c, due to IR hardware on some cx18 and ivtv supported cards. So at least IR Rx works for the cheap bundled remote. I still think input subsystem will never be able to rpovide a feature complete interface though. I don't mind putting enough work in for the "Just works" part with the bundled remote with -input, but not more. > 2. Is there any problem with lirc kernel-user interface? Here's my list 1. Unused transmit mode defines/enums. It's not a big deal really, but I had a hard time figuring out the differences between CODE, MODE2, PULSE since some are not well documented and some of those are not even used for Tx. 2. The LIRC ioctls() wanting to change one parameter at a time will cause me some thought/work. It would be better, I think, if LIRC would do a get/set of all the parameters in one go. That's what I do internally here: http://linuxtv.org/hg/v4l-dvb/file/e0cd9a337600/linux/include/media/v4l2-subdev.h#l283 http://linuxtv.org/hg/v4l-dvb/file/e0cd9a337600/linux/drivers/media/video/cx23885/cx23888-ir.c#l746 http://linuxtv.org/hg/v4l-dvb/file/e0cd9a337600/linux/drivers/media/video/cx23885/cx23885-input.c#l269 The idea is that you set up the IR hardware infrequently and spend most of the time letting it run. I'd have to think, if setting up the hardware one parameter at a time may have it operating in a strange mode, until the sequence of configuration ioctl() is complete. I was planning on a lirc_v4l module aggregating all the lirc_dev ioctl requests somehow to possibly avoid that potential problem. Maybe an additional ioctl() from LIRC userspace and lirc_dev saying it was done with the current IR device configuration sequence would be another way to mitigate the problem for me. > If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge > the Jarod's lirc patches (at least the core) so at least the > non-controversial part is done? > > Doing so doesn't block improving input layer IR interface, does it? It never has AFAICT. A current related problem is that i2c based devices can only be bound to only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time. Currently it is somewhat up to the bridge driver which binding is preferred. Discussion about this for the pvrusb2 module had the biggest email churn IIRC. This will be a general problem to fix for all the V4L-DVB drivers where both LIRC and input can handle the device. A reasonable default assumption *may* be that the user who bothers to configure LIRC wants LIRC to override handling by input. That's a detail though... Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 (not very) new board 5168:0307
Am Samstag, den 28.11.2009, 11:55 +0100 schrieb tomloh...@gmail.com: > hermann pitton a écrit : > > Hi Tom, > > > > Am Mittwoch, den 18.11.2009, 14:06 +0100 schrieb tomloh...@gmail.com: > > > >> Hello list, > >> > >> looking from saa7134.h, this board 5168:0307 is not included > >> This cars is on some asus laptop and some medion laptop > >> It was previously working with this settings (1) card=55 tuner=54 > >> or (2) with tuner = 86 > >> ok, so with this settings, nothing : > >> > >> with card = 55 : > >> > >> [ 109.375445] Linux video capture interface: v2.00 > >> [ 109.410546] saa7130/34: v4l2 driver version 0.2.14 loaded > >> [ 109.410606] saa7133[0]: found at :06:03.0, rev: 208, irq: 19, > >> latency: 181, mmio: 0xb4007800 > >> [ 109.410614] saa7133[0]: subsystem: 5168:0307, board: LifeView FlyDVB-T > >> DUO / MSI t...@nywhere Duo [card=55,insmod option] > >> [ 109.410674] saa7133[0]: board init: gpio is 1 > >> [ 109.410743] input: saa7134 IR (LifeView FlyDVB-T D as > >> /devices/pci:00/:00:1e.0/:06:03.0/input/input9 > >> [ 109.587912] saa7133[0]: i2c eeprom 00: 68 51 07 03 54 20 1c 00 43 43 a9 > >> 1c 55 d2 b2 92 > >> [ 109.587924] saa7133[0]: i2c eeprom 10: 00 00 62 08 ff 20 ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.587934] saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 > >> e7 ff ff ff ff > >> [ 109.587944] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.587953] saa7133[0]: i2c eeprom 40: ff 24 00 c2 96 10 05 01 01 16 22 > >> 15 ff ff ff ff > >> [ 109.587963] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.587972] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.587982] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.587992] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.588024] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.588034] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.588043] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.588053] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.588062] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.588072] saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.588081] saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 109.596023] saa7133[0]: i2c scan: found device @ 0x10 [???] > >> [ 109.612379] saa7133[0]: i2c scan: found device @ 0x96 [???] > >> [ 109.620016] saa7133[0]: i2c scan: found device @ 0xa0 [eeprom] > >> [ 109.984237] tuner' 0-004b: chip found @ 0x96 (saa7133[0]) > >> [ 110.064028] tda829x 0-004b: setting tuner address to 61 > >> [ 110.144024] tda829x 0-004b: type set to tda8290+75 > >> [ 114.804413] saa7133[0]: registered device video0 [v4l2] > >> [ 114.804463] saa7133[0]: registered device vbi0 > >> [ 114.804509] saa7133[0]: registered device radio0 > >> [ 114.891645] saa7134 ALSA driver for DMA sound loaded > >> [ 114.891706] saa7133[0]/alsa: saa7133[0] at 0xb4007800 irq 19 registered > >> as card -2 > >> [ 115.705042] dvb_init() allocating 1 frontend > >> [ 115.756244] DVB: registering new adapter (saa7133[0]) > >> [ 115.756254] DVB: registering adapter 0 frontend 0 (Philips TDA10046H > >> DVB-T)... > >> [ 115.940033] tda1004x: setting up plls for 48MHz sampling clock > >> [ 116.106914] tda1004x: found firmware revision ff -- invalid > >> [ 116.106921] tda1004x: trying to boot from eeprom > >> [ 116.572024] tda1004x: found firmware revision 23 -- ok > >> [ 117.016161] tda827x_probe_version: could not read from tuner at addr: > >> 0xc0 > >> > >> > >> [ 3969.562904] saa7130/34: v4l2 driver version 0.2.14 loaded > >> [ 3969.562994] saa7133[0]: found at :06:03.0, rev: 208, irq: 19, > >> latency: 181, mmio: 0xb4007800 > >> [ 3969.563007] saa7133[0]: subsystem: 5168:0307, board: LifeView FlyDVB-T > >> / Genius VideoWonder DVB-T [card=86,insmod option] > >> [ 3969.563091] saa7133[0]: board init: gpio is 1 > >> [ 3969.563219] input: saa7134 IR (LifeView FlyDVB-T / as > >> /devices/pci:00/:00:1e.0/:06:03.0/input/input9 > >> [ 3969.738045] saa7133[0]: i2c eeprom 00: 68 51 07 03 54 20 1c 00 43 43 a9 > >> 1c 55 d2 b2 92 > >> [ 3969.738069] saa7133[0]: i2c eeprom 10: 00 00 62 08 ff 20 ff ff ff ff ff > >> ff ff ff ff ff > >> [ 3969.738090] saa7133[0]: i2c eeprom 20: 01 40 01 03 03 01 01 03 08 ff 01 > >> e7 ff ff ff ff > >> [ 3969.738111] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff > >> ff ff ff ff ff > >> [ 3969.738132] saa7133[0]: i2c eeprom 40: ff 24 00 c2 96 10 05 01 01 16 22 > >> 15 ff ff ff ff > >> [ 3
Re: Compile error saa7134 - compro videomate S350
Hi Dominic, Am Samstag, den 28.11.2009, 17:30 -0800 schrieb Dominic Fernandes: > Hi Hermann, > > I'm getting closer!!! > > I'm using ubuntu 9.10, unloading saa7134 alsa wasn't working for me so I put > it into the blacklist which prevented it from loading and then I was able to > do the "modprobe -vr saa7134-alsa saa7134-dvb" and "modprobe -v saa7134 > card=16". > > And now the card recongnised correctly as the S350 and the dvb frontend > loads. > > So, now I've plugged in the cable to the SAT dish which is pointing to Astra > 19.2 and want to tune into some channels. > I installed dvb-apps and use the command below to create a channels.conf to > use later:- > > scan -x0 /usr/share/dvb/dvb-s/Astra-19.2E | tee channels.conf > > but this soon concludes with tunning finished with no channels found. I get > a warning >>> tuning failed. > > So, I tried both the modification of the GPIO address of xc and what it > was originally x8000 which gave the same tuning failed message. > > Are there some other commands to test the DVB Frontend? if Astra-19.2E is unchanged in dvb-apps, it has not much. # Astra 19.2E SDT info service transponder # freq pol sr fec S 12551500 V 2200 5/6 We don't even know if 13 and 18 Volts to the LNB work both for sure with that variant, IIRC. The report says just somehow works. I think I would try with some peace of copper from a LNB cable into the RF connector and a Voltmeter, if there is any sign of life first, either using kaffeine with better files for scanning or the "setvoltage" tool in /test. You might want to set dvb_powerdown_on_sleep=0 for dvb_core. For the other saa7134 driver cards currently is hacked on, For Dominic with the Leadtek on the saa7134 driver, Terry, me or anyone else interested should provide some test patches. Why that AverMedia analog only in the Ukraine doesn't have sound even on PAL around there, is beyond my imagination, except it would not have ever been tested for TV sound, also beyond what I can imagine. Any log for obviously failing sound carrier detection is still missing. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Sun, Nov 29, 2009 at 3:35 PM, Andy Walls wrote: >> If decoding can *only* be sanely handled in user-space, that's one >> thing. If it can be handled in kernel, then that would be better. > > Why does the address space in which decoding is performed make the > decoding process better or worse? The in kernel infrastructre and > restrictions add constraints to a decoding implementation. Userspace is > much more flexible. In which case I look forward to seeing your patches to move drivers/hid/ to userspace. Please cc: me so I can enjoy the ensuing festival. -- 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: [RFC] What are the goals for the architecture of an in-kernel IR system?
On Nov 29, 2009, at 4:31 PM, Dmitry Torokhov wrote: > On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa wrote: > >> 1. Do we agree that a lirc (-style) kernel-user interface is needed at >> least? >> >> 2. Is there any problem with lirc kernel-user interface? >> >> If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge >> the Jarod's lirc patches (at least the core) so at least the >> non-controversial part is done? > > > Isn't the meat of Jarod's patch the lirc interface? Patch 1 was the lirc interface, 2 and 3 are individual device drivers that use it. /me has some catching up to do on this thread after being partially detached from the computer over the holiday weekend here in the US... -- Jarod Wilson ja...@wilsonet.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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote: > On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov > wrote: >>> In the code I posted there is one evdev device for each configured >>> remote. Mapped single keycodes are presented on these devices for each >>> IR burst. There is no device for the IR receiver. A LIRC type process >>> could watch these devices and then execute scripts based on the >>> keycodes reported. >>> > ... >> >> Maybe we should revisit Jon's patchset as well. Regretfully I did not >> have time to do that when it was submitted the last time. > > Consider my patch set a technology demo starting point. It shows a > modern architecture for integrating IR into evdev. Use the input from > everyone else to turn these concepts into a real design. I wrote the > code for the fun of it, I have no commercial interest in IR. I was > annoyed with how LIRC handled Sony remotes on my home system. > > The design is a clean slate implementation of IR for the kernel. No > attempt was made at legacy compatibility. I was familiar with evdev vs > /dev/mouse problems from my work on the X server. Because of working > on X I've also always hated keymaps (that's what drove the configfs > design). > > I wish one of the set top box or TV manufacturers would step up and > own this. They are the ones that would benefit the most. Jarod would > probably be open to some consulting, right? Mauro may actually have better connections on that front than I do... Thus far, I've only talked to a few vendors of IR devices, with mixed results getting any sort of support out of them. But its on my todo list to put out some feelers on the work front to see if we have any connections that we might be able to utilize. -- Jarod Wilson ja...@wilsonet.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: saa7134 (not very) new board 5168:0307
hermann pitton a écrit : Hi Thomas, Hi Hermann, thanks for informations ... This card is not mine so physically inspect it is not possible and the owner is at 700 kms from me... However, it seems there is only one hybrid tuner. The card is referenced as AR307 rev N (seen on photos) and i found a link about this card : http://www.pchub.com/uph/model/0--13652-1/LR307-parts.html yes, if another one is not at the backisde, under the huge shielding of the frontside is only one. searching on LR307, i found a previous mail where you talked about a LR307- rev q http://osdir.com/ml/linux-media/2009-09/msg00744.html The bttv-gallery.de has a LR307 Revision Q too. It has an extra sticker for some LNA version on it. Also gpio init and eeprom data differ. I modified a little the patch found in this mail (subvendor) and i have partial result : - dvb tune work partially, not all channels are found - dvb channel in kaffeine works (image and sound) for few seconds and then nothing Then at least some little progress with antenna_config = 2 and gpio 21 high for RF routing for DVB it seems. - nothing for analogic stations That's a little strange somehow, since if only one RF connector and no radio, RF for analog should come through as well, because gpio 21 was high in that test patch for analog TV too. Maybe some unknown LNA circuitry. with others cards like 81,104,105 and 109, same results, kaffeine works and then hangs With the HVR1110 you have a card with LNA config = 1 there, known issues with that on some Pinnacle 310i, a older setup did exist. What do you want to help this card to be supported ? Hard to say, but since the hvr1110 does not have the antenna_switch = 2 and the RF input routing, you also did not really test &tda827x_cfg_1 yet. Might be worth a try. Cheers, Hermann Thanks in advance Cheers, Thomas Hi Hermann, We will try what you suggest. 2 things : - when kaffeine hangs , the owner try the analogic part with kdetv , no results, but after that, trying kaffeine, dvb works for another few seconds and so on ... -we replace tda10046.fw by tda10046livefiew and before rev in log was 20 with 3 attempts, after, rev 23 at the first time Will post dmesg with gpio-tracking Cheers, Thomas -- 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
StarTech.com USB 2.0 Video Capture Cable SVID2USB2 dmesg log
Hello! I have a StarTech.com USB 2.0 Video Capture Cable SVID2USB2 device. I have yet to get the device working for me under Fedora 12. I found the request to send an email with the log, so I thought I'd pass it along. I tried several card= insmod options (0, 1, and 8) with no luck. I would like to get the device working and am willing to contribute to the project if there's anything I can do to help out. Please let me know if there's any more information about my setup you'd like to know. em28xx: New device USB 2821 Device @ 480 Mbps (eb1a:2821, interface 0, class 0) em28xx #0: chip ID is em2820 (or em2710) em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 21 28 90 00 11 03 6a 22 00 00 em28xx #0: i2c eeprom 10: 00 00 04 57 06 21 01 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 20: 02 00 01 01 f0 10 00 00 00 00 00 00 5b 00 00 00 em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 10 01 03 01 00 00 00 00 em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 32 00 31 00 20 00 44 00 em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x37da7b8a em28xx #0: EEPROM info: em28xx #0: AC97 audio (5 sample rates) em28xx #0: 500mA max power em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) em28xx #0: found i2c device @ 0x4a [saa7113h] em28xx #0: found i2c device @ 0xa0 [eeprom] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. em28xx #0: You may try to use card= insmod option to workaround that. em28xx #0: Please send an email with this log to: em28xx #0: V4L Mailing List em28xx #0: Board eeprom hash is 0x37da7b8a em28xx #0: Board i2c devicelist hash is 0x6ba50080 em28xx #0: Here is a list of valid choices for the card= insmod option: em28xx #0: card=0 -> Unknown EM2800 video grabber em28xx #0: card=1 -> Unknown EM2750/28xx video grabber em28xx #0: card=2 -> Terratec Cinergy 250 USB em28xx #0: card=3 -> Pinnacle PCTV USB 2 em28xx #0: card=4 -> Hauppauge WinTV USB 2 em28xx #0: card=5 -> MSI VOX USB 2.0 em28xx #0: card=6 -> Terratec Cinergy 200 USB em28xx #0: card=7 -> Leadtek Winfast USB II em28xx #0: card=8 -> Kworld USB2800 em28xx #0: card=9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker em28xx #0: card=10 -> Hauppauge WinTV HVR 900 em28xx #0: card=11 -> Terratec Hybrid XS em28xx #0: card=12 -> Kworld PVR TV 2800 RF em28xx #0: card=13 -> Terratec Prodigy XS em28xx #0: card=14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 em28xx #0: card=15 -> V-Gear PocketTV em28xx #0: card=16 -> Hauppauge WinTV HVR 950 em28xx #0: card=17 -> Pinnacle PCTV HD Pro Stick em28xx #0: card=18 -> Hauppauge WinTV HVR 900 (R2) em28xx #0: card=19 -> EM2860/SAA711X Reference Design em28xx #0: card=20 -> AMD ATI TV Wonder HD 600 em28xx #0: card=21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder em28xx #0: card=22 -> EM2710/EM2750/EM2751 webcam grabber em28xx #0: card=23 -> Huaqi DLCW-130 em28xx #0: card=24 -> D-Link DUB-T210 TV Tuner em28xx #0: card=25 -> Gadmei UTV310 em28xx #0: card=26 -> Hercules Smart TV USB 2.0 em28xx #0: card=27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) em28xx #0: card=28 -> Leadtek Winfast USB II Deluxe em28xx #0: card=29 -> em28xx #0: card=30 -> Videology 20K14XUSB USB2.0 em28xx #0: card=31 -> Usbgear VD204v9 em28xx #0: card=32 -> Supercomp USB 2.0 TV em28xx #0: card=33 -> em28xx #0: card=34 -> Terratec Cinergy A Hybrid XS em28xx #0: card=35 -> Typhoon DVD Maker em28xx #0: card=36 -> NetGMBH Cam em28xx #0: card=37 -> Gadmei UTV330 em28xx #0: card=38 -> Yakumo MovieMixer em28xx #0: card=39 -> KWorld PVRTV 300U em28xx #0: card=40 -> Plextor ConvertX PX-TV100U em28xx #0: card=41 -> Kworld 350 U DVB-T em28xx #0: card=42 -> Kworld 355 U DVB-T em28xx #0: card=43 -> Terratec Cinergy T XS em28xx #0: card=44 -> Terratec Cinergy T XS (MT2060) em28xx #0: card=45 -> Pinnacle PCTV DVB-T em28xx #0: card=46 -> Compro, VideoMate U3 em28xx #0: card=47 -> KWorld DVB-T 305U em28xx #0: card=48 -> KWo
