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: > > On Sat, May 15, 2021 at 10:22:26AM +0100, Sean Young wrote: > > > On Fri, May 14, 2021 at 01:16:47PM +0200, Johan Hovold wrote: > > > > On Tue, May 11, 2021 at 11:32:19AM +0100, Sean Young wrote: > > > > > On Mon, May 10, 2021 at 10:15:14AM +0200, Johan Hovold wrote: > > > > > > On Thu, May 06, 2021 at 01:44:52PM +0100, Sean Young wrote: > > > > > > > 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
