Andy Walls wrote:

On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:

quoted

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.

quoted

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

quoted

Cheers,
Mauro.