Re: [PATCH v2 01/25] media: lirc: implement scancode sending

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09/10/17 17:11, Sean Young wrote:
> On Mon, Oct 09, 2017 at 11:14:28AM +0200, Hans Verkuil wrote:
>> On 05/10/17 10:45, Sean Young wrote:
> -snip-
>>> +/*
>>> + * struct lirc_scancode - decoded scancode with protocol for use with
>>> + *	LIRC_MODE_SCANCODE
>>> + *
>>> + * @timestamp: Timestamp in nanoseconds using CLOCK_MONOTONIC when IR
>>> + *	was decoded.
>>> + * @flags: should be 0 for transmit. When receiving scancodes,
>>> + *	LIRC_SCANCODE_FLAG_TOGGLE or LIRC_SCANCODE_FLAG_REPEAT can be set
>>> + *	depending on the protocol
>>> + * @target: target for transmit. Unused, set to 0.
>>> + * @source: source for receive. Unused, set to 0.
>>> + * @unused: set to 0.
>>> + * @rc_proto: see enum rc_proto
>>> + * @scancode: the scancode received or to be sent
>>> + */
>>> +struct lirc_scancode {
>>> +	__u64	timestamp;
>>> +	__u32	flags;
>>> +	__u8	target;
>>> +	__u8	source;
>>> +	__u8	unused;
>>> +	__u8	rc_proto;
>>> +	__u64	scancode;
>>
>> I'm thinking how this will be implemented using CEC. Some RC commands take arguments
>> (up to 4 bytes for the 0x67 (Tune Function) code), so how will they be handled?
>>
>> See CEC table 6 in the HDMI 1.4 spec.
>>
>> Should they be part of the scancode, or would it be better to add a '__u8 args[8];'
>> field?
>>
>> I've no idea what makes sense, it's a weird corner case.
> 
> I've given it some more thought.
> 
> For cec remote control passthrough, you have the tv with the IR receiver (A),
> which then transmits CEC_MSG_USER_CONTROL_PRESSED and
> CEC_MSG_USER_CONTROL_RELEASED cec messages to the correct target, with
> arguments. Then on the target (B), it reads those commands and should execute
> them as if it received them itself.
> 
> First of all (B) is already implemented in cec using rc-core. If RC
> passthrough is enabled, then cec will pass those keycodes to rc-core (which
> end up in an input device).
> 
> So the problem we are trying to solve here is (A). How I would see this
> implemented is:
> 
> 1) A physical IR receiver exists which has an rc-core driver and a /dev/lircN
>    device. This is configured using ir-keytable to map to regular input events
> 
> 2) A process receives input events, and decides that a particular key/command
>    is not for itself (e.g. tell top set box to tune), so it knows what the
>    target cec address is and the tune arguments, so it fills out a 
>    cec_msg with the target, CEC_MSG_USER_CONTROL_PRESSED, 0x67, arguments,
>    and then transmits it using the ioctl CEC_TRANSMIT, followed by
>    another CEC_MSG_USER_CONTROL_RELEASED cec_msg sent using ioctl CEC_TRANSMIT.
> 
> In this way of viewing things, an rc-core device is either cec or lirc, and
> thus rc-core lirc devices have a /dev/lircN and rc-core cec devices have a
> /dev/cecN.
> 
> So, the alternative which is being proposed is that a cec device has both
> a /dev/cecN and a /dev/lircN. In this case step 2) would look like:
> 
> 2) A process receives input events, and decides that a particular key/command
>    is not for itself (e.g. tell top set box to tune), so it knows what the
>    target cec address is and the tune arguments, so it fills in a 
>    lirc_scancode with the target, CEC_MSG_USER_CONTROL_PRESSED, 0x67, arguments,
>    and then transmits it using write() to the /dev/lircN device, which
>    then passes it on to cec_transmit() in drivers/media/cec/cec-api.c
>    (without having a cec_fh), and then another lirc_scancode is
>    filled in CEC_MSG_USER_CONTROL_RELEASED and sent.
> 
> Now, I think that this has a number of problems:
> 
>  - It's a lot of API for simply doing a CEC_TRANSMIT
> 
>  - and another chardev for a cec device (i.e. /dev/lircN).
> 
>  - lirc scancode tx deals with scancodes, for cec rc passthrough it isn't
>    really scancodes.
> 
>  - Wiring this up is not going to be pretty or easy.
> 
>  - The lirc chardev has no other function other than sending
>    CEC_MSG_USER_CONTROL_PRESSED and CEC_MSG_USER_CONTROL_RELEASED cec messages.
>  
> So what I am proposing is that we don't use lirc for sending rc passthrough
> messages for cec.
> 
> I hope this makes sense and where not, please *do* tell me exactly where I
> am wrong. I think that I missed something about the scancode tx idea.

You are right, it makes no sense. Let's forget about this.

Regards,

	Hans

> 
>>
>>> +};
>>> +
>>> +#define LIRC_SCANCODE_FLAG_TOGGLE	1
>>> +#define LIRC_SCANCODE_FLAG_REPEAT	2
>>
>> These flags need documentation.
> 
> They do, fair point.
> 
> Thanks,
> 
> Sean
> 




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux