Is irsend supported with devinput?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Is irsend supported with devinput?

Piotr Oniszczuk
Hi,
I’m courious: is it possible to have MCEUSB receiving via devinput and sending via IRSEND?
I’m on 4.11.6, lirc-0.10rc1.
lircd runs via following command:

lircd —device=/dev/input/event6 --driver devinput --debug -n /etc/lirc/lircd.conf.d/lircd.conf.devinput

event6 is from my MCEUSB dongle.

Receiving commands works.

Issuing

irsend list devinput-32 ""

shows long list of available keys.

but issuing i.e.:

root@FE-IntelNUC:~ # irsend send_once devinput-32 KEY_POWER

gives me:

hardware does not support sending
Error running command: Input/output error  


lidcd reports:

lircd-0.10.0rc1[8811]: Notice: accepted new client on /var/run/lirc/lircd
lircd-0.10.0rc1[8811]: Debug: Sending once, msg: send_once devinput-32 KEY_POWER
, args: devinput-32 KEY_POWER, once: 1
lircd-0.10.0rc1[8811]: Debug: Sending error
lircd-0.10.0rc1[8811]: Error: error processing command: send_once devinput-32 KEY_POWER
lircd-0.10.0rc1[8811]: Error: hardware does not support sending
lircd-0.10.0rc1[8811]: Info: removed client

where issue might be?


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is irsend supported with devinput?

Alec Leamas


On 19/06/17 22:23, Piotr Oniszczuk wrote:

> Hi,
> I’m courious: is it possible to have MCEUSB receiving via devinput and sending via IRSEND?
> I’m on 4.11.6, lirc-0.10rc1.
> lircd runs via following command:
>
> lircd —device=/dev/input/event6 --driver devinput --debug -n /etc/lirc/lircd.conf.d/lircd.conf.devinput
>
> event6 is from my MCEUSB dongle.
>
> Receiving commands works.
>
> Issuing
>
> irsend list devinput-32 ""
>
> shows long list of available keys.
>
> but issuing i.e.:


This won't work, since the devinput driver is just a thin layer on top
of the kernel decoding which does not support sending at all.

In many cases when using the devinput driver it's possible to use the
default driver instead; this supports sending. However, this requires a
lircd.conf file describing the remote. And, to work, the kernel driver
must set up a /dev/lirc0 device which the default driver can use,

Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is irsend supported with devinput?

Piotr Oniszczuk
In reply to this post by Piotr Oniszczuk
Alec,

Ok - got it.
This effectively excludes very effective setup where all IR subsystem configuration for receiving and sending will be minimized to practically zero effort (assuming IR controlled application uses key name space conformant with linux input.h).

Sad. 

Solution You proposed removes main goal I want to achieve: zero configuration for IR in MiniMyth2. (as user will still need to provide correct lircd.conf I assume).

I had another idea:
-use devinput for receiving (lircd with devinput driver + lircd.conf generated from linux.h)
-use default driver for sending

Both lircd instances are using different sockets, protocols (RC6 and LIRC) and inputs (inputX and lirc0).

I was able to get this running but it is not working due following issue:

any usage irsend turnoff RC6 protocol - so receiving stops working.
Manual enabling RC6 brings back receiving  - and again - any usage irsend turnoffs again RC6 protocol.

It looks like usage of default driver automatically turnoffs any other protocols than LIRC 
Is this behavior expected?  

If there will be way to disable this other-than-LIRC protocol turningoff - then maybe solution I'm proposing will offer final goal (IR zero config)



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is irsend supported with devinput?

Alec Leamas
Hi!

On 20/06/17 11:23, Piotr Oniszczuk wrote:


> This effectively excludes very effective setup where all IR subsystem
> configuration for receiving and sending will be minimized to practically
> zero effort.

Yes. But the kernel stuff is out of control for us.

> I had another idea:
> -use devinput for receiving (lircd with devinput driver + lircd.conf
> generated from linux.h)
> -use default driver for sending
>
> Both lircd instances are using different sockets, protocols (RC6 and
> LIRC) and inputs (inputX and lirc0).

Yes. But they will still collide on the actual kernel/physical device
which leads to problems...

> any usage irsend turnoff RC6 protocol - so receiving stops working.
> Manual enabling RC6 brings back receiving  - and again - any usage
> irsend turnoffs again RC6 protocol.

... like these

> It looks like usage of default driver automatically turnoffs any other
> protocols than LIRC. Is this behavior expected?

More or less, yes. Accessing the same kernel device from two different
drivers is, well, not strictly defined. This is more about the kernel
than lirc.

> If there will be way to disable this other-than-LIRC protocol turningoff
> - then maybe solution I'm proposing will offer final goal (IR zero config)

Realistically, there are really only one zero-config usecase supporting
blasting:  The default driver + an existing lircd.conf file available
using irdb-get(1) or so. And hardware with rc (i. e., /dev/lirc0) kernel
support).

OTOH, most users don't do blasting. For these, the devinput driver
supports anything supported by the kernel. This is IMHO a big enough
userbase to care about.



Cheers!

--alec

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Loading...