Ubuntu

Or read and understand the device driver source code. That's likely to be quite difficult unfortunately.

If these are binary drivers without source code, you're wholly out of luck. Transfers it to the USB drivers. USB has its own protocol, etc. quite unrelated to whatever serial buffers the device might have.

What do you need TIOCOUTQ for? Might there be a workaround that doesn't involve bare-metal hardware driver hacking?

There are c source of cdc-acm.c, sierra.c, option.c in drivers/usb I was able to recompile (create *.ko files) and use after that.
For example, drivers/usb/class/cdc-acm.c overrides tty method:
741 static int acm_tty_chars_in_buffer(struct tty_struct *tty);

That method supposes to return amount of not sent data.
Unfortunately, it makes those calculations based on amount of urb buffers returned by
505 static void acm_write_bulk(struct urb *urb);
acm_write_bulk seems to return urb buffer after its data were transferred to device, not really sent to destination.


For example, I have a USB modem connected to my intel machine and I want to send packets over it with the lowest latency the modem provides.
When network is in good condition the latency (or delay) is lower or about 1 second, which is good.
When network goes weak latency can be huge (even 1 minute).

The idea was:
1) send a packet over sendto()
2) check if packet was sent completely in "short" time.
3a) if it was sent fast enough, my app is happy and continues to send packets over it.
3b) if it wasn't, my app resends that packet over another USB modem and stops using the first modem until it's in good condition again.

If I was able to check if modem is empty I'd be able to implement it.

How about tcdrain()?

I didn't know about tcdrain.
I will test it tomorrow.

According to man: The tcdrain() function waits until all output written to the terminal referenced by fildes has been transmitted to the terminal.
What is called terminal? is it hardware? if it is it's exactly the same as cdc-acm does currently: it controls urbs going to device and doesn't control if urbs are sent really.

Linux, perhaps even UNIX in general, considers serial ports and all things pretending to be serial ports, as terminals. (And vice versa!) Consider an old-fashioned hardware serial port with a hardware terminal attached. To transmit the data to the terminal -- that is, display it -- it really would have to transmit it. In other words, it does exactly what it says on the tin. Don't panic.

Unfortunately, tcdrain didn't help to solve the problem. But actually it's not bad anymore. Nobody says that packets are stuck inside modems. They could be stuck somewhere on providers' routers.
So we decided to implement tricky two-direction protocol to control if modem is working properly. And surprisingly the protocol works so good that we are able to stream 1080p live, which we wanted to.

So thanks for help. I'm really appreciated.