[Q] Keyboard popup on longpress menu key - XPERIA X10 Q&A, Help & Troubleshooting

Hi,
Does anyone know how to map the keyboard popup to a longpress menu?
I know I'd need to edit the /system/usr/keylayout/qwerty.kl but I'd need both the SCANCODE for the long-press on the menu button and the KEYCODE for the keyboard application, but I cant find either anywhere.
This functionality was included in the old 1.6 stock rom and was great for when you need to use a keyboard but had no text field to press to enable the keyboard popup.

---

JasonGee said:
Hi,
Does anyone know how to map the keyboard popup to a longpress menu?
I know I'd need to edit the /system/usr/keylayout/qwerty.kl but I'd need both the SCANCODE for the long-press on the menu button and the KEYCODE for the keyboard application, but I cant find either anywhere.
This functionality was included in the old 1.6 stock rom and was great for when you need to use a keyboard but had no text field to press to enable the keyboard popup.
Click to expand...
Click to collapse
What about checking the qwerty.kl file in an older stock SE Rom? If you have an unzipped version of such ROM around?

---

Good idea, thanks. Downloading a 1.6 ROM now. Will see if I can extract the qwerty.kl and find the right entry.

---

Ok so I got a 1.6ROM, extracted the system.sin, converted to an IMG and then unyaffsed it to get to the file system.
I couldnt see anything in any of the .kl files that looked like it was loading the keyboard, so I looked for some diff entries and entered them in the correspoding .kl file on my phones system. None of these changes seemed to have any effect. So I finally, in a last ditch attempt, copied all the .kl files from the 1.6ROM to my phone which only had the effect of completely disabling all my hardware keys.
I've changed them back now and I think I'll have to give up. I think the .bin files in the keychars folder would need editing too, but I fear that's beyond me.

---

JasonGee said:
I've changed them back now and I think I'll have to give up. I think the .bin files in the keychars folder would need editing too, but I fear that's beyond me.
Click to expand...
Click to collapse
No no, don't give up
I have tried with cm7 v009 files but still it won't work. I took all keychars and keylayout files from that rom. My keys are still working but the longpress function still don't work.
Maybe we need files from newer cm7. I know that this worked in v011 so maybe those files will make it work. The reason that I used 009 was that this was the only version I already had downloaded on my SD.
Sent from my X10i using Tapatalk

---

Maybe some dev can help us out?
Sent from my X10i using Tapatalk

---

That's interesting, so the CM7 RC11 has the keyboard popup?
Yeah a devs help would be good.
I cant find a download of the RC11 so I've downloaded RC12, hope it also has the same functionality, I'll take a look into it now.

---

yeah I just tried overwriting all my keylayout and keychar files with the ones from CM7 RC12 and there is no change.
All my hardware keys still work as usual but no keyboard on menu longpress.
As far as I can see there is no diff between the RC12 files and my files. I'm currently on CM6.1.3 v53

---

So it seems that the key layouts are correct and that it's coded somewhere deeper in the OS.
I got a reply from j and he hasn't done anything special to make it work. Just answered "it's included in 2.3"
But since it's working in 2.1 also I'm sure someone can make it work in 2.2
Sent from my X10i using Tapatalk

---

Source:
http://www.theandroider.com/2009/12/18/back-and-other-hard-keys-three-stories/
It seems that onKeyLongPress is controlled by the framework.
Is it possible to edit the long press behavior in 2.2 framework to enable keyboard toggle?
Story 2: Embracing long press
One of the fairly late addition to the Android platform was the use of long press on hard keys to perform alternative actions. In 1.0 this was long press on HOME for the recent apps switcher and long press on CALL for the voice dialer. In 1.1 we introduced long press on SEARCH for voice search, and 1.5 introduced long press on MENU to force the soft keyboard to be displayed as a backwards compatibility feature for applications that were not yet IME-aware.
(As an aside: long press on MENU was only intended for backwards compatibility, and thus has some perhaps surprising behavior in how strongly the soft keyboard stays up when it is used. This is not intended to be a standard way to access the soft keyboards, and all apps written today should have a more standard and visible way to bring up the IME if they need it.)
Unfortunately the evolution of this feature resulted in a less than optimal implementation: all of the long press detection was implemented in the client-side framework’s default key handling code, using timed messages. This resulted in a lot of duplication of code and some behavior problems; since the actual event dispatching code had no concept of long presses and all timing for them was done on the main thread of the application, the application could be slow enough to not update within the long press timeout.
In Android 2.0 this all changes, with a real KeyEvent API and callback functions for long presses. These greatly simplify long press handling for applications, and allow them to interact correctly with the framework. For example: you can override Activity.onKeyLongPress() to supply your own action for a long press on one of the hard keys, overriding the default action provided by the framework.
Perhaps most significant for developers is a corresponding change in the semantics of the BACK key. Previously the default key handling executed the action for this key when it was pressed, unlike the other hard keys. In 2.0 the BACK key is now execute on key up. However, for existing apps, the framework will continue to execute the action on key down for compatibility reasons. To enable the new behavior in your app you must set android:targetSdkVersion in your manifest to 5 or greater.
Here is an example of code an Activity subclass can use to implement special actions for a long press and short press of the CALL key:
@Override
public boolean onKeyLongPress(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_CALL) {
// a long press of the call key.
// do our work, returning true to consume it. by
// returning true, the framework knows an action has
// been performed on the long press, so will set the
// canceled flag for the following up event.
return true;
}
return super.onKeyLongPress(keyCode, event);
}
@Override
public boolean onKeyUp(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_CALL && event.isTracking()
&& !event.isCanceled()) {
// if the call key is being released, AND we are tracking
// it from an initial key down, AND it is not canceled,
// then handle it.
return true;
}
return super.onKeyUp(keyCode, event);
}
Note that the above code assumes we are implementing different behavior for a key that is normally processed by the framework. If you want to implement long presses for another key, you will also need to override onKeyDown to have the framework track it:
@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_0) {
// this tells the framework to start tracking for
// a long press and eventual key up. it will only
// do so if this is the first down (not a repeat).
event.startTracking();
return true;
}
return super.onKeyDown(keyCode, event);
}
Click to expand...
Click to collapse

---

Bump!
Anyone have a clue on this one?
Sent from my X10i using Tapatalk