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? Obviously a user-space implementation (e.g. accessing the device through /dev/ttyUSB0) is not going to be able to use in-kernel RC functionality. For that you'd need to use either a line-discipline or serdev driver, that is, a kernel driver, but not everything has to live in the kernel. > The other nice thing is that IR TX feeds data from an urb interrupt handler, > so you don't need to rely userspace being scheduled quickly enough to feed > more data before the device runs out. The tty layer and tty drivers provide write buffering so that need not be an issue. > > > > Why can't you just add support for the above features to whatever > > > > subsystem is managing this device today? > > > > > > > > Serdev still doesn't support hotplugging unfortunately so that route may > > > > take a bit more work. > > > > > > There seems to be at least three ways of attaching drivers to serial > > > devices: serio, serdev, and line-discipline. All seem to have limitations, > > > as you say none of them provide a way of hotplugging devices without > > > user-space attaching them through an ioctl or so. > > > > serio is also a line-discipline driver, which unlike serdev needs to be > > set up by user space. > > serio is unusable for this case. serio does not allow more than one byte > to be written nor does it have callbacks for CTS readiness. Ok, but you could still implement this as an rc-core line-discipline or serdev driver. And when you use hardware flow control as you do here, you shouldn't need any callbacks for CTS events either, right? > > And the problem with serdev is that it does not (yet) support > > hotplugging (specifically hangups) so it can't be enabled for USB serial > > just yet. > > > > > If you want to go down this route, then ideally you'd want a quirk on > > > fdti saying "attach usb-uirt serdev device to this pid/vid". Considering > > > module dependencies, I don't know how that could work without again > > > userspace getting involved. > > > > We'd just reuse or add another matching mechanism for USB devices. This > > can be handled without user-space interaction just fine as long as you > > have a dedicated device id as you do here. > > Right, ok. I don't quite follow what you have in mind. If at all possible > keep me in the loop for any patches for this, I'm happy to test/re-write > this driver and the drivers/media/rc/ir_toy.c driver on top of any such > patches. Thanks for that pointer. Judging from a quick look, the new driver appears to based on this one. By abstracting the serial interface bits in a generic RC serdev/ldisc driver you may be able reuse more code, even if I'm not in a position to judge how much of the IR protocol bits that can be shared. > There are a bunch old serial usb device IR devices and even older non-usb > serial devices that would be nice to have supported, if anyone is still > using them. I noticed that drivers/media/rc/serial_ir.c also appears to use a similar approach of implementing a minimal one-off serial (8250?) driver and tying it closely to RC core. This one might also benefit from using the standard serial drivers for the transport and having an RC layer on top. Currently it appears to use module-parameters for configuration instead of devicetree or some to-be-implemented interface for instantiating serdev devices from user space. Johan
