Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Thu, 2009-11-26 at 11:25 -0200, Mauro Carvalho Chehab wrote:
Andy Walls wrote:
On Mon, 2009-11-23 at 22:46 +0100, Krzysztof Halasa wrote:
lirc@xxxxxxxxxxxx (Christoph Bartelmus) writes:

I think we shouldn't at this time worry about IR transmitters.
Sorry, but I have to disagree strongly.
Any interface without transmitter support would be absolutely unacceptable
for many LIRC users, including myself.
I don't say don't use a transmitter.
I say the transmitter is not an input device, they are completely
independent functions. I can't see any reason to try and fit both in the
same interface - can you?

The underlying hardware need not be completely independent.

For example, the CX2584[0123], CX2388[578], CX23418, and CX2310[012]
chips have IR hardware that shares a common timing source, interrupt
line, interrupt status register, etc, between IR Rx and Tx. They can
also do things like loopback of Tx to Rx.

That said, an underlying hardware implementation can be split up to user
space with separate interfaces Tx and Rx. The underlying driver module
would have to manage the dependencies. I would guess that would be
easier for driver modules, if the userspace interfaces were designed
with such combined IR Tx/Rx hardware in mind.

True, but, in the case of Rx, there are already API's for it. Tx case is
simpler, as we don't have any API for it yet.

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.

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, 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.

(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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC] Should we create a raw input interface for IRs ? - Was: Re: [PATCH 1/3 v2] lirc core d
    ... Any interface without transmitter support would be absolutely unacceptable ... I don't say don't use a transmitter. ... The underlying hardware need not be completely independent. ... I would add the protocol explicitly for each scancode to be transmitted, ...
    (Linux-Kernel)
  • Re: [RFC] Staging:IIO: New ABI
    ... Hardware chip or device accessed by on communication port. ... An event driven driver of data capture to an in kernel buffer. ... There is already a well-defined api for these things. ... don't have a custom interface just for these device. ...
    (Linux-Kernel)
  • Re: Newbie Modelling Interface Question
    ... A client's access to this subsystem is ... interface has a message identifier and a by-value data packet. ... The client then has a pointer to each interface. ... For example, in a hardware interface, clients usually want to manipulate ...
    (comp.object)
  • Re: OpenGL-based framebuffer concepts
    ... Agreed that kernel should only deal with necessary tasks as minimum as ... Designing the interface inevitably involves clear understanding of the ... hardware capabilities and closed hardware spec is an obvious obstacle. ... Open Graphics card would be a great thing ...
    (Linux-Kernel)
  • Re: Cubase SX or Pro-Tools M-Powered?
    ... electronic type composers, MIDI editing, sound stretching etc while ... besides a history lesson and marketing targets, they all employ a 'hyper-tape' type setup unifying audio, midi, and automation in one interface, but obviously going beyond the abilities of tape. ... ProTools would restrict your choice of hardware. ...
    (rec.audio.pro)