Re: Re: High-bit strip?

On Fri, Feb 23, 2001 at 12:32:37PM -0800, Aaron Burt wrote:
> > Yep, by default it does.  You can change it by using the --enable-8bit
> > configure option with 7.0.0 or editing conserver/cons.h in pre-7.0.0
> > versions (option CPARITY - set to 0).  If that doesn't do it for you,
> > let me know ("conserver -V" should tell you your current policy with
> > recent versions).
> 
> Well, it still draws MMMM with TERM=linux but things look great with
> TERM=vt220 or xterm.  I tried a stock 6.1.7 client connecting to a 8-bit
> 7.0.0 server, too.  Worked fine.

Hmmm...I have a RAID array that uses line drawing characters and they
pass through just fine (7 or 8 bit compilation setting).  Are you
logging the data to a file?  Does the data in the file look correct?
In my logfile it looks like there's a "start line drawing" sequence
(ctrl-n), then a bunch of normal characters (m,q,j, etc) and a "stop
line drawing" sequence (ctrl-o) (an echo of ctrl-n,mqqqqj,ctrl-o makes
line characters appear, actually, so that's probably it).  Do things
like that being logged?  Since all of that are 7-bit characters, it
should "just work" through conserver.

Whatever conserver gets on the console is logged without change (except
for possibly stripping the high bit) to the logfile.

> >> Also, is there any info on how keycodes are passed on?
> 
> To amplify, it'd be nice to understand the mechanism well enough to ensure
> Fn keys and suchlike are sent properly, and perhaps even to remap <BREAK>
> to something like, say, SysRQ (for Linux kernel hackers, y'see).
> Also, no matter what the terminal-type is set to in the inittab for getty
> on the machine being controlled, backspace and delete don't work when
> logging in.  Though ^H does.  Arrow keys move the cursor but seem to
> invisibly mess up the username/password.

Oops..forgot to address this question.  Conserver and the console
client do no translation of characters (in either direction)...it's
just a "semi-stupid" conduit between your keyboard and the serial port
(well, console - could be a command being run instead of a serial port,
ya know).  I say semi-stupid because you have all the escape sequences
to replay logs, send a break, etc.  I'd suggest logging into a console
that you're having trouble with, run 'cat -tv' and then hit the
backspace and return keys.  Do you get a '^H' as output or some long
sequence of escape characters (which some things like to send)?  It's
one way of finding out what, exactly, your keyboard is sending and what
the terminal driver is seeing and having to cope with.  That should,
hopefully, help you determine what you need to do to get it to pass the
right data.

> And yes, I'm trynta look at the source, too.

Good luck!  I hope some of what I've said helps.  Yell if I made things
less clear or anything.

Bryan