From: Johan Hovold <johan@kernel.org>
To: Sean Young <sean@mess.org>
Cc: Oliver Neukum <oneukum@suse.com>,
linux-media@vger.kernel.org, linux-usb@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jon Rhees <support@usbuirt.com>
Subject: Re: [PATCH v3 0/3] IR driver for USB-UIRT device
Date: Thu, 24 Jun 2021 11:41:28 +0200 [thread overview]
Message-ID: <YNRTSLEHzFKU1KOa@hovoldconsulting.com> (raw)
In-Reply-To: <20210624091349.GA7476@gofer.mess.org>
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
next prev parent reply other threads:[~2021-06-24 9:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-06 12:44 [PATCH v3 0/3] IR driver for USB-UIRT device Sean Young
2021-05-06 12:44 ` [PATCH v3 1/3] USB: serial: move ftdi_sio.h into include directories Sean Young
2021-05-14 11:16 ` Johan Hovold
2021-05-06 12:44 ` [PATCH v3 2/3] media: rc: new driver for USB-UIRT device Sean Young
2021-05-14 11:38 ` Johan Hovold
2021-05-15 9:52 ` Sean Young
2021-05-17 9:38 ` Johan Hovold
2021-05-06 12:44 ` [PATCH v3 3/3] USB: serial: blacklist USB-UIRT when driver is selected Sean Young
2021-05-14 11:40 ` Johan Hovold
2021-05-15 9:56 ` Sean Young
2021-05-17 9:40 ` Johan Hovold
2021-05-10 8:15 ` [PATCH v3 0/3] IR driver for USB-UIRT device Johan Hovold
2021-05-11 10:32 ` Sean Young
2021-05-14 11:16 ` Johan Hovold
2021-05-15 9:22 ` Sean Young
2021-05-17 9:30 ` Johan Hovold
2021-05-17 10:35 ` Sean Young
2021-05-17 12:35 ` Sean Young
2021-05-20 13:40 ` Johan Hovold
2021-05-20 13:31 ` Johan Hovold
2021-05-21 11:39 ` Sean Young
2021-06-23 12:48 ` Johan Hovold
2021-05-25 12:25 ` Oliver Neukum
2021-06-23 13:10 ` Johan Hovold
2021-06-24 9:13 ` Sean Young
2021-06-24 9:41 ` Johan Hovold [this message]
2021-06-25 8:08 ` Sean Young
2021-07-02 10:44 ` Johan Hovold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YNRTSLEHzFKU1KOa@hovoldconsulting.com \
--to=johan@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=oneukum@suse.com \
--cc=sean@mess.org \
--cc=support@usbuirt.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.