What are the goals for the architecture of an in-kernel IR system?
in [Kernel]
|
Prev: [PATCH 2/3] sched: make tunable scaling style configurable
Next: [PATCH] pata_rdc: MWDMA0 is unsupported
From: Krzysztof Halasa on 8 Dec 2009 10:30 Mauro Carvalho Chehab <mchehab(a)redhat.com> writes: > The enable/disable protocol decoder enable/disable interface is needed anyway, > due to the needs for the hardware IR decoders Why do they need it exactly? The key tables say all they need I hope? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Krzysztof Halasa on 8 Dec 2009 10:30 Dmitry Torokhov <dmitry.torokhov(a)gmail.com> writes: > No, the IR core responsible for registering receivers and decoders. Well. This makes me think now that LIRC can be just "another decoder". >> Those are simple things. The only part which needs to be stable is the >> (in this case LIRC) kernel-user interface. > > For which some questions are still open. I believe Jon just oulined some > of them. Those are rather "how does it work", not "let's change something because it's not optimal". > No we do not. We do not merge something that we expect to rework almost > completely (no, not the lirc-style device userspace inetrface, although > even it is not completely finalized I believe, but the rest of the > subsystem). I don't think we need to rework it almost completely. Perhaps we need to change a hook here or there. > No, not at all. You merge core subsystem code, then start addig > decoders... You must have at least one common decoder merged with the core code, otherwise you don't know if the core is adequate. And you have to have at least one common input device. But perhaps it is a workable idea after all, given the "another decoder". -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Bartelmus on 8 Dec 2009 17:40 Hi Andy, on 07 Dec 09 at 23:10, Andy Walls wrote: [...] > (Christoph can correct me if I get anything wrong.) Just a few additions. [...] >> What is the time standard for the data, where does it come from? > I think it is usec, IIRC. Yes, it is. > I know that the hardware I work with has sub 100 ns resolution, Highest IR carrier frequency I know is 500kHz. usec resolution is enough even for raw modulated IR pulses. But you only look at the signal after it has been demodulated by the IR chip, so higher resolution would be overkill. [...] >> How do you define the start and stop of sequences? > For the end of Rx signalling: > > Well with the Conexant hardware I can set a maximum pulse (mark or > space) width, and the hardware will generate an Rx Timeout interrupt to > signal the end of Rx when a space ends up longer than that max pulse > width. The hardware also puts a special marker in the hardware pulse > widht measurement FIFO (in band signalling essentially). > > I'm not sure anything like that gets communicated to userspace via > lirc_dev, and I'm too tired to doublecheck right now. There is no such thing in the protocol. Some devices cannot provide any end of signal marker, so lircd handles this using timers. If there is some interest, the MODE2 protocol can be extended. We still have 7 bits unused... > If you have determined the protocol you are after, it's easy to know > what the pulse count should be and what the max pulse width should be (+ > slop for crappy hardware) so finding the end of an Rx isn't hard. The > button repeats intervals are *very* large. I've never seen a remote > rapid fire codes back to back. I did. There are some protocols that have a gap of only 6000 us between signals. And the settop boxes are very picky about this. If you make it too long, they won't accept the command. [...] >> Is transmitting synchronous or queued? > kfifo's IIRC. No, it's synchronous. >> How big is the transmit queue? No queue. [...] > My particular gripes about the current LIRC interface: > > 1. The one thing that I wish were documented better were the distinction > between LIRC_MODE_PULSE, LIRC_MODE_RAW, and LIRC_MODE2 modes of > operation. I think I've figured it out, but I had to look at a lot of > LIRC drivers to do so. No driver uses RAW until now and lircd does not support it. PULSE is used on the transmit path, MODE2 on the receive path. There is no special reasoning for that, it's rather historic. MODE2 makes sense on the receive path because you can easily distinguish between pulse/space. > 2. I have hardware where I can set max_pulse_width so I can optimize > pulse timer resolution and have the hardware time out rapidly on end of > RX. I also have hardware where I can set a min_pulse_width to set a > hardware low-pass/glitch filter. Currently LIRC doesn't have any way to > set these, but it would be nice to have. Should be really easy to add these. The actual values could be derived from the config files easily. > In band signalling of a > hardware detected "end of Rx" may also make sense then too. See above. > 3. As I mentioned before, it would be nice if LIRC could set a batch of > parameters atomically somehow, instead of with a series of ioctl()s. I > can work around this in kernel though. Is there any particular sequence that you are concerned about? Setting carrier frequency and then duty cycle is a bit problematic. Currently it's solved by resetting the duty cycle to 50% each time you change the carrier frequency. But as the LIRC interface is "one user only", I don't see a real problem. Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Bartelmus on 8 Dec 2009 17:40
Hi Dmitry, on 06 Dec 09 at 23:51, Dmitry Torokhov wrote: [...] >>> I suppose we could add MSC_SCAN_END event so that we can transmit >>> "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by >>> MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32 >>> bit. >> >> And I set a timeout to know that no MSC_SCAN_END will arrive? This is >> broken design IMHO. >> > EV_SYN signals the end of state transmission. >> Furthermore lircd needs to know the length of the scan code in bits, not >> as a multiple of 32. > I really do not think that LIRCD is the type of application that should > be using evdev interface, but rather other way around. Well, all I'm asking is that lircd can keep using the LIRC interface for getting the scan codes. ;-) Christoph -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |