Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 works. So the plan is to have two ways of using IR in the future which are incompatible to each other, the feature-set of one being a subset of the other? When designing the key mapping in the kernel you should be aware that there are remotes out there that send a sequence of scan codes for some buttons, e.g. http://lirc.sourceforge.net/remotes/pioneer/CU-VSX159 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
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|4 radio-maxiradio.c |4 radio-mr800.c |4 radio-rtrack2.c|4 radio-sf16fmi.c|4 radio-sf16fmr2.c |4 radio-tea5764.c|4 +++- radio-terratec.c |4 radio-trust.c |4 radio-typhoon.c|4 radio-zoltrix.c|4 14 files changed, 55 insertions(+), 1 deletion(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev
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 may be better on a debug switch. You >> would use raw mode when decoding a new protocol. After you figure out >> the new protocol, write an in-kernel encoder/decoder for it. > > Also neglected to recall there was raw IR data access too. However, a > few things... One, this is, in some sense, cheating, as its not an input > layer interface being used. :) Granted though, it *is* an existing > kernel interface being used, instead of adding a new one. Two, there's > no userspace to do anything with it at this time. No; it is a new interface, just using an existing mechanism (sysfs). Not all of sysfs in itself is an interface really; rather there is a number of interfaces which are implemented by means of sysfs. sysfs is primarily meant for simple textual attributes though, not for I/O streams. -- Stefan Richter -=-==--= =-== ==-== http://arcgraph.de/sr/ -- 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 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? -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote: > On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson 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. > > That is scripting. Scripting always needs to be done in user space. > > 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. > > The configfs model is very flexible. You could make a "remote" that > translates the UP/DOWN buttons of several different remotes into > KEY_UP/DOWN. That lets several different remotes control the same > app. > > Sure it is clunky to play with IR hex codes and keycodes in the > configfs mapping dir. If you don't like it write a GUI app for > manipulating the codes. GUI would then generate a script for udev to > run which builds the configfs entries. > > Maybe I should rename those directory entries to "app" instead of > "remote". They contain the mappings from IR hex codes to keycodes that > an app is interested in. Usually there is a 1:1 correspondence between > remote and app but there doesn't have to be. > 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. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 11/23/2009 12:37 PM, Dmitry Torokhov wrote: >> On Mon, Nov 23, 2009 at 03:14:56PM +0100, Krzysztof Halasa wrote: >>> Mauro Carvalho Chehab writes: >>> Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. >>> >>> This can hardly work as the only means, the remotes have different keys, >>> the user almost always has to provide customized key<>function mapping. >>> >> >> Is it true? I would expect the remotes to have most of the keys to have >> well-defined meanings (unless it is one of the programmable remotes)... > > Its the cases like programmable universal remotes that really throw > things for a loop. That, and people wanting to use random remote X that > came with the amp or tv or set top box, with IR receiver Y. Right, but still the keys usually do have the well-defined meaning, >>> >>> Except when they don't. I have two very similar remotes, one that was >>> bundled with a system from CaptiveWorks, and one that was bundled with an >>> Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote >>> having a mouse pad instead of up/down/left/right/enter, they have an >>> identical layout, and the keys in the same locations on the remotes send >>> the same IR signal. But the button names vary a LOT between the two. So on >>> the DVD key on the Antec and the MUTE key on the CW send the same signal. >>> Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that >>> not all IR protocols spell things out particularly well for what a given >>> code should actually mean. >> >> I guess we are talking about different things. While the 2 remotes may >> use different protocols to communicate > > The remotes use the exact same protocol. Their respective bundled > receivers however, do translate key presses differently. Perhaps this is > a bad example though, because both of these remotes came with receivers > that do onboard decoding. But there's nothing stopping me from wanting > to use either of these remotes with an mceusb IR transceiver. > >> and may use the same codes to >> mean different things they buttons have well-defined meaning and we >> could map that to input keycodes. Then what is left is to load the >> proper mapping for particular device into the kernel. > > In this case, its not the device, but the remote, that we need a > different mapping for. I would say that the remote is the device, not the receiver... > >> This can be done >> either automatically (when we know the mapping) or with the help of the >> user (owner of the system). > > Yep, that'd work. Just trying to illustrate that the same code doesn't > always mean anywhere near the same thing from one remote to another. We have the same scenatio with atkbd and various laptops - the "extended" keys may use the same scancodes for different keys and we use DMI data to load the proper keymap. Obviously in case if IRC we won't be using DMI but something else. > teh issue is in mapping raw code to the appropriate keycode. This can be done either by lirc config file (when lirc is used) or by some other means. >>> >>> The desire to map a button press to multiple keystrokes isn't uncommon >>> either, though I presume that's doable within the input layer context too. >> >> 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. > What is Ctrl-x? Alt-tab? This are application-specific binding and of course kernel does not emit these. If there is a distinct action that needs to be signalled then there [normally] is a keycode for it. -- 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: [IR-RFC PATCH v4 0/6] In-kernel IR support using evdev
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson 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 may be better on a debug switch. You >> would use raw mode when decoding a new protocol. After you figure out >> the new protocol, write an in-kernel encoder/decoder for it. > > Also neglected to recall there was raw IR data access too. However, a few > things... One, this is, in some sense, cheating, as its not an input layer > interface being used. :) Granted though, it *is* an existing kernel > interface being used, instead of adding a new one. Two, there's no userspace > to do anything with it at this time. I mean, sure, in theory, writing it > wouldn't be that hard, but we can already do the same thing using the lirc > interface, and already have userspace code for it. I think users need/desire > to use raw IR modes may be more prevalent that most people think. I would view raw mode as a developer interface which would be used to implement a new protocol decode engine. There is an assumption in my design that all IR timings can be decoded/constructed by a protocol engine. Sure we may end up with 40 protocol engines, but they are only about 50 lines of code. You could put each engine into a loadable module if you want. You see raw data used a lot with Sony remotes. Sony remotes mix multiple protocols in a single remote. The irrecord program does not understand these mixed protocols and generates a raw mode config file. The mixed protocols don't bother the protocol state machine system. This happens with other mixed protocol remotes too. > Two drivers are supplied. mceusb2 implements send and receive support >> for the Microsoft USB IR dongle. > > I'd be game to try hacking up the lirc_mceusb driver (which has, since your > work was done, merged mce v1 and v2 transceiver support) to support both > your in-kernel interface and the lirc interface as an example of the hybrid > approach I'm thinking of. > >> Code is only lightly tested. Encoders and decoders have not been >> written for all protocols. Repeat is not handled for any protocol. I'm >> looking for help. There are 15 more existing LIRC drivers. > > And there's the hangup for me. The lirc drivers and interface have been > pretty heavily battle-tested over years and years in the field. And there > are those 15 more drivers that already work with the lirc interface. I'm > woefully short on time to work on any porting myself, and about to get even > shorter with some new responsibilities at work requiring even more of my > attention. > > If we go with a hybrid approach, all those existing drivers can be brought > in supporting just the lirc interface initially, and have in-kernel decode > support added as folks have time to work on them, if it actually makes sense > for those devices. > > Just trying to find a happy middle ground that minimizes regressions for > users *and* gives us maximum flexibility. You are going to have to choose. Recreate the problems of type specific devices like /dev/mouse and /dev/kbd that evdev was created to fix, or skip those type specific devices and go straight to evdev. We've known for years the /dev/mouse was badly broken. How many more years is it going to be before it can be removed? /dev/lirc has the same type of problems that /dev/mouse has. The only reason that /dev/lirc works now is because there is a single app that uses it. Also, implementing a new evdev based system in the kernel in no way breaks existing lirc installations. Just don't load the new implementation and everything works exactly the same way as before. I'd go the evdev only route for in-kernel and leave existing lirc out of tree. Existing lirc will continue to work. This is probably the most stable strategy, even more so than a hybrid approach. The in-kernel implementation will then be free to evolve without the constraint of legacy APIs. As people become happy with it they can switch over. -- 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 0/6] In-kernel IR support using evdev
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson 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 to be > reinventing a way to set up key mapping when setkeycode already exists, and > is used by a number of existing IR devices in the v4l/dvb subsystem (as well > as misc things like the ati rf remotes, iirc). Is there some distinct > advantage to going this route vs. setkeycode that I'm missing? The configfs scheme and keymaps offer the same abilities. One is an ancient binary protocol and the other one uses Unix standard commands like mkdir and echo to build the map. You need special commands - setkeycodes, getkeycodes, showkey, loadkeys, xmodmap, dump-keys to use a keymap. I've been using Linux forever and I can't remember how these commands work. Keymaps are a binary protocol written by Risto Kankkunen in 1993. Configfs was added by Oracle about two years ago but it has not been used for mapping purposes. It's another discussion, but if IR goes the configfs route I'd consider writing a patch to switch keymaps/keycodes onto the configfs model. It is a huge advantage to get rid of these pointless special purpose commands that nobody knows how to use. I'd keep the legacy IOCTLs working and redirect the data structure to a configfs one instead of the existing structure. The same idea is behind getting rid of IOCTLs and using sysfs. Normal Unix commands can manipulate sysfs. IOCTLs have problems with strace, endianess and the size of int (32/64b). -- 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 0/6] In-kernel IR support using evdev
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 patch series I wrote a year ago. Many of the ideas being discussed in the currect "Should we create a raw input interface for IR's?" thread have already been implemented in this code. --- All of this kernel code is tiny, about 20K including a driver. Basic flow works like this: patch: Minimal changes to the core input system Add a new IR data type to the input framework patch: Core IR module In-kernel decoding of core IR protocols - RC5, RC6, etc This only converts from protocol pulse timing to common command format. Check out: http://www.sbprojects.com/knowledge/ir/sirc.htm I think we can definitely take advantage of this for the in-kernel side of the initial hybrid approach I think we're converging on. patch: Configfs support for IR Decoded core protocols pass through a translation map based on configfs When core protocol matches an entry in configfs it is turned into a keycode event. 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 to be reinventing a way to set up key mapping when setkeycode already exists, and is used by a number of existing IR devices in the v4l/dvb subsystem (as well as misc things like the ati rf remotes, iirc). Is there some distinct advantage to going this route vs. setkeycode that I'm missing? patch: Microsoft mceusb2 driver for in-kernel IR subsystem Example mceusb IR input driver Bah. I completely forgot you'd actually did have transmit code too. ... Raw IR pulse data is available in a FIFO via sysfs. You can use this to figure out new remote protocols. Two input events are generated 1) an event for the decoded raw IR protocol 2) a keycode event if the decoded raw IR protocol matches an entry in the configfs You can also send pulses. ... 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 may be better on a debug switch. You would use raw mode when decoding a new protocol. After you figure out the new protocol, write an in-kernel encoder/decoder for it. Also neglected to recall there was raw IR data access too. However, a few things... One, this is, in some sense, cheating, as its not an input layer interface being used. :) Granted though, it *is* an existing kernel interface being used, instead of adding a new one. Two, there's no userspace to do anything with it at this time. I mean, sure, in theory, writing it wouldn't be that hard, but we can already do the same thing using the lirc interface, and already have userspace code for it. I think users need/desire to use raw IR modes may be more prevalent that most people think. Two drivers are supplied. mceusb2 implements send and receive support for the Microsoft USB IR dongle. I'd be game to try hacking up the lirc_mceusb driver (which has, since your work was done, merged mce v1 and v2 transceiver support) to support both your in-kernel interface and the lirc interface as an example of the hybrid approach I'm thinking of. Code is only lightly tested. Encoders and decoders have not been written for all protocols. Repeat is not handled for any protocol. I'm looking for help. There are 15 more existing LIRC drivers. And there's the hangup for me. The lirc drivers and interface have been pretty heavily battle-tested over years and years in the field. And there are those 15 more drivers that already work with the lirc interface. I'm woefully short on time to work on any porting myself, and about to get even shorter with some new responsibilities at work requiring even more of my attention. If we go with a hybrid approach, all those existing drivers can be brought in supporting just the lirc interface initially, and have in-kernel decode support added as folks have time to work on them, if it actually makes sense for those devices. Just trying to find a happy middle ground that minimizes regressions for users *and* gives us maximum flexibility. -- 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 Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson 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. That is scripting. Scripting always needs to be done in user space. 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. The configfs model is very flexible. You could make a "remote" that translates the UP/DOWN buttons of several different remotes into KEY_UP/DOWN. That lets several different remotes control the same app. Sure it is clunky to play with IR hex codes and keycodes in the configfs mapping dir. If you don't like it write a GUI app for manipulating the codes. GUI would then generate a script for udev to run which builds the configfs entries. Maybe I should rename those directory entries to "app" instead of "remote". They contain the mappings from IR hex codes to keycodes that an app is interested in. Usually there is a 1:1 correspondence between remote and app but there doesn't have to be. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 key. However, on a multiprotocol mode, we'll need to disable > > >> this > > >> feature. > > > > > > I don't think so. We can pass the space/mark data to all (configured, > > > i.e. with active mapping) protocol handlers at once. Should a check > > > fail, we ignore the data. Perhaps another protocol will make some sense > > > out of it. > > > > What happens if it succeeds on two protocol handlers? > > 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. It also possible to have a space/mark length > that is within the allowable tolerances for one remote, but is even closer > another remote. You don't want to just find *a* match, you want to find > the *best* match. > > The in kernel code in v4l is very simple in that it is only designed to > work with one procotol and one remote. Once you have multiple remotes of > any type things become much more complicted. Keep in mind that remotes > that aren't even intended to be used with the computer but are used in the > same room will still be received by the receiver. It's not enough to > decode the signals you expect to receive, you must also not get confused by > random signals destined for somewhere else. Giving some random living room these days, likely open to the kids rooms, you have to take that into account. Another point, if decoding from IRQs generated by the remote, there is flawed hardware around, needing to poll IRQs in some timely manner to get it to something at all. This will break such remotes. Never seen? For me the first priority is, that existing remotes are not broken. Don't tell you have done a nice job just now, but are unfortunately in need of testers ... 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 at 03:14:56PM +0100, Krzysztof Halasa wrote: Mauro Carvalho Chehab writes: Event input has the advantage that the keystrokes will provide an unique representation that is independent of the device. This can hardly work as the only means, the remotes have different keys, the user almost always has to provide customized key<>function mapping. Is it true? I would expect the remotes to have most of the keys to have well-defined meanings (unless it is one of the programmable remotes)... Its the cases like programmable universal remotes that really throw things for a loop. That, and people wanting to use random remote X that came with the amp or tv or set top box, with IR receiver Y. Right, but still the keys usually do have the well-defined meaning, Except when they don't. I have two very similar remotes, one that was bundled with a system from CaptiveWorks, and one that was bundled with an Antec Veris IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse pad instead of up/down/left/right/enter, they have an identical layout, and the keys in the same locations on the remotes send the same IR signal. But the button names vary a LOT between the two. So on the DVD key on the Antec and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, TV vs. History, etc. Moral of the story is that not all IR protocols spell things out particularly well for what a given code should actually mean. I guess we are talking about different things. While the 2 remotes may use different protocols to communicate The remotes use the exact same protocol. Their respective bundled receivers however, do translate key presses differently. Perhaps this is a bad example though, because both of these remotes came with receivers that do onboard decoding. But there's nothing stopping me from wanting to use either of these remotes with an mceusb IR transceiver. and may use the same codes to mean different things they buttons have well-defined meaning and we could map that to input keycodes. Then what is left is to load the proper mapping for particular device into the kernel. In this case, its not the device, but the remote, that we need a different mapping for. This can be done either automatically (when we know the mapping) or with the help of the user (owner of the system). Yep, that'd work. Just trying to illustrate that the same code doesn't always mean anywhere near the same thing from one remote to another. teh issue is in mapping raw code to the appropriate keycode. This can be done either by lirc config file (when lirc is used) or by some other means. The desire to map a button press to multiple keystrokes isn't uncommon either, though I presume that's doable within the input layer context too. 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. -- 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
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 you mind if I add the lirc drivers at >> drivers/staging from >> my trees? >> > > Mauro, > > I would not mind if you will be pushing it to staging, however I am not > sure we have an agreement on what exactly the interface that we will be > using. I would hate to get something in that will need to be reworked > again. I understand your concerns. IMHO, we should be really careful with API's when migrating from staging to the right place, but I'm not that much concerned with staging. We already have several drivers there with bad behaviors and even with some API's there that will go to /dev/null. For example there's a V4L2 driver there (staging/go7007) that has their own private API to handle compressed streams. I won't ack moving it from staging while it has their own private extensions for something that are part of V4L2 API. Also, staging drivers without progress for a few kernel cycles will be moved to /dev/null, so I don't see much sense of denying a driver to go there. Anyway, I'll add it there only when you feel comfortable about that and send us your ack. - >From what I heard on the comments, I think we have already a consensus of some >points: 1) all IR's should implement the standard evdev interface; 2) IR's with raw interfaces will implement a raw pulse/space IR interface. The proposal is to use lirc API interface for raw pulse/code TX and RX. Do you think we'll need to better detail the IR raw interface API before accepting the patches for staging? If so, what level of details do you want? 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
[IR-RFC PATCH v4 5/6] Example of PowerPC device tree support for GPT based IR
---
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
+++ b/arch/powerpc/boot/dts/dspeak01.dts
@@ -131,16 +131,6 @@
#gpio-cells = <2>;
};
- gpt7: ti...@670 { /* General Purpose Timer in GPIO mode */
- compatible =
"fsl,mpc5200b-gpt-gpio","fsl,mpc5200-gpt-gpio";
- cell-index = <7>;
- reg = <0x670 0x10>;
- interrupts = <0x1 0x10 0x0>;
- interrupt-parent = <&mpc5200_pic>;
- gpio-controller;
- #gpio-cells = <2>;
- };
-
r...@800 { // Real time clock
compatible = "fsl,mpc5200b-rtc","fsl,mpc5200-rtc";
device_type = "rtc";
@@ -320,6 +310,14 @@
reg = <0x8000 0x4000>;
};
+ i...@670 { /* General Purpose Timer 6 in Input mode */
+ compatible = "gpt-ir";
+ cell-index = <7>;
+ reg = <0x670 0x10>;
+ interrupts = <0x1 0x10 0x0>;
+ interrupt-parent = <&mpc5200_pic>;
+ };
+
/* This is only an example device to show the usage of gpios.
It maps all available
* gpios to the "gpio-provider" device.
*/
@@ -335,7 +333,6 @@
&gpt3 0 0 /* timer3 13d
x6-4 */
&gpt4 0 0 /* timer4 61c
x2-16 */
&gpt6 0 0 /* timer6 60c
x8-15 */
-&gpt7 0 0 /* timer7 36a
x17-9 */
>;
};
};
--
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
[IR-RFC PATCH v4 6/6] Microsoft mceusb2 driver for in-kernel IR subsystem
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 + 3 files changed, 752 insertions(+), 0 deletions(-) create mode 100644 drivers/input/ir/ir-mceusb2.c diff --git a/drivers/input/ir/Kconfig b/drivers/input/ir/Kconfig index 172c0c6..b854900 100644 --- a/drivers/input/ir/Kconfig +++ b/drivers/input/ir/Kconfig @@ -17,5 +17,11 @@ config IR_GPT default m help Driver for GPT-based IR receiver found on Digispeaker + +config IR_MCEUSB2 + tristate "Microsoft Media Center Ed. Receiver, v2" + default m + help + Driver for the Microsoft Media Center Ed. Receiver, v2 endif diff --git a/drivers/input/ir/Makefile b/drivers/input/ir/Makefile index ab0da3f..0bdafb0 100644 --- a/drivers/input/ir/Makefile +++ b/drivers/input/ir/Makefile @@ -8,4 +8,5 @@ ir-objs := ir-core.o ir-configfs.o obj-$(CONFIG_IR_GPT) += ir-gpt.o +obj-$(CONFIG_IR_MCEUSB2) += ir-mceusb2.o diff --git a/drivers/input/ir/ir-mceusb2.c b/drivers/input/ir/ir-mceusb2.c new file mode 100644 index 000..1bc1155 --- /dev/null +++ b/drivers/input/ir/ir-mceusb2.c @@ -0,0 +1,745 @@ +/* + * LIRC driver for Philips eHome USB Infrared Transceiver + * and the Microsoft MCE 2005 Remote Control + * + * (C) by Martin A. Blatter + * + * Transmitter support and reception code cleanup. + * (C) by Daniel Melander + * + * Derived from ATI USB driver by Paul Miller and the original + * MCE USB driver by Dan Corti + * + * This driver will only work reliably with kernel version 2.6.10 + * or higher, probably because of differences in USB device enumeration + * in the kernel code. Device initialization fails most of the time + * with earlier kernel versions. + * + ** + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include +#include + +#define DRIVER_AUTHOR "Daniel Melander , " \ + "Martin Blatter " +#define DRIVER_DESC"Philips eHome USB IR Transceiver and Microsoft " \ + "MCE 2005 Remote Control driver" +#define DRIVER_NAME"ir_mceusb2" + +#define USB_BUFLEN 16 /* USB reception buffer length */ +#define LIRCBUF_SIZE 256 /* LIRC work buffer length */ + +/* MCE constants */ +#define MCE_CMDBUF_SIZE384 /* MCE Command buffer length */ +#define MCE_TIME_BASE 50 /* Approx 50us resolution */ +#define MCE_CODE_LENGTH5 /* Normal length of packet (with header) */ +#define MCE_PACKET_SIZE4 /* Normal length of packet (without header) */ +#define MCE_PACKET_HEADER 0x84 /* Actual header format is 0x80 + num_bytes */ +#define MCE_CONTROL_HEADER 0x9F /* MCE status header */ +#define MCE_TX_HEADER_LENGTH 3 /* # of bytes in the initializing tx header */ +#define MCE_MAX_CHANNELS 2 /* Two transmitters, hardware dependent? */ +#define MCE_DEFAULT_TX_MASK 0x03 /* Val opts: TX1=0x01, TX2=0x02, ALL=0x03 */ +#define MCE_PULSE_BIT 0x80 /* Pulse bit, MSB set == PULSE else SPACE */ +#define MCE_PULSE_MASK 0x7F /* Pulse mask */ +#define MCE_MAX_PULSE_LENGTH 0x7F /* Longest transmittable pulse symbol */ +#define MCE_PACKET_LENGTH_MASK 0x7 /* Packet length */ + + +/* general constants */ +#define SEND_FLAG_IN_PROGRESS 1 +#define SEND_FLAG_COMPLETE 2 +#define RECV_FLAG_IN_PROGRESS 3 +#define RECV_FLAG_COMPLETE 4 + +#define PHILUSB_RECEIVE1 +#define PHILUSB_SEND 2 + +#define VENDOR_PHILIPS 0x0471 +#define VENDOR_SMK 0x0609 +#define VENDOR_TATUNG 0x1460 +#define VENDOR_GATEWAY 0x107b +#define VENDOR_SHUTTLE 0x1308 +#define VENDOR_SHUTTLE20x051c +#define VENDOR_MITSUMI 0x03ee +#define VENDOR_TOPSEED 0x1784 +#define VENDOR_RICAVISION 0x179d +#define VENDOR_ITRON 0x195d +#define VENDOR_FIC 0x1509 +#define VENDOR_LG 0x043e +#define VENDOR_MICROSOFT 0x045e +#define VENDOR_FORMOSA 0x147a +#define VENDOR_FINTEK 0x1934 +#define VENDOR_PINNACLE
[IR-RFC PATCH v4 4/6] GPT driver for in-kernel IR support.
GPT is a GPIO pin that is cable able of measuring the lenght of pulses.
GPTs are common on embedded systems
---
drivers/input/ir/Kconfig |6 +
drivers/input/ir/Makefile |3 +
drivers/input/ir/ir-gpt.c | 184 +
3 files changed, 193 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/ir/ir-gpt.c
diff --git a/drivers/input/ir/Kconfig b/drivers/input/ir/Kconfig
index a6f3f25..172c0c6 100644
--- a/drivers/input/ir/Kconfig
+++ b/drivers/input/ir/Kconfig
@@ -12,4 +12,10 @@ menuconfig INPUT_IR
if INPUT_IR
+config IR_GPT
+ tristate "GPT Based IR Receiver"
+ default m
+ help
+ Driver for GPT-based IR receiver found on Digispeaker
+
endif
diff --git a/drivers/input/ir/Makefile b/drivers/input/ir/Makefile
index 2ccdda3..ab0da3f 100644
--- a/drivers/input/ir/Makefile
+++ b/drivers/input/ir/Makefile
@@ -6,3 +6,6 @@
obj-$(CONFIG_INPUT_IR) += ir.o
ir-objs := ir-core.o ir-configfs.o
+
+obj-$(CONFIG_IR_GPT) += ir-gpt.o
+
diff --git a/drivers/input/ir/ir-gpt.c b/drivers/input/ir/ir-gpt.c
new file mode 100644
index 000..41d2fa6
--- /dev/null
+++ b/drivers/input/ir/ir-gpt.c
@@ -0,0 +1,184 @@
+/*
+ * GPT timer based IR device
+ *
+ * Copyright (C) 2008 Jon Smirl
+ */
+
+#define DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct ir_gpt {
+ struct input_dev *input;
+ int irq, previous;
+ struct mpc52xx_gpt __iomem *regs;
+};
+
+/*
+ * Interrupt handlers
+ */
+static irqreturn_t dpeak_ir_irq(int irq, void *_ir)
+{
+ struct ir_gpt *ir_gpt = _ir;
+ int sample, count, delta, bit, wrap;
+
+ sample = in_be32(&ir_gpt->regs->status);
+ out_be32(&ir_gpt->regs->status, 0xF);
+
+ count = sample >> 16;
+ wrap = (sample >> 12) & 7;
+ bit = (sample >> 8) & 1;
+
+ delta = count - ir_gpt->previous;
+ delta += wrap * 0x1;
+
+ ir_gpt->previous = count;
+
+ if (bit)
+ delta = -delta;
+
+ input_ir_queue(ir_gpt->input, delta);
+
+ return IRQ_HANDLED;
+}
+
+
+/* -
+ * OF platform bus binding code:
+ * - Probe/remove operations
+ * - OF device match table
+ */
+static int __devinit ir_gpt_of_probe(struct of_device *op,
+ const struct of_device_id *match)
+{
+ struct ir_gpt *ir_gpt;
+ struct resource res;
+ int ret, rc;
+
+ dev_dbg(&op->dev, "ir_gpt_of_probe\n");
+
+ /* Allocate and initialize the driver private data */
+ ir_gpt = kzalloc(sizeof *ir_gpt, GFP_KERNEL);
+ if (!ir_gpt)
+ return -ENOMEM;
+
+ ir_gpt->input = input_allocate_device();
+ if (!ir_gpt->input) {
+ ret = -ENOMEM;
+ goto free_mem;
+ }
+ ret = input_ir_create(ir_gpt->input, ir_gpt, NULL);
+ if (ret)
+ goto free_input;
+
+ ir_gpt->input->id.bustype = BUS_HOST;
+ ir_gpt->input->name = "GPT IR Receiver";
+
+ ir_gpt->input->irbit[0] |= BIT_MASK(IR_CAP_RECEIVE_36K);
+ ir_gpt->input->irbit[0] |= BIT_MASK(IR_CAP_RECEIVE_38K);
+ ir_gpt->input->irbit[0] |= BIT_MASK(IR_CAP_RECEIVE_40K);
+ ir_gpt->input->irbit[0] |= BIT_MASK(IR_CAP_RECEIVE_RAW);
+
+ ret = input_register_device(ir_gpt->input);
+ if (ret)
+ goto free_input;
+ ret = input_ir_register(ir_gpt->input);
+ if (ret)
+ goto free_input;
+
+ /* Fetch the registers and IRQ of the GPT */
+ if (of_address_to_resource(op->node, 0, &res)) {
+ dev_err(&op->dev, "Missing reg property\n");
+ ret = -ENODEV;
+ goto free_input;
+ }
+ ir_gpt->regs = ioremap(res.start, 1 + res.end - res.start);
+ if (!ir_gpt->regs) {
+ dev_err(&op->dev, "Could not map registers\n");
+ ret = -ENODEV;
+ goto free_input;
+ }
+ ir_gpt->irq = irq_of_parse_and_map(op->node, 0);
+ if (ir_gpt->irq == NO_IRQ) {
+ ret = -ENODEV;
+ goto free_input;
+ }
+ dev_dbg(&op->dev, "ir_gpt_of_probe irq=%d\n", ir_gpt->irq);
+
+ rc = request_irq(ir_gpt->irq, &dpeak_ir_irq, IRQF_SHARED,
+"gpt-ir", ir_gpt);
+ dev_dbg(&op->dev, "ir_gpt_of_probe request irq rc=%d\n", rc);
+
+ /* set prescale to ? */
+ out_be32(&ir_gpt->regs->count, 0x0087);
+
+ /* Select input capture, enable the counter, and interrupt */
+ out_be32(&ir_gpt->regs->mode, 0x0);
+ out_be32(&ir_gpt->regs->mode, 0x0501);
+
+ /* Save what we've done so it can be found again later */
+ dev_set_drvdata(&op->dev, ir_gpt);
+
+ printk("GPT IR Receiver driver\n");
+
+ return 0;
+
+free_input:
+ input_free_device(ir_gpt->input);
+free_mem:
+ kfree(ir_
[IR-RFC PATCH v4 3/6] Configfs support for IR
Now uses configfs to build mappings from remote buttons to key strokes. When
ir-core loads it creates /config/remotes. Make a directory for each remote you
have; this will cause a new input devices to be created. Inside these
directories make a directory for each key on the remote. In the key directory
attributes fill in the protocol, device, command, keycode. Since this is
configfs all of this can be easily scripted.
Now when a key is pressed on a remote, the configfs directories are searched
for a match on protocol, device, command. If a matches is found, a key stroke
corresponding to keycode is created and sent on the input device that was
created when the directory for the remote was made.
The configfs directories are pretty flexible. You can use them to map multiple
remotes to the same key stroke, or send a single button push to multiple apps.
---
drivers/input/ir/Makefile |2
drivers/input/ir/ir-configfs.c | 348
drivers/input/ir/ir-core.c | 15 +-
3 files changed, 354 insertions(+), 11 deletions(-)
create mode 100644 drivers/input/ir/ir-configfs.c
diff --git a/drivers/input/ir/Makefile b/drivers/input/ir/Makefile
index 6acb665..2ccdda3 100644
--- a/drivers/input/ir/Makefile
+++ b/drivers/input/ir/Makefile
@@ -4,5 +4,5 @@
# Each configuration option enables a list of files.
obj-$(CONFIG_INPUT_IR) += ir.o
-ir-objs := ir-core.o
+ir-objs := ir-core.o ir-configfs.o
diff --git a/drivers/input/ir/ir-configfs.c b/drivers/input/ir/ir-configfs.c
new file mode 100644
index 000..e0819bb
--- /dev/null
+++ b/drivers/input/ir/ir-configfs.c
@@ -0,0 +1,348 @@
+/*
+ * Configfs routines for IR support
+ *
+ * configfs root
+ * --remotes
+ * specific remote
+ * --keymap
+ * protocol
+ * device
+ * command
+ * keycode
+ * --repeat keymaps
+ *
+ * another remote
+ * --more keymaps
+ *
+ *
+ * Copyright (C) 2008 Jon Smirl
+ */
+
+#include
+#include
+#include
+
+#include "ir.h"
+
+struct keymap {
+ struct config_item item;
+ int protocol;
+ int device;
+ int command;
+ int keycode;
+};
+
+static inline struct keymap *to_keymap(struct config_item *item)
+{
+ return item ? container_of(item, struct keymap, item) : NULL;
+}
+
+struct remote {
+ struct config_group group;
+ struct input_dev *input;
+};
+
+static inline struct remote *to_remote(struct config_group *group)
+{
+ return group ? container_of(group, struct remote, group) : NULL;
+}
+
+
+static struct configfs_attribute item_protocol = {
+ .ca_owner = THIS_MODULE,
+ .ca_name = "protocol",
+ .ca_mode = S_IRUGO | S_IWUSR,
+};
+
+static struct configfs_attribute item_device = {
+ .ca_owner = THIS_MODULE,
+ .ca_name = "device",
+ .ca_mode = S_IRUGO | S_IWUSR,
+};
+
+static struct configfs_attribute item_command = {
+ .ca_owner = THIS_MODULE,
+ .ca_name = "command",
+ .ca_mode = S_IRUGO | S_IWUSR,
+};
+
+static struct configfs_attribute item_keycode = {
+ .ca_owner = THIS_MODULE,
+ .ca_name = "keycode",
+ .ca_mode = S_IRUGO | S_IWUSR,
+};
+
+static ssize_t item_show(struct config_item *item,
+ struct configfs_attribute *attr,
+ char *page)
+{
+ struct keymap *keymap = to_keymap(item);
+
+ if (attr == &item_protocol)
+ return sprintf(page, "%d\n", keymap->protocol);
+ if (attr == &item_device)
+ return sprintf(page, "%d\n", keymap->device);
+ if (attr == &item_command)
+ return sprintf(page, "%d\n", keymap->command);
+ return sprintf(page, "%d\n", keymap->keycode);
+}
+
+static ssize_t item_store(struct config_item *item,
+ struct configfs_attribute *attr,
+ const char *page, size_t count)
+{
+ struct keymap *keymap = to_keymap(item);
+ struct remote *remote;
+ unsigned long tmp;
+ char *p = (char *) page;
+
+ tmp = simple_strtoul(p, &p, 10);
+ if (!p || (*p && (*p != '\n')))
+ return -EINVAL;
+
+ if (tmp > INT_MAX)
+ return -ERANGE;
+
+ if (attr == &item_protocol)
+ keymap->protocol = tmp;
+ else if (attr == &item_device)
+ keymap->device = tmp;
+ else if (attr == &item_command)
+ keymap->command = tmp;
+ else {
+ if (tmp < KEY_MAX) {
+ remote = to_remote(to_config_group(item->ci_parent));
+ set_bit(tmp, remote->input->keybit);
+ keymap->keycode = tmp;
+ }
+ }
+ return count;
+}
+
+static void keymap_release(struct config_item *item)
+{
+ struct keymap *keymap = to_keymap(item);
+ struct rem
[IR-RFC PATCH v4 2/6] Core IR module
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.
---
drivers/input/Kconfig |2
drivers/input/Makefile |1
drivers/input/input.c |3
drivers/input/ir/Kconfig | 15 +
drivers/input/ir/Makefile |8
drivers/input/ir/ir-core.c | 735
drivers/input/ir/ir.h | 63
include/linux/input.h |5
8 files changed, 830 insertions(+), 2 deletions(-)
create mode 100644 drivers/input/ir/Kconfig
create mode 100644 drivers/input/ir/Makefile
create mode 100644 drivers/input/ir/ir-core.c
create mode 100644 drivers/input/ir/ir.h
diff --git a/drivers/input/Kconfig b/drivers/input/Kconfig
index 816639c..a1e35ee 100644
--- a/drivers/input/Kconfig
+++ b/drivers/input/Kconfig
@@ -172,6 +172,8 @@ source "drivers/input/touchscreen/Kconfig"
source "drivers/input/misc/Kconfig"
+source "drivers/input/ir/Kconfig"
+
endif
menu "Hardware I/O ports"
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 99e2b5e..fec8972 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_INPUT_JOYSTICK) += joystick/
obj-$(CONFIG_INPUT_TABLET) += tablet/
obj-$(CONFIG_INPUT_TOUCHSCREEN)+= touchscreen/
obj-$(CONFIG_INPUT_MISC) += misc/
+obj-$(CONFIG_INPUT_IR) += ir/
obj-$(CONFIG_INPUT_APMPOWER) += apm-power.o
diff --git a/drivers/input/input.c b/drivers/input/input.c
index a531cf5..2843b84 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -23,6 +23,8 @@
#include
#include
+#include "ir/ir.h"
+
MODULE_AUTHOR("Vojtech Pavlik ");
MODULE_DESCRIPTION("Input core");
MODULE_LICENSE("GPL");
@@ -1167,6 +1169,7 @@ static void input_dev_release(struct device *device)
struct input_dev *dev = to_input_dev(device);
input_ff_destroy(dev);
+ input_ir_destroy(dev);
kfree(dev);
module_put(THIS_MODULE);
diff --git a/drivers/input/ir/Kconfig b/drivers/input/ir/Kconfig
new file mode 100644
index 000..a6f3f25
--- /dev/null
+++ b/drivers/input/ir/Kconfig
@@ -0,0 +1,15 @@
+#
+# LIRC driver(s) configuration
+#
+menuconfig INPUT_IR
+ select CONFIGFS_FS
+ tristate "Infrared Remote (IR) receiver/transmitter drivers"
+ default n
+ help
+ Say Y here, and all supported Infrared Remote Control IR
+ receiver and transmitter drivers will be displayed. The receiver
drivers
+ allow control of your Linux system via remote control.
+
+if INPUT_IR
+
+endif
diff --git a/drivers/input/ir/Makefile b/drivers/input/ir/Makefile
new file mode 100644
index 000..6acb665
--- /dev/null
+++ b/drivers/input/ir/Makefile
@@ -0,0 +1,8 @@
+# Makefile for the ir drivers.
+#
+
+# Each configuration option enables a list of files.
+
+obj-$(CONFIG_INPUT_IR) += ir.o
+ir-objs := ir-core.o
+
diff --git a/drivers/input/ir/ir-core.c b/drivers/input/ir/ir-core.c
new file mode 100644
index 000..85adfcb
--- /dev/null
+++ b/drivers/input/ir/ir-core.c
@@ -0,0 +1,735 @@
+/*
+ * Core routines for IR support
+ *
+ * Copyright (C) 2008 Jon Smirl
+ */
+
+#include
+#include
+#include
+
+#include "ir.h"
+
+void input_ir_translate(struct input_dev *dev, int protocol, int device, int
command)
+{
+ /* generate the IR format event */
+ input_report_ir(dev, IR_PROTOCOL, protocol);
+ input_report_ir(dev, IR_DEVICE, device);
+ input_report_ir(dev, IR_COMMAND, command);
+ input_sync(dev);
+}
+
+static int encode_sony(struct ir_device *ir, struct ir_command *command)
+{
+ /* Sony SIRC IR code */
+ /* http://www.sbprojects.com/knowledge/ir/sirc.htm */
+ int i, bit, dev, cmd, total;
+
+ ir->send.count = 0;
+ switch (command->protocol) {
+ case IR_PROTOCOL_SONY_20:
+ dev = 10; cmd = 10; break;
+ case IR_PROTOCOL_SONY_15:
+ dev = 8; cmd = 7; break;
+ default:
+ case IR_PROTOCOL_SONY_12:
+ dev = 5; cmd = 7; break;
+ }
+ ir->send.buffer[ir->send.count++] = 2400;
+ ir->send.buffer[ir->send.count++] = 600;
+
+ for (i = 0; i < cmd; i++) {
+ bit = command->command & 1;
+ command->command >>= 1;
+ ir->send.buffer[ir->send.count++] = (bit ? 1200 : 600);
+ ir->send.buffer[ir->send.count++] = 600;
+ }
+ for (i = 0; i < dev; i++) {
+ bit = command->device & 1;
+ command->device >>= 1;
+ ir->send.buffer[ir->send.count++] = (bit ? 1200 : 600);
+ ir->send.buffer[ir->send.count++] = 600;
+ }
+ total = 0;
+ for (i = 0; i < ir->send.count; i++)
+ total += ir->send.buffer[i];
+ ir->se
[IR-RFC PATCH v4 1/6] Minimal changes to the core input system
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
---
drivers/input/input.c | 17 +
include/linux/input.h | 75 +++
include/linux/mod_devicetable.h |3 ++
3 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 7c237e6..a531cf5 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -274,6 +274,10 @@ static void input_handle_event(struct input_dev *dev,
case EV_PWR:
disposition = INPUT_PASS_TO_ALL;
break;
+
+ case EV_IR:
+ disposition = INPUT_PASS_TO_ALL;
+ break;
}
if (disposition != INPUT_IGNORE_EVENT && type != EV_SYN)
@@ -727,6 +731,7 @@ static const struct input_device_id
*input_match_device(const struct input_devic
MATCH_BIT(sndbit, SND_MAX);
MATCH_BIT(ffbit, FF_MAX);
MATCH_BIT(swbit, SW_MAX);
+ MATCH_BIT(irbit, IR_MAX);
return id;
}
@@ -849,6 +854,8 @@ static int input_devices_seq_show(struct seq_file *seq,
void *v)
input_seq_print_bitmap(seq, "FF", dev->ffbit, FF_MAX);
if (test_bit(EV_SW, dev->evbit))
input_seq_print_bitmap(seq, "SW", dev->swbit, SW_MAX);
+ if (test_bit(EV_IR, dev->evbit))
+ input_seq_print_bitmap(seq, "IR", dev->irbit, IR_MAX);
seq_putc(seq, '\n');
@@ -1024,6 +1031,8 @@ static int input_print_modalias(char *buf, int size,
struct input_dev *id,
'f', id->ffbit, 0, FF_MAX);
len += input_print_modalias_bits(buf + len, size - len,
'w', id->swbit, 0, SW_MAX);
+ len += input_print_modalias_bits(buf + len, size - len,
+ 'i', id->irbit, 0, IR_MAX);
if (add_cr)
len += snprintf(buf + len, max(size - len, 0), "\n");
@@ -1125,6 +1134,7 @@ INPUT_DEV_CAP_ATTR(LED, led);
INPUT_DEV_CAP_ATTR(SND, snd);
INPUT_DEV_CAP_ATTR(FF, ff);
INPUT_DEV_CAP_ATTR(SW, sw);
+INPUT_DEV_CAP_ATTR(IR, ir);
static struct attribute *input_dev_caps_attrs[] = {
&dev_attr_ev.attr,
@@ -1136,6 +1146,7 @@ static struct attribute *input_dev_caps_attrs[] = {
&dev_attr_snd.attr,
&dev_attr_ff.attr,
&dev_attr_sw.attr,
+ &dev_attr_ir.attr,
NULL
};
@@ -1253,6 +1264,8 @@ static int input_dev_uevent(struct device *device, struct
kobj_uevent_env *env)
INPUT_ADD_HOTPLUG_BM_VAR("FF=", dev->ffbit, FF_MAX);
if (test_bit(EV_SW, dev->evbit))
INPUT_ADD_HOTPLUG_BM_VAR("SW=", dev->swbit, SW_MAX);
+ if (test_bit(EV_IR, dev->evbit))
+ INPUT_ADD_HOTPLUG_BM_VAR("IR=", dev->irbit, IR_MAX);
INPUT_ADD_HOTPLUG_MODALIAS_VAR(dev);
@@ -1371,6 +1384,10 @@ void input_set_capability(struct input_dev *dev,
unsigned int type, unsigned int
__set_bit(code, dev->ffbit);
break;
+ case EV_IR:
+ __set_bit(code, dev->irbit);
+ break;
+
case EV_PWR:
/* do nothing */
break;
diff --git a/include/linux/input.h b/include/linux/input.h
index 8b3bc3e..159a99d 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -80,6 +80,8 @@ struct input_absinfo {
#define EVIOCRMFF _IOW('E', 0x81, int)/*
Erase a force effect */
#define EVIOCGEFFECTS _IOR('E', 0x84, int)/*
Report number of effects playable at the same time */
+#define EVIOIRSEND _IOC(_IOC_WRITE, 'E', 0x80, sizeof(struct
ir_command)) /* send an IR command */
+
#define EVIOCGRAB _IOW('E', 0x90, int)/*
Grab/Release device */
/*
@@ -98,6 +100,7 @@ struct input_absinfo {
#define EV_FF 0x15
#define EV_PWR 0x16
#define EV_FF_STATUS 0x17
+#define EV_IR 0x18
#define EV_MAX 0x1f
#define EV_CNT (EV_MAX+1)
@@ -985,6 +988,56 @@ struct ff_effect {
#define FF_MAX 0x7f
#define FF_CNT (FF_MAX+1)
+/*
+ * IR Support
+ */
+
+#define IR_PROTOCOL_RESERVED 0
+#define IR_PROTOCOL_JVC 1
+#define IR_PROTOCOL_NEC 2
+#define IR_PROTOCOL_NOKIA 3
+#define IR_PROTOCOL_SHARP 4
+#define IR_PROTOCOL_SONY_12 5
+#define IR_PROTOCOL_SONY_15 6
+#define IR_PROTOCOL_SONY_20 7
+#define IR_PROTOCOL_PHILIPS_RC5 8
+#define IR_PROTOCOL_PHILIPS_RC6 9
+#define IR_PROTOCOL_PHILIPS_RCMM 10
+#define IR_PROTOCOL_PHILIPS_RECS80 11
+#define IR_PROTOCOL_RCA 12
+#define IR_PROTOCOL_ITT 13
+
+#define IR_PROTOCOL 1
+#define IR_DEVICE 2
+#define IR_COMMAND 3
+
+#define IR_CAP_RECEIVE_BASEBAND 0
+#define IR_CAP_RECEIVE_36K 1
+#define IR_CAP_RECEIVE_38K 2
+#define IR_CAP_RECEI
[IR-RFC PATCH v4 0/6] In-kernel IR support using evdev
This is a repost of the LIRC input patch series I wrote a year ago. Many of the ideas being discussed in the currect "Should we create a raw input interface for IR's?" thread have already been implemented in this code. --- All of this kernel code is tiny, about 20K including a driver. Basic flow works like this: patch: Minimal changes to the core input system Add a new IR data type to the input framework patch: Core IR module In-kernel decoding of core IR protocols - RC5, RC6, etc This only converts from protocol pulse timing to common command format. Check out: http://www.sbprojects.com/knowledge/ir/sirc.htm patch: Configfs support for IR Decoded core protocols pass through a translation map based on configfs When core protocol matches an entry in configfs it is turned into a keycode event. patch: Microsoft mceusb2 driver for in-kernel IR subsystem Example mceusb IR input driver patch: the other ones are an embedded driver using a GPT pin. You make a directory in /configfs/remotes for each remote you have. Making the directory creates a new evdev device. Under the directory make an entry for each command generated by the device. These entries cause the decoded IR data to be mapped into keycodes on the new evdev device. udev would load these configfs mappings at boot time... mkdir /config/remotes/sony -- this creates a new evdev device mkdir remotes/sony/one echo 7 >remotes/sony/one/protocol echo 264 >remotes/sony/one/command echo 2 >remotes/sony/one/keycode This transforms a button push of 1 on my remote into a key stroke for KEY_1 * configfs root * --remotes * specific remote * --keymap * protocol * device * command * keycode * --repeat keymaps * * another remote * --more keymaps You can map the 1 button from multiple remotes to KEY_1 if you want. Or you can use a single remote to create multiple virtual keyboards. - Raw IR pulse data is available in a FIFO via sysfs. You can use this to figure out new remote protocols. Two input events are generated 1) an event for the decoded raw IR protocol 2) a keycode event if thedecoded raw IR protocol matches an entry in the configfs You can also send pulses. -- If you want to script this, you would have a user space task that watches for either the decoded IR codes or the mapped keycodes. This system also works with user space device drivers. They can inject input events into the early event flow and they will get processed as if the event originated in the kernel. - Sure you could push the protocol decoding code (RC5, etc) into user space. Seems like a lot of hassle to move about 3KB of code out of the kernel. previos comment on the patches... Now when a key is pressed on a remote, the configfs directories are searched for a match on protocol, device, command. If a matches is found, a key stroke corresponding to keycode is created and sent on the input device that was created when the directory for the remote was made. The configfs directories are pretty flexible. You can use them to map multiple remotes to the same key stroke, or send a single button push to multiple apps. To do the mapping it uses configfs (part of the kernel). The main directory is remotes. You use a shell script to build mappings between the IR event and key stroke. mkdir /config/remotes/sony -- this creates a new evdev device mkdir remotes/sony/one echo 7 >remotes/sony/one/procotol echo 264 >remotes/sony/one/command echo 2 >remotes/sony/one/keycode This transforms a button push of 1 on my remote into a key stroke for KEY_1 * configfs root * --remotes * specific remote * --keymap * protocol * device * command * keycode * --repeat keymaps * * another remote * --more keymaps You can map the 1 button from multiple remote to KEY_1 if you want. Or you can use a single remote to create multiple virtual keyboards. >From last release... 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 may be better on a debug switch. You would use raw mode when decoding a new protocol. After you figure out the new protocol, write an in-kernel encoder/decoder for it. The in-kernel code is tiny, about 20K including a driver. >From last post... Note that user space IR device drivers can use the existing support in evdev to inject events into the input queue. Send and receive are implemented. Received IR messages are decoded and sent to user space as input messages. Send is done via an IOCTL on the input device. Two drivers are supplied. mceusb2 implements send and receive support for th
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Trent Piepho 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. Right. > It also possible to have a space/mark length > that is within the allowable tolerances for one remote, but is even closer > another remote. You don't want to just find *a* match, you want to find > the *best* match. That won't work, the decoders don't calculate quality. And even if they did, if you have two remotes generating the same e.g. RC5 code, you won't be able to differentiate between them. Your TV etc. won't do that either. > The in kernel code in v4l is very simple in that it is only designed to > work with one procotol and one remote. Once you have multiple remotes of > any type things become much more complicted. If you're using them at once, sure :-) > Keep in mind that remotes > that aren't even intended to be used with the computer but are used in the > same room will still be received by the receiver. It's not enough to > decode the signals you expect to receive, you must also not get confused by > random signals destined for somewhere else. This is usually not a problem. My experience is the decoding is very reliable. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov 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. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Friday 27 November 2009 00:19:44 Krzysztof Halasa wrote: > Mauro Carvalho Chehab 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 bit emulation and stuff like strace. You either need to encode the variable length into the ioctl cmd, making it variable as well, or use a pointer in the data structure, which requires conversion. Ideally, ioctl arguments have a constant layout, no pointers and are at most 64 bits long. Arnd <>< -- 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 ?
Dmitry Torokhov 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? Don't you think you are trying to optimize something that > does not have any real performavnce impact here? Maybe, anyway it will have to work before it's included in the kernel, so I don't worry too much about it. Perhaps we should then merge the lirc patches so both driver sets can be improved? -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Fri, Nov 27, 2009 at 01:13:51AM +0100, Krzysztof Halasa wrote: > Dmitry Torokhov 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". There is nothing in input layer that precludes you from creating multiple input devices per *whatever*. Please, when you are talking about limitations, specify whether those limitations are applicable to the input layer, the current implementation of IR in DVB or something else. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab 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. But I think it's a minor implementation decision and we don't need to look at it at this time. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov 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: 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 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 lirc drivers at > drivers/staging from > my trees? > Mauro, I would not mind if you will be pushing it to staging, however I am not sure we have an agreement on what exactly the interface that we will be using. I would hate to get something in that will need to be reworked again. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 = IR_RC5 > input_event->value = > > In case the 32bit value is too small we might want send two events > instead, with ->code being set to IR__1 and IR__2 > > Advantages: > * Applications (including lircd) can get access to the unmodified > rc5/rc6/... codes. > * All the ir-code -> keycode mapping magic can be handled by the > core input layer then. All the driver needs to do is to pass on > the information which keymap should be loaded by default (for the > bundled remote if any). The configuration can happen in userspace > (sysfs attribute + udev + small utility in tools/ir/). > * lirc drivers which get ir codes from the hardware can be converted > to pure input layer drivers without regressions. lircd is not > required any more. > I think we need to separate 2 kinds of applications since they have different requirements as far as interface goes: 1. "Reguilar" user-space applications interested in receiving keystrokes from user and reacting to them. Movie players, CD players, MythTV-like applications and so on. Those, to my understanding, are not concerned with the fine details of RC5, RC6, NEC and so forth protocol decoding and just want to know when to start playing, when to stop and when to revind. That class of applications is best served by current input layer since it unifies data coming from IR, keyboards, button devices and so forth. 2. "System" applications that are interested in protocol decoding. Those need interface best suited for IR and nothing else. This protocol is appears is better kept separate from the evdev input protocol. In case where we rely solely on such userspace application(s) to perform protocol decoding we should route input events back to kernel through uinput for consumption by "class 1" applications. We use this approach for PS/2 (serio allows binding either psmouse/atkbd or serio_raw to provide alternate interfaces depending on the users need), USB hid allows raw access as well, maybe we should follow the suit here. -- 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: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
>> 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 from >> 'tzap'. >> >> Kind regards, >> Vince > revert patch attached My problem was also mostly with Channel 9, but other channels also exhibited issues, although less often. Given the original checkin message of http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 was "Both ATSC and DVB @ 6MHz bandwidth require the same offset. While we're fixing it, let's cleanup the bandwidth setup to better reflect the fact that it is a function of the bandwidth." How about the attached patch which reverts e6a8672631a0 and 966ce12c444d but without the "cleanup" which breaks my DViCO. Could people who had the original 6MHz issue please test and report back Thanks -Rob > >> >> >> On 11/26/09, Robert Lowery wrote: 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 screeching audio. I have traced this issue down to http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for DVB @ 6MHz) >>> Actually, in addition to the above changeset, I also had to revert >>> http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T) to >>> get >>> things going. Seems this one might have been an attempt to fix an >>> issue >>> introduced by the latter, but for me both must be reverted. >>> >>> -Rob >>> In this change, the offset used by my card has been changed from 275 to 225. The old code which works used to do something like offset = 275 if (((priv->cur_fw.type & DTV7) && (priv->cur_fw.scode_table & (ZARLINK456 | DIBCOM52))) || ((priv->cur_fw.type & DTV78) && freq < 47000)) offset -= 50; In Australia, (type & DTV7) == true _BUT_ scode_table == 1<<29 == SCODE, so the subtraction is not done. The new code which does not work does if (priv->cur_fw.type & DTV7) offset = 225; which appears to be off by 500khz causing the tuning regression for me. Could any one please advice why this check against scode_table & (ZARLINK456 | DIBCOM52) was removed? Thanks -Rob -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" >>> in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> -- >> 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 >> > revert2.diff Description: /
Re: [RFC] Should we create a raw input interface for IR's ?
On Thu, Nov 26, 2009 at 07:40:01PM +0100, Krzysztof Halasa wrote: > Dmitry Torokhov 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. There are binary sysfs attributes. For ioctl you also need to open and close the device. Plus, how often do you expect to perform this operation? Don't you think you are trying to optimize something that does not have any real performavnce impact here? -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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: > Mauro Carvalho Chehab writes: > > > Event input has the advantage that the keystrokes will provide an unique > > representation that is independent of the device. > > This can hardly work as the only means, the remotes have different keys, > the user almost always has to provide customized key<>function mapping. > > >>> > >>> Is it true? I would expect the remotes to have most of the keys to have > >>> well-defined meanings (unless it is one of the programmable remotes)... > >> > >> Its the cases like programmable universal remotes that really throw > >> things for a loop. That, and people wanting to use random remote X that > >> came with the amp or tv or set top box, with IR receiver Y. > > > > Right, but still the keys usually do have the well-defined meaning, > > Except when they don't. I have two very similar remotes, one that was bundled > with a system from CaptiveWorks, and one that was bundled with an Antec Veris > IR/LCD (SoundGraph iMON rebrand). Outside of the Antec remote having a mouse > pad instead of up/down/left/right/enter, they have an identical layout, and > the keys in the same locations on the remotes send the same IR signal. But > the button names vary a LOT between the two. So on the DVD key on the Antec > and the MUTE key on the CW send the same signal. Same with Audio vs. Eject, > TV vs. History, etc. Moral of the story is that not all IR protocols spell > things out particularly well for what a given code should actually mean. I guess we are talking about different things. While the 2 remotes may use different protocols to communicate and may use the same codes to mean different things they buttons have well-defined meaning and we could map that to input keycodes. Then what is left is to load the proper mapping for particular device into the kernel. This can be done either automatically (when we know the mapping) or with the help of the user (owner of the system). > > > teh > > issue is in mapping raw code to the appropriate keycode. This can be > > done either by lirc config file (when lirc is used) or by some other > > means. > > The desire to map a button press to multiple keystrokes isn't uncommon > either, though I presume that's doable within the input layer context too. No, at present we expect 1:1 button->event mapping leaving macro expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to userspace). -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 10:27:08PM +0100, Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > > > No. All the other API functions there work with 32 bits for scancodes. > > We don't need them, do we? We need a new ioctl for changing key mappings > anyway (a single ioctl for setting the whole table I think), and we can > have arbitrary length of scan codes there. Unless we determine that we 100% need bigger size of scancode then the current ioctls are just fine. Why do we _need_ an ioctl to load the whole tabe? Are you concerned about speed with which the keymap is populated? I don't think it would be an issue. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 07:05:01PM -0200, Mauro Carvalho Chehab wrote:
>
> For example, the two ioctls to replace a scancode x key code are defined as:
>
> #define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /*
> get keycode */
> #define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /*
> set keycode */
>
> We need to better analyze the API to see how this can be extended to
> allow bigger widths.
>
> (what's worse is that it is defined as "int" instead of "u32" - so the number
> of bits is different on 32 and on 64 systems)
>
Not really, int is 32 bits on both, longs the ones that differ.
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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! There's no generation of artificial pulse codes in the drivers. > > The LIRC interface includes ways to pass decoded IR codes of arbitrary > > length to userspace. > > I might have got wrong then a comment in the middle of the > imon_incoming_packet() of the SoundGraph iMON IR patch: > > + /* > + * Translate received data to pulse and space lengths. > + * Received data is active low, i.e. pulses are 0 and > + * spaces are 1. I'm not sure about this specific code, but what is likely going on here is the waveform is being RLE encoding. For example, a cx88 receiver has two ways of being connected (without using an external decoder chip). One generates an IRQ on each edge of the signal. The time between IRQs gives mark/space lengths which is what lirc expects. This is how a simple serial port receiver works too. Another connections effectivly samples the waveform one bit deep at IIRC 4kHz. I think that's what the code you are looking at gets. The code extracts the edges from the waveform and returns the time between them. In effect one is run length encoding a sequence of bits. -- 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 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. > > > > I don't think so. We can pass the space/mark data to all (configured, > > i.e. with active mapping) protocol handlers at once. Should a check > > fail, we ignore the data. Perhaps another protocol will make some sense > > out of it. > > What happens if it succeeds on two protocol handlers? 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. It also possible to have a space/mark length that is within the allowable tolerances for one remote, but is even closer another remote. You don't want to just find *a* match, you want to find the *best* match. The in kernel code in v4l is very simple in that it is only designed to work with one procotol and one remote. Once you have multiple remotes of any type things become much more complicted. Keep in mind that remotes that aren't even intended to be used with the computer but are used in the same room will still be received by the receiver. It's not enough to decode the signals you expect to receive, you must also not get confused by random signals destined for somewhere 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
Re: [cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: OK
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:http://www.linuxtv.org/hg/v4l-dvb > changeset: 13527:b3695bd384cc > gcc version: gcc (GCC) 4.3.1 > hardware:x86_64 > host os: 2.6.26 > > sparse (linux-2.6.31): ERRORS > sparse (linux-2.6.32-rc8): ERRORS > > Detailed results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Thursday.log Hi all, I have enabled the sparse checker again in the daily build. Take a quick look at the log and check the sparse output against your driver code. The 'bad constant expression' and 'cannot size expression' errors seem to be mostly bogus. But most of the others seem to warrant a closer look. I particularly liked this one: v4l/ir-functions.c:68:8: warning: memset with byte count of 0 Someone should fix that one :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Christoph Bartelmus wrote: > 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 generating artificial pulse codes. >>> Nonsense! There's no generation of artificial pulse codes in the drivers. >>> The LIRC interface includes ways to pass decoded IR codes of arbitrary >>> length to userspace. > >> I might have got wrong then a comment in the middle of the >> imon_incoming_packet() of the SoundGraph iMON IR patch: > > Indeed, you got it wrong. > As I already explained before, this device samples the signal at a > constant rate and delivers the current level in a bit-array. This data is > then condensed to pulse/space data. Ah, ok. It is now clear to me. IMHO, it would be better to explain this at the source code, since the imon_incoming_packet() is a little complex. It would help the review process if those big routines could be broken into a few functions. While this improves code readability, it shouldn't affect performance, as gcc will handle the static functions used only once as inline. > Christoph 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: > Mauro Carvalho Chehab writes: > >> No. All the other API functions there work with 32 bits for scancodes. > > We don't need them, do we? We need a new ioctl for changing key mappings > anyway (a single ioctl for setting the whole table I think), and we can > have arbitrary length of scan codes there. Why do you want to replace everything into a single shot? Had you ever tried to replace a scancode table with the current API? $ wc ./keycodes/dib0700_rc_keys 216 432 3541 ./keycodes/dib0700_rc_keys This is the biggest table we have: 216 scancodes. It has codes for several different IR's bound together into the same table. Let's replace the entire table (tested on a dib8076 reference design device): $ time ./keytable ./keycodes/dib0700_rc_keys real0m0.029s user0m0.000s sys 0m0.027s Don't you think that 29ms to replace 216 codes to be fast enough, especially since you only need to do it once after plugging a device? Also, if you want to control your device with two different IR controllers, the better is to allow adding new keycodes there, instead of just allowing the replacement of the entire table. Maybe we'll need some extensions there, for example to extend the size of the dynamic table, but I don't see any timing issue here. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 generating artificial >>> pulse codes. >> >> Nonsense! There's no generation of artificial pulse codes in the drivers. >> The LIRC interface includes ways to pass decoded IR codes of arbitrary >> length to userspace. > I might have got wrong then a comment in the middle of the > imon_incoming_packet() of the SoundGraph iMON IR patch: Indeed, you got it wrong. As I already explained before, this device samples the signal at a constant rate and delivers the current level in a bit-array. This data is then condensed to pulse/space data. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Nov 26, 2009, at 9:46 AM, Krzysztof Halasa wrote: Dmitry Torokhov 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 have more than 256 keycodes already _defined_ in the input core and we can add more if needed. 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. The protocol itself doesn't have the above limitations, but has others, with are acceptable for key input. -- Krzysztof Halasa -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4 v9] TVP7002 driver for DM365
On Thursday 26 November 2009 21:04:25 santiago.nu...@ridgerun.com wrote:
> From: Santiago Nunez-Corrales
>
> 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 behaviour.
Now, that cleans it up nicely! I thought that was fishy :-)
>
> Signed-off-by: Santiago Nunez-Corrales
> ---
> drivers/media/video/tvp7002.c | 1262
> +
> 1 files changed, 1262 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/tvp7002.c
>
> diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
> new file mode 100644
> index 000..1a5b767
> --- /dev/null
> +++ b/drivers/media/video/tvp7002.c
> @@ -0,0 +1,1262 @@
> +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
> + * Digitizer with Horizontal PLL registers
> + *
> + * Copyright (C) 2009 Texas Instruments Inc
> + * Author: Santiago Nunez-Corrales
> + *
> + * This code is partially based upon the TVP5150 driver
> + * written by Mauro Carvalho Chehab (mche...@infradead.org),
> + * the TVP514x driver written by Vaibhav Hiremath
> + * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
> + * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "tvp7002_reg.h"
> +
> +MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer driver");
> +MODULE_AUTHOR("Santiago Nunez-Corrales ");
> +MODULE_LICENSE("GPL");
> +
> +/* Module Name */
> +#define TVP7002_MODULE_NAME "tvp7002"
> +
> +/* I2C retry attempts */
> +#define I2C_RETRY_COUNT (5)
> +
> +/* End of registers */
> +#define TVP7002_EOR 0x5c
> +
> +/* Read write definition for registers */
> +#define TVP7002_READ 0
> +#define TVP7002_WRITE1
> +#define TVP7002_RESERVED 2
> +
> +/* Indexes for digital video presets */
> +#define INDEX_720P60 0
> +#define INDEX_1080I601
> +#define INDEX_1080I502
> +#define INDEX_720P50 3
> +#define INDEX_1080P604
> +#define INDEX_480P59_94 5
> +#define INDEX_576P50 6
> +
> +/* Interlaced vs progressive mask and shift */
> +#define TVP7002_IP_SHIFT 5
> +#define TVP7002_INPR_MASK(0x01 << TVP7002_IP_SHIFT)
> +
> +/* Shift for CPL and LPF registers */
> +#define TVP7002_CL_SHIFT 8
> +#define TVP7002_CL_MASK 0x0f
> +
> +/* Debug functions */
> +static int debug;
> +module_param(debug, bool, 0644);
> +MODULE_PARM_DESC(debug, "Debug level (0-2)");
> +
> +/* Structure for register values */
> +struct i2c_reg_value {
> + u8 reg;
> + u8 value;
> + u8 type;
> +};
> +
> +/*
> + * Register default values (according to tvp7002 datasheet)
> + * In the case of read-only registers, the value (0xff) is
> + * never written. R/W functionality is controlled by the
> + * writable bit in the register struct definition.
> + */
> +static const struct i2c_reg_value tvp7002_init_default[] = {
> + { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
> + { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
> + { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
> + { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
> + { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
> + { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
> + { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
> + { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
> + { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
> + { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
> + { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
> + { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
> + { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
> + { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
> + { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
> + { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
> + { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
> + { TVP7002_SYNC_SEPARATOR_THRS,
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: OK
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 (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: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> The removal of the existing keymaps from kernel depends on having an
>> application
>> to be called from udev to load the proper keymaps when a device is probed.
>>
>> After having it for a while, we should deprecate the in-kernel keymaps
>> and move them to userspace.
>
> Sounds like a plan.
>
>> I also think that it is important to remove the 7 bits limitation from
>> all drivers
>> and re-generate the keymaps, since they'll change after it.
>
> I think the existing space/mark media drivers need to be reworked
> completely.
Nah. the changes aren't big. The first part of the change were already done
for 2.6.32: instead of having a vector of 128 elements, where the element order
used to be the masked scancode, we now have a table of scancode x keycode,
defined
as:
struct ir_scancode {
u16 scancode;
u32 keycode;
};
Changing scancode to u32 is as easy as edit a file - it is currently 16 just
because
all currently supported IR's and protocols have 16 bits only - there's no
in-kernel
implementation for RC6 mode 6 yet. However, increasing it above to 64 bits will
break on
32 bits kernels (and above 64 bits, on all architectures), due to the current
API limits.
this change is currently limited to the ir keytables, but I have a patch
already done
extending this change for the drivers to work directly with the new table.
The next step is to replace the ir->mask_keycode at the drivers to a value that
gets the entire scancode. We may still need a mask there, since not all drivers
output
a 32 bits scancode.
Also, there's no single "space/mark" media driver. All drivers that support
pulse/space also support in-hardware IR decoding, in order to support the
different types of devices. They generally support several ways to get keys:
- serial pulse/space decoding on one GPIO pin (most pci hardware have);
- serial pulse/space decoding via a IRQ enabled GPIO pin (several
saa7134 IR's use this way);
- i2c IR's (common on several popular devices);
- parallel scancode output via gpio pins several cx88 IR's use this
way);
- direct IR hardware decoding done by the video chipset
(DibCom and newer em28xx hardware, for example).
So, the driver input complexity is needed to support all those different ways.
So, rewriting it would likely cause regressions.
I agree that there are some cleanups that should be done for the serial
pulse/space raw
decoding. By adding a lirc interface, we'll need to have a common code for
handling
those events anyway.
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab writes: > No. All the other API functions there work with 32 bits for scancodes. We don't need them, do we? We need a new ioctl for changing key mappings anyway (a single ioctl for setting the whole table I think), and we can have arbitrary length of scan codes there. > (what's worse is that it is defined as "int" instead of "u32" - so the number > of bits is different on 32 and on 64 systems) Most (all?) 64-bit systems use 32-bit ints (and 64-bit longs). u32 and similar are for sure better. >> We signal both and hope it isn't self-destruct button. >> We can't fix it no matter how hard we try. > > We can fix. Just let the userspace select what protocol(s) is(are) enabled. Sure, I meant the situation when both protocols (and scan codes) where enabled and configured. If we don't use RCx in the mapping table, we don't pass anything to RCx routine. If we have RCx but don't have the scan code in question, we don't find the key in the table and thus we ignore it again. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab writes:
>
>> see include/linux/input.h:
>>
>> struct input_event {
>> struct timeval time;
>> __u16 type;
>> __u16 code;
>> __s32 value;
>> };
>>
>> extending the value to more than 32 bits require some changes at the
>> input layer, probably breaking kernel API.
>
> Yeah, but that's a "key" space, not "raw code" space.
> Keys via input and raw codes via lirc and there is no problem.
No. All the other API functions there work with 32 bits for scancodes.
For example, the two ioctls to replace a scancode x key code are defined as:
#define EVIOCGKEYCODE _IOR('E', 0x04, int[2]) /* get
keycode */
#define EVIOCSKEYCODE _IOW('E', 0x04, int[2]) /* set
keycode */
We need to better analyze the API to see how this can be extended to
allow bigger widths.
(what's worse is that it is defined as "int" instead of "u32" - so the number
of bits is different on 32 and on 64 systems)
> The mapping tables for input layer need to have variable code widths,
> depending on the protocol, sure.
>
>>> I don't think so. We can pass the space/mark data to all (configured,
>>> i.e. with active mapping) protocol handlers at once. Should a check
>>> fail, we ignore the data. Perhaps another protocol will make some sense
>>> out of it.
>> What happens if it succeeds on two protocol handlers?
>
> We signal both and hope it isn't self-destruct button.
> We can't fix it no matter how hard we try.
We can fix. Just let the userspace select what protocol(s) is(are) enabled.
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 generating artificial >> pulse codes. > > Nonsense! There's no generation of artificial pulse codes in the drivers. > The LIRC interface includes ways to pass decoded IR codes of arbitrary > length to userspace. I might have got wrong then a comment in the middle of the imon_incoming_packet() of the SoundGraph iMON IR patch: + /* +* Translate received data to pulse and space lengths. +* Received data is active low, i.e. pulses are 0 and +* spaces are 1. +* +* My original algorithm was essentially similar to +* Changwoo Ryu's with the exception that he switched +* the incoming bits to active high and also fed an +* initial space to LIRC at the start of a new sequence +* if the previous bit was a pulse. +* +* I've decided to adopt his algorithm. +*/ 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 codes. Nonsense! There's no generation of artificial pulse codes in the drivers. The LIRC interface includes ways to pass decoded IR codes of arbitrary length to userspace. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab writes:
> see include/linux/input.h:
>
> struct input_event {
> struct timeval time;
> __u16 type;
> __u16 code;
> __s32 value;
> };
>
> extending the value to more than 32 bits require some changes at the
> input layer, probably breaking kernel API.
Yeah, but that's a "key" space, not "raw code" space.
Keys via input and raw codes via lirc and there is no problem.
The mapping tables for input layer need to have variable code widths,
depending on the protocol, sure.
>> I don't think so. We can pass the space/mark data to all (configured,
>> i.e. with active mapping) protocol handlers at once. Should a check
>> fail, we ignore the data. Perhaps another protocol will make some sense
>> out of it.
>
> What happens if it succeeds on two protocol handlers?
We signal both and hope it isn't self-destruct button.
We can't fix it no matter how hard we try.
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab writes: > The removal of the existing keymaps from kernel depends on having an > application > to be called from udev to load the proper keymaps when a device is probed. > > After having it for a while, we should deprecate the in-kernel keymaps > and move them to userspace. Sounds like a plan. > I also think that it is important to remove the 7 bits limitation from > all drivers > and re-generate the keymaps, since they'll change after it. I think the existing space/mark media drivers need to be reworked completely. -- 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
[PATCH 4/4 v9] Menu support for TVP7002 in DM365
From: Santiago Nunez-Corrales This patch provides menu configuration options for the TVP7002 decoder driver in DM365. Signed-off-by: Santiago Nunez-Corrales --- drivers/media/video/Kconfig | 41 + drivers/media/video/Makefile |3 +++ 2 files changed, 44 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index e6186b3..de3328b 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -392,6 +392,15 @@ config VIDEO_TVP5150 To compile this driver as a module, choose M here: the module will be called tvp5150. +config VIDEO_TVP7002 + tristate "Texas Instruments TVP7002 video decoder" + depends on VIDEO_V4L2 && I2C + ---help--- + Support for the Texas Instruments TVP7002 video decoder. + + To compile this driver as a module, choose M here: the + module will be called tvp7002. + config VIDEO_VPX3220 tristate "vpx3220a, vpx3216b & vpx3214c video decoders" depends on VIDEO_V4L2 && I2C @@ -466,6 +475,29 @@ config VIDEO_THS7303 To compile this driver as a module, choose M here: the module will be called ths7303. +config VIDEO_THS7353 + tristate "THS7353 Video Amplifier" + depends on I2C + help + Support for TI THS7353 video amplifier + + To compile this driver as a module, choose M here: the + module will be called ths7353. + +config VIDEO_THS7353_LUMA_CHANNEL + int "THS7353 channel number for Luma Input" + default 3 + depends on VIDEO_THS7353 + help + Select the luma channel number for the THS7353 input. + + THS7353 has three identical channels. For the component + interface, luma input will be connected to one of these + channels and cb and cr will be connected to other channels + This config option is used to select the luma input channel + number. Possible values for this option are 1,2 or 3. Any + other value will result in value 2. + config VIDEO_ADV7343 tristate "ADV7343 video encoder" depends on I2C @@ -475,6 +507,15 @@ config VIDEO_ADV7343 To compile this driver as a module, choose M here: the module will be called adv7343. +config VIDEO_THS8200 + tristate "THS8200 video encoder" + depends on I2C + help + Support for Analog Devices I2C bus based THS8200 encoder. + + To compile this driver as a module, choose M here: the + module will be called ths8200. + comment "Video improvement chips" config VIDEO_UPD64031A diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index e541932..5327ff4 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -47,15 +47,18 @@ obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o +obj-$(CONFIG_VIDEO_THS8200) += ths8200.o obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o obj-$(CONFIG_VIDEO_BT819) += bt819.o obj-$(CONFIG_VIDEO_BT856) += bt856.o obj-$(CONFIG_VIDEO_BT866) += bt866.o obj-$(CONFIG_VIDEO_KS0127) += ks0127.o obj-$(CONFIG_VIDEO_THS7303) += ths7303.o +obj-$(CONFIG_VIDEO_THS7353) += ths7353.o obj-$(CONFIG_VIDEO_VINO) += indycam.o obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o +obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o obj-$(CONFIG_VIDEO_CS5345) += cs5345.o obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o -- 1.6.0.4 -- 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 3/4 v9] TVP7002 driver for DM365
From: Santiago Nunez-Corrales
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 behaviour.
Signed-off-by: Santiago Nunez-Corrales
---
drivers/media/video/tvp7002.c | 1262 +
1 files changed, 1262 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/tvp7002.c
diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..1a5b767
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1262 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include "tvp7002_reg.h"
+
+MODULE_DESCRIPTION("TI TVP7002 Video and Graphics Digitizer driver");
+MODULE_AUTHOR("Santiago Nunez-Corrales ");
+MODULE_LICENSE("GPL");
+
+/* Module Name */
+#define TVP7002_MODULE_NAME"tvp7002"
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* End of registers */
+#define TVP7002_EOR0x5c
+
+/* Read write definition for registers */
+#define TVP7002_READ 0
+#define TVP7002_WRITE 1
+#define TVP7002_RESERVED 2
+
+/* Indexes for digital video presets */
+#define INDEX_720P60 0
+#define INDEX_1080I60 1
+#define INDEX_1080I50 2
+#define INDEX_720P50 3
+#define INDEX_1080P60 4
+#define INDEX_480P59_945
+#define INDEX_576P50 6
+
+/* Interlaced vs progressive mask and shift */
+#define TVP7002_IP_SHIFT 5
+#define TVP7002_INPR_MASK (0x01 << TVP7002_IP_SHIFT)
+
+/* Shift for CPL and LPF registers */
+#define TVP7002_CL_SHIFT 8
+#define TVP7002_CL_MASK0x0f
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, "Debug level (0-2)");
+
+/* Structure for register values */
+struct i2c_reg_value {
+ u8 reg;
+ u8 value;
+ u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+ { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+ { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
+ { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
+ { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
+ { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
+ { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
+ { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
+ { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
+ { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
+ { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+ { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
+ { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
+ { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
+ { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
+ { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
+ { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
+ { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
+ { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
+ { TVP7002_MISC_CTL_2, 0x00, TV
[PATCH 2/4 v9] Definitions for TVP7002 in DM365
From: Santiago Nunez-Corrales This patch provides the required definitions for the TVP7002 driver in DM365. Signed-off-by: Santiago Nunez-Corrales --- drivers/media/video/tvp7002_reg.h | 150 + include/media/tvp7002.h | 57 ++ 2 files changed, 207 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/tvp7002_reg.h create mode 100644 include/media/tvp7002.h diff --git a/drivers/media/video/tvp7002_reg.h b/drivers/media/video/tvp7002_reg.h new file mode 100644 index 000..0e34ca9 --- /dev/null +++ b/drivers/media/video/tvp7002_reg.h @@ -0,0 +1,150 @@ +/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics + * Digitizer with Horizontal PLL registers + * + * Copyright (C) 2009 Texas Instruments Inc + * Author: Santiago Nunez-Corrales + * + * This code is partially based upon the TVP5150 driver + * written by Mauro Carvalho Chehab (mche...@infradead.org), + * the TVP514x driver written by Vaibhav Hiremath + * and the TVP7002 driver in the TI LSP 2.10.00.14 + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +/* Naming conventions + * -- + * + * FDBK: Feedback + * DIV: Divider + * CTL: Control + * SEL: Select + * IN:Input + * OUT: Output + * R: Red + * G: Green + * B: Blue + * OFF: Offset + * THRS: Threshold + * DGTL: Digital + * LVL: Level + * PWR: Power + * MVIS: Macrovision + * W: Width + * H: Height + * ALGN: Alignment + * CLK: Clocks + * TOL: Tolerance + * BWTH: Bandwidth + * COEF: Coefficient + * STAT: Status + * AUTO: Automatic + * FLD: Field + * L:Line + */ + +#define TVP7002_CHIP_REV 0x00 +#define TVP7002_HPLL_FDBK_DIV_MSBS 0x01 +#define TVP7002_HPLL_FDBK_DIV_LSBS 0x02 +#define TVP7002_HPLL_CRTL 0x03 +#define TVP7002_HPLL_PHASE_SEL 0x04 +#define TVP7002_CLAMP_START0x05 +#define TVP7002_CLAMP_W0x06 +#define TVP7002_HSYNC_OUT_W0x07 +#define TVP7002_B_FINE_GAIN0x08 +#define TVP7002_G_FINE_GAIN0x09 +#define TVP7002_R_FINE_GAIN0x0a +#define TVP7002_B_FINE_OFF_MSBS0x0b +#define TVP7002_G_FINE_OFF_MSBS 0x0c +#define TVP7002_R_FINE_OFF_MSBS 0x0d +#define TVP7002_SYNC_CTL_1 0x0e +#define TVP7002_HPLL_AND_CLAMP_CTL 0x0f +#define TVP7002_SYNC_ON_G_THRS 0x10 +#define TVP7002_SYNC_SEPARATOR_THRS0x11 +#define TVP7002_HPLL_PRE_COAST 0x12 +#define TVP7002_HPLL_POST_COAST0x13 +#define TVP7002_SYNC_DETECT_STAT 0x14 +#define TVP7002_OUT_FORMATTER 0x15 +#define TVP7002_MISC_CTL_1 0x16 +#define TVP7002_MISC_CTL_2 0x17 +#define TVP7002_MISC_CTL_3 0x18 +#define TVP7002_IN_MUX_SEL_1 0x19 +#define TVP7002_IN_MUX_SEL_20x1a +#define TVP7002_B_AND_G_COARSE_GAIN0x1b +#define TVP7002_R_COARSE_GAIN 0x1c +#define TVP7002_FINE_OFF_LSBS 0x1d +#define TVP7002_B_COARSE_OFF 0x1e +#define TVP7002_G_COARSE_OFF0x1f +#define TVP7002_R_COARSE_OFF0x20 +#define TVP7002_HSOUT_OUT_START0x21 +#define TVP7002_MISC_CTL_4 0x22 +#define TVP7002_B_DGTL_ALC_OUT_LSBS0x23 +#define TVP7002_G_DGTL_ALC_OUT_LSBS 0x24 +#define TVP7002_R_DGTL_ALC_OUT_LSBS 0x25 +#define TVP7002_AUTO_LVL_CTL_ENABLE0x26 +#define TVP7002_DGTL_ALC_OUT_MSBS 0x27 +#define TVP7002_AUTO_LVL_CTL_FILTER0x28 +/* Reserved 0x29*/ +#define TVP7002_FINE_CLAMP_CTL 0x2a +#define TVP7002_PWR_CTL0x2b +#define TVP7002_ADC_SETUP 0x2c +#define TVP7002_COARSE_CLAMP_CTL 0x2d +#define TVP7002_SOG_CLAMP 0x2e +#define TVP7002_RGB_COARSE_CLAMP_CTL 0x2f +#define TVP7002_SOG_COARSE_CLAMP_CTL 0x30 +#define TVP7002_ALC_PLACEMENT 0x31 +/* Reserved 0x32 */ +/* Reserved 0x33 */ +#define TVP7002_MVIS_STRIPPER_W0x34 +#define TVP7002_VSYNC_ALGN 0x35 +#define TVP7002_SYNC_BYPASS0x36 +#define TVP7002_L_FRAME_STAT_LSBS 0x37 +#define TVP7002_L_FRAME_STAT_MSBS 0x38 +#define TVP7002_CLK_L_STAT_LSBS0x39 +#define TVP7002_CLK_L_STAT_MSBS0x3a +#define TVP7002_H
[PATCH 0/4 v9] Support for TVP7002 in DM365
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, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P with video capture application and video output in 480P, 576P, 720P and 1080I. This driver depends upon board-dm365-evm.c and vpfe_capture.c to be ready for complete integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri. Removed shadow register values. Removed unnecesary power down and up of the device (tests work fine). BTW, happy thanksgivings! -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4 v9] Support for TVP7002 in v4l2 definitions
From: Santiago Nunez-Corrales
This patch provides required chip identification definitions
within v4l2.
Signed-off-by: Santiago Nunez-Corrales
---
include/media/v4l2-chip-ident.h |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-chip-ident.h b/include/media/v4l2-chip-ident.h
index cf16689..b4b874f 100644
--- a/include/media/v4l2-chip-ident.h
+++ b/include/media/v4l2-chip-ident.h
@@ -129,6 +129,9 @@ enum {
V4L2_IDENT_SAA6752HS = 6752,
V4L2_IDENT_SAA6752HS_AC3 = 6753,
+ /* module tvp7002: just ident 7002 */
+ V4L2_IDENT_TVP7002 = 7002,
+
/* module adv7170: just ident 7170 */
V4L2_IDENT_ADV7170 = 7170,
@@ -150,6 +153,12 @@ enum {
/* module adv7343: just ident 7343 */
V4L2_IDENT_ADV7343 = 7343,
+ /* module ths7353: just ident 7353 */
+ V4L2_IDENT_THS7353 = 7353,
+
+ /* module ths8200: just ident 8200 */
+ V4L2_IDENT_THS8200 = 8200,
+
/* module wm8739: just ident 8739 */
V4L2_IDENT_WM8739 = 8739,
--
1.6.0.4
--
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 0/4 v8] Support for TVP7002 in DM365
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, Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves testing problems. Tested on DM365 TI EVM with resolutions 720p, 10...@60, 576P and 480P with video capture application and video output in 480P, 576P, 720P and 1080I. This driver depends upon board-dm365-evm.c and vpfe_capture.c to be ready for complete integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri. Removed shadow register values. Removed unnecesary power down and up of the device (tests work fine). BTW, happy thanksgivings! -- Santiago Nunez-Corrales, Eng. RidgeRun Engineering, LLC Guayabos, Curridabat San Jose, Costa Rica +(506) 2271 1487 +(506) 8313 0536 http://www.ridgerun.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
[cron job] v4l-dvb daily build 2.6.22 and up: WARNINGS, 2.6.16-2.6.21: ERRORS
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 (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: WARNINGS 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: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc8-i686: WARNINGS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-rc8-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-rc8-mips: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-rc8-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS 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: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc8-x86_64: WARNINGS spec: OK sparse (linux-2.6.31): ERRORS sparse (linux-2.6.32-rc8): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote: > Krzysztof Halasa wrote: > > Andy Walls 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 some countries but from the > > technical POV handling the protocol in the kernel is more efficient > > or (/and) simpler. > > A software licensing from Microsoft won't apply to Linux kernel, so I'm > assuming that you're referring to some patent that they could be filled > about RC6 mode 6A. > > I don't know if is there any US patent pending about it (AFAIK, only US > accepts software patents), but there are some prior-art for IR key > decoding. So, I don't see what "innovation" RC6 would be adding. > If it is some new way to transmit waves, the patent issues > aren't related to software, and the device manufacturer had already handled > it when they made their devices. > > If it is just a new keytable, this issue > could be easily solved by loading the keytable via userspace. > > Also, assuming that you can use the driver only with a hardware that comes > with a licensed software, the user has already the license for using it. > > Do you have any details on what patents they are claiming? The US Philips RC-6 patent is US Patent 5,877,702 http://www.google.com/patents?vid=USPAT5877702 Click on download PDF to get a copy of the whole patent. I am not a lawyer. Philips claims' all appear to tie to a transmitter or receiver as part of a system, but most of the claims are about information and bit positions and lengths. I don't know for sure what Microsoft claims to be licensing. I think it is the protocol itself: http://www.microsoft.com/presspass/Press/2002/Apr02/04-16FreestylePhilipsPR.mspx "Under the terms of the agreement, Microsoft and Philips will license to OEMs an IR protocol based on Philips proprietary RC6 IR technology. The patented and globally adopted solution minimizes interference from other remote-control devices in the household. Use of this established protocol will help ensure uniform development of Windows infrared remote-control products, which include infrared remote-control units and remote-control receivers..." http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWEN05007_WinHEC05.ppt See Slide 5, which has the bullet: "How to License RC6" Since the content of the information field in RC-6 Mode 6A is left up to OEMs, I would not be surprised by bogus "innovations" in OEM patents about RC-6 Mode 6A contents. I would not be at all surprised by something like "a bit to indicate a toggled remote key press in the information field" since RC-6's T bits for mode 6 indicate Mode 6A or Mode 6B and not toggles. IMO, given a. the dearth of public information about RC-6, indicating someone thinks it's their trade secret or intellectual property b. Microsoft claiming to license something related to the MCE remote protocols (which are obviously RC-6 Mode 6A), c. my inability to draw a "clear, bright line" that RC-6 Mode 6A encoding and decoding, as needed by MCE remotes, implemented in software doesn't violate anyone's government granted rights to exclusivity. I think it's much better to implement software RC-6 Mode 6A encoding and decoding in user space, doing only the minimum needed to get the hardware setup and going in the kernel. Encoding/decoding of RC-6 by microcontrollers with firmware doesn't worry me. Maybe I'm being too conservative here, but I have a personal interest in keeping Linux free and unencumbered even in the US which, I cannot deny, has a patent system that is screwed up. Regards, Andy > 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote:
> Mauro Carvalho Chehab 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 mapping should be: key = proto + group + raw code, while
>>> key2 could be different_proto + different group (if any) + another code.
>> This may work for protocols up to RC5, that uses either 8 or 16 bits.
>> However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits
>> for a scancode. So, we don't have spare bits to represent a protocol,
>> if we consider RC6 mode 6 codes as well.
>
> I don't see this limitation. The number of bits should depend on the
> protocol.
see include/linux/input.h:
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
extending the value to more than 32 bits require some changes at the input
layer,
probably breaking kernel API.
>
>> 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.
>
> I don't think so. We can pass the space/mark data to all (configured,
> i.e. with active mapping) protocol handlers at once. Should a check
> fail, we ignore the data. Perhaps another protocol will make some sense
> out of it.
What happens if it succeeds on two protocol handlers?
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: > Mauro Carvalho Chehab 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 causing regressions, and to >> find a group of people that will help testing the new way. > > We don't want to "port it" to other drivers. We need to have a common > module which does all RCx decoding. The individual drivers should be as > simple as possible, something that I outlined in a previous mail. With the current 7bits mask applied to almost all devices, it is probably not very useful for those who want to use generic IRs. We really need to port the solution we've done on dvb-usb to the other drivers, allowing them to have the entire scancode at the tables while keep supporting table replacement. The issue is that we currently have only 7bits of the scan codes produced by the IR's. So, we need to re-generate the keycode tables for each IR after the changes got applied. With respect to a common module, unfortunately most of the work should be done on each driver, since the code that communicates with the hardware is specific to each device. There is a common code (at ir-common.ko) with helper decoding routines. Please feel free to send us contributions to improve the current code. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: > Mauro Carvalho Chehab 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 should remember that not all >> developers use lirc; > > It's fine, but please - no keymaps in the kernel (except for fixed > receivers, i.e. the ones which can only work with their own dedicated > remote, and which don't pass RC5/etc. code). > > The existing keymaps (those which can be used with lirc) have to be > moved to userspace as well. The removal of the existing keymaps from kernel depends on having an application to be called from udev to load the proper keymaps when a device is probed. After having it for a while, we should deprecate the in-kernel keymaps and move them to userspace. I also think that it is important to remove the 7 bits limitation from all drivers and re-generate the keymaps, since they'll change after it. 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] Should we create a raw input interface for IR's ?
Dmitry Torokhov 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 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 raw input is not sutable for input system
Maxim Levitsky 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: 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
Mauro Carvalho Chehab 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 mapping should be: key = proto + group + raw code, while >> key2 could be different_proto + different group (if any) + another code. > > This may work for protocols up to RC5, that uses either 8 or 16 bits. > However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits > for a scancode. So, we don't have spare bits to represent a protocol, > if we consider RC6 mode 6 codes as well. I don't see this limitation. The number of bits should depend on the protocol. > 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. I don't think so. We can pass the space/mark data to all (configured, i.e. with active mapping) protocol handlers at once. Should a check fail, we ignore the data. Perhaps another protocol will make some sense out of 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab 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 causing regressions, and to > find a group of people that will help testing the new way. We don't want to "port it" to other drivers. We need to have a common module which does all RCx decoding. The individual drivers should be as simple as possible, something that I outlined in a previous mail. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Mauro Carvalho Chehab 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 should remember that not all > developers use lirc; It's fine, but please - no keymaps in the kernel (except for fixed receivers, i.e. the ones which can only work with their own dedicated remote, and which don't pass RC5/etc. code). The existing keymaps (those which can be used with lirc) have to be moved to userspace as well. -- 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: > Dmitry Torokhov 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 acceptable for key input. This is not a limit at the input subsystem. It were a design decision for some drivers at the V4L subsystem that we need to change. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 just have a skewed perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. >>> >>> There's one gripe I agree with, and that is that its still not >>> plug-n-play. >>> Something where udev auto-loads a sane default remote config for say, >>> mceusb transceivers, and the stock mce remote Just Works would be nice, >>> but auto-config is mostly out the window the second you involve >>> transmitters >>> and universal remotes anyway. >> >> For several devices, an udev rule that auto-loads a sane default >> keymap does work. >> Of course, this won't cover 100% of the usages, and I lirc is a very >> good way >> of covering the holes. >> >>> But outside of that, I think objections are largely philosophical -- >>> in a nutshell, the kernel has an input layer, remotes are input devices, >>> and lirc doesn't conform to input layer standards. >> >> Yes. I think this is mainly the issue. >> >> The other issue is how to migrate the existing drivers to a new API >> without >> causing regressions. If we decide that IR's that receive raw pulse/code >> should use the raw input interface, this means that a large task force >> will be >> needed to convert the existing drivers to use it. > > Aversion to regression is definitely a major concern. And why I'm liking > the idea of a hybrid approach, at least initially. Yes. This indeed seems to be a very good idea. > >> What do you think of adding lirc at staging while we discuss/improve >> the API's and lircd >> support for the input event interface? Do you think this would work? > > Sure, I don't see why not. And I've got another dozen or so drivers to > follow those first three... :) Ok. As you said you'll do some work at the patches, could you please send us v3 in order to add it into drivers/staging? In the case of the API header file, I would tag at the header file that the API is experimental, so can be changed without prior announcements, etc (in order to avoid people to use and rely on it it outside lirc). IMO, the better is to keep such announcement there while we're still working at the hybrid approach, as we may need to change something during the development phase. 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 lirc drivers at drivers/staging from my trees? 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Dmitry Torokhov 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 acceptable for key input. -- 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: [PATCH] New driver for the radio FM module on Miro PCM20 sound card
At Thu, 26 Nov 2009 18:38:27 +0100, Krzysztof Helt wrote: > > On Thu, 26 Nov 2009 16:43:15 +0100 > Takashi Iwai wrote: > > > At Thu, 26 Nov 2009 13:50:17 +0100, > > Krzysztof Helt wrote: > > > > > > From: Krzysztof Helt > > > > > > 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 provides only basic functionality: frequency changing and > > > FM module muting. > > > > > > Signed-off-by: Krzysztof Helt > > > Reviewed-by: Hans Verkuil > > > --- > > > This is the second version of the patch with changes suggested by Hans > > > Verkuil. > > > > Thanks. But you didn't check my review comment in my previous mail...? > > > > I have missed it. I will redo the patch. OK, thanks ;) Takashi -- 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 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 perception). Aside for a video card's default remote setup, the suggestions so far don't strike me as any simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC already works for both transmit and receive and has existing support in applications such as MythTV and mplayer. There's one gripe I agree with, and that is that its still not plug-n-play. Something where udev auto-loads a sane default remote config for say, mceusb transceivers, and the stock mce remote Just Works would be nice, but auto-config is mostly out the window the second you involve transmitters and universal remotes anyway. For several devices, an udev rule that auto-loads a sane default keymap does work. Of course, this won't cover 100% of the usages, and I lirc is a very good way of covering the holes. But outside of that, I think objections are largely philosophical -- in a nutshell, the kernel has an input layer, remotes are input devices, and lirc doesn't conform to input layer standards. Yes. I think this is mainly the issue. The other issue is how to migrate the existing drivers to a new API without causing regressions. If we decide that IR's that receive raw pulse/code should use the raw input interface, this means that a large task force will be needed to convert the existing drivers to use it. Aversion to regression is definitely a major concern. And why I'm liking the idea of a hybrid approach, at least initially. What do you think of adding lirc at staging while we discuss/improve the API's and lircd support for the input event interface? Do you think this would work? Sure, I don't see why not. And I've got another dozen or so drivers to follow those first three... :) -- 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
[PATCH 1/2 v3] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
>From 8b24c617e1ac4d324538a3eec476d48b85c2091f Mon Sep 17 00:00:00 2001
From: Guennadi Liakhovetski
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, 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 we
cannot use fourcc codes to configure subdevice output data formats. This patch
adds codes for several such on-the-bus formats and an API, similar to the
familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
codes. After all users of the old API in struct v4l2_subdev_video_ops are
converted, it will be removed. Also add helper routines to support generic
pass-through mode for the soc-camera framework.
Signed-off-by: Guennadi Liakhovetski
---
v2 -> v3: more comments:
1. moved enum v4l2_mbus_packing, enum v4l2_mbus_order, and struct
v4l2_mbus_pixelfmt to soc-camera specific header, renamed them into
soc-namespace.
2. commented enum v4l2_mbus_pixelcode and removed unused values.
v1 -> v2: addressed comments from Hans, namely:
1. renamed image bus to media bus, now using "mbus" as a shorthand in
function and data type names.
2. made media-bus helper functions soc-camera local.
3. moved colorspace from struct v4l2_mbus_pixelfmt to struct
v4l2_mbus_framefmt.
4. added documentation for data types and enums.
5. added
V4L2_MBUS_FMT_FIXED = 1,
format as the first in enum.
soc-camera driver port will follow tomorrow.
Thanks
Guennadi
drivers/media/video/Makefile |2 +-
drivers/media/video/soc_mediabus.c | 157
include/media/soc_mediabus.h | 84 +++
include/media/v4l2-mediabus.h | 59 ++
include/media/v4l2-subdev.h| 19 -
5 files changed, 319 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/soc_mediabus.c
create mode 100644 include/media/soc_mediabus.h
create mode 100644 include/media/v4l2-mediabus.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7a2dcc3..e7bc8da 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o
-obj-$(CONFIG_SOC_CAMERA) += soc_camera.o
+obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
new file mode 100644
index 000..f293a8d
--- /dev/null
+++ b/drivers/media/video/soc_mediabus.c
@@ -0,0 +1,157 @@
+/*
+ * soc-camera media bus helper routines
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+
+#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1)
+
+static const struct soc_mbus_pixelfmt mbus_fmt[] = {
+ [MBUS_IDX(YUYV)] = {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .name = "YUYV",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(YVYU)] = {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .name = "YVYU",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(UYVY)] = {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = "UYVY",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(VYUY)] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .name = "VYUY",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(RGB555)] = {
+ .fourcc = V4L2_PIX_FMT_RGB555,
+ .name = "RGB555",
+ .b
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 itself. That was my guess, but I didn't have a timeline in front of me. :) The main reason for the input layer IR drivers appearing was lirc not being mainline. A in-kernel driver (bttv in that case) which depends on a out-of-tree subsystem for IR support was simply a pain in the ass for both maintainer (/me back then) and users. At least for IR hardware which allows access to the raw samples it certainly makes sense to support lirc, additional to the current (or improved) input layer support. I'm liking the idea of a hybrid approach, where IR devices can support both lirc and input device interfaces. I think its the most regression-proof for end-users, if done correctly, which is one of my biggest concerns. The lirc support in mythtv actually relies on mapping remote button names as defined in lircd.conf to keyboard key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. just yet, but I intend on fixing that... lircd can handle the input layer as input as well, so you actually can remap things via lircd even for pure input layer drivers. mythtv handling KEY_VOLUMEUP directly would be more elegant though. Yeah, no, I know lircd can attach to an input device. But even if you do that, you have to have a mapping that converts KEY_VOLUMEUP as captured by lircd into (iirc) right-bracket (]) for mythtv to actually consume it. Directly handling definitely needs to be added to mythtv. -- 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: IR Receiver on an Tevii S470
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 build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." -- Rich Cook -- 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
Gerd Hoffmann 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 time.
I think the address (aka group) should be just a part of the key
("command") code, IIRC this is what lirc RC5 does (I'm presently using
a custom "media" version of RC5).
> I know that lircd does matching instead of decoding, which allows to
> handle unknown encodings. Thats why I think there will always be
> cases which only lircd will be able to handle (using raw samples).
>
> That doesn't make attempts to actually decode the IR samples a useless
> exercise though ;)
Sure. Especially RC5-like protos are simple to decode, and it's very
reliable, even with a very unstable remote clock source (such as
RC-based = resistor + capacitor).
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 conversion
>> to raw pulse/code, if the hardware requires pulse/code instead of scancodes.
>
> That seems like a decision which will create a lots of duplicative code
> in the kernel. Add it's just busy-work to write such code when a
> userspace application in common use already handles the protocols and
> sends raw pulses to hardware that expects raw pulses.
I don't see how this would create lots of duplicative code.
>> However, as we have green field,
>> I would add the protocol explicitly for each scancode to be transmitted,
>> like:
>>
>> struct ir_tx {
>> enum ir_protocol proto;
>> u32 scancode;
>> };
>>
>> Eventually, we might have a protocol "raw" and some extra field to allow
>> passing
>> a raw pulse/code sequence instead of a scancode.
>
> I think you would have to. 32 bits is really not enough for all
> protocols, and it is already partial encoding of information anyway.
>
> If the Tx driver has to break them down into pulses anyway,
Do all Tx drivers need handle pulse by pulse, or there are some that works
only with scancodes?
> why not have fields with more meaningful names
>
> mode
> toggle
> customer code (or system code or address),
> information (or command)
>
> According to
>
> http://slycontrol.ru/scr/kb/rc6.htm
>
> the "information" field could be up to 128 bits.
Seems fine to me.
> (Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
> kernel.)
>
> Regards,
> Andy
>
>> 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 others will be shot on sight. > > I'm happy to see that the discussion is getting along. > 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. > > 1. For sure in-kernel decoding will require some assistance from userspace > to load the mapping from IR codes to keys. Current drivers have the IR keycode tables in-kernel also, directly associated with the board ID. > So, if there needs to be a tool > in userspace that does some kind of autodetection, why not have a tool > that does some autodetection and autoconfigures lircd for the current > device. There are userspace tools to change the IR keycode maps. It shouldn't be hard to change it to autodetect the hardware and to autoconfigure lircd. > Lots of code duplication in kernel saved. Huh? The code is already there. > What's the actual benefit of in-kernel decoding? There are two benefits: 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 should remember that not all developers use lirc; 2) the IR works out of the box. > 2. What would be the format of the key map? lircd.conf files already exist > for a lot of remote controls. Will we have a second incompatible format to > map the keys in-kernel? Where are the tools that create the key maps for > new remotes? No matter what tool you use, the format should be very close: scancode -> key_code. If you wan to take a look on a real example, I'm enclosing the keycode table used by dib0700 driver, as generated/readed by a simple keycode application I made to test the dynamic keycode loading: http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c Most of the keycodes there are RC5 keys. There are also some NEC keys, as those devices can work with either RC5 or NEC keycodes, by using a different parameter during module load. In the case of this driver, the pulse/space is done in hardware by the DibCom chip. The scancode is sent to PC via the USB interface. I hope it helps for you to better understand how this works. Cheers, Mauro. 0x0700 KEY_MUTE 0x0701 KEY_MENU 0x0739 KEY_POWER 0x0703 KEY_VOLUMEUP 0x0709 KEY_VOLUMEDOWN 0x0706 KEY_CHANNELUP 0x070c KEY_CHANNELDOWN 0x070f KEY_1 0x0715 KEY_2 0x0710 KEY_3 0x0718 KEY_4 0x071b KEY_5 0x071e KEY_6 0x0711 KEY_7 0x0721 KEY_8 0x0712 KEY_9 0x0727 KEY_0 0x0724 KEY_SCREEN 0x072a KEY_TEXT 0x072d KEY_REWIND 0x0730 KEY_PLAY 0x0733 KEY_FASTFORWARD 0x0736 KEY_RECORD 0x073c KEY_STOP 0x073f KEY_CANCEL 0xeb01 KEY_POWER 0xeb02 KEY_1 0xeb03 KEY_2 0xeb04 KEY_3 0xeb05 KEY_4 0xeb06 KEY_5 0xeb07 KEY_6 0xeb08 KEY_7 0xeb09 KEY_8 0xeb0a KEY_9 0xeb0b KEY_VIDEO 0xeb0c KEY_0 0xeb0d KEY_REFRESH 0xeb0f KEY_EPG 0xeb10 KEY_UP 0xeb11 KEY_LEFT 0xeb12 KEY_OK 0xeb13 KEY_RIGHT 0xeb14 KEY_DOWN 0xeb16 KEY_INFO 0xeb17 KEY_RED 0xeb18 KEY_GREEN 0xeb19 KEY_YELLOW 0xeb1a KEY_BLUE 0xeb1b KEY_CHANNELUP 0xeb1c KEY_VOLUMEUP 0xeb1d KEY_MUTE 0xeb1e KEY_VOLUMEDOWN 0xeb1f KEY_CHANNELDOWN 0xeb40 KEY_PAUSE 0xeb41 KEY_HOME 0xeb42 KEY_MENU 0xeb43 KEY_SUBTITLE 0xeb44 KEY_TEXT 0xeb45 KEY_DELETE 0xeb46 KEY_TV 0xeb47 KEY_DVD 0xeb48 KEY_STOP 0xeb49 KEY_VIDEO 0xeb4a KEY_AUDIO 0xeb4b KEY_SCREEN 0xeb4c KEY_PLAY 0xeb4d KEY_BACK 0xeb4e KEY_REWIND 0xeb4f KEY_FASTFORWARD 0xeb54 KEY_PREVIOUS 0xeb58 KEY_RECORD 0xeb5c KEY_NEXT 0x1e00 KEY_0 0x1e01 KEY_1 0x1e02 KEY_2 0x1e03 KEY_3 0x1e04 KEY_4 0x1e05 KEY_5 0x1e06 KEY_6 0x1e07 KEY_7 0x1e08 KEY_8 0x1e09 KEY_9 0x1e0a KEY_KPASTERISK 0x1e0b KEY_RED 0x1e0c KEY_RADIO 0x1e0d KEY_MENU 0x1e0e KEY_GRAVE 0x1e0f KEY_MUTE 0x1e10 KEY_VOLUMEUP 0x1e11 KEY_VOLUMEDOWN 0x1e12 KEY_CHANNEL 0x1e14 KEY_UP 0x1e15 KEY_DOWN 0x1e16 KEY_LEFT 0x1e17 KEY_RIGHT 0x1e18 KEY_VIDEO 0x1e19 KEY_AUDIO 0x1e1a KEY_MEDIA 0x1e1b KEY_EPG 0x1e1c KEY_TV 0x1e1e KEY_NEXT 0x1e1f KEY_BACK 0x1e20 KEY_CHANNELUP 0x1e21 KEY_CHANNELDOWN 0x1e24 KEY_LAST 0x1e25 KEY_OK 0x1e29 KEY_BLUE 0x1e2e KEY_GREEN 0x1e30 KEY_PAUSE 0x1e32 KEY_REWIND 0x1e34 KEY_FASTFORWARD 0x1e35 KEY_PLAY 0x1e36 KEY_STOP 0x1e37 KEY_RECORD 0x1e38 KEY_YELLOW 0x1e3b KEY_GOTO 0x1e3d KEY_POWER 0x0042 KEY_POWER 0x077c KEY_TUNER 0x0f4e KEY_PRINT 0x0840 KEY_SCREEN 0x0f71 KEY_DOT 0x0743 KEY_0 0x0c41 KEY_1 0x0443 KEY_2 0x0b7f KEY_3 0x0e41 KEY_4 0x0643 KEY_5 0x097f KEY_6 0x0d7e KEY_7 0x057c KEY_8 0x0a40 KEY_9 0x0e4e KEY_CLEAR 0x047c KEY_CHANNEL 0x0f41 KEY_LAST 0x0342 KEY_MUTE 0x064c KEY_RESERVED 0x0172 KEY_SHUFFLE 0x0c4e KEY_PLAYPAUSE 0x0b70 KEY_RECORD 0x037d KEY_VOLUMEUP 0x017d KEY_VOLUMEDOWN 0x0242 KEY_CHANNELUP 0x007d KEY_CHANNELDOWN 0x1d00 KEY_0 0x1d01 KE
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 the rest of the input devices. > > From the mythtv perspective, using the input layer could yield a better > out-of-the-box experience -- users don't have to set up an lircrc mapping > that converts key names as specified in lircd.conf into commands > (key strokes, actually) that mythtv understands. For example, a button > labeled "Play" > in lircd.conf has to be mapped to 'p' in ~/.lircrc for mythtv to do the right > thing with it. If everything came through the input layer, be that natively > or via lircd's uinput reinjection, there would be no need to do that extra > mapping step, mythtv would simply handle a KEY_PLAY event. So at worst, > one manual mapping to do -- IR signal to standard button name in lircd.conf > -- > instead of two. But the lircrc approach does also allow more flexibility, > in that you can only have a certain app respond to a certain key, if so > desired, > and remap a key to a different function (KEY_RED, KEY_GREEN, KEY_BLUE, > KEY_YELLOW > -- what should their default functionality be? I know some users map a pair > of those to mythtv's "skip to next commflag point" and "skip to prior > commflag point"). > > Unfortunately, mythtv currently doesn't handle KEY_PLAY, KEY_VOLUMEUP, etc., > etc. at > all right now, it operates purely on keys commonly found on a standard > keyboard. > Remedying that is on my TODO list for the next release, if I can carve out > the time. This discussion is a little OT from the API discussions, since it affects both out-of-the box IR reception via input layer and lirc. All media applications should be capable of handling the corresponding KEY_PLAY, KEY_VOLUMEUP ... keys without needing to do anything else than just handling the corresponding keycode. You shouldn't need to start a daemon or doing anything else for this to work out-of-the-box. They currently don't do it due to historic reasons (it is easier to let something else remap KEY_PLAY into 'p' than to add the proper code there). When using non-hot-pluggable devices where you're building a dedicated MCE hardware (this is the common case of MythTV setups), things are not that bad, since, once you set your hardware, it is done. However, by looking on the number of different new devices, it seems that the most common type of devices are the TV USB sticks. As they are hot pluggable, eventually users may have more than one hardware and they expect that the IR layer will work equally on all your devices. The proper way for supporting it is to have a common application-agnostic keycode to indicate the received events. For example, all IR's should produce KEY_CHANNELUP/KEY_CHANNELDOWN events for changing the channels. Also, on a perfect world, lirc should send this event to the multimedia application that handles TV when such key is pressed, instead of converting into some other keycode. This prevents future problems if, for some reason, the application needs to do something else with that key, or if the key has a different meaning on some different contexts. For example, on some applications, KEY_UP/KEY_DOWN can mean to change a channel, but those keys are also used for menu navigation. However, KEY_CHANNELUP has a clear unique meaning: to change a channel. The expected behavior, from users perspective, is to mimic a TV box, where if you press channel UP any open menu will be closed and the channel will be changed, but pressing UP key will navigate at the menu. Well, if you map KEY_CHANNELUP as KEY_UP, you'll produce a different behavior. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 device specific user space interface for IR. I believe all new input devices should implement the evdev framework. -- 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: [PATCH/RFC v2] V4L core cleanups HG tree
On Wed, Nov 25, 2009 at 11:21 AM, Laurent Pinchart 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 committed to v4l-dvb in time > for 2.6.33. > > On Wednesday 18 November 2009 13:54:06 Laurent Pinchart wrote: >> Hi everybody, >> >> the V4L cleanup patches are now available from >> >> http://linuxtv.org/hg/~pinchartl/v4l-dvb-cleanup >> >> The tree will be rebased if needed (or rather dropped and recreated as hg >> doesn't provide a rebase operation), so please don't pull from it yet if >> you don't want to have to throw the patches away manually later. >> >> I've incorporated the comments received so far and went through all the >> patches to spot bugs that could have sneaked in. >> >> Please test the code against the driver(s) you maintain. The changes are >> small, *should* not create any issue, but the usual bug can still sneak in. >> >> I can't wait for an explicit ack from all maintainers (mostly because I >> don't know you all), so I'll send a pull request in a week if there's no >> blocking issue. I'd like this to get in 2.6.33 if possible. I have a pile of testing in the next few days. In light of Devin's OOPS I'll test the cx88 and cx23885 changes and report back by sunday. Thanks for the cleanups Laurent. Regards, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab wrote: > Gerd Hoffmann wrote: >> On 11/25/09 19:20, Devin Heitmueller wrote: >>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson >>> wrote: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. >> >> I think at the end of the day we'll want to have all IR drivers use the >> same interface. The way the current in-kernel input layer drivers work >> obviously isn't perfect too, so we *must* consider both worlds to get a >> good solution for long-term ... I made an attempt at implementing all of this a year ago. http://lkml.org/lkml/2008/11/5/233 All of this kernel code is tiny, about 20K including a driver. Basic flow works like this: Add a new IR data type to the input framework http://lkml.org/lkml/2008/11/5/234 Example mceusb IR input driver http://lkml.org/lkml/2008/11/5/238 In-kernel decoding of core IR protocols - RC5, RC6, etc http://lkml.org/lkml/2008/11/5/234 Decoded core protocols pass through a translation map based on configfs When core protocol matches an entry in configfs it is turned into a keycode event. http://lkml.org/lkml/2008/11/5/235 You make a directory in /configfs/remotes for each remote you have. Making the directory creates a new evdev device. Under the directory make an entry for each command generated by the device. These entries cause the decoded IR data to be mapped into keycodes on the new evdev device. udev would load these configfs mappings at boot time... mkdir /config/remotes/sony -- this creates a new evdev device mkdir remotes/sony/one echo 7 >remotes/sony/one/protocol echo 264 >remotes/sony/one/command echo 2 >remotes/sony/one/keycode This transforms a button push of 1 on my remote into a key stroke for KEY_1 * configfs root * --remotes * specific remote * --keymap * protocol * device * command * keycode * --repeat keymaps * * another remote * --more keymaps You can map the 1 button from multiple remotes to KEY_1 if you want. Or you can use a single remote to create multiple virtual keyboards. - Raw IR pulse data is available in a FIFO via sysfs. You can use this to figure out new remote protocols. Two input events are generated 1) an event for the decoded raw IR protocol 2) a keycode event if thedecoded raw IR protocol matches an entry in the configfs You can also send pulses. -- If you want to script this, you would have a user space task that watches for either the decoded IR codes or the mapped keycodes. This system also works with user space device drivers. They can inject input events into the early event flow and they will get processed as if the event originated in the kernel. - Sure you could push the protocol decoding code (RC5, etc) into user space. Seems like a lot of hassle to move about 3KB of code out of the kernel. -- 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: [PATCH] New driver for the radio FM module on Miro PCM20 sound card
At Thu, 26 Nov 2009 13:50:17 +0100, Krzysztof Helt wrote: > > From: Krzysztof Helt > > 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 provides only basic functionality: frequency changing and > FM module muting. > > Signed-off-by: Krzysztof Helt > Reviewed-by: Hans Verkuil > --- > This is the second version of the patch with changes suggested by Hans > Verkuil. Thanks. But you didn't check my review comment in my previous mail...? Takashi -- 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
Gerd Hoffmann wrote: > On 11/25/09 19:20, Devin Heitmueller wrote: >> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson >> wrote: >>> Took me a minute to figure out exactly what you were talking >>> about. You're referring to the current in-kernel decoding done on >>> an ad-hoc basis for assorted remotes bundled with capture devices, >>> correct? >>> >>> Admittedly, unifying those and the lirc driven devices hasn't >>> really been on my radar. > > I think at the end of the day we'll want to have all IR drivers use the > same interface. The way the current in-kernel input layer drivers work > obviously isn't perfect too, so we *must* consider both worlds to get a > good solution for long-term ... > >> This is one of the key use cases I would be very concerned with. For >> many users who have bought tuner products, the bundled remotes work >> "out-of-the-box", regardless of whether lircd is installed. > > I bet this simply isn't going to change. > >> I have no objection so much as to saying "well, you have to install >> the lircd service now", but there needs to be a way for the driver to >> automatically tell lirc what the default remote control should be, >> to avoid a regression in functionality. > > *Requiring* lircd for the current in-kernel drivers doesn't make sense > at all. Allowing lircd being used so it can do some more advanced stuff > makes sense though. > >> This is why I think we really should put together a list of use >> cases, so that we can see how any given proposal addresses those use >> cases. I offered to do such, but nobody seemed really interested in >> this. > > Lets have a look at the problems the current input layer bits have > compared to lirc: > > > (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 = IR_RC5 > input_event->value = Agreed. We're doing this already with some drivers (dvb-usb ones). I've started working on a patchset to extend this to the remaining drivers. I'm not sure whare were already merged from this tree, but my intention is to extend this to all drivers. > In case the 32bit value is too small we might want send two events > instead, with ->code being set to IR__1 and IR__2 Well, RC6 mode 6 uses 32 bits. I don't know if is there any case for more than 32 bits. However, on some I2C IR chips, we see some cases where the IR scancode key is encapsulated into some protocol with more bytes. It seems that those extra bytes are used to handle key repetition sort of events. I'm not sure if it would make sense to pass the raw data to userspace. Probably not. > Advantages: > * Applications (including lircd) can get access to the unmodified > rc5/rc6/... codes. > * All the ir-code -> keycode mapping magic can be handled by the > core input layer then. All the driver needs to do is to pass on > the information which keymap should be loaded by default (for the > bundled remote if any). The configuration can happen in userspace > (sysfs attribute + udev + small utility in tools/ir/). I like the idea of such small utility to load the keymap table. > * lirc drivers which get ir codes from the hardware can be converted > to pure input layer drivers without regressions. lircd is not > required any more. > > > (2) input layer doesn't give access to the raw samples. > > Not sure how to deal with that best. Passing them through the input > layer would certainly be possible to hack up. But what would be the > point? The input layer wouldn't do any processing on them. It wouldn't > buy us much. So we might want to simply stick with todays lirc > interface for the raw samples. If we need such interface, the better is to keep using the lirc interface. Yet, I'm not sure if we should really keep outputing raw samples, since several devices won't support it. > Drivers which support both ir codes (be it by hardware or by in-kernel > decoding) and raw samples would register two devices then, one input > device and one lirc device. It would probably a good idea to stop > sending events to the input layer as soon as someone (most likely lircd) > opens the lirc device to avoid keystrokes showing up twice. > > By default the in-kernel bits will be at work, but optionally you can > have lircd grab the raw samples and do fancy advanced decoding. > > > (3) input layer doesn't allow transmitting IR codes. > > If we keep the lirc interface for raw samples anyway, then we can keep > it for sending too, problem solved ;) How does sending hardware work > btw? Do they all accept just raw samples? Or does some hardware also > accept ir-codes? I would do it in a way that it will accept scancodes and raw samples, since, even if we currently have only devices that accept raw samples, it would be more future-proof to allow sending scancodes also.
Re: [PATCH 1/2 v2] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
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 great!
Regards,
Hans
> 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
> we
> cannot use fourcc codes to configure subdevice output data formats. This
> patch
> adds codes for several such on-the-bus formats and an API, similar to the
> familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring
> those
> codes. After all users of the old API in struct v4l2_subdev_video_ops are
> converted, it will be removed. Also add helper routines to support generic
> pass-through mode for the soc-camera framework.
>
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> v1 -> v2: addressed comments from Hans, namely:
>
> 1. renamed image bus to media bus, now using "mbus" as a shorthand in
> function and data type names
>
> 2. made media-bus helper functions soc-camera local
>
> 3. moved colorspace from struct v4l2_mbus_pixelfmt to struct
> v4l2_mbus_framefmt
>
> 4. added documentation for data types and enums
>
> 5. added
>
> V4L2_MBUS_FMT_FIXED = 1,
>
> format as the first in enum
>
> I'm still testing the soc-camera driver conversion patch, I'll post it as
> a reply to this one, marked "2/2 v2" a bit later.
>
> Thanks
> Guennadi
>
> drivers/media/video/Makefile |2 +-
> drivers/media/video/soc_mediabus.c | 211
>
> include/media/soc_camera.h | 24
> include/media/v4l2-mediabus.h | 103 ++
> include/media/v4l2-subdev.h| 19 +++-
> 5 files changed, 357 insertions(+), 2 deletions(-)
> create mode 100644 drivers/media/video/soc_mediabus.c
> create mode 100644 include/media/v4l2-mediabus.h
>
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 7a2dcc3..e7bc8da 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
> obj-$(CONFIG_VIDEO_CX23885) += cx23885/
>
> obj-$(CONFIG_VIDEO_OMAP2)+= omap2cam.o
> -obj-$(CONFIG_SOC_CAMERA) += soc_camera.o
> +obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
> obj-$(CONFIG_SOC_CAMERA_PLATFORM)+= soc_camera_platform.o
> # soc-camera host drivers have to be linked after camera drivers
> obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
> diff --git a/drivers/media/video/soc_mediabus.c
> b/drivers/media/video/soc_mediabus.c
> new file mode 100644
> index 000..0d5c17d
> --- /dev/null
> +++ b/drivers/media/video/soc_mediabus.c
> @@ -0,0 +1,211 @@
> +/*
> + * soc-camera media bus helper routines
> + *
> + * Copyright (C) 2009, Guennadi Liakhovetski
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1)
> +
> +static const struct v4l2_mbus_pixelfmt mbus_fmt[] = {
> + [MBUS_IDX(YUYV)] = {
> + .fourcc = V4L2_PIX_FMT_YUYV,
> + .name = "YUYV",
> + .bits_per_sample= 8,
> + .packing= V4L2_MBUS_PACKING_2X8_PADHI,
> + .order = V4L2_MBUS_ORDER_LE,
> + }, [MBUS_IDX(YVYU)] = {
> + .fourcc = V4L2_PIX_FMT_YVYU,
> + .name = "YVYU",
> + .bits_per_sample= 8,
> + .packing= V4L2_MBUS_PACKING_2X8_PADHI,
> + .order = V4L2_MBUS_ORDER_LE,
> + }, [MBUS_IDX(UYVY)] = {
> + .fourcc = V4L2_PIX_FMT_UYVY,
> + .name = "UYVY",
> + .bits_per_sample= 8,
> + .packing= V4L2_MBUS_PACKING_2X8_PADHI,
> + .order = V4L2_MBUS_ORDER_LE,
> + }, [MBUS_IDX(VYUY)] = {
> + .fourcc = V4L2_PIX_FMT_VYUY,
> + .name = "VYUY",
> + .bits_per_sample= 8,
> + .packing= V4L2_MBUS_PACKING_2X8_PADHI,
> + .order = V4L2_MBUS_ORDER_LE,
> + }, [MBUS_IDX(VYUY_SMPTE170M_8)] = {
> + .fourcc = V4L2_PIX_FMT_VYUY,
> + .name = "VYUY
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 written and tested, everybody is >>> happy. >> The existing drivers use input layer. Do you want part of the tree to >> use existing lirc interface while the other part uses their own >> in-kernel (badly broken for example) code to do precisely the same >> thing? > > Took me a minute to figure out exactly what you were talking about. You're > referring to the > current in-kernel decoding done on an ad-hoc basis for assorted remotes > bundled with capture devices, correct? They are not limited to the currently bundled IR's, since almost all drivers allow replacing the existing scancode/keycode table to a new onw. > Admittedly, unifying those and the lirc driven devices hasn't really been on > my radar. It should be done. Having two ways for doing the same thing is not an option. We'll need to unify them sooner or later. The sooner, the better. >> We can have a good code for both, or we can end up with "badly broken" >> media drivers and incompatible, suboptimal existing lirc interface >> (though most probably much better in terms of quality, especially after >> Jarod's work). > > Well, is there any reason most of those drivers with > currently-in-kernel-but-badly-broken decoding can't be converted to > use the lirc interface if its merged into the kernel? > And/or, everything > could converge on a new in-kernel decoding infra that wasn't badly broken. > Sure, there may be two separate ways of doing essentially the same thing > for a while, but meh. The lirc way works NOW for an incredibly wide > variety of receivers, transmitters, IR protocols, etc. Yes: the same drivers support both pulse/space and in-hardware scancode conversion. In order to use the raw pulse/space API, they'll need to generate pseudo pulse/space's. This would be a dirty solution, IMHO. Also, changing the drivers would not be that easy, since it will require lots of tests with IR's and devices that the developers won't have. This is a weaker argument, since no matter what decided, we'll need to change the drivers code (on lirc drivers or on the in-kernel drivers) even without having all hardware available. > I do concur that Just Works decoding for bundled remotes w/o having to > configure anything would be nice, and one way to go about doing that > certainly is via in-kernel IR decoding. But at the same time, the second > you want to use something other than a bundled remote, things fall down, > and having to do a bunch of setkeycode ops seems less optimal than simply > dropping an appropriate lircd.conf in place. I don't see this as an issue. We have by far too much work to be done in kernelspace than the changes that are needed on userspace. Replace the entire scancode table with setkeycode ops is very fast, and needs to be done only once, at lirc startup. Once you load the new IR code at the driver, the kernel will send the new keycodes to lirc. It doesn't seem hard to modify lirc to do read the lircd.conf table and replace the IR scancodes at the in-kernel driver. It took me half an hour to write my own keycode loader code, and you can use it as the basis for such feature: http://linuxtv.org/hg/v4l-dvb/file/tip/v4l2-apps/util/keytable.c Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2 v2] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
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 we
cannot use fourcc codes to configure subdevice output data formats. This patch
adds codes for several such on-the-bus formats and an API, similar to the
familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
codes. After all users of the old API in struct v4l2_subdev_video_ops are
converted, it will be removed. Also add helper routines to support generic
pass-through mode for the soc-camera framework.
Signed-off-by: Guennadi Liakhovetski
---
v1 -> v2: addressed comments from Hans, namely:
1. renamed image bus to media bus, now using "mbus" as a shorthand in
function and data type names
2. made media-bus helper functions soc-camera local
3. moved colorspace from struct v4l2_mbus_pixelfmt to struct
v4l2_mbus_framefmt
4. added documentation for data types and enums
5. added
V4L2_MBUS_FMT_FIXED = 1,
format as the first in enum
I'm still testing the soc-camera driver conversion patch, I'll post it as
a reply to this one, marked "2/2 v2" a bit later.
Thanks
Guennadi
drivers/media/video/Makefile |2 +-
drivers/media/video/soc_mediabus.c | 211
include/media/soc_camera.h | 24
include/media/v4l2-mediabus.h | 103 ++
include/media/v4l2-subdev.h| 19 +++-
5 files changed, 357 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/soc_mediabus.c
create mode 100644 include/media/v4l2-mediabus.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7a2dcc3..e7bc8da 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o
-obj-$(CONFIG_SOC_CAMERA) += soc_camera.o
+obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
new file mode 100644
index 000..0d5c17d
--- /dev/null
+++ b/drivers/media/video/soc_mediabus.c
@@ -0,0 +1,211 @@
+/*
+ * soc-camera media bus helper routines
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+
+#include
+#include
+
+#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1)
+
+static const struct v4l2_mbus_pixelfmt mbus_fmt[] = {
+ [MBUS_IDX(YUYV)] = {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .name = "YUYV",
+ .bits_per_sample= 8,
+ .packing= V4L2_MBUS_PACKING_2X8_PADHI,
+ .order = V4L2_MBUS_ORDER_LE,
+ }, [MBUS_IDX(YVYU)] = {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .name = "YVYU",
+ .bits_per_sample= 8,
+ .packing= V4L2_MBUS_PACKING_2X8_PADHI,
+ .order = V4L2_MBUS_ORDER_LE,
+ }, [MBUS_IDX(UYVY)] = {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = "UYVY",
+ .bits_per_sample= 8,
+ .packing= V4L2_MBUS_PACKING_2X8_PADHI,
+ .order = V4L2_MBUS_ORDER_LE,
+ }, [MBUS_IDX(VYUY)] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .name = "VYUY",
+ .bits_per_sample= 8,
+ .packing= V4L2_MBUS_PACKING_2X8_PADHI,
+ .order = V4L2_MBUS_ORDER_LE,
+ }, [MBUS_IDX(VYUY_SMPTE170M_8)] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .name = "VYUY in SMPTE170M",
+ .bits_per_sample= 8,
+ .packing= V4L2_MBUS_PACKING_2X8_PADHI,
+ .order = V4L2_MBUS_ORDER_LE,
+ }, [MBUS_IDX(VYUY_SMPTE170M_16)] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .name = "VYUY in SMPTE170M, 16bit",
+ .bits_per_sample= 16,
+ .packing= V4L2_MBUS_PACKING_NON
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: > Andy Walls 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 some countries but from the > technical POV handling the protocol in the kernel is more efficient > or (/and) simpler. A software licensing from Microsoft won't apply to Linux kernel, so I'm assuming that you're referring to some patent that they could be filled about RC6 mode 6A. I don't know if is there any US patent pending about it (AFAIK, only US accepts software patents), but there are some prior-art for IR key decoding. So, I don't see what "innovation" RC6 would be adding. If it is some new way to transmit waves, the patent issues aren't related to software, and the device manufacturer had already handled it when they made their devices. If it is just a new keytable, this issue could be easily solved by loading the keytable via userspace. Also, assuming that you can use the driver only with a hardware that comes with a licensed software, the user has already the license for using it. Do you have any details on what patents they are claiming? 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 setup, the suggestions so far don't strike me as any >> simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC >> already works for both transmit and receive and has existing support in >> applications such as MythTV and mplayer. > > There's one gripe I agree with, and that is that its still not plug-n-play. > Something where udev auto-loads a sane default remote config for say, > mceusb transceivers, and the stock mce remote Just Works would be nice, > but auto-config is mostly out the window the second you involve transmitters > and universal remotes anyway. For several devices, an udev rule that auto-loads a sane default keymap does work. Of course, this won't cover 100% of the usages, and I lirc is a very good way of covering the holes. > But outside of that, I think objections are largely philosophical -- > in a nutshell, the kernel has an input layer, remotes are input devices, > and lirc doesn't conform to input layer standards. Yes. I think this is mainly the issue. The other issue is how to migrate the existing drivers to a new API without causing regressions. If we decide that IR's that receive raw pulse/code should use the raw input interface, this means that a large task force will be needed to convert the existing drivers to use it. > I do understand that argument, I just don't currently agree that all IR must > go through the input layer before the drivers are acceptable for upstream -- > especially since lircd can reinject decoded key presses into the input layer > via uinput. IMHO, there are some scenarios for an upcoming kernel IR raw input interface: 1) as a temporary solution for merging lirc drivers, knowing in advance that it will be later converted to the standard input API; 2) as a raw interface for some weird usages, with its usage limited to just a few device drivers; 3) as the solution for all IR's that produces pulse/code raw sequences; For (1), while it may make sense, we'll be creating an userspace API that is meant to be stable, knowing in advance that it will be removed in a close future. IMHO, we should avoid (2), since it will be hard to define what is the "limited usage", and I bet that it will evolute to (3) in a long term. For (3), we need to consider the migration of the existing drivers. By discarding scenario (2), this means that, in the long term, we'll need to either migrate all existing out-of-tree lirc drivers to the standard input API interface (scenario 1) or to migrate the existing drivers to the raw input interface (scenario 3). For me, scenario (1) is fine if we add the lirc drivers at drivers/staging. >> I believe Jarod's intent is to have the LIRC components, that need to be >> in kernel modules, moved into kernel mainline to avoid the headaches of >> out of kernel driver maintenance. I'm not sure it is time well spent >> for developers, or end users, to develop yet another IR receive >> implementation in addition to the ones we suffer with now. > > Yeah, a fairly relevant factor in all this is that, despite not being in the > linux > kernel source tree proper-like, the lirc drivers and lirc have been in use > for many > years by lots of users. The likes of Fedora, Debian, Ubuntu, SUSE, Mandriva, > etc. > have all been shipping lirc drivers for years now. While lirc certainly isn't > perfect (its not always the easiest thing for users to set up), it has > actually > proven itself pretty robust and useful in the field, once set up. The bulk of > breakage in lirc I've personally had to deal with has mostly come in the > form of kernel interface changes, which would definitely be mitigated by > not having to maintain the drivers out-of-tree any longer. > > Now, I'm all for "improving" things and integrating better with the input > subsystem, but what I don't really want to do is break compatibility with the > existing setups on thousands (and thousands?) of MythTV boxes around the > globe. > The lirc userspace can be pretty nimble. If we can come up with a shiny new > way > that raw IR can be passed out through an input device, I'm pretty sure lirc > userspace can be adapted to handle that. If a new input-layer-based transmit > interface is developed, we can take advantage of that too. But there's > already > a very mature lirc interface for doing all of this. So why not start with > adding > things more or less as they exist right now and evolve the drivers into an > idealized form? Getting *something* into the kernel in the first place is a > huge step in that direction. I agree. We should really move forward and add it to kernel as soon as possible, and start to work on improv
Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 strongly.
> >>> Any interface without transmitter support would be absolutely unacceptable
> >>> for many LIRC users, including myself.
> >> I don't say don't use a transmitter.
> >> I say the transmitter is not an input device, they are completely
> >> independent functions. I can't see any reason to try and fit both in the
> >> same interface - can you?
> >
> > The underlying hardware need not be completely independent.
> >
> > For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
> > chips have IR hardware that shares a common timing source, interrupt
> > line, interrupt status register, etc, between IR Rx and Tx. They can
> > also do things like loopback of Tx to Rx.
> >
> > That said, an underlying hardware implementation can be split up to user
> > space with separate interfaces Tx and Rx. The underlying driver module
> > would have to manage the dependencies. I would guess that would be
> > easier for driver modules, if the userspace interfaces were designed
> > with such combined IR Tx/Rx hardware in mind.
>
> True, but, in the case of Rx, there are already API's for it. Tx case is
> simpler, as we don't have any API for it yet.
>
> 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 conversion
> to raw pulse/code, if the hardware requires pulse/code instead of scancodes.
That seems like a decision which will create a lots of duplicative code
in the kernel. Add it's just busy-work to write such code when a
userspace application in common use already handles the protocols and
sends raw pulses to hardware that expects raw pulses.
> However, as we have green field,
> I would add the protocol explicitly for each scancode to be transmitted, like:
>
> struct ir_tx {
> enum ir_protocol proto;
> u32 scancode;
> };
>
> Eventually, we might have a protocol "raw" and some extra field to allow
> passing
> a raw pulse/code sequence instead of a scancode.
I think you would have to. 32 bits is really not enough for all
protocols, and it is already partial encoding of information anyway.
If the Tx driver has to break them down into pulses anyway, why not have
fields with more meaningful names
mode
toggle
customer code (or system code or address),
information (or command)
According to
http://slycontrol.ru/scr/kb/rc6.htm
the "information" field could be up to 128 bits.
(Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
kernel.)
Regards,
Andy
> 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 unacceptable
>>> for many LIRC users, including myself.
>> I don't say don't use a transmitter.
>> I say the transmitter is not an input device, they are completely
>> independent functions. I can't see any reason to try and fit both in the
>> same interface - can you?
>
> The underlying hardware need not be completely independent.
>
> For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
> chips have IR hardware that shares a common timing source, interrupt
> line, interrupt status register, etc, between IR Rx and Tx. They can
> also do things like loopback of Tx to Rx.
>
> That said, an underlying hardware implementation can be split up to user
> space with separate interfaces Tx and Rx. The underlying driver module
> would have to manage the dependencies. I would guess that would be
> easier for driver modules, if the userspace interfaces were designed
> with such combined IR Tx/Rx hardware in mind.
True, but, in the case of Rx, there are already API's for it. Tx case is
simpler, as we don't have any API for it yet.
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 conversion
to raw pulse/code, if the hardware requires pulse/code instead of scancodes.
However, as we have green field,
I would add the protocol explicitly for each scancode to be transmitted, like:
struct ir_tx {
enum ir_protocol proto;
u32 scancode;
};
Eventually, we might have a protocol "raw" and some extra field to allow passing
a raw pulse/code sequence instead of a scancode.
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Thu, 2009-11-26 at 10:36 -0200, Mauro Carvalho Chehab wrote: > Krzysztof Halasa wrote: > > Mauro Carvalho Chehab writes: > PS.: For those following those discussions that want to know more about > IR protocols, a good reference is at: > http://www.sbprojects.com/knowledge/ir/ir.htm > > Unfortunately, it doesn't describe RC6 mode 6. RC-6 Mode 0 and Mode 6A is briefly describe here: http://www.picbasic.nl/frameload_uk.htm?http://www.picbasic.nl/rc5-rc6_transceiver_uk.htm That page is slightly wrong, as there is some data coded in the header such as the RC-6 Mode. This page is an older version of the sbprojects.com RC-6 page, before the information on RC-6 Mode 6A was removed: http://slycontrol.ru/scr/kb/rc6.htm My personal opinion is that, for non-technical reasons, RC-6 Mode 6A decoding should not be included in the kernel. That's why I didn't do it for the HVR-1850/CX23888. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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, considering that some users may want to use lirc and some users may want to have their IR working out-of-the-box. By not using lirc, users will loose the advantages of having lircd, like clicking on a button and calling automatically the DVD player application, but this means that their device with the shipped IR will work without needing to do any setup. Whatever we do, both kind of usages should be possible, since there are demand for both. Also, the decision should consider that the existing drivers will need to support the new way without causing regressions. 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: Help needed with Hauppauge WinTV HVR-4000
On Thu, Nov 26, 2009 at 6:12 AM, Alan Ferrero 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 > (http://www.hauppauge.it/site/products/data_hvr4000.html). > > Days ago I installed Mythbuntu 9.10 (64 bit) on my HTPC, but I soon > found out the tv card didn't work. > Later, I learned that both firmware and driver included in Karmic were > bugged and didn't work. > So I followed the instructions reported at > http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000 to > install firmware 1.20.79.0 and instructions reported at > https://bugs.launchpad.net/mythbuntu/+bug/439163?comments=all to install > the patched driver (from: http://hg.kewl.org/v4l-dvb-20091103/). > > The end result? Nothing! > > Unfortunately, my HVR-4000 doesn't work yet! Test it on windows, the hardware could be faulty. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] New driver for the radio FM module on Miro PCM20 sound card
From: Krzysztof Helt
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 provides only basic functionality: frequency changing and
FM module muting.
Signed-off-by: Krzysztof Helt
Reviewed-by: Hans Verkuil
---
This is the second version of the patch with changes suggested by Hans Verkuil.
drivers/media/radio/Kconfig | 17 ++
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-miropcm20.c | 269 +
3 files changed, 287 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/radio-miropcm20.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index a87a477..b1df9f2 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -195,6 +195,23 @@ config RADIO_MAESTRO
To compile this driver as a module, choose M here: the
module will be called radio-maestro.
+config RADIO_MIROPCM20
+ tristate "miroSOUND PCM20 radio"
+ depends on ISA && VIDEO_V4L2
+ select SND_MIRO
+ ---help---
+ Choose Y here if you have this FM radio card. You also need to select
+ the "Miro miroSOUND PCM1pro/PCM12/PCM20radio driver" ALSA sound card
+ driver for this to work.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux API. Information on
+ this API and pointers to "v4l" programs may be found at
+ .
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-miropcm20.
+
config RADIO_SF16FMI
tristate "SF16FMI Radio"
depends on ISA && VIDEO_V4L2
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index 2a1be3b..8a63d54 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RADIO_TRUST) += radio-trust.o
obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o
obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o
obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o
+obj-$(CONFIG_RADIO_MIROPCM20) += radio-miropcm20.o
obj-$(CONFIG_USB_DSBR) += dsbr100.o
obj-$(CONFIG_RADIO_SI470X) += si470x/
obj-$(CONFIG_USB_MR800) += radio-mr800.o
diff --git a/drivers/media/radio/radio-miropcm20.c
b/drivers/media/radio/radio-miropcm20.c
new file mode 100644
index 000..6fd71f3
--- /dev/null
+++ b/drivers/media/radio/radio-miropcm20.c
@@ -0,0 +1,269 @@
+/* Miro PCM20 radio driver for Linux radio support
+ * (c) 1998 Ruurd Reitsma
+ * Thanks to Norberto Pellici for the ACI device interface specification
+ * The API part is based on the radiotrack driver by M. Kirkwood
+ * This driver relies on the aci mixer provided by the snd-miro
+ * ALSA driver.
+ * Look there for further info...
+ */
+
+/* What ever you think about the ACI, version 0x07 is not very well!
+ * I can't get frequency, 'tuner status', 'tuner flags' or mute/mono
+ * conditions...Robert
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+
+static int mono;
+module_param(mono, bool, 0);
+MODULE_PARM_DESC(mono, "Force tuner into mono mode.");
+
+struct pcm20 {
+ struct v4l2_device v4l2_dev;
+ struct video_device vdev;
+ unsigned long freq;
+ int muted;
+ struct snd_miro_aci *aci;
+};
+
+static struct pcm20 pcm20_card = {
+ .freq = 87*16000,
+ .muted = 1,
+};
+
+static int pcm20_mute(struct pcm20 *dev, unsigned char mute)
+{
+ dev->muted = mute;
+ return snd_aci_cmd(dev->aci, ACI_SET_TUNERMUTE, mute, -1);
+}
+
+static int pcm20_stereo(struct pcm20 *dev, unsigned char stereo)
+{
+ return snd_aci_cmd(dev->aci, ACI_SET_TUNERMONO, !stereo, -1);
+}
+
+static int pcm20_setfreq(struct pcm20 *dev, unsigned long freq)
+{
+ unsigned char freql;
+ unsigned char freqh;
+ struct snd_miro_aci *aci = dev->aci;
+
+ dev->freq = freq;
+
+ freq /= 160;
+ if (!(aci->aci_version == 0x07 || aci->aci_version >= 0xb0))
+ freq /= 10; /* I don't know exactly which version
+ * needs this hack */
+ freql = freq & 0xff;
+ freqh = freq >> 8;
+
+ pcm20_stereo(dev, !mono);
+ return snd_aci_cmd(aci, ACI_WRITE_TUNE, freql, freqh);
+}
+
+static const struct v4l2_file_operations pcm20_fops = {
+ .owner = THIS_MODULE,
+ .ioctl = video_ioctl2,
+};
+
+static int vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *v)
+{
+ strlcpy(v->driver, "Miro PCM20", sizeof(v->driver));
+ strlcpy(v->card, "Miro PCM20", sizeof(v->card));
+ strlcpy(v->bus_info, "ISA", sizeof(v->bus_info));
+ v
Mantis – anyone?
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 seems to work, CI handling looks quite broken, hangups/lockups are the rule, additional problems with more than one of these cards in the system. • mantis-v4l: does not compile out of the box for recent kernels. When hand-knitting the files into a kernel source directory (2.6.31), works quite unstable, module reloading frequently segfaults. IR does not work (at least for VDR), CI handling looks better than s2-liplianin. Conclusion: Stability is way below a level for reasonable usage while bug fixing. [1] gives an overview of the current state of (non-)development. Does this still apply? My questions are: • Is there someone feeling responsible for that baby? • What is the main part of the mantis stuff not working – mantis itself, the frontend, or adaptions from multiproto to s2api? • What can someone owning some of these cards (one Terratec, two Technisat) do to help the (former) authors to continue their work? • Is there some documentation available which would enable ‘the community’ to work on that further? Cheers, – Matthias 1: http://linuxtv.org/wiki/index.php/Azurewave_AD_SP400_CI_%28VP-1041%29#Drivers -- 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
Krzysztof Halasa wrote: > Mauro Carvalho Chehab 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 the driver generates artificial pulse code for lircd? > I think - pure bloat. lircd can get events from input layer without > problems. Perhaps I misunderstood? 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. > >> It is very bad to have two interfaces for the same thing, because people >> may do things like that. > > I think having a "raw" scan code interface + the key code "cooked" mode > is beneficial. For remotes lacking the raw interface only the latter > could be used. It sounds an interesting idea. >> Are you meaning that we should do more than one RC per input event >> interface? > > I think so. Why not? > > For example, one of my remotes generates codes from at least two RC5 > groups (in only one "mode"). Currently a remote is limited to only one > RC5 group. Yet, both are RC5. This can already be handled by the input layer. See dvb-usb implementation. 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. > > I think the mapping should be: key = proto + group + raw code, while > key2 could be different_proto + different group (if any) + another code. This may work for protocols up to RC5, that uses either 8 or 16 bits. However, RC6 mode 6 codes can be 32 bits, and we have "only" 32 bits for a scancode. So, we don't have spare bits to represent a protocol, if we consider RC6 mode 6 codes as well. >> If so, why do you think we need to handle more than one IR protocol at >> the same time? > > Why not? > There are X-in-1 remotes on the market for years. They can "speak" many > protocols at once. One may want to have a protocol to handle DVD apps > while another for DVB etc. > And someone may want to use several different remotes, why not? > Personally I use two different remotes (both set to speak RC5 but what > if I couldn't set the protocol?). Sure, it requires a bit of hackery > (not with pulse code and lircd). > >> I think this will just make the driver more complex without need. > > Not much more, and there is a need. 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. PS.: For those following those discussions that want to know more about IR protocols, a good reference is at: http://www.sbprojects.com/knowledge/ir/ir.htm Unfortunately, it doesn't describe RC6 mode 6. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
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 Halasa wrote: > >>> [...] > 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 > >>> unacceptable > >>> for many LIRC users, including myself. > >> > >> I agree with Christoph. > >> > >> Is it that the input subsystem is better developed and seen as a > >> leverage point for development and thus an "easier" place to get results > >> earlier? If so, then one should definitely deal with transmitters early > >> in the design, as that is where the most unknowns lie. > >> > >> With the end of analog TV, people will have STBs feeding analog only > >> video cards. Being able to change the channel on the STB with an IR > >> transmitter controlled by applications like MythTV is essential. > >> > >> > >> And on some different notes: > >> > >> 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 setup, the suggestions so far don't strike me as any > >> simpler for the end user than LIRC -- maybe I'm just used to LIRC. LIRC > >> already works for both transmit and receive and has existing support in > >> applications such as MythTV and mplayer. > > > > Is it that LIRC supports MythTV and mplayer or MythTV and mplayer are > > forced to support lirc because the remores are not available through > > other means? I believe it is the latter and applications writers would > > be happy to reduce number of ways they get button data. > > Well, when mythtv was started, I don't know that there were many input layer > remotes around... lirc was definitely around though. serial receivers and > transmitters, both supported by lirc_serial, were the most frequently used > devices outside of plain old keyboards. The lirc support in mythtv actually > relies on mapping remote button names as defined in lircd.conf to keyboard > key strokes. As mentioned elsewhere in this beast of a thread, mythtv doesn't > currently support things like KEY_PLAY, KEY_VOLUMEUP, KEY_CHANNELUP, etc. > just yet, but I intend on fixing that... > > > I don't think there is LIRC aversion per se. We are just trying to > > decide whether multiple interfaces for the same data is needed. And > > I don't think that we will completely reject userspace components. Just > > as input subsystem allows for userspace drivers I do not think why we > > can't have the same for the LIRC. But I do think that the primary > > interface for regular userspace consumers (read mplayer and MythTV and > > the likes) should be input event interface (EV_KEY/KEY_*). > > Works for me. Even though two interfaces is a bit of "extra" work, I'm not averse to Gerd's suggestions of a dual implementation: input layer for the simple, common use case, and lirc type interface for more sophisticated usage. One thing I would like to be provided by the input layer is automatic key-up after a specified time. Remote protocols send an initial button press and then after a certain amount of time (~115 ms for RC-5) send a repeated code or repeat sequence, if the button is still pressed. Currently, most of the V4L-DVB drivers have some code to perform a timeout just to send the key-up event. That's a good bit of redundant code for key-up timeouts that I suspect makes sense for the input layer to handle. 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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Krzysztof Halasa wrote: > Mauro Carvalho Chehab 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 bttv and saa7134 devices that polls (or >> receive >> IRQ interrupts) to detect pulses (and the absense of them) in order to create >> a pulse/space code. The conversion from pulse/space to scancode is done >> inside >> the driver, with the help of some generic routines and based on the protocol >> specifications. > > Right. There are currently several problems (I'm quite familiar with > saa713x RC5 code): the one that it barely works and is not implemented > for most such "GPIO/IRQ-driven" cards (as of 2.6.29 or so). This could > be fixed, I even have a working though quick&dirty patch. Another: the > RC5 allows for groups and codes within groups. The mapping can only use > one group, and there can only be one mapping. These design limitations > mean it's unusable in many cases. This is a current limitation, since the saa713x code converts the RC5 code into a 7bits scancode, by applying a mask. One of the reasons for that conversion is that the two ioctls that allows reading/changing the keycode table (EVIOCSKEYCODE and EVIOCGKEYCODE) were implemented via a table with a fixed size of 128 entries. We already have an implementation at the dvb-usb driver that uses a table without such limits, where the IR scancode is completely stored there. So, you can create any arbitrary scancode <--> keycode table there. 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 causing regressions, and to find a group of people that will help testing the new way. Maybe one alternative would be to add a modprobe parameter at the converted drivers to allow them to work with the old behavior, after their migration. >> Those devices where the decoding is done by software can support any >> IR protocols. > > Yes, and there can be multiple remote controllers, and multiple code > groups within a remote. > >> This can be solved by adding a few ioctls to enumerate the supported >> protocols and to select the one(s) that will be handled by the kernel >> driver. > > The driver may have to handle many protocols simultaneously. This is not > a problem from a technical POV. There are 3 different situations: 1) hardware where you can support multiple protocols at the same time; 2) hardware that supports one programmable protocol; 3) hardware that support just one (or a limited set) of protocols. In general, (1) applies only to those devices that outputs a raw pulse/space code, where they just connect the IR sensor to a generic I/O pin and let the software to decode the code. This is the case of most of cheapest devices. Yet, you can find some cheap devices with low-cost micro-controllers with a dedicated firmware on its ROM, doing (2). The most commonly found hardware, in general have a chip to decode IR pulse/space sequences, converting it on a scancode and implementing (3). That's said, a raw input interface, only fits on case (1). On the other hand, the existing input API works for all types of IR. However, we need to add the ioctls to allow protocol selection, to better handle (1) and (3). 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: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
> 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 from > 'tzap'. > > Kind regards, > Vince revert patch attached > > > On 11/26/09, Robert Lowery wrote: >>> 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 >>> screeching audio. >>> >>> I have traced this issue down to >>> http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies >>> for >>> DVB @ 6MHz) >> Actually, in addition to the above changeset, I also had to revert >> http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T) to get >> things going. Seems this one might have been an attempt to fix an issue >> introduced by the latter, but for me both must be reverted. >> >> -Rob >> >>> >>> In this change, the offset used by my card has been changed from >>> 275 >>> to 225. >>> >>> The old code which works used to do something like >>> offset = 275 >>> if (((priv->cur_fw.type & DTV7) && >>> (priv->cur_fw.scode_table & (ZARLINK456 | DIBCOM52))) || >>> ((priv->cur_fw.type & DTV78) && freq < 47000)) >>> offset -= 50; >>> >>> In Australia, (type & DTV7) == true _BUT_ scode_table == 1<<29 == >>> SCODE, >>> so the subtraction is not done. >>> >>> The new code which does not work does >>> if (priv->cur_fw.type & DTV7) >>> offset = 225; >>> which appears to be off by 500khz causing the tuning regression for me. >>> >>> Could any one please advice why this check against scode_table & >>> (ZARLINK456 | DIBCOM52) was removed? >>> >>> Thanks >>> >>> -Rob >>> >>> >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" >>> in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" >> in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > 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 > revert.diff Description: Binary data
