Message-ID: <4B0EBF99.1070404@redhat.com>
Date:	Thu, 26 Nov 2009 15:49:13 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Jarod Wilson <jarod@...sonet.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Andy Walls <awalls@...ix.net>,
	Christoph Bartelmus <lirc@...telmus.de>, khc@...waw.pl,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, superm1@...ntu.com
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was:
 Re: [PATCH 1/3 v2] lirc core device driver infrastructure

Jarod Wilson wrote:
> On 11/26/2009 08:54 AM, Mauro Carvalho Chehab wrote:
>> Jarod Wilson wrote:
>>> On Nov 23, 2009, at 7:53 PM, Andy Walls wrote:
>>>
>>>> On Mon, 2009-11-23 at 22:11 +0100, Christoph Bartelmus wrote:
>>> ...
>>>> I generally don't understand the LIRC aversion I perceive in this
>>>> thread
>>>> (maybe I just have a skewed perception).  Aside for a video card's
>>>> default remote setup, the suggestions so far don't strike me as any
>>>> simpler for the end user than LIRC -- maybe I'm just used to LIRC. 
>>>> LIRC
>>>> already works for both transmit and receive and has existing support in
>>>> applications such as MythTV and mplayer.
>>>
>>> There's one gripe I agree with, and that is that its still not
>>> plug-n-play.
>>> Something where udev auto-loads a sane default remote config for say,
>>> mceusb transceivers, and the stock mce remote Just Works would be nice,
>>> but auto-config is mostly out the window the second you involve
>>> transmitters
>>> and universal remotes anyway.
>>
>> For several devices, an udev rule that auto-loads a sane default
>> keymap does work.
>> Of course, this won't cover 100% of the usages, and I lirc is a very
>> good way
>> of covering the holes.
>>
>>> But outside of that, I think objections are largely philosophical --
>>> in a nutshell, the kernel has an input layer, remotes are input devices,
>>> and lirc doesn't conform to input layer standards.
>>
>> Yes. I think this is mainly the issue.
>>
>> The other issue is how to migrate the existing drivers to a new API
>> without
>> causing regressions. If we decide that IR's that receive raw pulse/code
>> should use the raw input interface, this means that a large task force
>> will be
>> needed to convert the existing drivers to use it.
> 
> Aversion to regression is definitely a major concern. And why I'm liking
> the idea of a hybrid approach, at least initially.

Yes. This indeed seems to be a very good idea.
> 
>> What do you think of adding lirc at staging while we discuss/improve
>> the API's and lircd
>> support for the input event interface? Do you think this would work?
> 
> Sure, I don't see why not. And I've got another dozen or so drivers to
> follow those first three... :)

Ok. As you said you'll do some work at the patches, could you please send us v3
in order to add it into drivers/staging? 

In the case of the API header file, I would tag at the header file that the API
is experimental, so can be changed without prior announcements, etc (in order to
avoid people to use and rely on it it outside lirc). IMO, the better is to keep
such announcement there while we're still working at the hybrid approach, as we
may need to change something during the development phase.

Dmitry,

While lirc is basically a series of input drivers, considering that they have lots
in common with the input drivers at V4L/DVB and that we'll need to work on
some glue to merge both, do you mind if I add the lirc drivers at drivers/staging from
my trees? 

Cheers,
Mauro.

--
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