What are the goals for the architecture of an in-kernel IR system?
in [Kernel]
|
Prev: [PATCH 2/3] sched: make tunable scaling style configurable
Next: [PATCH] pata_rdc: MWDMA0 is unsupported
From: Krzysztof Halasa on 30 Nov 2009 15:10 kevin granade <kevin.granade(a)gmail.com> writes: > This idea of the in-kernel decoding being disabled when the raw API is > opened worries me. I don't think we need to disable the in-kernel decoding automatically. That would be rather unfortunate. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Bartelmus on 1 Dec 2009 02:50 Hi Jon, on 30 Nov 09 at 16:35, Jon Smirl wrote: [...] > It would be interesting to split the lirc daemon. Put the protocol > decoder stuff in one daemon and the scripting support in the other. > The scripting daemon would then be optional. What would be the > relative sizes of the two daemons? > > -------------- > > The LIRC daemon always works with timing data, right? Timing data or hex codes (if decoding is done in hardware). > When it reads > the config files generated by irrecord it internally converts those to > timing data No. > and then matches the incoming data against it. Pattern matching is only done with raw mode config files. The normal case is that lircd is decoding the incoming data using the protocol description found in the config file. > Have you looked at the protocol engine idea? Running the protocol > engines in parallel until a match is achieved. Then map the > vendor/device/command triplet. The protocol engine concept fixes the > problem of Sony remotes in irrecord. No, only rewriting irrecord would fix the problem of Sony remotes. irrecord tries to guess the protocol parameters without any prior knowledge about any protocols. irrecord could also be rewritten to use the protocol engine concept without changing anything in the decoder itself. In fact partly this is already available. You can give irrecord a template config file and it will skip the protocol guessing step. This just would have to be extended so that the template config file could contain several protocol descriptions to match against. I havn't implemented this yet, because I don't care much. Sony remotes do work flawlessly also in raw mode. It's only a problem from the aesthetic view point. > Various Sony remote buttons > transmit in different protocols. irrecord assumes that a remote is > only using a single protocol. Since it can't figure out a protocol it > always records these remotes as raw. With manual intervention you can convert these raw config files afterwards with "irrecord -a". [...] > Button on remote programed to be Mot DVR --> protocol engine --> > Mot/dev/command --> MythTV which is looking for Mot/dev/command > No config files needed. You just move complexity to the application. MythTV would have to know how a Motorola command set looks like. Currently I would tend to an approach like this: - raw interface to userspace using LIRC - fixed set of in-kernel decoders that can handle bundled remotes That would allow zero configuration for simple use cases and full flexibility for more advanced use cases. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jarod Wilson on 1 Dec 2009 09:40 On Dec 1, 2009, at 4:52 AM, Gerd Hoffmann wrote: > On 11/30/09 13:34, Mauro Carvalho Chehab wrote: >> Christoph Bartelmus wrote: >>> Hi Mauro, >>> >>> I just don't want to change a working interface just because it could be >>> also implemented in a different way, but having no other visible advantage >>> than using more recent kernel features. >> >> I agree. The main reasons to review the interface is: >> 1) to avoid any overlaps (if are there any) with the evdev interface; > > Use lirc for raw samples. > Use evdev for decoded data. This is the approach I'm pretty well settled on wanting to take myself. > Hardware/drivers which can handle both can support both interfaces. Exactly. > IMHO it makes no sense at all to squeeze raw samples through the input layer. It looks more like a serial line than a input device. In fact you can homebrew a receiver and connect it to the serial port, which was quite common in pre-usb-ir-receiver times. > >> 2) to have it stable enough to be used, without changes, for a long >> time. > > It isn't like lirc is a new interface. It has been used in practice for years. I don't think API stability is a problem here. Yeah, in the ~3 years I've been maintaining lirc patches for the Fedora kernels, only once has something happened where new userspace could no longer talk to old kernelspace. The majority of the work has been keeping things running as kernel interfaces change -- the 2.6.31 i2c changes are still biting us, as some capture card devices lagged behind a bit on converting to the new i2c scheme, making it impossible for lirc_i2c and/or lirc_zilog to bind (and ir-kbd-i2c, for that matter). >> True, but even if we want to merge lirc drivers "as-is", the drivers will >> still need changes, due to kernel CodingStyle, due to the usage of some API's >> that may be deprecated, due to some breakage with non-Intel architectures, due >> to some bugs that kernel hackers may discover, etc. > > I assumed this did happen in already in preparation of this submission? Yes. There may still be a bit of work to do here, but there was a crew of us about a year, year and a half ago, that did a major sweep through all the lirc drivers, reformatting things so that we were at least mostly checkpatch-clean. The original lirc patches I put into the Fedora Core 6 kernel had several thousand lines of warnings and errors, while with the current lirc patches in Fedora 12, I get: total: 1 errors, 12 warnings, 15987 lines checked The error is new, hadn't seen that one before, going to fix it now... :) The warnings are almost all the same thing, "WARNING: struct file_operations should normally be const", need to fix that too, though we actually do edit the lirc_fops on a per-device basis right now, so they can't be const... Okay, the error and one of the warnings are gone from my local tree, now its all just the above. But yeah, for the most part, I think the coding style and formatting of the lirc drivers *does* look like kernel code these days, minor fixages suggested in Mauro's review aside. I submitted only a 3-part series (lirc_dev, lirc_mceusb and lirc_imon) to keep from overwhelming anyone (myself included) with too much code at once, and went with the two device drivers that I've personally done the most work on and have several devices driven by (which includes the IR parts I've been using in my "production" MythTV setup for years now). -- Jarod Wilson jarod(a)wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jarod Wilson on 2 Dec 2009 23:40 On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote: >> Anyway, we shouldn't postpone lirc drivers addition due to that. There are still lots of work >> to do before we'll be able to split the tables from the kernel drivers. > > Indeed. The sysfs bits are future work for both lirc and evdev drivers. There is no reason to make the lirc merge wait for it. At this point, my plan is to try to finish cleaning up lirc_dev and lirc_mceusb at least over the weekend while at FUDCon up in Toronto, and resubmit them next week. I'm still on the fence over what to do about lirc_imon. The driver supports essentially 3 generations of devices. First-gen is very old imon parts that don't do onboard decoding. Second-gen is the devices that all got (insanely stupidly) tagged with the exact same usb device ID (0x15c2:0xffdc), some of which have an attached VFD, some with an attached LCD, some with neither, some that are actually RF parts, but all (I think) of which do onboard decoding. Third-gen is the latest stuff, which is all pretty sane, unique device IDs for unique devices, onboard decoding, etc. So the lirc_imon I submitted supports all device types, with the onboard decode devices defaulting to operating as pure input devices, but an option to pass hex values out via the lirc interface (which is how they've historically been used -- the pure input stuff I hacked together just a few weeks ago), to prevent functional setups from being broken for those who prefer the lirc way. What I'm debating is whether this should be split into two drivers, one for the older devices that don't do onboard decoding (which would use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy', and one that is a pure input driver, not unlike the ati_remote{,2} drivers, with no lirc_dev dependency at all, probably called simply 'imon'. Could still be used with lirc via its devinput userspace driver, of course. But if I split it out, there may end up being a fair amount of code duplication, and the resulting lirc_imon wouldn't be as interesting to submit, and I wouldn't have any devices that worked with it, I've only got onboard decode devices... The new imon input driver would be a separate submission that is completely irrelevant to this whole discussion. So perhaps for round three, lirc_dev, lirc_mceusb and lirc_zilog, to make it more interesting... -- Jarod Wilson jarod(a)wilsonet.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on 3 Dec 2009 12:40
lirc(a)bartelmus.de (Christoph Bartelmus) writes: > Currently I would tend to an approach like this: > - raw interface to userspace using LIRC > - fixed set of in-kernel decoders that can handle bundled remotes I'd modify it a bit: - raw interface to userspace using LIRC - fixed set of in-kernel decoders Longer term: Removing the key assignment tables from the kernel. Plug-and-play can be then achieved with udev. The only thing needed from the kernel is indicating the tuner/sensor type, udev can guess the bundled remote type. Porting the in-kernel drivers (such as ir-common) to LIRC interface (while not removing the input layer mode). -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |