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: Dmitry Torokhov on 29 Nov 2009 16:40 On Nov 29, 2009, at 12:44 PM, Jon Smirl <jonsmirl(a)gmail.com> wrote: > On Sun, Nov 29, 2009 at 3: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? > > Can you consider sending the raw IR data as a new evdev message type > instead of creating a new device protocol? No, I think it would be wrong. Such events are ill-suited for consumption by regular applications and would introduce the "looping" interface I described in my other email. > evdev protects the messages in a transaction to stop incomplete > messages from being read. If such property is desired we can add it to the new lirc-like interface, can't we? -- > 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 17:50 On Nov 29, 2009, at 1:47 PM, Jon Smirl <jonsmirl(a)gmail.com> wrote: > On Sun, Nov 29, 2009 at 4:29 PM, Dmitry Torokhov > <dmitry.torokhov(a)gmail.com> wrote: >> On Nov 29, 2009, at 12:44 PM, Jon Smirl <jonsmirl(a)gmail.com> wrote: >> >>> On Sun, Nov 29, 2009 at 3: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? >>> >>> Can you consider sending the raw IR data as a new evdev message type >>> instead of creating a new device protocol? >> >> No, I think it would be wrong. Such events are ill-suited for >> consumption by >> regular applications and would introduce the "looping" interface I >> described >> in my other email. > > Regular applications are going to ignore these messages. The only > consumer for them is the LIRC daemon. Which is just going to process > them and re-inject the events back into evdev again in a different > form. > > IR is an input device, what make it so special that it needs to by > pass this subsystem and implement its own private communications > scheme? So are HID devices (both USB and BT), PS/2 and so on. You are not arguing for sending unprocessed data from these devices through evdev. > >>> evdev protects the messages in a transaction to stop incomplete >>> messages from being read. >> >> If such property is desired we can add it to the new lirc-like >> interface, >> can't we? > > Why do you want to redesign evdev instead of using it? > I just said why in my previous email: looping is a mark of badly designed 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: Jarod Wilson on 30 Nov 2009 00:00 On Nov 29, 2009, at 4:31 PM, Dmitry Torokhov wrote: > 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? Patch 1 was the lirc interface, 2 and 3 are individual device drivers that use it. /me has some catching up to do on this thread after being partially detached from the computer over the holiday weekend here in the US... -- 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 30 Nov 2009 14:50 Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: >> That's a question that I have not answered for myself concludingly. >> Is a remote control really on exactly the same level as a keyboard or >> mouse? > > On some devices like STB and TV sets (most of modern LCD/Plasma TV's > run Linux), > they are at the same level. I'd say that the same applies to PC's that > the user has dedicated to work as an MCE. A remote can just _be_ keyboard and/or (sort of) mouse. -- 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: Krzysztof Halasa on 30 Nov 2009 15:10
Andy Walls <awalls(a)radix.net> writes: > Nonetheless I'd still rather debug a problem with a dead process in > userspace than an oops or panic (not that an end user cares) and avoid > the risk of filesystem corruption. I'll concentrate on IRQ-driven space/mark drivers/devices since it's what I've been using. They are: very simple hardware (as simple as a TSOP1836 3-pin receiver "chip" + a resistor), very simple driver (the hardware signals change in input state with IRQ). Something like maybe 50 lines of code + the (default) key mapping table. Anyway, you can't move the whole driver to userspace, as it has to handle IRQs with timestamps. It doesn't have to sleep. It's about the last thing I'd worry about WRT the stability. > So are we optimizing for the embedded/STB and HTPC with no keyboard use > case, or the desktop or HTPC with a keyboard for maintencance? IOW the question is: do we want to continue supporting keyboard-less machines? -- 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/ |