Re: bin/51385: NetBSD-7/amd64 tset(1) requires subsequent stty erase '^?'

[Michael van Elst <mlelstv%serpens.de@localhost>]

The following reply was made to PR bin/51385; it has been noted by GNATS.

From: Michael van Elst <mlelstv%serpens.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: mlelstv%NetBSD.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
        Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
Subject: Re: bin/51385: NetBSD-7/amd64 tset(1) requires subsequent stty erase
 '^?'
Date: Tue, 2 Aug 2016 13:26:18 +0200

 On Tue, Aug 02, 2016 at 08:10:01AM +0000, Matthew Mondor wrote:
 > 
 >  If I understand, you are saying that there is nothing we can fix, are
 >  recommending that I create an alternate terminfo vt220 or wsvt25 entry
 >  variant, as well as an rxvt variant, or that I explicitely configure
 >  their backspace independently (wscons and urxvt), and that xterm has
 >  been broken by freedesktop.
 
 I am saying that you shouldn't run tset for all these terminals.
 
 xterm uses ^h by default. So it's fine to run tset as is (unless you
 use some hacked Linux xterm).
 
 wsvt25/vt220 is fine with a USB keyboard, but for a PS/2 keyboard
 you should configure wscons accordingly.
 
 rxvt is strange, terminfo says it is using ^h (and shift-backspace is
 ^?), but apparently that's wrong. In any case nobody needs tset here.
 
 
 
 >  Yet I don't remember needing to do this
 >  since NetBSD 1.5.
 
 I remember needing to do this since about NetBSD 5.
 
 
 >  So every NetBSD user with a PC and PS/2 keyboard
 >  must now have a special custom configuration, or completely avoid
 >  tset/reset.
 
 Actually, every NetBSD user with a USB keyboard had to.
 
 I wouldn't mind changing the PS/2 keymap to match the USB keymap.
 But that probably ends like an editor war....never.
 
 
 >  A good reason for having kept PS/2 was for debugging and reliability,
 >  as the bootloader and DDB input often had issues with USB (I'm not sure
 >  if that's still often the case).
 
 They still have. In particular with the server that has PS/2 connectors
 for keyboard and mouse but internally runs a PS/2->USB adapter.
 
 
 
 >  If PS/2 IBM-style keyboards are sending different codes, couldn't it not
 >  be considered one of the architecture-intimate pckbd(4)'s role to
 >  possibly help (i.e. via lower level layout/code mappings rather than
 >  encodings), perhaps eventually configurable via a potential pckbdctl(8)
 >  or similar?
 
 The key codes are fine and standardized, the mappings of course depend
 on the various layouts. For the MF2 keyboard you have the Backspace
 key (keycode 14) and the Delete key (keycode 211). The keyboard itself
 transmits 1-3 byte scan codes for pressing and releasing keys, the
 pckbd driver generates the keycodes from that. It also provides
 a map for wscons to translate this into key symbols.
 
 
 US (default for most things):
 /*  pos      command            normal          shifted */
     KC(14),  KS_Cmd_ResetEmul,  KS_Delete,      
 	KC(211),                    KS_Delete,
 
 GR:
 /*  pos      normal             shifted         altgr        shift-altgr */
     KC(14),  KS_Delete,         KS_BackSpace,
 
 
 
 A USB keyboard with keycode 42 (Backspace) and keycode 76 (Delete)
 (transmitted as is by the keyboard) would use the following maps:
 
 US (default for most things):
 /*  pos      command            normal          shifted */
     KC(42),                     KS_BackSpace,
     KC(76),                     KS_Delete,
 
 Colemak:
 /*  pos      command            normal          shifted */
     KC(57),                     KS_BackSpace,
 
 KC(57) is regularly the CapsLock key on the left side. So here
 you have two Backspace keys :)
 
 There is also some magic for Apple keyboards. If I understand this
 correctly, the Apple function key will make the Backspace key act
 like the Delete key.
 
 
 
 And then have a look what the tty layer and getty have to say about
 the topic and why bash and tcsh try to be agnostic.
 
 
 For now tset shouldn't be used (it got removed from the root .cshrc
 templates) unless you know how and why to use it.
 
 
 
 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."