On Mon, May 17, 2021 at 11:35:22AM +0100, Sean Young wrote:

On Mon, May 17, 2021 at 11:30:39AM +0200, Johan Hovold wrote:

quoted

On Sat, May 15, 2021 at 10:22:26AM +0100, Sean Young wrote:

quoted

On Fri, May 14, 2021 at 01:16:47PM +0200, Johan Hovold wrote:

quoted

On Tue, May 11, 2021 at 11:32:19AM +0100, Sean Young wrote:

quoted

On Mon, May 10, 2021 at 10:15:14AM +0200, Johan Hovold wrote:

quoted

On Thu, May 06, 2021 at 01:44:52PM +0100, Sean Young wrote:

quoted

This is a new rc-core driver for the USB-UIRT which you can see here
http://www.usbuirt.com/

This device is supported in lirc, via the usb serial kernel driver. This
driver is both for rc-core, which means it can use kernel/BPF decoding
ec. Also this implement is superior because it can:
 - support learning mode
 - setting transmit carrier
 - larger transmits using streaming tx command

This looks like something which should have been implemented as a
line-discipline or serdev driver instead of reimplementing a minimal
on-off ftdi driver and tying it closely to the RC subsystem.

The device is an infrared device, I'm not sure what it is lost by
doing it this way. The "minimal on-off ftdi driver" is super trivial.

It's still code duplication (and I meant to say "one-off" above").

What is preventing you from supporting the above functionality through
lirc?

I guess you mean the userspace lirc daemon, as opposed to the /dev/lirc
chardev. If you use the lirc daemon, you don't use rc-core which comes with
IR decoding using BPF IR decoding or in-kernel decoders, automatic setup of
rc keymaps via udev. None of the modern ir-ctl/ir-keytable tooling will
work, including the IRP encoder/BPF compiler I'm working on (very slowly).

Ok, but apart from BPF that sound like other stuff and not the three
items you list above? Is there anything preventing those items from
being implemented in user space?

Well, after IR is decoded, you want to send decoded scancodes/key codes
to any input device, so your remote works just like any input device.

There is another advantage. IR decoding in userspace involves a lot more
context switches/scheduling, and it can feel laggy when the cpu is under
load (e.g. video decoding on the CPU). When you press pause/play/stop or
so you expect the response the instantatiously. A 100ms delay is noticable.

Alternatively the key-up events get delayed and you end up with multiple
un-intended button repeats. None of this happens with kernel decoding and
it feels very snappy.


Sean