Tcl can't access serial port
Mike Clarke
I'm running gpsman-6.2.1 on FreeBSD 6.0-RELEASE with tcl-8.4.11,1 and
tk-8.4.11,2 but I can't get it to communicate with my Garmin Etrex
receiver on the second serial port, (which I assume is /dev/cuad1?)
The error message I get is:
bad option "-mode": should be one of -blocking, -buffering, -buffersize,
-encoding, -eofchar, or -translation while executing
"fconfigure $SRLFILE -blocking 0 -mode $baud,n,8,1 -translation binary"
("unix" arm line 3)
invoked from within
"switch $tcl_platform(platform) {
unix {
set Polling 0 ; set InBuff ""
fconfigure $SRLFILE -blocking 0 -mode $baud,n,8,1 -translation
binar..." (procedure "OpenSerialFailed" line 10)
invoked from within
"OpenSerialFailed $SERIALBAUD"
(procedure "GPSConnection" line 17)
invoked from within
"GPSConnection EnableGPS"
(procedure "CheckGPS" line 7)
invoked from within
"CheckGPS "
invoked from within
".rcw.fr.frgps.bs.state invoke"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke]"
(procedure "tk::ButtonUp" line 22)
invoked from within
"tk::ButtonUp .rcw.fr.frgps.bs.state"
(command bound to event)
The "Known problems" page on the gpsman website
<http://www.ncc.up.pt/gpsman/wGPSMan_6.html> acknowledges this problem
for some OS's but doesn't appear to have any known solution for me.
"GPSMan relies on the use of a serial port to communicate with
the GPS receiver. Some Tcl/Tk installations (e.g., in SuSe, Red
Hat and Mandrake Linux distributions), operating system drivers
and even hardware (in some laptops) were reported not to work
correctly with the serial port. Namely, the Tcl error: "bad
option -mode" is a problem of bad configuration of the Tcl/Tk
installation and upgrading to a newer version normally solves
the problem. To help debugging input from a serial port a Tcl/Tk
program is available from here. It must be edited before use to
set the correct path to the serial port."
My tcl/tk packages are up to date with 6.0-RELEASE and the test program
just comes up with the same arror.
Can anyone suggest how I might be able to get round this problem? The
GPS receiver works OK with Debian and Windows but I'm trying to migrate
from Debian to FreeBSD and I'm trying to reduce my dependence on
Windows.
--
Mike Clarke
Ewout Boks
I am having a similar problem. I am developing an application running on
an Atmel AVR and I use the serial port to communicate with my embedded
system.
ON FreeBSD 5 ,I had no trouble talking to /dev/cuaa0 and /dev/cuaa1.
After upgrading these have become /dev/cuad0 and /dev/cuad1, I can send
data to the Atmel AVR, but anything the Atmel sends back is not received.
This behaviour is very odd and has cost me two days of trying to sort
out what is going wrong, but to no avail (yet).
Has anyone got any clues? I know (from the 6.0 Release Notes that the
tty driver was added and subsequently outgoing tty as well.
Ewout Boks
Mike Clarke
<geen_olden...@boks.com> wrote:
>I am having a similar problem. I am developing an application running
>on an Atmel AVR and I use the serial port to communicate with my
>embedded system.
>
>ON FreeBSD 5 ,I had no trouble talking to /dev/cuaa0 and /dev/cuaa1.
>After upgrading these have become /dev/cuad0 and /dev/cuad1, I can send
>data to the Atmel AVR, but anything the Atmel sends back is not
>received.
I took my problem to comp.lang.tcl where we've been having quite a bit
of discussion about it in the thread entitled "Can't access serial port
with Tcl and FreeBSD" starting with message-id
<43cfd71e$0$1451$ed26...@ptn-nntp-reader01.plus.net>. You'll find it at
<http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/d282cbd96
01fcd9e/dfb45c16f4432886?tvc=1#dfb45c16f4432886> or
<http://tinyurl.com/dkbmp>.
I got things working in the end by deleting the Tcl/Tk packages and
reinstalling the same version (8.4.11) from ports. I don't understand
why this makes a difference but it works now so I'm happy.
--
Mike Clarke
bob prohaska's usenet account
I've been fiddling with lprps (a serial postscript printer filter port)
which seems also to have problems in the 5.4 to 6.0 transmogrification.
Unfortunately, lprps is too simple to depend on Tcl/Tk, it just relies
on lpd (which is substantially changed) and the serial port defaults,
which have changed as well.
The odd thing is that cat'ing a postscript file to the printer produces
output, stty defaults notwithstanding. Lpd simply reports "lp is not
responding" under 6.0. Under 5.4 both approaches work.
The _really_ weird thing is that /etc/gettytab, which I thought
set all the serial port parameters, hasn't changed. Where'd the
diffs come from?
bob prohaska
Per Hedeland
prohaska's usenet account <b...@www.zefox.net> writes:
>
>I've been fiddling with lprps (a serial postscript printer filter port)
>which seems also to have problems in the 5.4 to 6.0 transmogrification.
>
>Unfortunately, lprps is too simple to depend on Tcl/Tk, it just relies
>on lpd (which is substantially changed) and the serial port defaults,
>which have changed as well.
Hm, lpd and serial ports substantially changed from 5.4 to 6.0? I
haven't tried 6.0 yet, but I have to say that I find this hard to
believe, both from my general experience of FreeBSD with respect to
things like backward compatibility, and from the fact that the 6.0
release notes seem totally silent about any such changes.
>The odd thing is that cat'ing a postscript file to the printer produces
>output, stty defaults notwithstanding. Lpd simply reports "lp is not
>responding" under 6.0. Under 5.4 both approaches work.
Hm again, I don't know how a serial-port-connected printer could "not
respond" - it's not expected to respond AFAIK. Are you sure that you
have lpd running, and that you don't have some "bogus" 'lp' entry in
/etc/printcap - e.g. specifying a remote printer?
>The _really_ weird thing is that /etc/gettytab, which I thought
>set all the serial port parameters, hasn't changed. Where'd the
>diffs come from?
/etc/gettytab is only relevant for the ports where you have getty(8)
running - which you certainly shouldn't have on the port where the
printer is connected. Non-default defaults for other ports can be set
via the /dev/(tty|cua)i* devices (at least in 5.x), see sio(4) - but of
course for a printer the normal way to set them would be via
/etc/printcap - 'br' and 'ms' capabilities.
--Per Hedeland
p...@hedeland.org
bob prohaska's usenet account
>
> Hm, lpd and serial ports substantially changed from 5.4 to 6.0? I
There is some mention about how network printing has been cleaned up
in 6.0, and the checksums for the lpd binary are different between
the two systems. One wouldn't expect that to affect serial port comms.
Taking the stty -a -f /dev/ttyd0 output from both systems and diffing them
yields:
> diff 5.4stty 6.0stty
2,7c2,7
< lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
< -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
< -nokerninfo -extproc
< iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk
< -brkint -inpck -ignpar -parmrk
< oflags: -opost -onlcr -ocrnl -oxtabs -onocr -onlret
---
> lflags: icanon isig iexten -echo -echoe -echok -echoke -echonl -echoctl
> -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
> -extproc
> iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
> brkint -inpck -ignpar -parmrk
> oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
I admit to some unclarity on the significance of the changes and expected
the ms capability in printcap to override any inappropriate defaults.
> haven't tried 6.0 yet, but I have to say that I find this hard to
> believe, both from my general experience of FreeBSD with respect to
> things like backward compatibility, and from the fact that the 6.0
> release notes seem totally silent about any such changes.
I share your puzzlement entirely.
> Hm again, I don't know how a serial-port-connected printer could "not
> respond" - it's not expected to respond AFAIK. Are you sure that you
Yes, it can respond with messages like "paper jam" "ready" and so forth.
You might be thinking of old style parallel printers, which could not reply.
>
> /etc/gettytab is only relevant for the ports where you have getty(8)
> running - which you certainly shouldn't have on the port where the
> printer is connected. Non-default defaults for other ports can be set
> via the /dev/(tty|cua)i* devices (at least in 5.x), see sio(4) - but of
> course for a printer the normal way to set them would be via
> /etc/printcap - 'br' and 'ms' capabilities.
Point taken, gettytab is not the place to look for changes, but where then?
are they hard-coded into the sio sources? On neither setup have I made any
intentional changes to serial port settings.
At this point I can copy the config files between 5.4 and 6.0, they work
on 5.4 and don't on 6.0, with the _only_ error reported on 6.0 is that
"lp is not responding". Usually this implies a hardware problem, but it
happens on the same host, same cable, same printer. On both 5.4 and 6.0
simply cat-ing a postscript program out the serial port produces output.
Ordinarily troubles like this prove to be my own doing, but at this stage
I'd be grateful if somebody could point out the mistake. The post about
other software having serial port difficulties was the first hint it might
not be just me 8-)
thanks for reading,
bob prohaska
Per Hedeland
>>
>> Hm, lpd and serial ports substantially changed from 5.4 to 6.0? I
>
>There is some mention about how network printing has been cleaned up
>in 6.0, and the checksums for the lpd binary are different between
>the two systems. One wouldn't expect that to affect serial port comms.
Indeed not - unfortunately, as I said, I don't have 6.0 yet (and will
probably wait for 6.1) - and it seems none of those that *do* have it
care to comment on this. The output of 'stty -a -f /dev/ttyd0' shouldn't
be too hard to produce...
>Taking the stty -a -f /dev/ttyd0 output from both systems and diffing them
>yields:
>
>> diff 5.4stty 6.0stty
>2,7c2,7
>< lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
>< -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
>< -nokerninfo -extproc
>< iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk
>< -brkint -inpck -ignpar -parmrk
>< oflags: -opost -onlcr -ocrnl -oxtabs -onocr -onlret
>---
>> lflags: icanon isig iexten -echo -echoe -echok -echoke -echonl -echoctl
>> -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
>> -extproc
>> iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
>> brkint -inpck -ignpar -parmrk
>> oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
>
>I admit to some unclarity on the significance of the changes and expected
>the ms capability in printcap to override any inappropriate defaults.
Just guessing, but the changed onlcr could be the culprit - it's the
"standard" setting that turns LF into CRLF on output, but it may
interfere with sending commands to the printer.
And you checked that you didn't have a getty running on the port? Or any
other process for that matter...
>> Hm again, I don't know how a serial-port-connected printer could "not
>> respond" - it's not expected to respond AFAIK. Are you sure that you
>
>Yes, it can respond with messages like "paper jam" "ready" and so forth.
>You might be thinking of old style parallel printers, which could not reply.
Actually my thinking about serial port printers dates back to the times
when they most certainly couldn't reply, due to the lack of necessary
computing power:-) - but my point was rather that *lpd* wouldn't expect
a reply. However I now realize that it's of course "lprps" that does the
talking to the printer, and expects responses from it that it doesn't
get.
This also means that 'br' and 'ms' in /etc/printcap are irrelevant, I
believe - lpd only talks to the printer filter, and has no idea what
physical interface it uses to talk to the actual printer.
>Point taken, gettytab is not the place to look for changes, but where then?
>are they hard-coded into the sio sources? On neither setup have I made any
>intentional changes to serial port settings.
I believe the defaults come (only) from the "i" devices, that in 6.0
apparently have been renamed to ".init". I.e. if you set the bits and
modes on (e.g.) /dev/ttyd0.init, that is what you get as defaults when
/dev/ttyd0 is opened. But most programs that "consciously" open a serial
port will set the parameters to its own liking anyway, i.e. in your case
it would be "normal" for the "lprps" stuff to do it. The defaults are
mostly for "stupid" programs (like when you 'cat' a file to the tty...).
>At this point I can copy the config files between 5.4 and 6.0, they work
>on 5.4 and don't on 6.0, with the _only_ error reported on 6.0 is that
>"lp is not responding". Usually this implies a hardware problem, but it
>happens on the same host, same cable, same printer. On both 5.4 and 6.0
>simply cat-ing a postscript program out the serial port produces output.
Well, 'cat' most certainly doesn't expect a response:-) - so the problem
is in any command/response things that "lprps" is doing. Either there is
some "mangling" (e.g. onlcr above) that makes commands fail but doesn't
affect data, or responses are not getting back. And the latter *could*
be hardware of course, RxD wire broken - or it could be some other
process gobbling up the responses, preventing "lprps" from seeing them.
(Of course it could be some "mangling" too, but somehow I think it is
less likely on input.)
--Per Hedeland
p...@hedeland.org
Torfinn Ingolfsen
> Indeed not - unfortunately, as I said, I don't have 6.0 yet (and will
> probably wait for 6.1) - and it seems none of those that *do* have it
> care to comment on this. The output of 'stty -a -f /dev/ttyd0' shouldn't
> be too hard to produce...
Sorry, the real world is keeping me busy, little time to read newsgroups.
Here is something:
root@kg-quiet# uname -a
FreeBSD kg-quiet.kg4.no 6.0-STABLE FreeBSD 6.0-STABLE #3: Sun Jan 8
20:22:06 CET 2006 ro...@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET amd64
root@kg-quiet# stty -a -f /dev/ttyd0
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten -echo -echoe -echok -echoke -echonl -echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
and from another box:
root@kg-fil# uname -a
FreeBSD kg-fil.kg4.no 6.0-STABLE FreeBSD 6.0-STABLE #2: Sat Jan 7
23:08:43 CET 2006 ro...@kg-fil.kg4.no:/usr/obj/usr/src/sys/FIL60 amd64
root@kg-fil# stty -a -f /dev/ttyd0
speed 9600 baud; 0 rows; 0 columns;
lflags: icanon isig iexten -echo -echoe -echok -echoke -echonl -echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk
oflags: opost onlcr -ocrnl -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
HTH
Sweet dreams!
--
Torfinn Ingolfsen,
Norway
bob prohaska's usenet account
>
> Just guessing, but the changed onlcr could be the culprit - it's the
> "standard" setting that turns LF into CRLF on output, but it may
> interfere with sending commands to the printer.
Just tried it, via the "ms" capability in printcap....no joy.
> And you checked that you didn't have a getty running on the port? Or any
> other process for that matter...
Well, /etc/ttys says /dev/ttyd0 is off, but
ps -aux | grep -i getty finds nothing, which is somewhat odd.
Output to the screen clearly shows /usr/libexec/gett, which seemed
to be truncated by the screen width.
Piping the output to a file, with the intent of trimming leading characters
to reveal the end of line, discloses that the truncation is not a display
effect; the lines really do stop short of completion.
>
> This also means that 'br' and 'ms' in /etc/printcap are irrelevant, I
> believe - lpd only talks to the printer filter, and has no idea what
> physical interface it uses to talk to the actual printer.
>
According to the lprps docs the "ms" capability is essential, though
the exact chain of command is less than crystal clear to me. I believe
lpr places files in the spool directory and calls lpd. Lpd reads printcap,
starting the input filter and passing it the ms capabilities. The input
filter then calls lprps, passing the relevant parameters along. Or so I think..
>
> I believe the defaults come (only) from the "i" devices, that in 6.0
> apparently have been renamed to ".init". I.e. if you set the bits and
> modes on (e.g.) /dev/ttyd0.init, that is what you get as defaults when
> /dev/ttyd0 is opened. But most programs that "consciously" open a serial
Looks like /dev/ttyd0.init is not meant to be tampered with, at least not
by mere mortals 8-) Where do its parameters come from? That would probably
explain the stty changes.
> Well, 'cat' most certainly doesn't expect a response:-) - so the problem
> is in any command/response things that "lprps" is doing. Either there is
> some "mangling" (e.g. onlcr above) that makes commands fail but doesn't
> affect data, or responses are not getting back. And the latter *could*
So it seems.
> be hardware of course, RxD wire broken - or it could be some other
No, the hardware is the same host/cable/printer, dual booting
5.4/6.0; this is clearly a software issue, though whether it's a bug or
a feature is fair game for debate.
Lprps is cited prominently in the FreeBSD Handbook's section on printing,
it's worked superbly for many years. I hope a small config change in the
port will fix it, if not there will be a large hole in the docs.
At worst I'll back down to 5.4 for print service and hope 6.1 is more
amenable to dealing with intelligent serial printers, which are admittedly
a dying breed; I'm just not quite ready to kill mine yet.
8-)
Thanks for reading,
bob prohaska
>
Per Hedeland
>>
>> Just guessing, but the changed onlcr could be the culprit - it's the
>> "standard" setting that turns LF into CRLF on output, but it may
>> interfere with sending commands to the printer.
>
>Just tried it, via the "ms" capability in printcap....no joy.
Well, see below - did it actually change the setting when running a
print job? And I was only guessing:-), you might want to (try to) clear
all flags that are set in 6.0 but not in 5.4.
>> And you checked that you didn't have a getty running on the port? Or any
>> other process for that matter...
This is rather moot now that we have confirmation from Torfinn that the
default modes really *are* different (sheesh!) - but anyway...
>Well, /etc/ttys says /dev/ttyd0 is off, but
>ps -aux | grep -i getty finds nothing, which is somewhat odd.
>Output to the screen clearly shows /usr/libexec/gett, which seemed
>to be truncated by the screen width.
>
>Piping the output to a file, with the intent of trimming leading characters
>to reveal the end of line, discloses that the truncation is not a display
>effect; the lines really do stop short of completion.
Yeah, ps is a bit weird (but pragmatic) in that way - drop the 'u' or
add a 'w' or two, see the man page. But I think we can rule this out as
the source of the problem.
>> This also means that 'br' and 'ms' in /etc/printcap are irrelevant, I
>> believe - lpd only talks to the printer filter, and has no idea what
>> physical interface it uses to talk to the actual printer.
Mostly baloney - as the handbook explains in excruciating detail, lpd
opens the device specified by 'lp=', sets the modes/flags if it's a tty,
and then runs the input filter ('if=') with the device as stdout (and
the job on stdin). Of course the filter can and in some cases does
totally ignore this service provided by lpd, and just contact the device
in some other fashion - but...
>According to the lprps docs the "ms" capability is essential,
...then it most likely follows the "standard" model.
> though
>the exact chain of command is less than crystal clear to me. I believe
>lpr places files in the spool directory and calls lpd. Lpd reads printcap,
>starting the input filter and passing it the ms capabilities. The input
>filter then calls lprps, passing the relevant parameters along. Or so I think..
Almost, see above (or better the handbook, in case I scr*wed up again:-).
>> I believe the defaults come (only) from the "i" devices, that in 6.0
>> apparently have been renamed to ".init". I.e. if you set the bits and
>> modes on (e.g.) /dev/ttyd0.init, that is what you get as defaults when
>> /dev/ttyd0 is opened. But most programs that "consciously" open a serial
>
>Looks like /dev/ttyd0.init is not meant to be tampered with, at least not
>by mere mortals 8-)
I think you should have a look also at the .lock device - any flags set
there are unchangeable on the "real" device, maybe on the .init device
too (until you clear them on the lock device). This could explain both the
failure of 'ms' above and your not being able to change .init (but we
should be able to ignore .init if 'ms' is able to do what it should).
> Where do its parameters come from? That would probably
>explain the stty changes.
Yeah, good question, they certainly don't live in /dev - i.e. they must
come from the driver. There has been some shuffling around in sio(4) &
Co in semi-recent times, in particular this change in sio.c seems
"ominous":
Revision 1.456, Wed Oct 13 08:27:20 2004 UTC (15 months, 2 weeks ago) by phk
Branch: MAIN
Changes since 1.455: +79 -521 lines
Use generic tty code instead of local stuff.
NB: device names are now consistent: {cua,tty}d$(port)[.lock,.init]
(not very recent perhaps, but it is only in 6.0, not 5.4) which among
the diffs removes this:
- /*
- * We don't use all the flags from <sys/ttydefaults.h> since they
- * are only relevant for logins. It's important to have echo off
- * initially so that the line doesn't start blathering before the
- * echo flag can be turned off.
- */
- tp->t_init_in.c_iflag = 0;
- tp->t_init_in.c_oflag = 0;
- tp->t_init_in.c_cflag = TTYDEF_CFLAG;
- tp->t_init_in.c_lflag = 0;
Without the full 6.0 sources around I can't easily see the implications
of this (i.e. what are those flags set to instead), but it seems like
6.0 really *does* use <sys/ttydefaults.h> (except for echo actually
being off) - breaking conventions that have been there since before
there was a "Free" in FreeBSD, and against better judgement IMHO. And
maybe it even locks down those settings, but it seems *too* improbable
on second thought...
--Per Hedeland
p...@hedeland.org
bob prohaska's usenet account
> In article <qtWDf.49010$PL5....@newssvr11.news.prodigy.com> bob
>>> Just guessing, but the changed onlcr could be the culprit - it's the
>>> "standard" setting that turns LF into CRLF on output, but it may
>>> interfere with sending commands to the printer.
>>
>>Just tried it, via the "ms" capability in printcap....no joy.
>
> Well, see below - did it actually change the setting when running a
> print job? And I was only guessing:-), you might want to (try to) clear
> all flags that are set in 6.0 but not in 5.4.
Seemingly not, unless the system defaults are restored after the device file
is close. Don't know how to capture the data in that case....
>>> And you checked that you didn't have a getty running on the port? Or any
>>> other process for that matter...
Thanks for the clue about dropping the "u" option, the only gettys are
running on ttyv* ports.
> I think you should have a look also at the .lock device - any flags set
> there are unchangeable on the "real" device, maybe on the .init device
> too (until you clear them on the lock device). This could explain both the
> failure of 'ms' above and your not being able to change .init (but we
> should be able to ignore .init if 'ms' is able to do what it should).
This is an interesting puzzle; it seems that /dev is depopulated on an
inactive root filesystem. Looks like the comparison has to be made between
running systems.
[question on the origins of tty defaults]
>
> Yeah, good question, they certainly don't live in /dev - i.e. they must
> come from the driver. There has been some shuffling around in sio(4) &
> Co in semi-recent times, in particular this change in sio.c seems
> "ominous":
>
> Revision 1.456, Wed Oct 13 08:27:20 2004 UTC (15 months, 2 weeks ago) by phk
> Branch: MAIN
> Changes since 1.455: +79 -521 lines
>
> Use generic tty code instead of local stuff.
>
> NB: device names are now consistent: {cua,tty}d$(port)[.lock,.init]
>
> (not very recent perhaps, but it is only in 6.0, not 5.4) which among
> the diffs removes this:
>
> - /*
> - * We don't use all the flags from <sys/ttydefaults.h> since they
> - * are only relevant for logins. It's important to have echo off
> - * initially so that the line doesn't start blathering before the
> - * echo flag can be turned off.
> - */
> - tp->t_init_in.c_iflag = 0;
> - tp->t_init_in.c_oflag = 0;
> - tp->t_init_in.c_cflag = TTYDEF_CFLAG;
> - tp->t_init_in.c_lflag = 0;
>
> Without the full 6.0 sources around I can't easily see the implications
> of this (i.e. what are those flags set to instead), but it seems like
If you can tell me how to extract the information I'd be happy to do it;
both 5.4 and 6.0 sources are readily at hand.
> 6.0 really *does* use <sys/ttydefaults.h> (except for echo actually
> being off) - breaking conventions that have been there since before
> there was a "Free" in FreeBSD, and against better judgement IMHO. And
> maybe it even locks down those settings, but it seems *too* improbable
> on second thought...
Unless the change troubles folks using serial consoles it's likely to go
unnoticed. I'm probably the only human being still using a serial printer
with FreeBSD and the second clause in that sentence is likely subject to
debate 8-)
It's tempting to think this is a problem with the serial ports, but
it would not be at all surprising if the lpd re-work is part of the
problem. I'll bet _nobody_ working on lpd has a serial PostScript printer
to use for testing. The Tcl folks have gone quiet on this thread, thats
a bad sign for my purposes. Without their pieces it's hard to assemble the
puzzle.
Thanks for reading and your good counsel.
bob prohaska
Per Hedeland
>> print job? And I was only guessing:-), you might want to (try to) clear
>> all flags that are set in 6.0 but not in 5.4.
>
>Seemingly not, unless the system defaults are restored after the device file
>is close. Don't know how to capture the data in that case....
Do a stty while the print job is running - since it apparently sits
there waiting for a reply that doesn't arrive, it shouldn't be too hard.
And yes the defaults are restored - not at close, but at the next open
(and stty has to open the device of course).
>> I think you should have a look also at the .lock device - any flags set
>> there are unchangeable on the "real" device, maybe on the .init device
>> too (until you clear them on the lock device). This could explain both the
>> failure of 'ms' above and your not being able to change .init (but we
>> should be able to ignore .init if 'ms' is able to do what it should).
>
>This is an interesting puzzle; it seems that /dev is depopulated on an
>inactive root filesystem. Looks like the comparison has to be made between
>running systems.
Yes of course - both 5.4 and 6.0 have devfs. But it would be enough to
check the .lock device on 6.0 - it should have all flags cleared
(-flag), if not try to make them so.
>> Without the full 6.0 sources around I can't easily see the implications
>> of this (i.e. what are those flags set to instead), but it seems like
>
>If you can tell me how to extract the information I'd be happy to do it;
>both 5.4 and 6.0 sources are readily at hand.
Hunting around in the sources to find the changes and the implications
thereof isn't something that can be remote-controlled, I'm afraid -
whoever is doing it needs to be able find his way around the code
himself.
>Unless the change troubles folks using serial consoles it's likely to go
>unnoticed. I'm probably the only human being still using a serial printer
>with FreeBSD and the second clause in that sentence is likely subject to
>debate 8-)
Well, I dunno, serial printers are probably not all that common these
days, but people connect a lot of other stuff to serial ports (e.g.
serial consoles of *other* boxes). But it might be the case that the new
settings work in "most" cases.
--Per Hedeland
p...@hedeland.org
bob prohaska's usenet account
> Do a stty while the print job is running - since it apparently sits
> there waiting for a reply that doesn't arrive, it shouldn't be too hard.
> And yes the defaults are restored - not at close, but at the next open
> (and stty has to open the device of course).
Sure enough, that worked and it seems the ms parameters make it from
/etc/printcap to /dev/ttyd0 while lpd is active.
>
>
> Yes of course - both 5.4 and 6.0 have devfs. But it would be enough to
> check the .lock device on 6.0 - it should have all flags cleared
> (-flag), if not try to make them so.
That appears to be the case, as well. Maybe lpd is the culprit, after all.
>
> Hunting around in the sources to find the changes and the implications
> thereof isn't something that can be remote-controlled, I'm afraid -
> whoever is doing it needs to be able find his way around the code
> himself.
Understood.
>
> Well, I dunno, serial printers are probably not all that common these
> days, but people connect a lot of other stuff to serial ports (e.g.
> serial consoles of *other* boxes). But it might be the case that the new
> settings work in "most" cases.
>
I'm afraid the serial ports will have to annoy a good programmer 8-)
Thanks for reading, and patient good counsel.
bob prohaska
Per Hedeland
>> Do a stty while the print job is running - since it apparently sits
>> there waiting for a reply that doesn't arrive, it shouldn't be too hard.
>> And yes the defaults are restored - not at close, but at the next open
>> (and stty has to open the device of course).
>
>Sure enough, that worked and it seems the ms parameters make it from
>/etc/printcap to /dev/ttyd0 while lpd is active.
Good, then it's not monumentally broken. Next step is to follow the
advice in my previous post:
>>>> Well, see below - did it actually change the setting when running a
>>>> print job? And I was only guessing:-), you might want to (try to) clear
>>>> all flags that are set in 6.0 but not in 5.4.
Or more precisely, you should have a list of flags in 'ms' that make
sure the settings when a print job is running is exactly the same as
they were when a print job was running in 5.4. I.e. if you had a 'ms'
setting that turned on some flags, they should be turned on in 6.0 too,
and all *other* flags that are set in 6.0 but not in 5.4 should be
forced off by the 'ms' list.
--Per Hedeland
p...@hedeland.org
bob prohaska's usenet account
>
> Or more precisely, you should have a list of flags in 'ms' that make
> sure the settings when a print job is running is exactly the same as
> they were when a print job was running in 5.4. I.e. if you had a 'ms'
> setting that turned on some flags, they should be turned on in 6.0 too,
> and all *other* flags that are set in 6.0 but not in 5.4 should be
> forced off by the 'ms' list.
>
I tried this once but didn't do it correctly; the stty snapshot
was taken when the printer was inactive. Looks like it's worth repeating
the experiment.
Thanks again for all your help!
bob prohaska