Active Topics

 


Reply
Thread Tools
Posts: 227 | Thanked: 53 times | Joined on Feb 2008 @ Lyon, France
#1
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?
 
Posts: 292 | Thanked: 131 times | Joined on Dec 2009
#2
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?
 
Posts: 227 | Thanked: 53 times | Joined on Feb 2008 @ Lyon, France
#3
Originally Posted by soeiro View Post
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";
    };
[...]
 
Posts: 289 | Thanked: 83 times | Joined on Jul 2006
#4
Originally Posted by vinc17 View Post
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.

Last edited by delaroca; 2010-02-04 at 11:49.
 
Posts: 227 | Thanked: 53 times | Joined on Feb 2008 @ Lyon, France
#5
Originally Posted by delaroca View Post
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.
 
Posts: 289 | Thanked: 83 times | Joined on Jul 2006
#6
Originally Posted by vinc17 View Post
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's Avatar
Posts: 1,296 | Thanked: 1,773 times | Joined on Aug 2009 @ Budapest, Hungary
#7
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.

Last edited by Venemo; 2010-03-23 at 22:26.
 
Posts: 5 | Thanked: 0 times | Joined on Apr 2010
#8
Originally Posted by delaroca View Post
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?
 
Posts: 289 | Thanked: 83 times | Joined on Jul 2006
#9
Originally Posted by accord View Post
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
 

The Following User Says Thank You to delaroca For This Useful Post:
Posts: 1,224 | Thanked: 1,763 times | Joined on Jul 2007
#10
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.
__________________
My repository

"N900 community support for the MeeGo-Harmattan" Is the new "Mer is Fremantle for N810".

No more Nokia devices for me.
 

The Following User Says Thank You to Matan For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 09:16.