#179 Shift not working correctly on some devices/apps

[Anonymous]

Originally created by: Klaus.We...@gmail.com
Originally owned by: Klaus.We...@gmail.com

I've heard reports that some devices or applications don't handle Shift as expected, where characters get sent as lowercase even though the keyboard state was supposed to send an uppercase letter.

If you're affected by this bug, can you please let me know which device and application is affected, and if it affects all applications?

Optionally, please look at the "Debug" section of the keyboard's settings menu and let me know what the "input connection" entry is showing, in case it's related to certain input fields.

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

From email report, where it affects "Better Terminal Emulator Pro" only:

the behaviour is the same for both sticky and multitouch shift. When I press shift, the keyboard correctly changes to the uppercase letters, but when I press any letter, lowercase letter is typed. The input connection details says "com.magicandroidapps.bettertermpro type=NULL"

[Anonymous]

Originally posted by: dnast...@gmail.com

Comment #1 above perfectly describes my issue too: same application, same behaviour.

If you want me to test anything please let me know.

[Anonymous]

Originally posted by: dnast...@gmail.com

Forgot to mention the device (if it's of any help): Acer Iconia A500 running a Thor ROM + kernel.

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Thanks for the updates. Are you willing to try a simple testing application which reports the keys it receives from the keyboard?

http://code.google.com/p/hackerskeyboard/downloads/detail?name=KeytestActivity-debug.apk

After launching it, turn off the "Focus" checkbox, then tap the "Keys" button to open the keyboard. If you type Shift + A, you should get a sequence of key events like this, newest on top:

3: onKeyUp, key=SHIFT_LEFT
2: onKeyUp, key=A, meta=SHIFT|SHIFT_LEFT
1: onKeyDown, key=A, meta=SHIFT|SHIFT_LEFT
0: onKeyDown, key=SHIFT_LEFT

If you try it, can you let me know if the sequence looks like this, and the flags and device info (if any) shown for the "onKeyDown, key=A" line?

[Anonymous]

Originally posted by: dnast...@gmail.com

Not to be picky but it would be great if I could copy text from the KeyTest app :)

I have attached a picture of the result. Pls let me know if ok and what else can I do.

[Anonymous]

Originally posted by: john...@gmail.com

I am the original reporter of this bug. I'm using Samsung Galaxy Tab P1000 with the latest stock ROM.
I'll try the keytest later when I will get home, I'm away right now and don't have the device with me.

I have also contacted the author of Better Terminal Emulator Pro, he said he will look into that too.

[Anonymous]

Originally posted by: john...@gmail.com

Ok, I'm back home.
I've tested both previous and current versions of the keyboard, see attached screenshots.
However, something strange happened while I was testing it. I had the older version installed when I started, I made the screenshot, then uninstalled the old version, installed the new version from the market, made the screenshot again and then just to make sure it still doesn't work, tried the terminal and it worked with the new version! I thought it was fixed in the meantime, so I was glad, then I went to the keyboard settings, unchecked auto capitalization and added Slovak QWERTY input language, went back to the terminal and boom, it doesn't work again. I reverted both auto capitalization and removed the input language, but it still didn't work. Then I completely uninstalled the keyboard and installed it again, but no luck... Then I also tried to uninstall it, install the old version, uninstall it and install the new version again, but still it didn't work... I'm not aware of anything else that I did what could cause the keyboard to start working correctly for that brief moment.

[Anonymous]

Originally posted by: john...@gmail.com

Sorry the second image was rotated, here is corrected one...

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Thanks for the updates, this is very mysterious. The key events shown in the key tester look correct and normal.

Note that I've just added a new workaround for Ctrl/Alt handling that wasn't working right in Android Terminal Emulator, see issue 165. It doesn't sound applicable for this issue since the keyboard wasn't sending standalone Shift key events, but it may be a clue towards what's going on.

My guess is that the application isn't correctly applying the meta=SHIFT flag from the incoming key event, and is doing its own translation to text which gets the wrong value as a result. It's possible that earlier versions of the keyboard worked despite this due to sending text strings instead of key events, but both are correct and should be handled by the application.

[Anonymous]

Originally posted by: roland.e...@googlemail.com

Same behavior here with Hackers Keyboard and Better Terminal Emulator Pro. This is a little bit nasty especially when happening while entering password for a SSH connection. Please let me know, if I can help.

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Has anyone affected by the bug heard back from the Better Terminal Emulator Pro author? Since it only appears to affect this one app, I strongly suspect the bug is in that app.

I'm fairly confident my keyboard is doing the right thing - version 1.30rc3 added a Ctrl/Alt compatibility workaround, but Shift handling has not changed since v1.29.

[Anonymous]

Originally posted by: john...@gmail.com

I did contact him, he replied immediately that he will look into it and offered me to test the beta version but when I replied that I will gladly try the beta, I did not get any reply since then... I will try to contact him again.

[Anonymous]

Originally posted by: john...@gmail.com

Ok, he just replied to me, my email to him previously ended up in his spam folder but it's fine now.
He will send me a new beta version with some things changed and bugs fixed and I'll test if it will help.
I am on a vacation right now and will try it as soon as I'll get back home at the end of this week.

[Anonymous]

Originally posted by: changwuf...@gmail.com

Any update on this issue?
I also have the same issue using Better Terminal Emulator Pro.
Login using Hackers Keyboard for password that has uppercase letters seldom work correctly.
I've to switch back using Swype Beta which does not appear to have this issue.
On one occasion using Hackers Keyboard when I activate the Shift Key, on screen there is a "^" char. Maybe this could help.
Great work on Hackers Keyboard :)

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Still waiting for feedback from users who tried the Better Terminal Emulator Pro beta or have other news. AFAIK this still appears to be a bug in that application, I haven't heard of other terminal emulators misbehaving.

Status: NeedInfo

[Anonymous]

Originally posted by: john...@gmail.com

This is what I got from the BTEP developer 2 weeks ago:

----------------------------------------
I found out one interesting data point:

When I start BTEP, uppercase characters in Hacker's Keyboard don't work.
If I switch input methods to another keyboard, then switch back to Hacker's
keyboard, then uppercase characters work!  When I quit BTEP and restart
with Hacker's Keyboard, uppercase characters don't work again...

Still looking into it.
----------------------------------------

I have sent him an email again today if he already found the problem or any other details...

[Anonymous]

Originally posted by: dnast...@gmail.com

Is there a BTEP beta that has the fix ?

I just switched to use the Terminal Emulator ...

[Anonymous]

Originally posted by: john...@gmail.com

There isn't because the author of BTEP still did not found what the problem is...

[Anonymous]

Originally posted by: ShiroiK...@gmail.com

I'm afected running GNU X apps in a chroot, accessing them via Remote VNC on a Samsung Galaxy Tab 7.7. Ran xev to compare the output between a 1.27 (working) and current (afected) versions of the keyboard.

xev output after hitting Shift-A in 1.27:

KeyPress event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916528293, (514,759), root:(515,760),
    state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916528293, (514,759), root:(515,760),
    state 0x1, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes: (41) "A"
    XmbLookupString gives 1 bytes: (41) "A"
    XFilterEvent returns: False

KeyRelease event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916528293, (514,759), root:(515,760),
    state 0x1, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes: (41) "A"
    XFilterEvent returns: False

KeyRelease event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916528293, (514,759), root:(515,760),
    state 0x1, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

This works, and a capital A is sent to the app from the keyboard.

xev output after hitting Shift-A in the currest version of the keyboard:

KeyPress event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916350292, (514,759), root:(515,760),
    state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916350292, (514,759), root:(515,760),
    state 0x1, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916350292, (514,759), root:(515,760),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XmbLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyPress event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916350292, (514,759), root:(515,760),
    state 0x0, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916350292, (514,759), root:(515,760),
    state 0x1, keycode 38 (keysym 0x41, A), same_screen YES,
    XLookupString gives 1 bytes: (41) "A"
    XFilterEvent returns: False

KeyRelease event, serial 27, synthetic NO, window 0x1800001,
    root 0x25, subw 0x0, time 3916350292, (514,759), root:(515,760),
    state 0x1, keycode 10 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

This doesn't work and a non-capital a gets sent. It seems the keyboard releases the Shift prior to sending the a.

Any fix for this?

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Interesting. I still think that the bug is in the application and not in the keyboard, but I don't fully understand what's going on here.

Note the very odd xev sequence - xev receives <shift press> <shift release> <a press> <shift press> <A release> <shift release>.

That's not what the keyboard sends - according to my KeyTest app, RemoteVNC should get the following:

  onKeyDown SHIFT_LEFT
  onKeyDown A, meta=SHIFT|SHIFT_LEFT
  onKeyUp A, meta=SHIFT|SHIFT_LEFT
  onKeyUp SHIFT_LEFT

Have you contacted the Remote VNC developer?

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

Also, have you tried the application with a physical keyboard, if you have one available? I suspect you're likely to see the same error.

[Anonymous]

Originally posted by: ShiroiK...@gmail.com

No there is no such issue with a bluetooth physical keyboard.

In fact I'm sure it's not a VNC pro. As if it was, the old version of your keyboard wouldn't work. Anyhow, to test, I'm gonna install a random VNC app now and connect to the debian session to see, if the same behavior is apparent. I'll report on it shortly.

[Anonymous]

Originally posted by: ShiroiK...@gmail.com

Went and tested it, installed PocketCloud VNC viewer, and sure enough, the xev symptoms are the same, and the capital letter doesn't get sent. It's not the app problem, it's the Shift implementation in your keyboard.

BTW, when turning Caps Lock on, and hitting A, the proper xev output is received and the shifted character is sent. So however, you're implementing Caps Lock, it's reacting properly, but Shift isn't.

In the meantime it's back to v. 1.27 for me, so that I can type properly...

[Anonymous]

Originally posted by: john...@gmail.com

Well, so it looks like it's not the BTEP's problem after all...

[Anonymous]

Originally posted by: Klaus.We...@gmail.com

I'll take another look to see what's going on. Yes, the behavior in the keyboard changed, but as far as I can tell it's still supposed to be correct. I can try to add a hack to add a special case for letters, but I'd prefer to understand what's happening.

ShiroiKuma, would you mind trying xev to see if the event sequence looks correct for shifted non-letter characters such as shift-Backspace?

v1.27 used sendText for letters, where a library method converts the letters to key events. This was device dependent and didn't work consistently. v1.29 changed it to have the keyboard generate the key events itself. Here's the core method:

    private void sendModifiedKeyDownUp(int key, boolean shifted) {
        InputConnection ic = getCurrentInputConnection();
        int meta = getMetaState(shifted);
        sendModifierKeysDown(shifted);
        sendKeyDown(ic, key, meta);
        sendKeyUp(ic, key, meta);
        sendModifierKeysUp(shifted);
    }

The really mystifying part is how this can result in the application getting a shift down event in between the sendKeyDown and sendKeyUp, and why it would treat shift differently from caps lock since they are both handled mostly equivalently. I'm wondering if the OS is reordering events. One difference from the physical keyboard is that it sends the events immediately one after the other, while the physical keyboard will have a significant time delay.

Status: Accepted