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 6 Dec 2009 15:40 Jon Smirl <jonsmirl(a)gmail.com> writes: >> Once again: how about agreement about the LIRC interface >> (kernel-userspace) and merging the actual LIRC code first? In-kernel >> decoding can wait a bit, it doesn't change any kernel-user interface. > > I'd like to see a semi-complete design for an in-kernel IR system > before anything is merged from any source. This is a way to nowhere, there is no logical dependency between LIRC and input layer IR. There is only one thing which needs attention before/when merging LIRC: the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, actually, making a correct IR core design without the LIRC merged can be only harder. -- 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 7 Dec 2009 15:10 Dmitry Torokhov <dmitry.torokhov(a)gmail.com> writes: >> There is only one thing which needs attention before/when merging LIRC: >> the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, >> actually, making a correct IR core design without the LIRC merged can be >> only harder. > > This sounds like "merge first, think later"... I'd say "merge the sane agreed and stable things first and think later about improvements". > The question is why we need to merge lirc interface right now, before we > agreed on the sybsystem architecture? Because we need the features and we can't improve something which is outside the kernel. What "subsystem architecture" do you want to discuss? Unrelated (input layer) interface? Those are simple things. The only part which needs to be stable is the (in this case LIRC) kernel-user interface. > Noone _in kernel_ user lirc-dev > yet and, looking at the way things are shaping, no drivers will be > _directly_ using it after it is complete. So, even if we merge it right > away, the code will have to be restructured and reworked. Sure. We do this constantly to every part of the kernel. > Unfortunately, > just merging what Jarod posted, will introduce sysfs hierarchy which > is userspace interface as well (although we not as good maintaining it > at times) and will add more constraints on us. Then perhaps it should be skipped, leaving only the things udev needs to create /dev/ entries. They don't have to be particularly stable. Perhaps it should go to the staging first. We can't work with the code outside the kernel, staging has not such limitation. > That is why I think we should go the other way around - introduce the > core which receivers could plug into and decoder framework and once it > is ready register lirc-dev as one of the available decoders. That means all the work has to be kept and then merged "atomically", it seems there is a lack of manpower for this. -- 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 8 Dec 2009 09:00 Dmitry Torokhov <dmitry.torokhov(a)gmail.com> writes: > Why woudl we want to do this? Quite often there is a need for "observer" > that maybe does not act on data but allows capturing it. Single-user > inetrfaces are PITA. Lircd can work as a multiplexer. IMHO single-open lirc interface is ok, though we obviously need simultaneous operation of in-kernel decoders. -- 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 8 Dec 2009 09:10 Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > Yes, an opaque type for scancode at the userspace API can be better, but > passing a pointer to kernel will require some compat32 logic (as pointer > size is different on 32 and 64 bits). Yes. I think we can't avoid that, but it's a single compat handler, I wouldn't worry about it too much. We don't need it in every driver fortunately. > We may use something like an u8[] with an arbitrary large number of > bytes. Yes. All of this pointed to by the pointer. > In this case, we need to take some care to avoid LSB/MSB troubles. Sure. -- 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 8 Dec 2009 09:10
Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > I don't think we need an userspace interface for the in-kernel > decoders. Of course we need it, to set (and probably retrieve) scancode-keycode mappings. This could probably be, ATM, the existing input layer channel. > All > it needs is to enable/disable the protocol decoders, imo via sysfs interface. This isn't IMHO needed at all. The protocol is enabled when at least one key using it is configured, otherwise it's disabled. We probably need some "wildcard" as well, to capture decoded scancodes (through the input layer). This is BTW pure optimization, the protocol could stay enabled all the time, only wasting the cycles. -- 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/ |