maemo.org - Talk - Advanced N900 keyboard remapping

maemo.org - Talk (https://talk.maemo.org/index.php)

- Nokia N900 (https://talk.maemo.org/forumdisplay.php?f=44)

- - Advanced N900 keyboard remapping (https://talk.maemo.org/showthread.php?t=40806)

vinc17

2010-01-15 23:57

Advanced N900 keyboard remapping

I'd like to do the following things. First, I'd like Fn-key to be possibly different from Fn-Shift-key. In the rx-51 file, I've tried to change

Code:

key <AC06> { [ h, H, parenleft, parenleft ] };

into

Code:

key <AC06> { [ h, H, parenleft, bracketleft ] };

but with no effect.

I'd also like Ctrl alone (which is unused) to behave like Sym, i.e. to make the virtual keyboard appear.

Unfortunately, the wiki doesn't cover these cases.

Any idea?

soeiro

2010-01-16 00:11

Re: Advanced N900 keyboard remapping

I've also tried this.

Unfortunately, I've read somewhere else in this forum that the shift key only works to capitalize the character in this setup. I've placed ccedilla and Ccedilla and it worked. However, no brackets. :-(

Does anyone know some way around this? Maybe another group?

vinc17

2010-01-18 02:51

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by soeiro (Post 475355)

Does anyone know some way around this? Maybe another group?

Perhaps. It seems that the behavior corresponds to THREE_LEVEL, as defined in "/usr/share/X11/xkb/types/iso9995":

Code:

partial default xkb_types "default" {



    // Definition for a key type which

    // can be used to implement ISO9995

    // style level three shift

    virtual_modifiers LevelThree;



    type "THREE_LEVEL" {

        modifiers = Shift+LevelThree;

        map[None] = Level1;

        map[Shift] = Level2;

        map[LevelThree] = Level3;

        map[Shift+LevelThree] = Level3;

        level_name[Level1] = "Base";

        level_name[Level2] = "Shift";

        level_name[Level3] = "Level3";

    };

};

I think that FOUR_LEVEL should be used instead, as defined in "/usr/share/X11/xkb/types/extra":

Code:

partial default xkb_types "default" {

    // Definition for a key type used for the czech keymap, for instance.

    // Defines style a with four level shift. It is similar to three_level

    // type used for iso9995 but it lets the shift key behave "normally".



    virtual_modifiers LevelThree;



    type "FOUR_LEVEL" {

        modifiers = Shift+LevelThree;

        map[None] = Level1;

        map[Shift] = Level2;

        map[LevelThree] = Level3;

        map[Shift+LevelThree] = Level4;

        level_name[Level1] = "Base";

        level_name[Level2] = "Shift";

        level_name[Level3] = "Alt Base";

        level_name[Level4] = "Shift Alt";

    };

[...]

delaroca

2010-01-31 20:06

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by vinc17 (Post 479076)

I think that FOUR_LEVEL should be used instead, as defined in "/usr/share/X11/xkb/types/extra":

Yes, but it doesn't seem to work in general... for example,

Code:

partial alphanumeric_keys

xkb_symbols "us" {

    include "nokia_vndr/rx-51(english_base)"

    include "nokia_vndr/rx-51(arrows_4btns)"



    name[Group1] = "U.S. English";

    key.type[Group1] = "FOUR_LEVEL";

   

    // 1. row



    // 2. row

    key <AC06>        { [h,        H, parenleft, bracketleft ] };

    key <AC07>        { [j,        J, parenright, bracketright ] };



    // 3. row

};

which upon pressing Fn + Shift ought to yield bracket chars... but it doesn't work. The variants FOUR_LEVEL_ALPHABETIC and FOUR_LEVEL_SEMIALPHABETIC don't make a difference.

Only case that you get a FOUR_LEVEL "effect" is when the character slotted at the 3rd level can be shifted, in which case the uppercase char is output.

Any suggestions as to what is going on?

--denis

Edit 2/4/10: Turns out that the hildon-input-method framework has bugs. Matan pointed that out and provided a patched version of that module to correct the problem.

vinc17

2010-02-05 02:29

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by delaroca (Post 504161)

Edit 2/4/10: Turns out that the hildon-input-method framework has bugs. Matan pointed that out and provided a patched version of that module to correct the problem.

Thanks, it is now clear why I couldn't make it work.

There would be an alternative to get much more characters: using some fixed dead keys. For instance, I've remapped the 4 Fn-arrow keys as suggested on the wiki (Remapping keyboard): acute accent, grave accent, circumflex accent and diaeresis. Thus Fn-Left + e give "é". But there are many combinations I don't use, such as Fn-Left + q. The definitions of these combinations seem to be defined in "/usr/share/X11/locale/en_US.UTF-8/Compose". I haven't tried yet, but modifying this file could give interesting things.

delaroca

2010-02-06 03:33

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by vinc17 (Post 511286)

Thus Fn-Left + e give "é". But there are many combinations I don't use, such as Fn-Left + q. The definitions of these combinations seem to be defined in "/usr/share/X11/locale/en_US.UTF-8/Compose". I haven't tried yet, but modifying this file could give interesting things.

The "Compose" key is defined in the rx-51 kbd configuration as "Fn + Ctrl". But that presently triggers the supplementary virtual keyboard... I don't see how the wonderful array of key combinations spelled in the above file actually work. Am I missing something?

--denis

Venemo

2010-03-23 22:24

Re: Advanced N900 keyboard remapping

I have a similar issue, and I couldn't find a more suitable thread for it.

I'm experimenting with a proper modification of Fn keyboard shortcuts to enable the special characters of my native language to be input on the HW keyboard.
Here is the idea.
(Rough Paint work, and not a photo of my device. :) )

It works, but there is one issue.
Fn+Enter is remapped to 'Ú'. If I press Fn and Enter simultaneously, it creates an 'Ú' character, but if I press Fn and then Enter, or I lock the Fn key and then Enter, this doesn't work.

If anyone can recommend a solution for this issue, I'll be very grateful. :)

accord

2010-04-05 01:52

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by delaroca (Post 504161)

Edit 2/4/10: Turns out that the hildon-input-method framework has bugs. Matan pointed that out and provided a patched version of that module to correct the problem.

Does it mean the patch will be in PR1.2?
Can I access this patch?

delaroca

2010-04-05 07:39

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by accord (Post 595756)

Does it mean the patch will be in PR1.2?
Can I access this patch?

The source patch and install DEB are the work of Matan Ziv-Av. See the relevant discussion over on the Maemo-Developers discussion list.

Don't know if the patch will make it to PR 1.2.

--denis

Matan

2010-04-05 09:37

Re: Advanced N900 keyboard remapping

The code handling shift and fn was changed in h-i-m-f-2.1.56 which is in SDK1.2, so presumably is also in PR1.2 itself. I cannot tell for sure, but it seems to me that it works a little better then previously, but still not as expected. If someone knows how to test this in the SDK, I'll be happy for advice.

The new code appears to handle sticky shift, locked shift and pressed shift as three different shifts, and only sticky shift gives the option of four characters per key.

fpp	2010-04-05 12:22

Re: Advanced N900 keyboard remapping

Hi Matan,

I wanted to give this a try, but the file linked by Denis just above (hildon-input-method-framework_2.1.41-1+0m5_armel.deb) is not there. Is that a mistake in the link, or have you taken it down for some reason?...
TIA,

Edit: nevermind, found it in the "fnlockled" subdirectory :-)

fp

Matan

2010-04-05 12:40

Re: Advanced N900 keyboard remapping

The patch is still there, but I don't know where did the package go. I uploaded a new one, but it is untested.

fpp	2010-04-05 16:42

Re: Advanced N900 keyboard remapping

As I mentioned in the edit to my previous message, I found it in the "fnlockled" subfolder. Maybe it got moved there unintentionally ?

Anyway it works just fine, and I wanted to thank you for this extremely useful patch!
And also Denis for bringing this to TMO, as I'd managed to miss the discussion on the mailing-list...

Here is my experience so far, optimizing a US keyboard layout for a mixed French+English usage:

Accessing the 4th level without locking Fn or shift is a hit-and-miss affair (because of my clumsy fingers), but mostly works.

One very nice feature (?) is that placing an accented character there gives access to both lowercase and uppercase forms.

For example I placed "agrave" in fourth position for the "a" key.

If I press and hold Fn first, then shift, I get "à". If I press and hold shift first, then Fn, I get "À". This is really great.

The only problem I see with this method is that sometimes Fn+shift+key will output TWO characters: the one for the key, plus the one for the next key to the right...

For example I have placed the "pipe" (bar) on Fn-z, and relegated the sterling sign to Fn+shift+z. Pressing that does print the sterling sign, but also the dollar which is Fn+shift+x (the next key).

By "sometimes" I mean some keys behave like that all the time (like Z), but some others for which I have redefined the 4th level never do... haven't detected any pattern to it.

Anyway, first locking Fn or shift solves the problem, as this does not seem to cause the double-character output. The one you lock determines capitalization for normal letters, same as above.

It's really good to have everything you need for both languages (and code) on such a small keyboard, without having to resort to the on-screen charmap at last !

So thanks again to all... Matan, is there anything changed in that new package you uploaded ?...

Matan

2010-04-05 16:56

Re: Advanced N900 keyboard remapping

Multiple keys - it's a hardware issue with x,z,j,k.

The version in fnlocked/ subdirectory also lights a led for fn sticky and fn locked states. But this requires replacing the led driver module (also in the same directory). If you don't replace the driver, all it does is try (and fail) to open and write to a non existent file whenever you press fn. You can see the patch himf3.diff in that directory for the details.

fpp	2010-04-06 09:31

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by Matan (Post 596482)

Multiple keys - it's a hardware issue with x,z,j,k.

Ah, good to know. I didn't change "x" but I did remap h/j/k/l (for brackets and braces), and was puzzled by the behaviour.

Quote:

The version in fnlocked/ subdirectory also lights a led for fn sticky and fn locked states. But this requires replacing the led driver module (also in the same directory). If you don't replace the driver, all it does is try (and fail) to open and write to a non existent file whenever you press fn. You can see the patch himf3.diff in that directory for the details.

That sounds useful (and fun :-). So the version in the N900 directory is the same, without the LED hack ?...

fpp	2010-04-06 11:56

Re: Advanced N900 keyboard remapping

Sorry for the probably very basic question, but what would be the correct way to replace the existing leds-lp5523.ko module with a new one ?

Matan

2010-04-06 12:06

Re: Advanced N900 keyboard remapping

You can replace it temporarily by

Code:

rmmod leds_lp5523

insmod /path/to/leds_lp5523.ko

chown user /sys/class/leds/lp5523\:a/brightness

This will not survive reboot. You can use the modified module to overwrite the original module file in /lib/modules/current/ in which case the module will be inserted automatically, but you will still need the chown command after every boot (for the fn lock led to work).

fpp	2010-04-06 13:33

Re: Advanced N900 keyboard remapping

Thanks for the detailed instructions Matan. I tried the manual method (all three lines) and got no error messages. Fn locking does not light the Led however... no pretty light shows for me :-)

edit: correction, it does have an effect, maybe not the intended one... when I lock the device the Led does glow red instead of blue. But not when I lock Fn :-)

Matan

2010-04-06 13:49

Re: Advanced N900 keyboard remapping

Checklist:

Did you reboot after installing hildon-input-... with led support? It is necessary (IOW: I don't know what programs need to be restarted).

Is it really installed? What is the output from grep leds /usr/lib/gtk-2.0/2.10.0/immodules/hildon-im-module.so

Did insmod and chown run correcrtly? What is the output from ls -l /sys/class/leds/lp5523:a/brightness

It works only in gtk input fields (xterm, browser text fields, etc.) Not on the desktop.

fpp	2010-04-06 15:02

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by Matan (Post 597685)

Checklist:
Did you reboot after installing hildon-input-... with led support? It is necessary (IOW: I don't know what programs need to be restarted).
Is it really installed? What is the output from grep leds /usr/lib/gtk-2.0/2.10.0/immodules/hildon-im-module.so
Did insmod and chown run correcrtly? What is the output from ls -l /sys/class/leds/lp5523:a/brightness
It works only in gtk input fields (xterm, browser text fields, etc.) Not on the desktop.

Thanks, again. Three out of four:
- yes I rebooted after installing the hildon-input deb (else it didn't work :-)
- yes insmod worked, I had the brightness file with the correct permissions (and the Led did glow red after all :-)
- yes I tried Fn-locking in xterm

However, the 'grep leds' returns nothing, so I probably don't have the right him package installed... although I did take it from the fnlockled directory!

I don't want to pester you any further on this Led issue which I was trying out of pure curiosity... My four-level layout itself work just fine, which is the important thing, for which I am forever grateful to you :-)

Matan

2010-04-06 15:10

Re: Advanced N900 keyboard remapping

I had led-less package there. Now I hope everything is in order. The package with the led is in fnlockled/ and the package without led is in n900/.

fpp	2010-04-06 15:51

Re: Advanced N900 keyboard remapping

Aha, mystery solved! I'm happy it wasn't me goofing around just for once :-)
Will re-download and re-install just for the sake of it...

lasergun

2010-06-01 09:00

Re: Advanced N900 keyboard remapping

Hi all,
People in this thread seem to know a lot about the maemo keyboard and hildon-input-method packages.

I am trying to make an auto replace/correct addition, for IM.
For instance:
" xD " = "I love you"
" bb " = "Bye Bye"
" myaddress " = "62 Hell's st., Heaven"
" mysig " = "Firstname Lastname"
etc.

I noticed that the hildon-input-method, has a source file named hildon-im-ui.
I am not familiar with the hildon framework so much, and it would be a great time saver if you could recommend to which function should I monitor the pressed keys in order to do so.

In addition, can I compile only the hildon-input-method package, and install it and it will override the current binary?

Thanks in advance,

NBD

manjiri

2010-06-01 10:10

Re: Advanced N900 keyboard remapping

Any idea how one can go about building a virtual keyboard that uses harmattan UI framework?
Also what event do I need to listen to in order to replace the current virtual keyboard with on of my own?

lasergun

2010-06-01 11:45

Re: Advanced N900 keyboard remapping

manjiri,
I don't know about harmatan,
but i think you should create your own virtual keyboard and load it to the "finger" configuration.
You can check the link below for references:

This is a link for a project of replacing the virtual keyboard with a handwriting recognition software. The source can be found there as well:
https://garage.maemo.org/frs/shownot...elease_id=3531

Hope it helped.

NBD

manjiri

2010-06-02 09:07

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by lasergun (Post 693551)

Thanks a bunch lasergun. I'll chk it out.

vinc17

2010-06-02 09:10

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by delaroca (Post 512709)

I was mentioning dead keys (e.g. dead acute accent), not the Compose key. One can already bind dead keys, to Fn-arrow (left, right, up, down) for instance. So, currently, I can type Fn-Left + e to get é. The question was: where is the "dead-accute + e" to é mapping defined (in order to be able to define mappings for other combinations)? I think this is under the same file as for the Compose key, but I'm not sure, and I haven't tried yet.

lasergun

2010-06-02 09:14

Re: Advanced N900 keyboard remapping

Hi all,

I just wanted to mention that I opened a new project for the Autotext thingy I previously mentioned.

I will be happy if any could help.

Project page:
https://garage.maemo.org/projects/autotext

For now I only uploaded the hildon-input-method sources for them to be altered.

Thanks,

NBD

BruceL

2010-07-01 02:06

Re: Advanced N900 keyboard remapping

I've been mapping my keys as these forums and the wiki suggest, but I find that I cannot make Tab or Delete work. Tab sometimes works (e.g., in vi) but it won't do tab-completion in x-term. Delete just prints strange characters.

Can anyone give me advice/help on this? I use tab completion and del quite a bit.

Bruce

vinc17

2010-07-01 10:52

Re: Advanced N900 keyboard remapping

Quote:

Originally Posted by BruceL (Post 736504)

I've been mapping my keys as these forums and the wiki suggest, but I find that I cannot make Tab or Delete work.

Some keys cannot be remapped as expected. Probably a bug. I don't know about Tab and Delete, though.

Quote:

Originally Posted by BruceL (Post 736504)

Tab sometimes works (e.g., in vi) but it won't do tab-completion in x-term. Delete just prints strange characters

You can type

Code:

cat > /dev/null

in the terminal, and see what character sequences you get when you type Tab or Delete. Note: you may need to type Ctrl-V before the key, otherwise some keys (typically Delete, unless it no longer works) will be interpreted in a special way.

Some keys may also generate a different sequence under applications that use the application mode (such as vi?). For that, you need to test under the tack utility (select n f k in the menus). But unfortunately, tack isn't available on the N900.

All times are GMT. The time now is 00:36.

vBulletin® Version 3.8.8