What are the goals for the architecture of an in-kernel IR system?
in [Kernel]
|
Prev: backlight: tdo24m: ensure chip select changes between transfers
Next: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
From: Dmitry Torokhov on 29 Nov 2009 00:00 On Sat, Nov 28, 2009 at 06:26:55PM -0500, Andy Walls wrote: > Jon, > > On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote: > > On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa <khc(a)pm.waw.pl> wrote: > > > Jon Smirl <jonsmirl(a)gmail.com> writes: > > > > > >> There are two very basic things that we need to reach consensus on first. > > >> > > >> 1) Unification with mouse/keyboard in evdev - put IR on equal footing. > > The only thing this buys for the user is remote/products bundles that > work out of the box. That can only be a solution for the 80% case. > > I don't hear users crying out "Please integrate IR with the input > system". I do hear users say "I want my remote to work", and "How can I > make my remote work?". Users are not specifically asking for this > integration of IR and the input system - a technical nuance. Right, but if remotes work users did not care if we went through 20 revisions of the interface and how much effort was wasted. When we talking about users here we do talk about application developers mostly, not the consumers. Well, consumers would bennefit of plug and play and proper power management too. -- 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/
From: Dmitry Torokhov on 29 Nov 2009 00:00 On Sat, Nov 28, 2009 at 11:32:01PM -0500, Andy Walls wrote: > On Sat, 2009-11-28 at 12:37 -0500, Jon Smirl wrote: > > On Sat, Nov 28, 2009 at 12:35 PM, Krzysztof Halasa <khc(a)pm.waw.pl> wrote: > > > Jon Smirl <jonsmirl(a)gmail.com> writes: > > > > > >> There are two very basic things that we need to reach consensus on first. > > >> > > >> 1) Unification with mouse/keyboard in evdev - put IR on equal footing. > > BTW, circa 1995 my serial mouse "Just Worked" in Linux. Sometime around > the release of Fedora Core 3 or 4, serial mice stopped being well > supported as input devices AFAICT. (I still have a dual boot > Windows95/Linux machine with a serial mouse because it has ISA slots.) > serport + sermouse combo should work well. At least I don't get any bug reports ;P > Are serial port connected IR devices going to see the same fate in this > model? > > > Why not consider IR devices as bi-directional communications devices vs. > input devices like mice or keyboards? Theoretically the TTY layer with > line discipline modules for underlying IR hardware could also interface > IR devices to user space. > > Sorry, the input subsystem cannot meet all the end user IR requirements. Again, what end users are you taling about here? An application that wants to prcess key (or button) presses? Or something entirely different, lice lirc itself? > I doubt it could easily support all the current user space only IR > drivers moving into the kernel. I suspect the serial port connected IR > devices will be deemed "too hard" and IR Tx as "not input" and dropped > on the floor. > > > The more I think about IR integration with input, the more I think any > effort beyond the plug-and-plug for default configurations is a waste of > time and effort. Something more is needed to handle the transmitters > and serial connected IRs. It's also too convenient to access USB IR > hardware from existing userspace drivers to bother porting into the > kernel. Having support 2 different interfaces for regular applications is also a waste of time and effort. The applications who don;t care about IRC protocol decoding should be able to just work with standard input 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/
From: Lennart Sorensen on 30 Nov 2009 12:50 On Sat, Nov 28, 2009 at 06:26:55PM -0500, Andy Walls wrote: > The only thing this buys for the user is remote/products bundles that > work out of the box. That can only be a solution for the 80% case. > > I don't hear users crying out "Please integrate IR with the input > system". I do hear users say "I want my remote to work", and "How can I > make my remote work?". Users are not specifically asking for this > integration of IR and the input system - a technical nuance. If such a > tecnical desire-ment drives excessive rework, I doubt anyone will care > enough about IR to follow through to make a complete system. Please integrate it so I can stop having issues with the lirc moduels when going to a new kernel version. > What does "equal footing" mean as an incentive anyway? The opportunity > to reimplement *everything* that exists for IR already over again in > kernel-space for the sake of developer technical desires? That's just a > lot of work for "not invented here" syndrome. IR transceivers are > arguably superior to keyboards and mice anyway because they can transmit > data too. I have no idea. I am sure you guys will come up with a great interface. I just use lirc with my mythtv box. -- Len Sorensen -- 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 30 Nov 2009 13:10 On Mon, Nov 30, 2009 at 03:33:52PM -0200, Mauro Carvalho Chehab wrote: > kevin granade wrote: > > On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab > > <mchehab(a)redhat.com> wrote: > > > >> After the boot, a device can open the raw API, disabling any in-kernel > >> decoding/handling and handle IR directly. Alternatively, an udev rule > >> can load a different keymap based on some config written on a file. > > > > This idea of the in-kernel decoding being disabled when the raw API is > > opened worries me. What guarantees that the following scenario will > > not happen? > > > > User uses apps which retrieve the decoded IR messages from the kernel. > > User installs an app which decodes messages via the raw API (not lirc). > > User's other applications no longer receive IR messages. > > > > I know the assumption has been that "only lirc will use the raw API", > > but this seems like a poor assumption for an API design to me. > > All those questions are theoretical, as we haven't a raw API code > already merged in kernel. So, this is just my understanding on how > this should work. > > If the user wants to use the raw interface, it is because the in-kernel > decoding is not appropriate for his usage Not necessarily, someone might just want to observe the data stream for one reason or enough. You would not believe how many times I wanted to use evtest from X but could not because X grabs the device and had to switch to console.... > (at least while such application > is opened). So, not disabling the evdev output seems senseless. You know what they say when you assume things? > > Btw, this is the same behavior that happens when some application directly > opens an evdev interface, instead of letting it to be redirected to stdin. Well, console applications don't get their input directly from event device but even if they did "not redirecting it to stdin" will not affect any other application that has the same event device open. This is a _huge_ difference. > > > A related question, what is an application developer who wishes to > > decode the raw IR signal (for whatever reason) to do? Are they > > *required* to implement full decoding and feed all the messages back > > to the kernel so they don't break other applications? > > If such application won't do it, the IR will stop working, while the > application is in use. > I don't think it is indication of a good solution. -- 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/
From: Dmitry Torokhov on 30 Nov 2009 14:10
On Mon, Nov 30, 2009 at 04:27:56PM -0200, Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: > > On Mon, Nov 30, 2009 at 03:33:52PM -0200, Mauro Carvalho Chehab wrote: > >> kevin granade wrote: > >>> On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab > >>> <mchehab(a)redhat.com> wrote: > >>> > >>>> After the boot, a device can open the raw API, disabling any in-kernel > >>>> decoding/handling and handle IR directly. Alternatively, an udev rule > >>>> can load a different keymap based on some config written on a file. > >>> This idea of the in-kernel decoding being disabled when the raw API is > >>> opened worries me. What guarantees that the following scenario will > >>> not happen? > >>> > >>> User uses apps which retrieve the decoded IR messages from the kernel. > >>> User installs an app which decodes messages via the raw API (not lirc). > >>> User's other applications no longer receive IR messages. > >>> > >>> I know the assumption has been that "only lirc will use the raw API", > >>> but this seems like a poor assumption for an API design to me. > >> All those questions are theoretical, as we haven't a raw API code > >> already merged in kernel. So, this is just my understanding on how > >> this should work. > >> > >> If the user wants to use the raw interface, it is because the in-kernel > >> decoding is not appropriate for his usage > > > > Not necessarily, someone might just want to observe the data stream for > > one reason or enough. You would not believe how many times I wanted > > to use evtest from X but could not because X grabs the device and had > > to switch to console.... > > > >> (at least while such application > >> is opened). So, not disabling the evdev output seems senseless. > > > > You know what they say when you assume things? > > > >> Btw, this is the same behavior that happens when some application directly > >> opens an evdev interface, instead of letting it to be redirected to stdin. > > > > Well, console applications don't get their input directly from event > > device but even if they did "not redirecting it to stdin" will not > > affect any other application that has the same event device open. > > > > This is a _huge_ difference. > > > >>> A related question, what is an application developer who wishes to > >>> decode the raw IR signal (for whatever reason) to do? Are they > >>> *required* to implement full decoding and feed all the messages back > >>> to the kernel so they don't break other applications? > >> If such application won't do it, the IR will stop working, while the > >> application is in use. > >> > > > > I don't think it is indication of a good solution. > > Well, maybe then we may have an ioctl to explicitly disable the evdev processing > of the data that could be applied to the raw IR interface, instead of making > assumptions. This is I think better. Still, this takes decision from one application and to another. Why don't we let consumers decide what they want to use? I.e if one does not want to use kernel-driven events - don't open that particular /dev/input/eventX but rather open event device created through uinput by lirc? -- 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/ |