1 Jan 2010 06:48
Re: upcoming imon driver split
On Wed, Dec 30, 2009 at 06:32:00PM +0100, Christoph Bartelmus wrote:
> Hi!
>
> In general I just dislike moving to a new interface loosing functionality.
> If possible I'd like to keep the possibility to get the raw scancodes
> through the lirc interface.
Hrm. Two possibilities then...
1) I tack lirc support back in on top of this pure input layer imon
driver. I'd do this *after* getting lirc_dev also merged upstream
though, as this new driver should get in Real Soon Now.
2) We just keep lirc_imon with support for the newer devices as
something that can still be built/enabled (a la lirc_atiusb vs.
ati_remote{,2}).
> Even though there is a input driver for the ati remotes in the kernel for
> a long time I have the impression that many people still prefer to use the
> lirc_atiusb driver.
Well, as far as I can tell, that's mostly due to lack of understanding
of how the devinput usespace driver works. With mouse event passthrough,
there isn't any loss of functionality using the lirc devinput driver
with ati_remote{,2} vs. lirc_atiusb. I know I haven't bothered with
lirc_atiusb myself in ages for my RWII.
Honestly though, I'm not sure how much real benefit there is for the
imon driver to pass raw scancodes anymore, I think we've got everything
for the current devices pretty well covered, and new devices will
require code addition anyway. And the driver will spit out the raw
(Continue reading)
RSS Feed