Am 18.12.2010 14:56, schrieb Andy Walls:
On Fri, 2010-12-17 at 22:24 -0200, Mauro Carvalho Chehab wrote:
Despite all discussions, we didn't reach an agreement yet.
There are some points to consider whatever solution we do:
1) A keycode table should be able to work with a generic raw decoder. So, on all
drivers, the bit order and the number of bits for a given protocol should be the same;
2) we should avoid to cause regressions on the existing definitions.
That's said, suggestions to meet the needs are welcome.
Just to throw out some ideas:
It appears to me that what you are looking at are communications
protocols with
a. a common Physical layer (PHY): a pulse distance protocol with a
common carrier freq, bit symbol encoding, leader pulse, trailer pulse,
and repeat sequence. The number of bits (and the leader pulse length?)
is allowed to vary.
b. differing Data Link layers (LL): the data link address can be
different lengths and in different places; so can the data payload, so
can the checks on address and data payload.
For the end user, I would present each PHY/LL combination a different
protocol. How the kernel implements it internally doesn't matter much.
It could be one raw decoder handling all the PHY/LL combinations that it
can, or one PHY decoder and several LL decoders.
The keytables should probably be working on cooked LL output from the
raw decoder. I think that will handle a lot of the issues you mention.
The output from a LL could include
destination address (from the transmitted code),
source address (useful if different remotes can be detected),
payload length,
payload, and
maybe button up/down.
The LL could swallow the automatic repeats, since they are just part of
the button up/down scheme.
Aside from backward compatibility with existing keytables, I don't see
much point in a decoder trying to flip bits from the PHY layer around to
present a pseudo-PHY layer output. Don't keytables get updated with the
kernel release anyway, or did they all move to userspace utils?
Anyway, just some thoughts.
Regards,
Andy
Thanks,
Mauro
TM5600, TM6000 and TM6010 IR
==========================
It give two ways to receive data
1. over the control pipe (ep0)
- polling must stop if it loads firmware
- data length are a byte (command)
2. over interrupt pipe (only TM6010)
- data length are two bytes (address << 8 | command)
It has any control registers to configure IR (protocol ...)
TM6010_REQ07_RD8_IR
??, we use 0x2f
TM6010_REQ07_RD8_IR_BSIZE
??
TM6010_REQ07_RD8_IR_WAKEUP_SEL
command mask, I think, we use here 0xff
TM6010_REQ07_RD8_IR_WAKEUP_ADD
address mask, we use 0xff
TM6010_REQ07_RD8_IR_LEADER1
TM6010_REQ07_RD8_IR_LEADER0
is a 16bit register
for NEC 0xaa30
TM6010_REQ07_RD8_IR_PULSE_CNT1
TM6010_REQ07_RD8_IR_PULSE_CNT0
is a 16bit register
for NEC 0x20d0
Stefan Ringel
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
