lkml.org 
[lkml]   [2009]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateThu, 26 Nov 2009 14:35:39 -0200
FromMauro Carvalho Chehab <>
SubjectRe: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Andy Walls wrote:
> On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:

>> I'm not sure if all the existing hardware for TX currently supports only
>> raw pulse/code sequencies, but I still think that, even on the Tx case,
>> it is better to send scancodes to the driver, and let it do the conversion
>> to raw pulse/code, if the hardware requires pulse/code instead of scancodes.
>
> That seems like a decision which will create a lots of duplicative code
> in the kernel. Add it's just busy-work to write such code when a
> userspace application in common use already handles the protocols and
> sends raw pulses to hardware that expects raw pulses.

I don't see how this would create lots of duplicative code.

>> However, as we have green field,
>> I would add the protocol explicitly for each scancode to be transmitted, like:
>>
>> struct ir_tx {
>> enum ir_protocol proto;
>> u32 scancode;
>> };
>>
>> Eventually, we might have a protocol "raw" and some extra field to allow passing
>> a raw pulse/code sequence instead of a scancode.
>
> I think you would have to. 32 bits is really not enough for all
> protocols, and it is already partial encoding of information anyway.
>
> If the Tx driver has to break them down into pulses anyway,

Do all Tx drivers need handle pulse by pulse, or there are some that works
only with scancodes?

> why not have fields with more meaningful names
>
> mode
> toggle
> customer code (or system code or address),
> information (or command)
>
> According to
>
> http://slycontrol.ru/scr/kb/rc6.htm
>
> the "information" field could be up to 128 bits.

Seems fine to me.

> (Not that I'm going to put any RC-6 Mode 6A decoding/encoding in the
> kernel.)
>
> Regards,
> Andy
>
>> Cheers,
>> Mauro.
>
>



\
 
 \ /
  Last update: 2009-11-26 17:39    [from the cache]
©2003-2010