Re: [PATCH 2/3] input: serio: allow more than one byte to be sent at once

[Sean Young <sean@mess.org>]

On Tue, May 12, 2020 at 10:37:27AM -0700, Dmitry Torokhov wrote:
> On Tue, May 12, 2020 at 10:07:24AM +0100, Sean Young wrote:
> > Now it would be nice to have a discussion about this rather than being
> > dismissed with:
> > 
> > > > > Ummm, serial protocol data size is at most 9 bits so I have no earthly
> > > > > idea how they expect to get 16.
> > 
> > Which is just a tad insulting.
> 
> That was not meant to be insulting, however serial protocol defines that
> the data size is at most 9 bits, so expecting that one can transmit
> anything more than that _atomically_ is wrong. If your device/firmware
> requires 16 bits to be transferred as indivisible units, then serial
> port abstraction is wrong one to be used.

Honestly thank you for explaining that. I had no idea this was an abstract
point about the demarcations of serial port-ness.

There is no physical rs-232 cabling involved at all in this case.

> Now serio is layer "above" serial ports (but does not have to have
> an underlying serial port) that provides byte-oriented communication
> that is expected to mostly flow into host. Its does not expect heavy
> data flows coming from the host and into the device (if you look at all
> the touchscreens, psmouse, etc, they all send initialization sequences
> to the device, and then all the data flows into the host). Therefore
> there is little benefit in optimizing serio writes.

True, I didn't think this would make much of an measurable improvement,
but still, some.

> You are using performance clams as a clutch for the requirement of
> sending u16s, but as I mentioned it is wrong if you use serial ports
> abstraction layer. Greg mentioned ir-usb. You can maybe enhance it, or
> create a similar driver that connects USB to rc-core and ensures that
> you can communicate with the device with exact format it needs.

Yes, I'll go down this route.

Thank you for the discussion, it was very helpful.


Sean