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.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
