On Sun, Jan 10, 2021 at 04:15:41PM -0600, Joe Abbott wrote:

quoted

Look for the set-line-request control request:

        bmRequestType   0x21
        bRequest        0x20    (SET_LINE_REQUEST)
        wValue          0
        wIndex          0
        wLength         7

the data stage should contain the corresponding 7 bytes of request data
for 110/cs7/parenb:

        d5 0e 00 80 00 02 07

Windows wireshark  URB_CONTROL_OUT packets
using putty set to at 110 baud 7E1

The windows usb captures have these 7 bytes for 110 baud:
           a8 a6 01 80 00 02 07

Interesting...

and these 7 bytes for 9600 baud:
           80 25 00 00 00 02 07   0x2580 = 9600

--------------------------------------------------------------------
Linux wireshark URB_CONTROL_OUT packet
using stty 110 evenp

usb capture for 110 baud 7E1
            d5 0e 00 80 00 02 07

I tried hard coding the first four 110 baud bytes into buf[0] - buf[3]
in the divisor subroutine and
110 baud work fine.  Possible problem in the divisor routine?

Or rather a new feature which do not yet support (or understand).

I tried hardcoding the same request with a HXD and it doesn't give me
110 baud. Instead the unsupported bits appears to be ignored and the
current divisor algorithm is applied so that

	a8 a6 01 80 00 02 07

gives the same result as if

	a8 06 00 80 00 02 07

had been requested (~35720 baud).

So in any case, we'd need to key this off of the device type.

I noticed that

	12000000 / 0x1a6a8 ~= 110.9

Possibly just a coincidence, especially as 0x1aa22 would be closer
match. But perhaps you can try a few more rates not in baud_sup and see
if you can figure it out.

Johan