Document unexpected setSignals behaviour due to RTS bug in usbser.sys #173
Description
The generic CDC-ACM driver usbser.sys in Windows 8.1, 10 and 11 has a bug when updating the RTS line (this seems to be a known bug that has been unresolved for many years).
For this specific driver the following SerialPort methods do not modify RTS:
.setSignals({requestToSend: false}); // RTS unchanged (default output - asserted?)
.setSignals({requestToSend: true}); // RTS unchanged
The following changes RTS, however RTS is set to the previous value:
.setSignals({requestToSend: true, dataTerminalReady: true}); // RTS unchanged
.setSignals({requestToSend: false, dataTerminalReady: true}); // RTS asserted (previous value)
.setSignals({requestToSend: true, dataTerminalReady: true}); // RTS negated (previous value)
.setSignals({requestToSend: true, dataTerminalReady: true}); // RTS asserted (previous value)
In USB traffic, I have noticed other windows serial terminals tend to issue the CDC SetControlLineState request multiple times in an attempt to circumvent the (undesirable) behaviour of usbser.sys
For web serial, an inelegant workaround is to issue the request twice in succession, while including a DTR value (either true or false) in the update 'mask'. For example:
// Assert RTS
.setSignals({requestToSend: true, dataTerminalReady: true});
.setSignals({requestToSend: true, dataTerminalReady: true}); // output asserted here (previous value)
// Negate RTS
.setSignals({requestToSend: false, dataTerminalReady: true});
.setSignals({requestToSend: false, dataTerminalReady: true}); // output negated here (previous value)
I suppose it might be possible to write a specific setSignals handler when usbser.sys is detected as the device driver?