Re: SI/SO G0/G1 in linux console
> That were the docs I used, I simply did not understand your > writing correctly. Can you suggest an improved phrasing for the part that was confusing or unclear? Andries -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: SI/SO G0/G1 in linux console
[28.02.02 17:15 +] [EMAIL PROTECTED] <-- : > For precise details, see the Keyboard and Console HOWTO > (http://www.win.tue.nl/~aeb/linux/kbd/kbd-6.html) > and manpage console_codes(4). That were the docs I used, I simply did not understand your writing correctly. The answer from Vasilis Vasaitis hit my nose directly onto the point where I made the mistake. -- Erika Pacholleck <[EMAIL PROTECTED]> for private replies unhex my last name -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: SI/SO G0/G1 in linux console
[28.02.02 17:22 +0200] Vasilis Vasaitis <-- : > On Thu, Feb 28, 2002 at 03:26:38PM +0100, Erika Pacholleck wrote: > > expected behaviour from this: > > - typing [Ctrl]+[o] sending Control_o (switch to G0) > > - typing [Ctrl]+[n] sending Control_n (switch to G1) > > Expected behaviour where? You can't expect terminal applications > to just echo every character they receive to the terminal. > A notable exception to this is cat(1), which will just echo at its > output whatever it receives in its input. In fact, cat is very useful > for tests like this. > As I said, just because you press ^N or ^O at the bash prompt, doesn't > mean that it will echo them to the terminal. Use cat and it will do what > you expect. Thanks, NOW I understand!! So a description how to produce that is type cat, press [ENTER], [Ctrl]+[n] or +[o], [ENTER], [Ctrl]+[d], [ENTER] and that really works, great. I simply did not understand the docs. > To summarize, remember that ^N and ^O, like most other codes, change the > state of the terminal when they are output to it, not when they are input > from it. That was what I wanted to achieve, have ls $HOME output in graphical mode, and to output it like that I needed to set the terminal to that state first. > As a rule of thumb, the ASCII value for ^X, where X is any letter of > the english alphabet, equals the position of that letter in the alphabet. I did not know that, this is really a good way to remember it. Thanks very much, everything is fine now. -- Erika Pacholleck <[EMAIL PROTECTED]> for private replies unhex my last name -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: SI/SO G0/G1 in linux console
On Thu, Feb 28, 2002 at 03:26:38PM +0100, Erika Pacholleck wrote: > When doing some experimenting with the acm/screen maps I discovered > some strange things, as to not-working and vice-versa-working. And > I would need an advice where to hook in for fixing, please. > > system information: > - running linux-2.4.10, compiled with/against 2.4.5 > - kbd-1.06, ncurses-5.2 > state after system start: > - with matrox fb > - with keymap de-latin-nodeadkeys > - without font loading/changing > - and $TERM=linux > - and dumpkeys saying 0x000f=control_o 0x000e=control_n > - and inputrc allowing 8-bits > - and locale charmap as ISO-8859-1 So far so good. > expected behaviour from this: > - G0 set to default latin1 and G1 set to VT100 graphics > - typing [Ctrl]+[o] sending Control_o (switch to G0) > - typing [Ctrl]+[n] sending Control_n (switch to G1) Expected behaviour where? You can't expect terminal applications (I assume you were using the shell here) to just echo every character they receive to the terminal. That defeats the whole point of keyboard handling. For example, a lot of programs, upon receiving ^L, while redraw the screen, and not send that character to the terminal. A notable exception to this is cat(1), which will just echo at its output whatever it receives in its input. In fact, cat is very useful for tests like this. > here is what happens in reality: > docs hit keysecho -e orders > SI=G0=^O [Ctrl]+[o] \\033o \\x1bo \\x0e \\016 > SO=G1=^N [Ctrl]+[n] \\033n \\x1bn \\x0f \\017 > resultsnegative neg.neg. both switched > > Ctrl+o looks like CR is sent; Ctrl+n beeps As I said, just because you press ^N or ^O at the bash prompt, doesn't mean that it will echo them to the terminal. Use cat and it will do what you expect. > \\033o \\x1bo and according n's don't show any change These sequences are ESCn and ESCo, completely different from the control characters you are talking about. > \\x0e \\016 look like switched to G1 VT100 graphics > \\x0f \\017 look like switched to G0 latin1 > > So only echoing the hex/oct values seem to get at least the G0/G1 maps > -- only that they now are just the other way round than it should be. Actually, the values you are using should be the other way round, as ^N is ASCII 14 and ^O is ASCII 15. As a rule of thumb, the ASCII value for ^X, where X is any letter of the english alphabet, equals the position of that letter in the alphabet. > And there seems to be no program to report the status (like say, tty2: > using G0, currently set to latin1) so I can only judge from what I see. Indeed, if there is a way I'm not aware of it. > I guess the keymap will need change to make the key-hitting work the > way it should be, but what do I check for the vice-versa 0e/0f signal? > > Thanks for your comments. To summarize, remember that ^N and ^O, like most other codes, change the state of the terminal when they are output to it, not when they are input from it. -- Vasilis Vasaitis [EMAIL PROTECTED] "Don't do drugs. Santa Claus is watching." -- winamp.com -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: SI/SO G0/G1 in linux console
> > Can you try out the dave jones tree. I have rewritten the > > VT emulation support and I like to see if I implemented > > correct behavior. > > Today we have some vaguely vt100-like behaviour described > by TERM=linux. Do you think we need a kernel that supplies > TERM=vt100? Not all of the functionality. For example I don't think we need to support font rotation. Just what we need. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: SI/SO G0/G1 in linux console
> Can you try out the dave jones tree. I have rewritten the > VT emulation support and I like to see if I implemented > correct behavior. Today we have some vaguely vt100-like behaviour described by TERM=linux. Do you think we need a kernel that supplies TERM=vt100? Andries -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: SI/SO G0/G1 in linux console
> SI/SO G0/G1 in linux console doesnt work, or at least > what it does is not at all according to what vt100 does > or ECMA says. > > For precise details, see the Keyboard and Console HOWTO > (http://www.win.tue.nl/~aeb/linux/kbd/kbd-6.html) > and manpage console_codes(4). Can you try out the dave jones tree. I have rewritten the VT emulation support and I like to see if I implemented correct behavior. -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
Re: SI/SO G0/G1 in linux console
SI/SO G0/G1 in linux console doesnt work, or at least what it does is not at all according to what vt100 does or ECMA says. For precise details, see the Keyboard and Console HOWTO (http://www.win.tue.nl/~aeb/linux/kbd/kbd-6.html) and manpage console_codes(4). From: Erika Pacholleck <[EMAIL PROTECTED]> When doing some experimenting with the acm/screen maps I discovered some strange things, as to not-working and vice-versa-working. And I would need an advice where to hook in for fixing, please. expected behaviour from this: - G0 set to default latin1 and G1 set to VT100 graphics - typing [Ctrl]+[o] sending Control_o (switch to G0) - typing [Ctrl]+[n] sending Control_n (switch to G1) and indeed, that is what I find. here is what happens in reality: docs hit keysecho -e orders SI=G0=^O [Ctrl]+[o] \\033o \\x1bo \\x0e \\016 SO=G1=^N [Ctrl]+[n] \\033n \\x1bn \\x0f \\017 resultsnegative neg.neg. both switched Ctrl+o looks like CR is sent; Ctrl+n beeps \\033o \\x1bo and according n's don't show any change \\x0e \\016 look like switched to G1 VT100 graphics \\x0f \\017 look like switched to G0 latin1 what you are testing is your shell rather than the console settings. Andries -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
SI/SO G0/G1 in linux console
When doing some experimenting with the acm/screen maps I discovered some strange things, as to not-working and vice-versa-working. And I would need an advice where to hook in for fixing, please. system information: - running linux-2.4.10, compiled with/against 2.4.5 - kbd-1.06, ncurses-5.2 state after system start: - with matrox fb - with keymap de-latin-nodeadkeys - without font loading/changing - and $TERM=linux - and dumpkeys saying 0x000f=control_o 0x000e=control_n - and inputrc allowing 8-bits - and locale charmap as ISO-8859-1 expected behaviour from this: - G0 set to default latin1 and G1 set to VT100 graphics - typing [Ctrl]+[o] sending Control_o (switch to G0) - typing [Ctrl]+[n] sending Control_n (switch to G1) here is what happens in reality: docs hit keysecho -e orders SI=G0=^O [Ctrl]+[o] \\033o \\x1bo \\x0e \\016 SO=G1=^N [Ctrl]+[n] \\033n \\x1bn \\x0f \\017 resultsnegative neg.neg. both switched Ctrl+o looks like CR is sent; Ctrl+n beeps \\033o \\x1bo and according n's don't show any change \\x0e \\016 look like switched to G1 VT100 graphics \\x0f \\017 look like switched to G0 latin1 So only echoing the hex/oct values seem to get at least the G0/G1 maps -- only that they now are just the other way round than it should be. And there seems to be no program to report the status (like say, tty2: using G0, currently set to latin1) so I can only judge from what I see. I guess the keymap will need change to make the key-hitting work the way it should be, but what do I check for the vice-versa 0e/0f signal? Thanks for your comments. -- Erika Pacholleck <[EMAIL PROTECTED]> for private replies unhex my last name -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
