[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m34oo1va2y.fsf@intrepid.localdomain>
Date: Tue, 08 Dec 2009 15:01:25 +0100
From: Krzysztof Halasa <khc@...waw.pl>
To: Mauro Carvalho Chehab <mchehab@...hat.com>
Cc: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Jon Smirl <jonsmirl@...il.com>,
hermann pitton <hermann-pitton@...or.de>,
Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
kraxel@...hat.com, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system?
Mauro Carvalho Chehab <mchehab@...hat.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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists