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:

quoted

Now it would be nice to have a discussion about this rather than being
dismissed with:

quoted

quoted

quoted

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