issue with keyboard input for multiple keys Ctrl-b / nkey rollover?

issue with keyboard input for multiple keys Ctrl-b / nkey rollover?

[Alan Davis]

I have left behind at least three different keyboards due to a problem
when, especially backing up a character at a time, in Emacs, and perhaps in
bash.  The following are the most recent keyboards with this problem:

   - Microsoft Surface bluetooth keyboard
   - A mechanical keyboard with Nkey rollover

I quit using the first of these due to this problem, replacing it with the
mechanical keyboard.  I hoped the Nkey rollover would mean key chords like
Ctrl-b would work.   Unfortunately the results are unsatisfactory.  Often
when editing with emacs (truth be told I don't remember whether this is the
case with a bash console), I have to repeat the keychord twice before the
cursor will move.  So if I want to back up two characteris, I need to type
Alt-b 4 times to move the cursor back 2 positions.

I had hoped that NKey rollover would eliminate this problem.  That is not
the case: the mechanical keyboard has this same problem.

I am afraid I have not nailed down the specific instances when this
occurs.   It has occured to me that this may happen with some terminal
emulators but not on others. Even this seems to be inconsistent: in fact
just now I tried this key combination in an emacs window, and it worked
fine.

Since I am unable to reproduce this issue at all times, perhaps I can just
request information about keyboard behavior that might shed light on the
problem or similar problems.

Alas, I throw up my hands in despair...   Does this behavior mean something
to someone?  Is it an expected behavior?  Is there a simple solution?

Any pointers would be appreciated.

Thank you for any advice whatsoever,

Alan Davis


-- 
The foundation of morality is to have done, once and for all, with lying.
                     ---Thomas Huxley,

Re: issue with keyboard input for multiple keys Ctrl-b / nkey rollover?

[2QdxY4RzWzUUiLuE]

On 2020-08-02 at 03:59:33 -0700,
Alan Davis <alan3davis@gmail.com> wrote:

> I have left behind at least three different keyboards due to a problem
> when, especially backing up a character at a time, in Emacs, and perhaps in
> bash.  The following are the most recent keyboards with this problem:
> 
>    - Microsoft Surface bluetooth keyboard
>    - A mechanical keyboard with Nkey rollover
> 
> I quit using the first of these due to this problem, replacing it with the
> mechanical keyboard.  I hoped the Nkey rollover would mean key chords like
> Ctrl-b would work.   Unfortunately the results are unsatisfactory.  Often
> when editing with emacs (truth be told I don't remember whether this is the
> case with a bash console), I have to repeat the keychord twice before the
> cursor will move.  So if I want to back up two characteris, I need to type
> Alt-b 4 times to move the cursor back 2 positions.
> 
> I had hoped that NKey rollover would eliminate this problem.  That is not
> the case: the mechanical keyboard has this same problem.
> 
> I am afraid I have not nailed down the specific instances when this
> occurs.   It has occured to me that this may happen with some terminal
> emulators but not on others. Even this seems to be inconsistent: in fact
> just now I tried this key combination in an emacs window, and it worked
> fine.

Even if you can't nail down the specific instances when this occurs, a
few examples of when it does (or has) or doesn't (or hasn't) would help
someone help you.

You said "bash" and "terminal emulator," so I could probably assume
Linux or BSD, but what OS(es), desktop environment(s), and/or window
manager(s) are you running or have you tried?

What made you think that n-key rollover would make a difference?  Are
you running assistive software, or some sort of uncommon hardware or I/O
subsystem?  Is it some kind of virtual machine?

Re: issue with keyboard input for multiple keys Ctrl-b / nkey rollover?

[Alan Davis]

Yes.  GNU/Linux.

On Sun, Aug 2, 2020, 04:46 <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

>
>
> Even if you can't nail down the specific instances when this occurs, a
> few examples of when it does (or has) or doesn't (or hasn't) would help
> someone help you.
>
> You said "bash" and "terminal emulator," so I could probably assume
> Linux or BSD, but what OS(es), desktop environment(s), and/or window
> manager(s) are you running or have you tried?
>

i3 almost exclusively for 2+years.

What made you think that n-key rollover would make a difference?


?  Grasping at straws, given emacs requires one to use N keys?

Are
> you running assistive software, or some sort of uncommon hardware or I/O
> subsystem?  Is it some kind of virtual machine?
>
No.

Thank you for these ideas.

Alan

>

Re: issue with keyboard input for multiple keys Ctrl-b / nkey rollover?

[Yuri Khan]

On Sun, 2 Aug 2020 at 18:00, Alan Davis <alan3davis@gmail.com> wrote:
>
> I have left behind at least three different keyboards due to a problem
> when, especially backing up a character at a time, in Emacs, and perhaps in
> bash.  The following are the most recent keyboards with this problem:
>
>    - Microsoft Surface bluetooth keyboard
>    - A mechanical keyboard with Nkey rollover
>
> I quit using the first of these due to this problem, replacing it with the
> mechanical keyboard.  I hoped the Nkey rollover would mean key chords like
> Ctrl-b would work.

N-key rollover does not matter at all. Modifier keys (Ctrl, Alt, Shift
and whatever OS-specific fourth key you use) are always reported
independently in the USB HID keyboard protocol.

> Often
> when editing with emacs (truth be told I don't remember whether this is the
> case with a bash console), I have to repeat the keychord twice before the
> cursor will move.  So if I want to back up two characteris, I need to type
> Alt-b 4 times to move the cursor back 2 positions.

I suppose you meant Ctrl-b here.

> I am afraid I have not nailed down the specific instances when this
> occurs.   It has occured to me that this may happen with some terminal
> emulators but not on others. Even this seems to be inconsistent: in fact
> just now I tried this key combination in an emacs window, and it worked
> fine.

Stab in the dark: Do you use tmux some but not all of the time? It
uses Ctrl+b as prefix key by default, so you have to press it twice
for it to get reported to the application running within. You can
configure tmux to use a different prefix key.


Also, since you seem to be into mechanical keyboards, consider getting
one that puts arrow keys in an easily accessible place, or configure
layers to put arrow keys at your home row.

Re: issue with keyboard input for multiple keys Ctrl-b / nkey rollover?

[Perry Smith]

> On Aug 2, 2020, at 8:50 AM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> 
> On Sun, 2 Aug 2020 at 18:00, Alan Davis <alan3davis@gmail.com> wrote:
>> I am afraid I have not nailed down the specific instances when this
>> occurs.   It has occured to me that this may happen with some terminal
>> emulators but not on others. Even this seems to be inconsistent: in fact
>> just now I tried this key combination in an emacs window, and it worked
>> fine.
> 
> Stab in the dark: Do you use tmux some but not all of the time? It
> uses Ctrl+b as prefix key by default, so you have to press it twice
> for it to get reported to the application running within. You can
> configure tmux to use a different prefix key.

Ah… that is what I was thinking of.  OPs description triggered a faint memory
but I couldn’t place it.

Re: issue with keyboard input for multiple keys Ctrl-b / nkey rollover?

[Alan Davis]

Thank you for these several responses to my imprecise trouble report.

I have used tmux, recently; and this might have happened.  This does not
explain the many instances  long before i started using it.

I am running i3 Manjaro GNU/Linux and have been for over two years.  For a
time i used the st terminal emulator, and urxvt, mostly recently.  Perhaps
experiments along this line would be suggested.   I sure hope i3 has not
been involved.

I appreciate these responses.

Alan



On Sun, Aug 2, 2020, 08:03 Perry Smith <pedz@easesoftware.com> wrote:

>
>
> > On Aug 2, 2020, at 8:50 AM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> >
> > On Sun, 2 Aug 2020 at 18:00, Alan Davis <alan3davis@gmail.com> wrote:
> >> I am afraid I have not nailed down the specific instances when this
> >> occurs.   It has occured to me that this may happen with some terminal
> >> emulators but not on others. Even this seems to be inconsistent: in fact
> >> just now I tried this key combination in an emacs window, and it worked
> >> fine.
> >
> > Stab in the dark: Do you use tmux some but not all of the time? It
> > uses Ctrl+b as prefix key by default, so you have to press it twice
> > for it to get reported to the application running within. You can
> > configure tmux to use a different prefix key.
>
> Ah… that is what I was thinking of.  OPs description triggered a faint
> memory
> but I couldn’t place it.
>
>
>

Re: N-key rollover keyboards (was: issue with keyboard input for multiple keys Ctrl-b / nkey rollover?)

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 949 bytes --]

Yuri Khan <yuri.v.khan@gmail.com> wrote:
> On Sun, 2 Aug 2020 at 18:00, Alan Davis <alan3davis@gmail.com> wrote:
>> I hoped the Nkey rollover would mean key chords like Ctrl-b would work.

> N-key rollover does not matter at all. Modifier keys (Ctrl, Alt, Shift
> and whatever OS-specific fourth key you use) are always reported
> independently in the USB HID keyboard protocol.

FWIW, N-key rollover is not really about USB or protocols; itʼs about circuit of the keyboard.

It does matter, when you reconfigure modifiers in a human-friendly way, that is move one of the ‘controls’ (normally, the left one) closer to ‘space’ — under your thumb — (ctrl:swap_lalt_lctl setxkbmap(1) -option or equivalent).

Then, on many ordinary keyboards few combinations, that are in use in Emacs, are indeed get ‘ghosted’.  And M-C-b with inner M- and C- is a very likely variant.

Two-key chords can never be affected, of course.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: N-key rollover keyboards (was: issue with keyboard input for multiple keys Ctrl-b / nkey rollover?)

[Alan Davis]

On Sun, Aug 2, 2020, 10:04 Dmitry Alexandrov <dag@gnui.org> wrote:

> Yuri Khan <yuri.v.khan@gmail.com>


> FWIW, N-key rollover is not really about USB or protocols; itʼs about
> circuit of the keyboard.
>
> It does matter, when you reconfigure modifiers in a human-friendly way,
> that is move one of the ‘controls’ (normally, the left one) closer to
> ‘space’ — under your thumb — (ctrl:swap_lalt_lctl setxkbmap(1) -option or
> equivalent).
>
> Then, on many ordinary keyboards few combinations, that are in use in
> Emacs, are indeed get ‘ghosted’.  And M-C-b with inner M- and C- is a very
> likely variant.
>
> Two-key chords can never be affected, of course.
>

'ghosted'?  Does this mean these apparently problematic combinations
require N-key rollover?

I am also using org-mode with several multiple-key chords.  I cannot
remember any instance where these have been a problem.

Allan

>

Re: N-key rollover keyboards

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]

Alan Davis <alan3davis@gmail.com> wrote:
> On Sun, Aug 2, 2020, 10:04 Dmitry Alexandrov <dag@gnui.org> wrote:
>> FWIW, N-key rollover is not really about USB or protocols; itʼs about circuit of the keyboard.
>>
>> It does matter, when you reconfigure modifiers in a human-friendly way, that is move one of the ‘controls’ (normally, the left one) closer to ‘space’ — under your thumb — (ctrl:swap_lalt_lctl setxkbmap(1) -option or equivalent).
>>
>> Then, on many ordinary keyboards few combinations, that are in use in Emacs, are indeed get ‘ghosted’.  And M-C-b with inner M- and C- is a very likely variant.
>>
>> Two-key chords can never be affected, of course.
>
> 'ghosted'?

Yes.  https://www.bing.com/search?q=key+ghosting

> Does this mean these apparently problematic combinations require N-key rollover?

No, not necessary.  Much cheaper redesign of a circuit would suffice.

> I am also using org-mode with several multiple-key chords.  I cannot remember any instance where these have been a problem.

So, evidently, either your keyboards are not affected or youʼve just never bumped into affected chords.  Do an exhaustive check, if you are concerned:

	(while t
	  (let ((key (read-key)))
	    (message "%s: ok\n" (format-kbd-macro (vector key)))
	    (when (eql ?\C-g key) (keyboard-quit))))

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: N-key rollover keyboards

[Alan Davis]

Thank you.  An impressive bit of coding.  Executing this code in emacs,
then serially typing in various keys, combinations results in an "ok" in
the minibuffer.  There was one combination that executed an i3 command anv
moved the window to the other display.   This gives me something to work
on.  An emacs instance in a terminal ($emacs -nw ) om either urxvt or st
gives the same result.  I wonder why the combination Shift-Ctrl-B passes
through to i3 and is executed, but not other commands.   This is so in
either of these terminals as well as in an emacs window.

Is there a similar tool that can be used in bash?

Alan Davis




On Mon, Aug 3, 2020 at 11:17 AM Dmitry Alexandrov <dag@gnui.org> wrote:

> Alan Davis <alan3davis@gmail.com> wrote:
> > On Sun, Aug 2, 2020, 10:04 Dmitry Alexandrov <dag@gnui.org> wrote:
> >> FWIW, N-key rollover is not really about USB or protocols; itʼs about
> circuit of the keyboard.
> >>
> >> It does matter, when you reconfigure modifiers in a human-friendly way,
> that is move one of the ‘controls’ (normally, the left one) closer to
> ‘space’ — under your thumb — (ctrl:swap_lalt_lctl setxkbmap(1) -option or
> equivalent).
> >>
> >> Then, on many ordinary keyboards few combinations, that are in use in
> Emacs, are indeed get ‘ghosted’.  And M-C-b with inner M- and C- is a very
> likely variant.
> >>
> >> Two-key chords can never be affected, of course.
> >
> > 'ghosted'?
>
> Yes.  https://www.bing.com/search?q=key+ghosting
>
> > Does this mean these apparently problematic combinations require N-key
> rollover?
>
> No, not necessary.  Much cheaper redesign of a circuit would suffice.
>
> > I am also using org-mode with several multiple-key chords.  I cannot
> remember any instance where these have been a problem.
>
> So, evidently, either your keyboards are not affected or youʼve just never
> bumped into affected chords.  Do an exhaustive check, if you are concerned:
>
>         (while t
>           (let ((key (read-key)))
>             (message "%s: ok\n" (format-kbd-macro (vector key)))
>             (when (eql ?\C-g key) (keyboard-quit))))
>


-- 
The foundation of morality is to have done, once and for all, with lying.
                     ---Thomas Huxley,

Re: N-key rollover keyboards

[2QdxY4RzWzUUiLuE]

On 2020-08-03 at 14:48:34 -0700,
Alan Davis <alan3davis@gmail.com> wrote:

> Is there a similar tool that can be used in bash?

There's xev, but the output is not nearly as concise.

You mentioned Manjaro; xev is in a package called xorg-apps on my Arch
system.

Re: N-key rollover keyboards

[Alan Davis]

I have verified that my original complaint happens in a terminal with tmux
running, running emacs with the "-nw" option.  as some responses
suggested.   That said, I wonder whether there may exist an interaction
between i3 keybindings and emacs' bindings.  I wonder why it seems to be
this specific combination and not other ones; and I intend to verify this
using another keyboard.

Thank you for suggestions that helped clear my thinking about this
problem.

Alan Davis

On Mon, Aug 3, 2020 at 3:13 PM <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:

> On 2020-08-03 at 14:48:34 -0700,
> Alan Davis <alan3davis@gmail.com> wrote:
>
> > Is there a similar tool that can be used in bash?
>
> There's xev, but the output is not nearly as concise.
>
> You mentioned Manjaro; xev is in a package called xorg-apps on my Arch
> system.
>
>

-- 
The foundation of morality is to have done, once and for all, with lying.
                     ---Thomas Huxley,

Re: N-key rollover keyboards

[Yuri Khan]

On Tue, 4 Aug 2020 at 17:08, Alan Davis <alan3davis@gmail.com> wrote:
>
> I have verified that my original complaint happens in a terminal with tmux
> running, running emacs with the "-nw" option.  as some responses
> suggested.   That said, I wonder whether there may exist an interaction
> between i3 keybindings and emacs' bindings.

Of course there is an interaction. You have a stack of software, all
listening for keystrokes. They will have a chance to handle them in
roughly this order:

1. your kernel (typically handles Ctrl+Alt+F1..F10 to switch TTYs)
2. your X server (in older times, it would terminate on
Ctrl+Alt+Backspace; also keyboard layout switching happens here)
3. your window manager or desktop environment (Alt+Tab window
switching in GNOME/Xfce/KDE, any i3 bindings, any desktop-wide
shortcuts such as Volume Up or Launch Web Browser)
4a. the actual application if it is a GUI-based one
--- or, for terminal-based applications: ---
4b. your X terminal emulator (GUI terminals may have some bindings to
display their help, activate their menu bar, open, close, or switch
tabs)
5. your terminal multiplexer if any (GNU Screen takes Ctrl+a, Tmux
takes Ctrl+b by default)
6. the actual terminal-based application running within the stack

> I wonder why it seems to be
> this specific combination and not other ones; and I intend to verify this
> using another keyboard.

I predict that your issue is not caused by hardware.

Re: N-key rollover keyboards

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

Yuri Khan <yuri.v.khan@gmail.com> wrote:
> Of course there is an interaction. You have a stack of software, all listening for keystrokes. They will have a chance to handle them in roughly this order:
>
> 1. your kernel (typically handles Ctrl+Alt+F1..F10 to switch TTYs)

Is that really the case?

— M-! xkbcomp $DISPLAY -
— remove  XF86Switch_VT_1  from  key <FK01>
— M-| xkbcomp - $DISPLAY
→ and Ctrl-Alt-F1 does not work anymore for me.

> 2. your X server (in older times, it would terminate on Ctrl+Alt+Backspace; also keyboard layout switching happens here)

Oh, indeed!  If one is experiecing oddities with input when using Emacs (as well as some app running under terminal emulator), it might be due to the fact that it still is not layout-aware.  And if user have never needed non-latin input, he in turn might be not aware of that fact.

@alan3davis@gmail.com, were not your experimenting with similar to QWERTY yet slightly different layouts?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: N-key rollover keyboards

[Yuri Khan]

On Wed, 5 Aug 2020 at 00:46, Dmitry Alexandrov <dag@gnui.org> wrote:
>
> Yuri Khan <yuri.v.khan@gmail.com> wrote:
> > Of course there is an interaction. You have a stack of software, all listening for keystrokes. They will have a chance to handle them in roughly this order:
> >
> > 1. your kernel (typically handles Ctrl+Alt+F1..F10 to switch TTYs)
>
> Is that really the case?
>
> — M-! xkbcomp $DISPLAY -
> — remove  XF86Switch_VT_1  from  key <FK01>
> — M-| xkbcomp - $DISPLAY
> → and Ctrl-Alt-F1 does not work anymore for me.

Good catch. Things in parentheses are just examples though; my point
is that there is a hierarchy of layers and each higher layer may
choose to intercept and handle certain keystrokes before they ever
reach the lower ones. When debugging an “I press a key and do not get
the expected effect” issue, it helps to understand exactly on which
layer you expect an effect, and which layers above might have a say.

Re: N-key rollover keyboards

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

2QdxY4RzWzUUiLuE@potatochowder.com wrote:
> On 2020-08-03 at 14:48:34 -0700,
> Alan Davis <alan3davis@gmail.com> wrote:
>
>> Is there a similar tool that can be used in bash?
>
> There's xev, but the output is not nearly as concise.

xev has nothing to do with Bash.

> xev is in a package called xorg-apps

Exactly!  It creates an X window and thus is absolutely unsuitable for testing what your terminal recognizes / intercepts.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: N-key rollover keyboards

[2QdxY4RzWzUUiLuE]

On 2020-08-04 at 20:25:17 +0300,
Dmitry Alexandrov <dag@gnui.org> wrote:

> 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
> > On 2020-08-03 at 14:48:34 -0700,
> > Alan Davis <alan3davis@gmail.com> wrote:
> >
> >> Is there a similar tool that can be used in bash?
> >
> > There's xev, but the output is not nearly as concise.
> 
> xev has nothing to do with Bash.
> 
> > xev is in a package called xorg-apps
> 
> Exactly!  It creates an X window and thus is absolutely unsuitable for testing what your terminal recognizes / intercepts.

The OP mentioned i3, an X window manager, more than once, and
specifically used the phrase "terminal emulator," which usually means an
X application that emulates a terminal.  I agree that xev can't test
exactly what your terminal receives, but it can tell you what the X
server saw from the keyboard, and could provide clues as to which key
combinations are or aren't getting to the applications.

Re: N-key rollover keyboards

[Dmitry Alexandrov]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

Alan Davis <alan3davis@gmail.com> wrote:
> Is there a similar tool that can be used in bash?

Just  $ read -r  should be enough, unless you need a fancy output.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]