Shift not working correctly on some devices/apps

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by Klaus.We...@gmail.com on 24 Jan 2012 at 10:25

[GoogleCodeExporter]

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"

Original comment by Klaus.We...@gmail.com on 24 Jan 2012 at 10:38

[GoogleCodeExporter]

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

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

Original comment by dnast...@gmail.com on 24 Jan 2012 at 11:38

[GoogleCodeExporter]

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

Original comment by dnast...@gmail.com on 24 Jan 2012 at 11:42

[GoogleCodeExporter]

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-d
ebug.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?

Original comment by Klaus.We...@gmail.com on 25 Jan 2012 at 12:42

[GoogleCodeExporter]

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.

Original comment by dnast...@gmail.com on 25 Jan 2012 at 3:14

Attachments:

• IMAG0269-1.jpg

[GoogleCodeExporter]

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. 

Original comment by john...@gmail.com on 25 Jan 2012 at 7:47

[GoogleCodeExporter]

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.

Original comment by john...@gmail.com on 25 Jan 2012 at 9:56

Attachments:

• shot_000001.png

[GoogleCodeExporter]

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

Original comment by john...@gmail.com on 25 Jan 2012 at 9:57

Attachments:

• shot_000002.png

[GoogleCodeExporter]

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.

Original comment by Klaus.We...@gmail.com on 25 Jan 2012 at 10:12

[GoogleCodeExporter]

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.

Original comment by roland.e...@googlemail.com on 5 Feb 2012 at 10:53

[GoogleCodeExporter]

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.

Original comment by Klaus.We...@gmail.com on 5 Feb 2012 at 8:15

[GoogleCodeExporter]

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.

Original comment by john...@gmail.com on 5 Feb 2012 at 8:20

[GoogleCodeExporter]

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.

Original comment by john...@gmail.com on 6 Feb 2012 at 5:27

[GoogleCodeExporter]

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 :)

Original comment by changwuf...@gmail.com on 24 Feb 2012 at 5:32

[GoogleCodeExporter]

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.

Original comment by Klaus.We...@gmail.com on 24 Feb 2012 at 5:56

• Changed state: NeedInfo

[GoogleCodeExporter]

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... 

Original comment by john...@gmail.com on 24 Feb 2012 at 2:16

[GoogleCodeExporter]

Is there a BTEP beta that has the fix ? 

I just switched to use the Terminal Emulator ...

Original comment by dnast...@gmail.com on 26 Feb 2012 at 12:57

[GoogleCodeExporter]

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

Original comment by john...@gmail.com on 26 Feb 2012 at 1:05

[GoogleCodeExporter]

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?

Original comment by ShiroiK...@gmail.com on 6 Mar 2012 at 7:37

[GoogleCodeExporter]

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?

Original comment by Klaus.We...@gmail.com on 6 Mar 2012 at 9:05

[GoogleCodeExporter]

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.

Original comment by Klaus.We...@gmail.com on 6 Mar 2012 at 9:06

[GoogleCodeExporter]

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.

Original comment by ShiroiK...@gmail.com on 6 Mar 2012 at 9:39

[GoogleCodeExporter]

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...

Original comment by ShiroiK...@gmail.com on 6 Mar 2012 at 10:07

[GoogleCodeExporter]

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

Original comment by john...@gmail.com on 6 Mar 2012 at 10:35

[GoogleCodeExporter]

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.

Original comment by Klaus.We...@gmail.com on 7 Mar 2012 at 12:41

• Changed state: Accepted

[GoogleCodeExporter]

I just tried android-vnc-viewer and PocketCloud Pro, for me the shift key works 
as expected for both. I can't reproduce the effect you are seeing.

For everyone affected by this issue, could you please post your device type and 
Android version, to see if there's some common factor causing this?

johny77, you had said "Samsung Galaxy Tab P1000 with the latest stock ROM", do 
you have a version number for that? I'm mainly interested in the core Android 
version such as 2.3 (Gingerbread).

Original comment by Klaus.We...@gmail.com on 7 Mar 2012 at 12:54

[GoogleCodeExporter]

I tested non-letter chararters:

Shift-Enter works properly, i.e. press Shift, press Enter, release Enter, 
release Shift
Shift-Tab
Shift-Backspace only does press Backspace, release Backspace, i.e. no Shift 
pressed or released
shifted numbers work semi-properly, in that the key sequences sent are: press 
Shift, press number, release Shift, release number, however this still 
generates tte proper character.

BTW, how did you test with android-vnc-server, since it's impossible to test 
direct software keyboard input witt it, as it only has an 'enter text' box 
which is an Android text entry box, which then sends the data text, i.e. no 
direct text ennry possibility.

Original comment by ShiroiK...@gmail.com on 7 Mar 2012 at 5:38

[GoogleCodeExporter]

In the above I meant Shift-Tab also works properly.

Original comment by ShiroiK...@gmail.com on 7 Mar 2012 at 5:39

[GoogleCodeExporter]

Thanks for the update. Turns out that the Backspace key actually doesn't 
support shifting in the current implementation since it has a special-case 
handler (inherited from the original Gingerbread keyboard), though that would 
be easy to add. 

Shift-Enter is an interesting case. That's basically the same code path as used 
for letters, so I'm confused why this would act so differently on your device.

        asciiToKeyCode['\n'] = KeyEvent.KEYCODE_ENTER | KF_SHIFTABLE;
[...]
            asciiToKeyCode['A' + i] = KeyEvent.KEYCODE_A + i | KF_UPPER;
[...]
                boolean shiftable = (combinedCode & KF_SHIFTABLE) > 0;
                boolean upper = (combinedCode & KF_UPPER) > 0;
                boolean shifted = modShift && (upper || shiftable);
                sendModifiedKeyDownUp(code, shifted);

It's expected that the key events for shifted numbers refer to the digit keys - 
key events assign an ID to each physical key, and since "1" and "!" are on the 
same physical key they get the same ID. The resulting character depends on the 
shift state.

One more test please - can you try Ctrl-A and Shift-Ctrl-A in xev to see if 
those are handled differently?

After that, please try 1.32rc3 from 
http://code.google.com/p/hackerskeyboard/downloads/list . I've added a 
workaround in revision 243bb4c9a8b6 that attempts to restore the original 
sendText method from v1.27 for letters, though I worry that this may break 
again if I don't have an explanation why this makes a difference.

Original comment by Klaus.We...@gmail.com on 7 Mar 2012 at 7:23

[GoogleCodeExporter]

This is what I see in the "about device" section of settings:
Firmware version 2.3.3
Baseband version P1000XXJPZ
Kernel version 2.6.35.7 se.infra@SEP-52 #2
Build version GINGERBREAD.XXJQ1

Hope it helps.

Original comment by john...@gmail.com on 7 Mar 2012 at 8:48

[GoogleCodeExporter]

So, ran the tests. To summarize:

shift-a: press shift, release shift, press a, press shift, release a, release 
shift
ctrl-shift-a: press shift, press ctrl, release shift, press a, press shift, 
release a, release ctrl, release shift
shift-ctrl-a: same
ctrl-caps-a: press ctrl, press "^A", release "^A", release ctrl
caps-ctrl-a: same

Interesting really, as in the case of Caps, not two keypresses and releases, 
for shift and a, are registered, but literally xev specifies "^A", which is 
capital a with ctrl, though it also specifies the ctrl.

The version 1.32rc3 with the hack works, shift works now in chroot X apps. For 
the explanation, I don't know, but perhaps you could keep it as an option, for 
the future versions, so that the functionality would be preserved for those who 
are faced with the prob.

Original comment by ShiroiK...@gmail.com on 7 Mar 2012 at 10:10

[GoogleCodeExporter]

ShiroiKuma, thank you for testing. This is very mysterious. I'm suspecting this 
may be a Samsung Galaxy Tab specific bug - both you and johny77 are using that, 
right?

For anyone else affected by this bug, can you please let me know which device 
you're using? I'm interested in confirmations if it's also a Galaxy Tab, but 
especially if it's something different.

(I previously had a very annoying bug affecting Samsung Galaxy S2 only due to a 
misguided vendor-specific change: see issue 122.)

Anyway, I'll probably keep the workaround in place for everyone instead of 
making it an option, I think it should work for all devices even if they don't 
need the workaround. But my confidence is shaken since I don't understand 
what's happening.

Original comment by Klaus.We...@gmail.com on 7 Mar 2012 at 7:15

• Changed state: FixInTest

[GoogleCodeExporter]

Yeah, I'm using Samsung Galaxy Tab 7.7.

I have a Motorola Drokd 3 lying around somewhere, so if I find it tomorrow, 
I'll test on it, to see if it's also afected.

Original comment by ShiroiK...@gmail.com on 7 Mar 2012 at 8:24

[GoogleCodeExporter]

I'm using Samsung Galaxy Tab 7 P1000 using custom ROM based on stock 2.3.6

PS: Not using BTEP anymore, using connectbot for now, seems to work ok.

Original comment by changwuf...@gmail.com on 8 Mar 2012 at 3:24

[GoogleCodeExporter]

So, I've just tested on a Motorola Droid 3 and indeed the issue is not present. 
Must be either related to Samsung Galaxy Tabs, or Gingerbread, or Samsung's 
implementation of Gingerbread.

Original comment by ShiroiK...@gmail.com on 8 Mar 2012 at 11:07

[GoogleCodeExporter]

I am also having this issue with Better Terminal Emulator Pro. I, however am 
using an ASUS eeePad tf101.  Currently running a custom rom, based off android 
4.0.3.

Original comment by WiggityW...@gmail.com on 21 Mar 2012 at 1:46

[GoogleCodeExporter]

So what's the resolution on this issue? It's still not working with the latest 
version...

Original comment by john...@gmail.com on 27 Mar 2012 at 9:07

[GoogleCodeExporter]

I've just noticed this issue affects Ctrl as well, realized Ctrl combos don't 
register properly in a GNU chroot, so investigated with xev and this are the 
results:

When having Left Ctrl selected for Ctrl in Hacker's keyboard options, pressing 
Ctrl-C, when I press Ctrl, it sends:

press Ctrl
release Ctrl

Then when you press C, it sends the above again, i.e. doesn't send a Ctrl-C, or 
a clean C, which would be wrong, but semi-logical, seeing as how the Ctrl gets 
released above, but it only resends the press and release of Ctrl. No C gets 
sent.

When selecting "Nothing" for Ctrl in the koyboard's options, pressing Ctrl 
sends nothing, logically, then pressing C sends

press Ctrl
release Ctrl

again, without C. What's wrong?

Incidentally, the shifted characters send order is slightly off too, but they 
work, but pressing e.g. Shift-a sends

press Shift
press a
release Shift
release a

Should be release a then shigt, but mostly cosmetic, as it works.

Original comment by ShiroiK...@gmail.com on 1 Apr 2012 at 9:12

[GoogleCodeExporter]

I've got the same deal, but only with non-letter keys and only at some specific 
times with some apps...

I've set "pop-up mini-keyboard contents" to "add upper" on my HTC Sensation 
running Android 2.3.4. When I enter the stock Messages app and try to write, 
for instance, ":D" at the beginning of a message, if I do so by long pressing 
the ";" key and immediately letting go, the default selection is ";", not ":" 
as it should be. Which is weird, because it works correctly at any point 
besides the beginning of a line, giving me ":" as my only option.

What's even more peculiar is that it performs correctly in search boxes (for 
instance, in Dolphin Browser, the stock Google Maps app, and the stock Facebook 
app), but does not in almost everything else (the aforementioned Messages, 
stock Gmail, and even the browser and Facebook when not in in a Search bar(!))

Original comment by MaestroX...@gmail.com on 4 Apr 2012 at 5:55

[GoogleCodeExporter]

i have the issue with shift not working correctly on htc sensation (original 
2.3 rom, cm7, cm9) and BetterTerminalPro. 

i can make it to work correctly if i open a new window (which is configured to 
start SSH client gui) and press Start Session (Local). it wil work until i tap 
on the terminal window to activate ctrl (not ctrl on wide keyboard) and press 
any key (i.e. "c") after that. that will send ^C i.e. (control + capital C) and 
the original issue will come back. 

also, if i change the input method of BTP from Character-based to Word-based it 
doesn't happen. there are other issues in that mode... ;P

Original comment by flipm...@gmail.com on 18 Apr 2012 at 1:04

[GoogleCodeExporter]

oh yeah... hacker's keyboard ver. 1.31 from playstore

Original comment by flipm...@gmail.com on 18 Apr 2012 at 1:07

[GoogleCodeExporter]

The same bug happens on Vim Touch app, om Xoom tablet.

Original comment by socolow...@gmail.com on 4 May 2012 at 11:57

[GoogleCodeExporter]

fwiw - I have this issue as well, using a Galaxy Note - with stock ICS ROM 
(that was just released the other week).

'Locking' shift on the Hackers Keyboard (i.e. hitting it twice) then the letter 
- works Ok, but hitting Shift just once - then pressing the letter key, doesn't 
work.

I've also tested this with a Motorola Xoom 2 (stock Honeycomb 3.2.2) and that 
has exactly the same issue with BTEP. Everything on both devices is as updated 
as the current Play Store has (as of 15/06/2012).

Are there any updates on this?

Thanks.

Original comment by karl.pie...@googlemail.com on 15 Jun 2012 at 10:09

[GoogleCodeExporter]

For anyone still affected by this issue, have you tried a prerelease version 
from https://code.google.com/p/hackerskeyboard/downloads/list ? This should be 
fixed in v1.32rc3 or later. If you're still seeing problems with current 
prereleases, please let me know, and the specific version you're using.

Original comment by Klaus.We...@gmail.com on 19 Jun 2012 at 12:54

[GoogleCodeExporter]

Great! Problem solved. What exactly was the problem then?

Original comment by john...@gmail.com on 19 Jun 2012 at 5:53

[GoogleCodeExporter]

johny77, see update 29 above for some more info. I had made a code change that 
was supposed to be equivalent according to the docs, but apparently some 
devices had odd implementations of key handling and misbehaved, so I added a 
workaround.

Original comment by Klaus.We...@gmail.com on 19 Jun 2012 at 7:17

[GoogleCodeExporter]

[bulk bug update]

The changes from the 1.32rcX prerelease series are included in version 1.33 as 
published on the Play Store, and this bug should be fixed. If it's still not 
working for you, please reopen or file a new bug. Thanks to everyone who helped 
with finding bugs and testing!

Original comment by Klaus.We...@gmail.com on 3 Jul 2012 at 7:24

• Changed state: Fixed

[GoogleCodeExporter]

Bulk update - changing "Fixed" to "Verified" for old bugs.

(Background: I'm changing the "Fixed" status to be considered open, the next 
steps in the lifecycle will be the closed states "FixInTest" and "Verified". 
This lets me mark issues as "Fixed" in commit messages without hiding them from 
the issue tracker.)

Original comment by Klaus.We...@gmail.com on 22 Jan 2013 at 7:33

[GoogleCodeExporter]

Bulk update - changing "Fixed" to "Verified" for old bugs.

Original comment by Klaus.We...@gmail.com on 22 Jan 2013 at 7:34

• Changed state: Verified