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 28 Nov 2009 15:30 Jon Smirl <jonsmirl(a)gmail.com> writes: > Endianess comes into play when send/receiving multibyte integers on > platforms with different endianess. It's the case when you're sending this data to a machine with a different endianness. For example, in a network or to another CPU in e.g. add-on card. Ioctls are not affected by this, since both ends are the same. Obviously you can be affected if you try to access data as integers in one point and as arrays of bytes in the other, but it has nothing to do with ioctls. -- 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 29 Nov 2009 07:10 Hi Mauro, on 28 Nov 09 at 09:21, Mauro Carvalho Chehab wrote: > Hi Christoph, > > Christoph Bartelmus wrote: >>> Maybe we decide to take the existing LIRC system as is and not >>> integrate it into the input subsystem. But I think there is a window >>> here to update the LIRC design to use the latest kernel features. >> >> If it ain't broke, don't fix it. [...] > So, even not being broken, the subsystem internal media API's changed > a lot during the last years, and there are still several new changes > on our TODO list. > > So, I'd say that if we can do it better, then let's do it. I'm not against improving things. If there are feature request that cannot be handled with an interface, it has to be extended or redesigned. But currently the LIRC interface supports all features that came up until now since many years. I just don't want to change a working interface just because it could be also implemented in a different way, but having no other visible advantage than using more recent kernel features. [...] >> For devices that do the decoding in hardware, the only thing that I don't >> like about the current kernel implementation is the fact that there are >> mapping tables in the kernel source. I'm not aware of any tools that let >> you change them without writing some keymaps manually. [...] > Still, I prefer first to migrate all drivers to use the full scancode and > re-generate the keymaps before such step. Good to see that this is in the works. [...] >> With the approach that you >> suggested for the in-kernel decoder, this device simply will not work for >> anything but RC-5. The devil is in all the details. > I haven't seen such limitations on his proposal. We currently have in-kernel > decoders for NEC, pulse-distance, RC4 protocols, and some variants. If > non-RC5 decoders are missing, we need for sure to add them. That was not my point. If you point a NEC remote at the Igor USB device, you won't be able to use a NEC decoder because the device will swallow half of the bits. LIRC won't care unless the resulting scancodes are identical. Granted, this is an esoteric arguement, because this device is utter garbage. [...] >> If we decide to do the >> decoding in-kernel, how long do you think this solution will need to >> become really stable and mainline? Currently I don't even see any >> consensus on the interface yet. But maybe you will prove me wrong and it's >> just that easy to get it all working. > The timeframe to go to mainline will basically depend on taking a decision > about the API and on people having time to work on it. > > Providing that we agree on what we'll do, I don't see why not > adding it on staging for 2.6.33 and targeting to have > everything done for 2.6.34 or 2.6.35. The problem that I see here is just that even when we have very talented people working on this, that put together all resources, we won't be able to cover all the corner cases with all the different receivers and remote control protocols out there. It will still require lots of fine-tuning which was done in LIRC over the years. >> I also understand that people want to avoid dependency on external >> userspace tools. All I can tell you is that the lirc tools already do >> support everything you need for IR control. And as it includes a lot of >> drivers that are implemented in userspace already, LIRC will just continue >> to do it's work even when there is an alternative in-kernel. > The point is that for simple usage, like an user plugging his new USB stick > he just bought, he should be able to use the shipped IR without needing to > configure anything or manually calling any daemon. This currently works > with the existing drivers and it is a feature that needs to be kept. Admittedly, LIRC is way behind when it comes to plug'n'play. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-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 29 Nov 2009 15:00 Hi, on 29 Nov 09 at 14:16, Jon Smirl wrote: > On Sun, Nov 29, 2009 at 2:04 PM, Alan Cox <alan(a)lxorguk.ukuu.org.uk> wrote: >>> Jon is asking for an architecture discussion, y'know, with use cases. [...] > So we're just back to the status quo of last year which is to do > nothing except some minor clean up. > > We'll be back here again next year repeating this until IR gets > redesigned into something fairly invisible like keyboard and mouse > drivers. Last year everyone complained that LIRC does not support evdev - so I added support for evdev. This year everyone complains that LIRC is not plug'n'play - we'll fix that 'til next year. There's progress. ;-) Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-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 29 Nov 2009 15:30 1. Do we agree that a lirc (-style) kernel-user interface is needed at least? 2. Is there any problem with lirc kernel-user interface? If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge the Jarod's lirc patches (at least the core) so at least the non-controversial part is done? Doing so doesn't block improving input layer IR interface, does it? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-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: Dmitry Torokhov on 29 Nov 2009 16:40
On Nov 29, 2009, at 12:27 PM, Krzysztof Halasa <khc(a)pm.waw.pl> wrote: > 1. Do we agree that a lirc (-style) kernel-user interface is needed at > least? > > 2. Is there any problem with lirc kernel-user interface? > > If the answer for #1 is "yes" and for #2 is "no" then perhaps we merge > the Jarod's lirc patches (at least the core) so at least the > non-controversial part is done? Isn't the meat of Jarod's patch the lirc interface? -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-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/ |