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
