On Wed, 5 Dec 2001 11:32:13 -0500 (EST), in
comp.emulators.ms-windows.wine lawson_whitney@juno.com wrote:
> On Wed, 5 Dec 2001, T REX wrote:
>
> > Hmm well it is a posibilty, the weird thing here is that the Thinkboxx
> > does not use hardware flow controll, this i know since the serial cabel
> > suplied only has three pins where two are data and one is ground.
>
> It is basically impossible for linux to transfer data over such a cable
> if hardware flow control (CRTSCTS) is enabled. A write may succeed, but
> no data will go out the serial line until CTS comes up, and with only 3
> wires, there is none for it to come up on.
>
> > I think that the lacking support may be conusing the error, but why does it
> > work under windows when hardware flow controll is not available.
> > The program must be relaying on software flow controll,
> > does windows use software flow controll that emulates DTS/DTR signals.
>
> Seems I saw in a trace it asks for hardware flow control. Unless there
> are 2 different comm devices in this piece, here it was:
>
> | 0806d898:Call kernel32.SetCommState(00000060,406150ac) ret=0043e017
> | trace:comm:SetCommState handle 96, ptr 0x406150ac
> | trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 0 Parity 0
> | stopbits 1
> | trace:comm:SetCommState ~IXON ~IXOFF
> | trace:comm:SetCommState CRTSCTS
> | warn:comm:SetCommState DSR/DTR flow control not supported
> | 0806d898:Ret kernel32.SetCommState() retval=00000001 ret=0043e017
>
> | 'flow control not supported'. This could be the reason.
> | I have no idea why it's not supported - I suspect a system-related
> | reason, if there is no api available to managed this stuff in the
> | Linux Api, for example.
>
> | Gerard
> _______________________________________________
> | /gp/pine/wine-users byte 430933/509199 84%
>
> Flow control as practiced by linux (CRTSCTS) is supported and works.
> We don't know what DSR/DTR is 'spoze to do, so it isn't. Most windose
> apps seem to ask for both, as this one does, even though the cable makes
> it impossible for either of them to work. Maybe hardware flow control
> is a stub in windose?
Hmm, it is this snippet that does the warning.
if (lpdcb->fDtrControl == DTR_CONTROL_ENABLE)
{
WARN("DSR/DTR flow control not supported\n");
}
But in the preceding COMM_BuildOldCommDCB() call the default case is
selected:
} else {
lpdcb->fInX = FALSE;
lpdcb->fOutX = FALSE;
lpdcb->fOutxCtsFlow = FALSE;
lpdcb->fOutxDsrFlow = FALSE;
lpdcb->fDtrControl = DTR_CONTROL_ENABLE;
I don't have the time right now to fully look at this, but I feel that
the first DTR_CONTROL_ENABLE should really be DTR_CONTROL_HANDSHAKE.
The latter specifies flowcontrol (flow is stopped if buffers get
full), the former just specifies to set the DTR line high.
Something similar a few lines above in the code where:
lpdcb->fRtsControl == RTS_CONTROL_ENABLE
)
{
port.c_cflag |= CRTSCTS;
TRACE("CRTSCTS\n");
}
perhaps the RTS_CONTROL_ENABLE should be RTS_CONTROL_HANDSHAKE?
This would explain why in this case crtcts flowcontrol gets enabled on
a 3 wire serial link.
Rein.
--
Rein Klazes
rklazes@xs4all.nl
