Re: wsvt25 backspace key should match terminfo definition

2021-11-22 Thread Valery Ushakov
On Tue, Nov 23, 2021 at 00:01:40 +, RVP wrote: > On Tue, 23 Nov 2021, Johnny Billquist wrote: > > > If something pretends to be a VT220, then the key that deletes > > characters to the left should send DEL, not BS... > > Just saying... > > That's fine with me too. As long as things are

Re: wsvt25 backspace key should match terminfo definition

2021-11-22 Thread RVP
On Tue, 23 Nov 2021, Johnny Billquist wrote: If something pretends to be a VT220, then the key that deletes characters to the left should send DEL, not BS... Just saying... That's fine with me too. As long as things are consistent. I suggested the kernel change because both terminfo

Re: wsvt25 backspace key should match terminfo definition

2021-11-22 Thread Johnny Billquist
If something pretends to be a VT220, then the key that deletes characters to the left should send DEL, not BS... Just saying... Johnny On 2021-11-23 00:48, RVP wrote: The kernel currently defines the backspace key as: $ fgrep CERASE /usr/include/sys/ttydefaults.h #define CERASEĀ 

wsvt25 backspace key should match terminfo definition

2021-11-22 Thread RVP
The kernel currently defines the backspace key as: $ fgrep CERASE /usr/include/sys/ttydefaults.h #define CERASE 0177 $ This should probably be changed to CTRL('h') to match both the NetBSD and GNU terminfo backspace key definitions, otherwise the key doesn't work right after reset(1)

Re: if_ethersubr.c: if_ierrors -> if_iqdrops?

2021-11-22 Thread RVP
On Mon, 22 Nov 2021, SAITOH Masanobu wrote: I wrote a patch for better counting: Better counting for ierrors, iqdrops and noproto in ether_input(). - Use if_noproto for unknown or unsupported protocols. - Use if_ierror for wrong mbuf and oversized frame. Thank you for that. I'm

Re: if_ethersubr.c: if_ierrors -> if_iqdrops?

2021-11-22 Thread SAITOH Masanobu
return; } The same diff is at: https://www.netbsd.org/~msaitoh/ether_input_noproto-20211122-0.dif Is the above change acceptable? Don't know if it is the TP-Link WiFi extender I'm cabled to that is sending these short frames or what. The alc driver isn't reporting a