Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Gerd, on 26 Nov 09 at 00:22, Gerd Hoffmann wrote: [...] To sum it up: I don't think this information will be useful at all for lircd or anyone else. [...] I know that lircd does matching instead of decoding, which allows to handle unknown encodings. Thats why I think there will always be

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi, on 25 Nov 09 at 12:44, Jarod Wilson wrote: [...] Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: [...] [*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all others will be shot on sight.

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 09:01:00AM +0100, Christoph Bartelmus wrote: Hi, on 25 Nov 09 at 12:44, Jarod Wilson wrote: [...] Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: [...] [*] assuming, of course, that it was actually agreed upon that in-kernel

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

2009-11-26 Thread Robert Lowery
Hi, After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything appeared to be ok, but I have now noticed certain channels in Australia are showing corruption which manifest themselves as blockiness and

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Gerd Hoffmann
On 11/26/09 08:28, Christoph Bartelmus wrote: Hi Gerd, on 26 Nov 09 at 00:22, Gerd Hoffmann wrote: [...] To sum it up: I don't think this information will be useful at all for lircd or anyone else. [...] I know that lircd does matching instead of decoding, which allows to handle unknown

Re: [PATCH] soc-camera: Add mt9t112 camera support

2009-11-26 Thread Kuninori Morimoto
Hi Magnus So now I've done some testing of the mt9t112 sensor hooked up to CEU0 on the ecovec board. I tried 16-bit RGB and NV12 in various resolutions with mplayer. My only comment is that it seems to take a bit of time to setup the sensor initially, but that may be something related to

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Gerd Hoffmann
On 11/26/09 07:23, Jarod Wilson wrote: Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. lirc predates the input layer IR drivers by years, maybe even the input layer itself. The main reason for the input layer

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

2009-11-26 Thread Vincent McIntyre
Hi Rob would you mind very much posting a patch that implements these two reversions, so I can try it easily? My hg-fu is somewhat lacking... I have the same hardware and noticed what I think is the same issue, just with Channel 9. Another manifestation is huge BER and nonzero REC in the output

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

2009-11-26 Thread Vincent McIntyre
On 11/26/09, Vincent McIntyre vincent.mcint...@gmail.com wrote: Another manifestation is huge BER and nonzero REC in the output from 'tzap'. doh! I meant huge BER and nonzero UNC. Apologies also for the top-post. -- To unsubscribe from this list: send the line unsubscribe linux-media in the

[PATCH/RFC v1] Mem-to-mem device framework

2009-11-26 Thread Pawel Osciak
Hello, this is a proposed implementation for mem-to-mem memory device framework. Previous discussion and RFC on this topic: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/10668 A mem-to-mem device is a device that uses memory buffers passed by userspace applications for

[PATCH 1/2] Added memory-to-memory device helper framework for V4L2.

2009-11-26 Thread Pawel Osciak
A mem-to-mem device is a device that uses memory buffers passed by userspace applications for both source and destination. This is different from existing drivers that use memory buffers for only one of those at once. In terms of V4L2 such a device would be both of OUTPUT and CAPTURE type.

[PATCH 2/2] Added a mem-to-mem V4L2 framework test device.

2009-11-26 Thread Pawel Osciak
Signed-off-by: Pawel Osciak p.osc...@samsung.com Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com Reviewed-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/video/Kconfig |7 + drivers/media/video/Makefile |1 + drivers/media/video/mem2mem_testdev.c

[EXAMPLE v1] Mem-to-mem userspace test application.

2009-11-26 Thread Pawel Osciak
This is an example application for testing mem-to-mem framework using mem2mem-testdev device. It is intended to be executed multiple times in parallel to test multi-instance operation and scheduling. Each process can be configured differently using command-line arguments. The application opens

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

2009-11-26 Thread Robert Lowery
Hi Rob would you mind very much posting a patch that implements these two reversions, so I can try it easily? My hg-fu is somewhat lacking... I have the same hardware and noticed what I think is the same issue, just with Channel 9. Another manifestation is huge BER and nonzero REC in the

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: (This is no recommendation for lirc. I have no idea whether a pulse/space - scancode - keycode translation would be practical there.) It would, but not exactly in the present shape. For example, there are several

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Andy Walls
On Thu, 2009-11-26 at 01:23 -0500, Jarod Wilson wrote: On Nov 26, 2009, at 12:49 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 07:53:57PM -0500, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: Czesc Krzysztof, on 23 Nov 09 at 15:14, Krzysztof

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: If you see patch 3/3, of the lirc submission series, you'll notice a driver that has hardware decoding, but, due to lirc interface, the driver generates pseudo pulse/space code for it to work via lirc interface. IOW

Mantis – anyone?

2009-11-26 Thread Matthias Wächter
I am now playing around with the available code for quite some time now with mixed success, but no solution comes near the term “stable”. • kernel: nothing in there. Well, reasonable. • v4l-dvb: nothing in there. • s2-liplianin: mantis available, but obviously not under development/bugfixing. IR

[PATCH] New driver for the radio FM module on Miro PCM20 sound card

2009-11-26 Thread Krzysztof Helt
From: Krzysztof Helt krzysztof...@wp.pl This is recreated driver for the FM module found on Miro PCM20 sound cards. This driver was removed around the 2.6.2x kernels because it relied on the removed OSS module. Now, it uses a current ALSA module (snd-miro) and is adapted to v4l2 layer. It

Re: Help needed with Hauppauge WinTV HVR-4000

2009-11-26 Thread Steven Toth
On Thu, Nov 26, 2009 at 6:12 AM, Alan Ferrero al...@tin.it wrote: Hi! I posted yesterday the following message to the mythtv-users mailing list, but they answered me it's more suitable to post it in your mailing list. Alan Hi! I REALLY need some help with the Hauppauge WinTV HVR-4000

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Andy Walls wrote: I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Regards, Andy LIRC Fan-Boy Walls This is not a lirc love or hate thread. We're simply discussing the better API's for IR, from the technical standpoint,

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Andy Walls
On Thu, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote: Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: PS.: For those following those discussions that want to know more about IR protocols, a good reference is at:

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Andy Walls wrote: On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree strongly. Any interface without transmitter support would be absolutely

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Andy Walls
On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote: Andy Walls wrote: On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I think we shouldn't at this time worry about IR transmitters. Sorry, but I have to disagree

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Jarod Wilson wrote: On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: ... I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed perception). Aside for a video card's default remote

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote: Andy Walls awa...@radix.net writes: I would also note that RC-6 Mode 6A, used by most MCE remotes, was developed by Philips, but Microsoft has some sort of licensing interest in it and it is almost surely encumbered somwhow: I don't know about legal problems in

[PATCH 1/2 v2] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-11-26 Thread Guennadi Liakhovetski
Video subdevices, like cameras, decoders, connect to video bridges over specialised busses. Data is being transferred over these busses in various formats, which only loosely correspond to fourcc codes, describing how video data is stored in RAM. This is not a one-to-one correspondence, therefore

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Jarod Wilson wrote: On Nov 25, 2009, at 12:40 PM, Krzysztof Halasa wrote: l...@bartelmus.de (Christoph Bartelmus) writes: I'm not sure what two ways you are talking about. With the patches posted by Jarod, nothing has to be changed in userspace. Everything works, no code needs to be

Re: [PATCH 1/2 v2] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-11-26 Thread Hans Verkuil
Hi Guennadi, Just two things really: 1) Can you move v4l2_mbus_packing and v4l2_mbus_order to a soc-mediabus.h header or something similar? It's now soc-specific, so it doesn't belong in the public header. 2) What are your plans for documenting the mediabus pixel codes? Otherwise it looks

Re: [PATCH] New driver for the radio FM module on Miro PCM20 sound card

2009-11-26 Thread Takashi Iwai
At Thu, 26 Nov 2009 13:50:17 +0100, Krzysztof Helt wrote: From: Krzysztof Helt krzysztof...@wp.pl This is recreated driver for the FM module found on Miro PCM20 sound cards. This driver was removed around the 2.6.2x kernels because it relied on the removed OSS module. Now, it uses a

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jon Smirl
On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Gerd Hoffmann wrote: On 11/25/09 19:20, Devin Heitmueller wrote: On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilsonja...@wilsonet.com wrote: Took me a minute to figure out exactly what you were talking about. You're

Re: [PATCH/RFC v2] V4L core cleanups HG tree

2009-11-26 Thread Steven Toth
On Wed, Nov 25, 2009 at 11:21 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hopefully CC'ing the au0828, cx231xx, cx23885, s2255 and cx25821 maintainers. Could you please ack patch http://linuxtv.org/hg/~pinchartl/v4l-dvb- cleanup/rev/7a762df57149 ? The patch should be

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jon Smirl
BTW, we used to have device specific user space interfaces for mouse and keyboard. These caused all sort of problems. A lot of work went into unifying them under evdev. It will be years until the old, messed up interfaces can be totally removed. I'm not in favor of repeating the problems with a

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Jarod Wilson wrote: I guess the question is what is the interface we want the regular userspace (i.e. not lircd) to use. Right now programs has to use 2 intercfaces - one lirc for dealing with remotes that are not using the standard event interface and evdev for remotes using it as well as

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Christoph Bartelmus wrote: Hi, on 25 Nov 09 at 12:44, Jarod Wilson wrote: [...] Ah, but the approach I'd take to converting to in-kernel decoding[*] would be this: [...] [*] assuming, of course, that it was actually agreed upon that in-kernel decoding was the right way, the only way, all

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Andy Walls wrote: On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote: I'm not sure if all the existing hardware for TX currently supports only raw pulse/code sequencies, but I still think that, even on the Tx case, it is better to send scancodes to the driver, and let it do the

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Gerd Hoffmann kra...@redhat.com writes: Why not? With RC5 remotes applications can get the device address bits for example, which right now are simply get lost in the ir code - keycode conversion step. Right, this in fact makes the input layer interface unusable for many remotes at this

Re: IR Receiver on an Tevii S470

2009-11-26 Thread Matthias Fechner
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. Bye, Matthias -- Programming today is a race between software engineers striving to

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jarod Wilson
On 11/26/2009 04:14 AM, Gerd Hoffmann wrote: On 11/26/09 07:23, Jarod Wilson wrote: Well, when mythtv was started, I don't know that there were many input layer remotes around... lirc was definitely around though. lirc predates the input layer IR drivers by years, maybe even the input layer

[PATCH 1/2 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-11-26 Thread Guennadi Liakhovetski
From 8b24c617e1ac4d324538a3eec476d48b85c2091f Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski g.liakhovet...@gmx.de Date: Thu, 26 Nov 2009 18:20:45 +0100 Subject: [PATCH] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats Video subdevices, like cameras, decoders,

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jarod Wilson
On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote: Jarod Wilson wrote: On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: ... I generally don't understand the LIRC aversion I perceive in this thread (maybe I just have a skewed

Re: [PATCH] New driver for the radio FM module on Miro PCM20 sound card

2009-11-26 Thread Takashi Iwai
At Thu, 26 Nov 2009 18:38:27 +0100, Krzysztof Helt wrote: On Thu, 26 Nov 2009 16:43:15 +0100 Takashi Iwai ti...@suse.de wrote: At Thu, 26 Nov 2009 13:50:17 +0100, Krzysztof Helt wrote: From: Krzysztof Helt krzysztof...@wp.pl This is recreated driver for the FM module found

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Dmitry Torokhov dmitry.torok...@gmail.com writes: In what way the key interface is unsufficient for delivering button events? At present: 128 different keys only (RC5: one group). One remote per device only. The protocol itself doesn't have the above limitations, but has others, with are

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Jarod Wilson wrote: On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote: Jarod Wilson wrote: On Nov 23, 2009, at 7:53 PM, Andy Walls wrote: On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote: ... I generally don't understand the LIRC aversion I perceive in this thread (maybe I

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote: Dmitry Torokhov dmitry.torok...@gmail.com writes: In what way the key interface is unsufficient for delivering button events? At present: 128 different keys only (RC5: one group). One remote per device only. The protocol itself doesn't have the above

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes: 1) the developer that adds the hardware also adds the IR code. He has the hardware and the IR for testing, so it means a faster development cycle than waiting for someone else with the same hardware and IR to recode it on some other place. You

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes: Technically, it is not hard to port this solution to the other drivers, but the issue is that we don't have all those IR's to know what is the complete scancode that each key produces. So, the hardest part is to find a way for doing it without

Re: IR raw input is not sutable for input system

2009-11-26 Thread Krzysztof Halasa
Maxim Levitsky maximlevit...@gmail.com writes: But devices that send raw pulse/space data should be handled in lirc that will feed the data back to the kernel via uinput. I still do want the in-kernel RCx decoding. And lirc pulse/space. -- Krzysztof Halasa -- To unsubscribe from this list:

Re: [RFC] Should we create a raw input interface for IR's ?

2009-11-26 Thread Krzysztof Halasa
Dmitry Torokhov dmitry.torok...@gmail.com writes: Why would sysfs write be slower than ioctl? Sysfs is generally one-value, one-file. open, read/write, close. ioctl() OTOH does everything (e.g. a whole key table) in one syscall. -- Krzysztof Halasa -- To unsubscribe from this list: send the

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: 1) the developer that adds the hardware also adds the IR code. He has the hardware and the IR for testing, so it means a faster development cycle than waiting for someone else with the same hardware and IR to recode it

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Technically, it is not hard to port this solution to the other drivers, but the issue is that we don't have all those IR's to know what is the complete scancode that each key produces. So, the hardest part is to find a

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: The issue I see is to support at the same time NEC and RC5 protocols. While this may work with some devices, for others, the hardware won't allow. Sure. We can handle it for the simple devices at least. I think the

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Andy Walls
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote: Krzysztof Halasa wrote: Andy Walls awa...@radix.net writes: I would also note that RC-6 Mode 6A, used by most MCE remotes, was developed by Philips, but Microsoft has some sort of licensing interest in it and it is almost

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

2009-11-26 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Nov 26 19:00:02 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13520:74ad936bcca2 gcc version: gcc

[PATCH 0/4 v8] Support for TVP7002 in DM365

2009-11-26 Thread Santiago Nunez-Corrales
This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition of TVP7002 specific data structures * Kconfig and Makefile support This series corrects many issued pointed out by Snehaprabha Narnakaje,

[PATCH 1/4 v9] Support for TVP7002 in v4l2 definitions

2009-11-26 Thread santiago . nunez
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides required chip identification definitions within v4l2. Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com --- include/media/v4l2-chip-ident.h |9 + 1 files changed, 9 insertions(+), 0

[PATCH 0/4 v9] Support for TVP7002 in DM365

2009-11-26 Thread Santiago Nunez-Corrales
This series of patches provide support for the TVP7002 decoder in DM365. Support includes: * Inclusion of the chip in v4l2 definitions * Definition of TVP7002 specific data structures * Kconfig and Makefile support This series corrects many issued pointed out by Snehaprabha Narnakaje,

[PATCH 2/4 v9] Definitions for TVP7002 in DM365

2009-11-26 Thread santiago . nunez
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides the required definitions for the TVP7002 driver in DM365. Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com --- drivers/media/video/tvp7002_reg.h | 150 +

[PATCH 3/4 v9] TVP7002 driver for DM365

2009-11-26 Thread santiago . nunez
From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides the implementation of the TVP7002 decoder driver for DM365. Implemented using the V4L2 DV presets API. Removed shadow register values. Testing shows that the device needs not to be powered down and up for correct

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Mauro, on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote: [...] lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by generating artificial pulse

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Christoph Bartelmus wrote: Hi Mauro, on 26 Nov 09 at 10:36, Mauro Carvalho Chehab wrote: [...] lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by

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

2009-11-26 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Nov 26 20:48:58 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13527:b3695bd384cc gcc version: gcc

Re: [PATCH 3/4 v9] TVP7002 driver for DM365

2009-11-26 Thread Hans Verkuil
On Thursday 26 November 2009 21:04:25 santiago.nu...@ridgerun.com wrote: From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com This patch provides the implementation of the TVP7002 decoder driver for DM365. Implemented using the V4L2 DV presets API. Removed shadow register values.

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa k...@pm.waw.pl wrote: Dmitry Torokhov dmitry.torok...@gmail.com writes: In what way the key interface is unsufficient for delivering button events? At present: 128 different keys only (RC5: one group). Where did this limitation come from? We

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Mauro, on 26 Nov 09 at 18:59, Mauro Carvalho Chehab wrote: Christoph Bartelmus wrote: [...] lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by

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

2009-11-26 Thread Hans Verkuil
On Thursday 26 November 2009 22:37:12 Hans Verkuil wrote: 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:Thu Nov 26 20:48:58 CET 2009 path:

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Trent Piepho
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote: See above. Also, several protocols have a way to check if a keystroke were properly received. When handling just one protocol, we can use this to double check the key. However, on a multiprotocol mode, we'll need to disable this feature.

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Trent Piepho
On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote: lircd supports input layer interface. Yet, patch 3/3 exports both devices that support only pulse/space raw mode and devices that generate scan codes via the raw mode interface. It does it by generating artificial pulse codes. Nonsense!

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote: On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote:

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Wed, Nov 25, 2009 at 10:58:29PM +0100, Gerd Hoffmann wrote: (1) ir code (say rc5) - keycode conversion looses information. I think this can easily be addressed by adding a IR event type to the input layer, which could look like this: input_event-type = EV_IR input_event-code =

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote: Dmitry, While lirc is basically a series of input drivers, considering that they have lots in common with the input drivers at V4L/DVB and that we'll need to work on some glue to merge both, do you mind if I add the

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Dmitry Torokhov dmitry.torok...@gmail.com writes: One remote per device only. Why would you want more? One physical device usually corresponds to a logical device. If you have 2 remotes create 2 devices. I meant per receiver device. -- Krzysztof Halasa -- To unsubscribe from this list:

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes: Why do you want to replace everything into a single shot? Why not? It seems simpler to me. We need to change this anyway. If we change the whole table in a single ioctl, we can easily enumerate protocols requested and enable then selectively.

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote: Dmitry Torokhov dmitry.torok...@gmail.com writes: One remote per device only. Why would you want more? One physical device usually corresponds to a logical device. If you have 2 remotes create 2 devices. I meant per

Re: [RFC] Should we create a raw input interface for IR's ?

2009-11-26 Thread Krzysztof Halasa
Dmitry Torokhov dmitry.torok...@gmail.com writes: There are binary sysfs attributes. Aren't they to be used for things like ROMs and EEPROMs exclusively? For ioctl you also need to open and close the device. Sure, but I do it once. Plus, how often do you expect to perform this operation?

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Arnd Bergmann
On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote: Mauro Carvalho Chehab mche...@redhat.com writes: Why do you want to replace everything into a single shot? Why not? It seems simpler to me. We need to change this anyway. ioctls with a variable argument length are a pain for 32

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Dmitry Torokhov dmitry.torok...@gmail.com writes: There is nothing in input layer that precludes you from creating multiple input devices per *whatever*. Of course. I though it was obvious I mean present situation with the media drivers but I can see now it was far from being obvious. --

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Krzysztof Halasa
Trent Piepho xy...@speakeasy.org writes: Then you use the protocol that fits best. For instance decoding with one protocol might produce a scancode that isn't assigned to any key, while another protocol produces an assigned scancode. Clearly then the latter is most likely to be correct.

[IR-RFC PATCH v4 1/6] Minimal changes to the core input system

2009-11-26 Thread Jon Smirl
Minimal changes to the core input system. The bulk of IR support loads as a module. These changes are passive if the rest of IR isn't loaded. Jon Smirl jonsm...@gmail.com --- drivers/input/input.c | 17 + include/linux/input.h | 75

[IR-RFC PATCH v4 6/6] Microsoft mceusb2 driver for in-kernel IR subsystem

2009-11-26 Thread Jon Smirl
USB device commonly found on Microsoft Media Center boxes. Hardware can send and recieve at all common IR frequencies - 36K, 38K, 40K, 56K --- drivers/input/ir/Kconfig |6 drivers/input/ir/Makefile |1 drivers/input/ir/ir-mceusb2.c | 745

[IR-RFC PATCH v4 5/6] Example of PowerPC device tree support for GPT based IR

2009-11-26 Thread Jon Smirl
--- arch/powerpc/boot/dts/dspeak01.dts | 19 --- 1 files changed, 8 insertions(+), 11 deletions(-) diff --git a/arch/powerpc/boot/dts/dspeak01.dts b/arch/powerpc/boot/dts/dspeak01.dts index 429bb2f..50cc247 100644 --- a/arch/powerpc/boot/dts/dspeak01.dts +++

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Mauro Carvalho Chehab
Dmitry Torokhov wrote: On Thu, Nov 26, 2009 at 03:49:13PM -0200, Mauro Carvalho Chehab wrote: Dmitry, While lirc is basically a series of input drivers, considering that they have lots in common with the input drivers at V4L/DVB and that we'll need to work on some glue to merge both, do

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jarod Wilson
On 11/26/2009 06:23 PM, Dmitry Torokhov wrote: On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote: On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: On 11/23/2009 12:37 PM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread hermann pitton
Am Donnerstag, den 26.11.2009, 14:59 -0800 schrieb Trent Piepho: On Thu, 26 Nov 2009, Mauro Carvalho Chehab wrote: See above. Also, several protocols have a way to check if a keystroke were properly received. When handling just one protocol, we can use this to double check the

Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev

2009-11-26 Thread Jarod Wilson
First up, thank you for reposting this. I believe several of us were keeping this code in mind for the in-kernel decoding portion of this discussion, but it hadn't been stated outright in the recent threads here. On 11/26/2009 08:34 PM, Jon Smirl wrote: This is a repost of the LIRC input

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jon Smirl
On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson ja...@wilsonet.com wrote: No, at present we expect 1:1 button-event mapping leaving macro expansion (i.e. KEY_PROG1 -  do some multi-step sequence to userspace). Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow. Bummer.

Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev

2009-11-26 Thread Jon Smirl
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson ja...@wilsonet.com wrote: This part... Not so wild about. The common thought I'm seeing from people is that we should be using setkeycode to load keymaps. I mean, sure, I suppose this could be abstracted away so the user never sees it, but it seems

Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev

2009-11-26 Thread Jon Smirl
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson ja...@wilsonet.com wrote: Raw mode. There are three sysfs attributes - ir_raw, ir_carrier, ir_xmitter. Read from ir_raw to get the raw timing data from the IR device. Set carrier and active xmitters and then copy raw data to ir_raw to send. These

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 09:28:51PM -0500, Jarod Wilson wrote: On 11/26/2009 06:23 PM, Dmitry Torokhov wrote: On Thu, Nov 26, 2009 at 01:16:01AM -0500, Jarod Wilson wrote: On Nov 26, 2009, at 12:31 AM, Dmitry Torokhov wrote: On Mon, Nov 23, 2009 at 11:37:53PM -0500, Jarod Wilson wrote: On

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Dmitry Torokhov
On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote: On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson ja...@wilsonet.com wrote: No, at present we expect 1:1 button-event mapping leaving macro expansion (i.e. KEY_PROG1 -  do some multi-step sequence to userspace). Hm. So ctrl-x,

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Jon Smirl
On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov dmitry.torok...@gmail.com 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

Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev

2009-11-26 Thread Stefan Richter
Jarod Wilson wrote: On 11/26/2009 08:34 PM, Jon Smirl wrote: Raw mode. There are three sysfs attributes - ir_raw, ir_carrier, ir_xmitter. Read from ir_raw to get the raw timing data from the IR device. Set carrier and active xmitters and then copy raw data to ir_raw to send. These attributes

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

2009-11-26 Thread Hans Verkuil
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - radio: add trivial checks on the tuner and type args. Thanks, Hans diffstat: radio-aimslab.c|4 radio-aztech.c |4 radio-gemtek-pci.c |4 radio-maestro.c

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Jon, on 27 Nov 09 at 00:06, Jon Smirl wrote: [...] 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. Can you elaborate on this? I'm not aware of any issue with Sony remotes. Christoph -- To unsubscribe from this

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-11-26 Thread Christoph Bartelmus
Hi Mauro, on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote: Christoph Bartelmus wrote: [...] But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just because I'm not familiar at all with input layer toolset. [...] I hope it helps for you to better understand how this