On Thu, Jun 24, 2021 at 10:13:49AM +0100, Sean Young wrote: > 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. Not at all. Not everything can be done in user space, but some things can. > > > 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. Sure, you already explained that. I was just asking (earlier) why you didn't use the infrastructure that's already in place. If there are good reasons for not doing so then fine. > > > > 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. See above. > > > > 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. I'm not, again see above. I'm saying that we should not make one-off copies of serial drivers if we can avoid it. In this case the limitations of lircd and the lack of hotplugging in serdev may be a sufficient reason for making an exception. As we've already discussed. Johan
