DTR / DTS vs RTS/CTS vs Wine

[List vmn]

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

[Mike McCormack]

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

[mfeitosa]

Mike,

Thanks for a prompt answer!
I am going to test the cabling scheme and will send some info by the end of 
next week.
Are you aware how windows implements hw flow control?
I read in the wine-devel history a comment that stated that windows might 
not imlpement hw flow control at all.
This intrigues me because the printer does work on windows.

Miguel

At 16:43 24/7/2002 -0500, you wrote:
> 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

[Mike McCormack]

Hi Miguel,

I'm pretty sure that Windows 95 and Windows NT's standard drivers both 
implement hardware flow control (DTR/DSR and RTS/CTS). Windows 3.1 may 
be a different story though...

Mike

mfeitosa wrote:
> Mike,
>
> Thanks for a prompt answer!
> I am going to test the cabling scheme and will send some info by the end 
> of next week.
> Are you aware how windows implements hw flow control?
> I read in the wine-devel history a comment that stated that windows 
> might not imlpement hw flow control at all.
> This intrigues me because the printer does work on windows.
>
> Miguel

[Marcelo Welter]

Hi miguel

If your are using a fiscal printers of brazilian producers.

In wine the DTR/DTS are true everytime. Then you need stop your application after eat command to wait printer get a ready status before next command.
in delphi use SLEEP command to this.

sorry per my english.

see ya!

Marcelo Welter

Hi Marcelo!

Seems you are familiar with the problem!
Yes, I am debugging a fiscal printer !
I was using sleep but I decided to look into the problem because 
sometimes you need to catch the signal, say if the printer runs out of paper,
or whatever....

I am going to try the cable and then see what happens.

Miguel

Quoting Marcelo Welter :
> Hi miguel
>
> If your are using a fiscal printers of brazilian producers.
>
> In wine the DTR/DTS are true everytime. Then you need stop your
> application after eat command to wait printer get a ready status before
> next command.
> in delphi use SLEEP command to this.
>
> sorry per my english.
>
> see ya!
>
> Marcelo Welter

-------------------------------------------------
This mail sent through IMP: webmail.vmn.com.br