Right shift + backspace doesn't become delete

[Daniel W]

The rightmost key on the top row is, on its own, supposed to be backspace and, in combination with shift, to be delete. That works fine when I use the left shift key, but with the right shift, I get a somewhat strange behavior.

When the cursor is at the very beginning (in the first position of the first row, if it's a multi-line edit) of somewhere I can type, right shift + backspace, as expected, works like delete, but whenever the cursor is somewhere inside a text, right shift + backspace doesn't become delete, but just backspace.

The behavior seems consistent across the apps I've examined so far, such as AirMail, Agenda, Messaging, some notepad apps, and even in oddball locations, such as when editing a filename in the FM Radio app, so this seems to be a keyboard issue rather than a problem with any particular apps.

The only exception I could find, was when I used the Microsoft Remote Desktop client to log on to a Windows computer. There, none of the shift keys made backspace work as delete, probably because Windows itself doesn't think shift + backspace equals delete.

My Gemini has a Swedish keyboard and the "Integrated keyboard" is set to "Gemini Keyboard - Swedish", though I doubt the selected layout matters, as delete, presumably, is supposed to work the same across all locales.

While waiting for the Cosmo, I'm trying to use my Gemini for most mobile-related things (except photos/video, actual phone calls and messaging) and thus I'm increasingly typing on it. I can press left shift + backspace even with one hand (say, when holding something edible in the other), though it's a bit awkward and sometimes a stray knuckle brushes against the screen, causing random results.

Does anybody else experience this, and, if so, is there a fix for it?

[gymbo]

Does anybody else experience this, and, if so, is there a fix for it?

Can't offer any solution, but I can confirm I get the same behavior. I am using a Norwegian keyboard and setup.

(I might have encountered it earlier, but have probably dismissed it as not registering the shift key. Usually I use the shift key on the opposite side to the key I need, right-hand shift for left hand key and vice-versa, so most of the time I would use left shift for delete, so it wouldn't be my most used key-combination. Would probably have done the same for "ctrl" and "fn" if there were two of them as well...)

[mithrandir]

This might be interesting. I have tried from within Debian and captured the events with xev (German layout). As you can see both times the same keycode (119) gets registered. All events are double, one for press (state=0) and one for depress (state=1).

So, if our devices are not different hardware wise, I suspect this is a software issue. Might be in the kernel (since the Debian kernel got some modifications in the keyboard driver (there have been some simplifications at the time the keyboard off on lid close fix came in). But in my opinion it is much more probable, that the issue is somewhere in user space. Maybe Adam can confirm that his changes cannot be connected to the different behavior regarding Debian and Android.

KeyPress event, serial 49, synthetic NO, window 0x2e00001,
    root 0x271, subw 0x0, time 63523035, (314,821), root:(1758,894),
    state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 49, synthetic NO, window 0x2e00001,
    root 0x271, subw 0x0, time 63523655, (314,821), root:(1758,894),
    state 0x1, keycode 22 (keysym 0xffff, Delete), same_screen YES,
    XKeysymToKeycode returns keycode: 119
    XLookupString gives 1 bytes: (7f) ""
    XmbLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False

KeyRelease event, serial 49, synthetic NO, window 0x2e00001,
    root 0x271, subw 0x0, time 63524022, (314,821), root:(1758,894),
    state 0x1, keycode 22 (keysym 0xffff, Delete), same_screen YES,
    XKeysymToKeycode returns keycode: 119
    XLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False

KeyRelease event, serial 49, synthetic NO, window 0x2e00001,
    root 0x271, subw 0x0, time 63524628, (314,821), root:(1758,894),
    state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 49, synthetic NO, window 0x2e00001,
    root 0x271, subw 0x0, time 63526428, (314,821), root:(1758,894),
    state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 49, synthetic NO, window 0x2e00001,
    root 0x271, subw 0x0, time 63527016, (314,821), root:(1758,894),
    state 0x1, keycode 22 (keysym 0xffff, Delete), same_screen YES,
    XKeysymToKeycode returns keycode: 119
    XLookupString gives 1 bytes: (7f) ""
    XmbLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False

KeyRelease event, serial 49, synthetic NO, window 0x2e00001,
    root 0x271, subw 0x0, time 63527283, (314,821), root:(1758,894),
    state 0x1, keycode 22 (keysym 0xffff, Delete), same_screen YES,
    XKeysymToKeycode returns keycode: 119
    XLookupString gives 1 bytes: (7f) ""
    XFilterEvent returns: False

KeyRelease event, serial 49, synthetic NO, window 0x2e00001,
    root 0x271, subw 0x0, time 63527762, (314,821), root:(1758,894),
    state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[Adam Boardman]

Maybe Adam can confirm that his changes cannot be connected to the different behavior regarding Debian and Android.

Nothing intentional on that front from me, I'd be looking at this fix for the biggest changes in terms of key press interpretation:
Mostly fixed keyboard ghosting issue

[Daniel W]

Interesting indeed. Thank you mithrandir. Yes, I (too) presume the actual keyboard hardware is identical, regardless of what happens to be engraved on the keycaps.

According to your captured events, both the KeyPress and KeyRelease events for the Delete key has state 1. Maybe that could cause confusion in some software layer, but since both Shift keys seems to behave as expected (0 for press, 1 for release) and the resulting keycode becomes 22 (Delete), regardless of which Shift key is held, I would deduce that the "Right shift + backspace doesn't become delete" issue doesn't exist in Debian. Is that so?

From the Google Play Store, I installed KeyEvent Display v0.04 by Alexandros Schillings onto my X25 Gemini running Andorid 7.1.1, and captured the following events:
[size=]
//Lines beginning with two slashes and some non-breaking spaces, to line columns up, were inserted by me.
//left Shift only
^ KeyDown:      action=0 code= 59 repeat=0 meta= 65 scancode=42 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 59 repeat=0 meta=  0 scancode=42 mFlags=8 label='' chars='null' number=''
//right Shift only
^ KeyDown:      action=0 code= 60 repeat=0 meta=129 scancode=54 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 60 repeat=0 meta=  0 scancode=54 mFlags=8 label='' chars='null' number=''
//Backspace only
^ KeyDown:      action=0 code= 67 repeat=0 meta=  0 scancode=14 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 67 repeat=0 meta=  0 scancode=14 mFlags=8 label='' chars='null' number=''
//left Shift + Backspace
^ KeyDown:      action=0 code= 59 repeat=0 meta= 65 scancode=42 mFlags=8 label='' chars='null' number=''
^ KeyDown:      action=0 code=112 repeat=0 meta= 65 scancode=14 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code=112 repeat=0 meta= 65 scancode=14 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 59 repeat=0 meta=  0 scancode=42 mFlags=8 label='' chars='null' number=''
//right Shift + Backspace
^ KeyDown:      action=0 code= 60 repeat=0 meta=129 scancode=54 mFlags=8 label='' chars='null' number=''
^ KeyDown:      action=0 code= 67 repeat=0 meta=129 scancode=14 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 67 repeat=0 meta=129 scancode=14 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 60 repeat=0 meta=  0 scancode=54 mFlags=8 label='' chars='null' number=''
//left Shift + right Shift + Backspace
^ KeyDown:      action=0 code= 59 repeat=0 meta= 65 scancode=42 mFlags=8 label='' chars='null' number=''
^ KeyDown:      action=0 code= 60 repeat=0 meta=193 scancode=54 mFlags=8 label='' chars='null' number=''
^ KeyDown:      action=0 code= 67 repeat=0 meta=193 scancode=14 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 67 repeat=0 meta=193 scancode=14 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 60 repeat=0 meta= 65 scancode=54 mFlags=8 label='' chars='null' number=''
^ KeyUp:        action=1 code= 59 repeat=0 meta=  0 scancode=42 mFlags=8 label='' chars='null' number=''
[/size][/font]
So, in the Gemini flavor of Android 7.1.1, it seems scancode 14 (Backspace key) in meta state 65 (left Shift held) produces code 112 (apparently Delete), but in meta state 129 (right Shift held) or 193 (both Shift held) it produces code 67 (apparently Backspace). Thus, left Shift + Backspace becomes Delete, but right Shift + Backspace doesn't. To me, that seems like a bug in this particular version of Android. I would presume a text editor app looking at the actual scancodes and mete states could work around this, but the correct solution would probably be to fix this in the Gemini Android version.