--- In "Yan Seiner" <> wrote:
>
> --- In "Anouk Ahamitet" <snowcone27@> wrote:
> > [...]
> > 'linux'; and the local console (connected directly to the TS-7KV) also
> > reports 'linux'. However, PuTTY tells the terminal handler that it is
> > an 'xterm'.
>
> Your login script may be doing that. Try setting TERM=xterm or
> whatever by hand.
That could be, I'll check, but FWIW, I've not edited (or replaced) the
login script(s) onboard the TS-7250 as vi is my personal kryptonite.
...hmmm... There don't seem to be any of the login scripts that I've
heard of. 'ls -al' in root's home directory shows a .ash_history
file, but no other '.' files and neither /etc nor /etc/init.d seem to
have any shared login scripts, either.
And, doing 'export TERM=xterm' makde the fuzzy boxes being displayed
for line graphics characters turn into lower case letters, but that
isn't a whole lot better. Also, 'linux' is actually correct for the
local terminal, but it doesn't work like other 'linux' terminals or
consoles I've used (in RedHat, Debian, Vanilla-kernal or others).
> > fix the fonts, but none of the terminal settings have helped, and
> > there's no i18n on TS-Linux.
>
> Probably due to the TERM mismatch.
That's what I thought, too, but as I said above, changing the TERM
setting for a PuTTY (or minicom) session didn't help, and 'linux' is
normally correct to a physical terminal (like the TS-7KV).
> > 3: Some of the function keys seem to be getting mis-translated by the
> > TS-7KV and terminal keyboard handler. For example, F2 never seems to
>
> That's just plain weird.
To say the least.
> What type of keyboard are you using? USB?
A generic USB keyboard. There's no PS/2 or old-style keyboard port
available. Or at least, not one with a socket (there may be a header).
> Is the keyboard showing up on /dev/input/event*? What does dmesg say
> when you plug in the keyboard?
ls: /dev/input/event*: No such file or directory
The keyboard is present at power on, as it will be when the device is
installed for the customer. Here's what I found by running dmesg:
hub.c: new USB device not_pci-1, assigned address 2
input: USB HID v1.00 Keyboard [055d:0001] on usb1:2.0
> I had some trouble early on with /dev/input; it turned out to be
> related to the app that I was using failing to properly understand the
> keyboard. Nothing to do with the kernel.
I guess I could believe that, but... that would make linux a pretty
weak OS if applications required code for such a basic device as a
keyboard. Also, what I'm seeing is also true for remote telnet
clients as well, so rather than being specific to the USB keyboard, it
would seem to be at a different level in the OS -- somewhere that all
various key event are processed and passed to stdin (where things like
getch() read from).
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|