Hi Miguel,
You are correct; the Linux kernel does not support DTR/DSR flow control. If a windows program requests DTR/DSR flow control in wine, we just write a FIXME to stderr and ignore the setting.
Your idea to build a cable that wires the printer's DTR/DSR to the computer's RTS/CTS may work, but you may also need some small hacks in wine to select RTS/CTS flow control when the program asks for DTR/DSR flow control. That won't garantuee that your program works, but it will at least be a little better...
I guess the other option is to implement DTR/DSR flow control in the Linux kernel... but that may not be easy :)
Mike
List vmn wrote:
Hi,
I am testing a serial printer driver that uses DTR/DTS hardware flow control on wine. While testing the driver running winedbg everything worked, not so when I ran the program directly from wine. I sent this problem to the printer manufacturer and they put a data scope on the serial line. It seems that the DTR/DTS signal was not being caught by the computer and therefore the computer was sending info over the serial port when the printer was not ready. I read on the net that the linux kernel does not implement DTR/DTS but only RTS/CTS hardware flow control.
I also read that it is usual for cables to be built that connect the RTS/CTS pins to the DTR/DTS pins therefore tricking the computer and printer [the computer understands RTS/CTS and the printer DTR/DTS ] and getting good results.
The output of --debugmsg +comm after SetCommState was called was ~IXONN ~IXOFF. Can anybody indicate that If I build the correct cable and ask for RTS/CTS with SetCommState , that the serial io will work? Any limitation of wine with RTS/CTS?
Is it correct that windows does not do ANY hardware flow control? If so, how can this app work under windows since it only uses standard SetCommState, ReadFile, WriteFile calls...
Thanks, Miguel Feitosa