On Wed, Jun 23, 2021 at 03:10:20PM +0200, Johan Hovold wrote: > Sorry about the late reply on this one too. > > On Tue, May 25, 2021 at 02:25:49PM +0200, Oliver Neukum wrote: > > Am Donnerstag, den 20.05.2021, 15:31 +0200 schrieb Johan Hovold: > > > > Isn't that already handled by lircd using uinput? > > > > The problem with that reasoning, though it is true, is > > > > 1) We would need to remove a lot of subsystems if we took that > > to the logical conclusion. > > Removing code is always nice. ;) So rather than adding hotplug to serdev, we should remove line-discipline, serdev, and serio and all its drivers from the kernel? This is taking your own argument and applying it your code. > > 2) It makes runtime PM much harder > > Possibly, depends on the bus and device. > > > 3) We end up with two classes of LIRC devices > > We already do, right? That's kind of my point since we have lircd > supporting uinput. This is not an either-or situation, lircd is the "old" solution which is slowing being supplanted with rc-core. All the new keymaps are rc-core and do not work with lircd. The new rc-core tooling (in the v4l-utils package) does not work with lircd. lircd hasn't had any real patches merged for years now. There is whole new tooling in the works for rc-core which is not compatible with lircd. > > > I hear you, but we still need to have those discussions from time to > > > time to make sure our architecture is sane. One of the problems today > > > with the kernel development process appears to be that too few > > > questions > > > are asked. If it builds, ship it... > > > > Indeed, so, could we force a line discipline on a device on the kernel > > level? Code duplication is bad. > > Not sure I understand what you have mind here. serdev is sort of a > line-discipline which we'd "force" on a device if there's a matching > description in devicetree, while line disciplines always need to be > instantiated by user space. Or are you referring to ldisc/serdev code > reuse? I am pretty sure Oliver is suggesting that all ldisc/serdev code in the kernel is duplication of code which can be done in userspace, by your own argument. > > > But I think I've got that point across by now. > > > > Yes and and we need to think about the conclusion we draw from > > that point. It seems to me that an architecture that pushes data > > through the whole tty layer into a demon, then through uinput > > is definitely not elegant. > > The elegant answer is serdev, but it does not yet support the features > needed in this case (i.e. hotplugging). > > Since we already support user-space drivers for these devices, I see > nothing wrong with implementing support for another one in user space > unless there are strong reasons against doing so (e.g. performance, > pm or usability). But if uinput works then great, we're done. As discussed lircd has terrible latency, and lircd is out of date and unmaintained and does not work with modern tooling and keymaps. Also essentially your saying that any input device that connects to a serial port should be done in user space. There are a ton of kernel drivers doing exactly that, and that is why serio exists in the first place. Sean
