It's the keyboard layout.

[Neelix]

The point is to optimise the dynamic area for specific languages.   That might mean putting certain letters at different places to where you would put them in the default combined layout.  If you have them printed somewhere other than where they are mapped that creates confusion.

But an AltGr layer gives you the biggest possible "dynamic area", since every single key is available: all letters, all numbers, all punctuation symbols, etc. Take the example of Polish:

There is no way, even if you arrange the missing US-QWERTY keys on Meta and Shift+Meta in the most compact way, to accommodate something like the above just by assigning new Meta actions to unlabeled Meta keys.

My proposed layout has 17 unlabelled Meta keys, and still has all your dead-keys in place.   I only count  9 specific Alt-Gr symbols in that polish layout, so creating an optimised layout including them all should be no problem.   My suggestion is not to try to replicate the Alt-Gr layouts of the specific regions, as obviously the placement of the static portion of the  meta layer would block that, rather it is to allow people in different regions to have a layout that is tailored to that region. 

Also, I don't see much reason to put letters that are already labeled at different places than where they already are in the combined layout. Would ÜÖÄ at Meta+UOA or at Meta+OKL (or where would you put them if you were a German?) really be much better than at Meta+FCV, where they happen to be now in my proposal? I don't think so. I think the main thing you want to do is add new letters (currently unlabeled). And for that, the AltGr layer is a better option than adding stuff into the Meta layer.

You've said it yourself, different languages have different letter frequencies for the same letters, so they have different priorities for the letters they have in common. In some regions Meta+A might be the optimal position for Ä, in other regions it would make more sense to have À there.

Keep in mind that we can have both Meta and AltGr at a shoulder button. Together with Shift that means you can have up to eight symbols per key if you want, all efficiently chordable using just one thumb press. I propose to make a good default for the first four layers (primary, Shifted, Meta and Shift+Meta), where only two or three layers are printed per key: I would say three for the number row (primary numbers, shifted symbols, Meta F-keys) and two for the letter keys (primary (uppercase/lowercase is implicit) and Meta), to keep it visually clean. For the next four layers (AltGr, Shift+AltGr, Meta+AltGr and Shift+Meta+AltGr), US-International would be a good default, but it does not need to be labeled, and I would disable the AltGr behavior of R_Alt by default (since it makes Alt+letter menu shortcuts impossible), using R_Ctrl + R_Alt instead as the default AltGr mechanism.

You can, and perhaps some users would want to take advantage of that. I wouldn't recommend it for the default layouts though. The idea here is to have some predefined regional layouts and to allow the user to select a regional layout on first boot, (later switchable though the configbutton applet) optimised for their region.

- Neelix

 

[comradekingu]

Muschle memory isnt a detriment, its how people know how to type. Without it, they dont. Zero languages other than english work out of the box. I dont understand the point of re-learning because some amount of learning is required.

There isnt even a AltGr key, how do you explain that? Why not use the explaining on something that makes sense for a lot of people?

People are fast right away when its their layout, if part of the layout is missing, they will never be fast. Thats the part that there isn't any way to get around.

If i was german, i would put ÜÖÄ on ÜÖÄ. Do you honestly believe anyone will put up with pressing shift+AltGr+letter instead of just letter placed where letter is supposed to be? Thats absurd.

The fact that not everyone uses QWERTY only makes it a really bad idea to hardcode QWERTY by adding other symbols to the keys so they cant be switched around.

 

[_wb_]

There isnt even a AltGr key, how do you explain that? Why not use the explaining on something that makes sense for a lot of people?

People are fast right away when its their layout, if part of the layout is missing, they will never be fast. Thats the part that there isn't any way to get around.

If i was german, i would put ÜÖÄ on ÜÖÄ. Do you honestly believe anyone will put up with pressing shift+AltGr+letter instead of just letter placed where letter is supposed to be? Thats absurd.

The fact that not everyone uses QWERTY only makes it a really bad idea to hardcode QWERTY by adding other symbols to the keys so they cant be switched around.

AltGr does not have to be labeled: just like Compose it is a user-configurable key that can be put anywhere you want. The usual default position for AltGr is RightAlt or Ctrl+Alt.

"Putting ÜÖÄ on ÜÖÄ" is not really an option, if you mean dedicated primary keys by that:

A "wider keyboard" (with room for ÜÖÄß as dedicated keys at or near their expected position) has one big problem: there are only three keys left for comma, period, shift, Meta/Fn/AltGr, Enter and Tab. In other words, you have to eliminate three out of those six keys (i.e. make them non-dedicated keys or move them away from the main keyboard section). To me, that is an unacceptable trade-off.

Meta+FCV is what I proposed for üöä. That is one shoulder button and one thumb press. Yes, that is worse than just one thumb press, but that is an inevitable consequence of having less keys than usual: Germans will also have to learn to live with non-primary keys for + - #  ß < acute and circumflex, for example.

But labeled üöäß Meta-keys, available in one shoulder and one thumb press, while not as good as a full-size German keyboard, is still much better than what the Pandora layout offered Germans: [ Shift+Enter ] [ Fn ] [ S ] [ U ] just to get ü, that is one shoulder and FOUR thumb presses.

And arguably, labeled üöäß Meta-keys are better even than a layout like the one you propose, where Germans are supposed to map their letters to [ ] < Shift, then recursively remap [ { ] } < > elsewhere, live without keyboard shift, and get used to a wobbly space key that may or may not accidentally produce dots instead of spaces and spaces instead of dots. And they cannot rely on any "visual muscle memory" because Z and Y are still wrong, the number row is misaligned, Tab, Enter and Space are not where they should be, ß is not where it should be, and all of the punctuation symbols are in completely different places than on a normal German keyboard. So they have to remember a lot of things, and looking at the keymat is not going to be of much help because it is not accurate.

 

[_wb_]

The point is to optimise the dynamic area for specific languages.   That might mean putting certain letters at different places to where you would put them in the default combined layout.  If you have them printed somewhere other than where they are mapped that creates confusion.

But an AltGr layer gives you the biggest possible "dynamic area", since every single key is available: all letters, all numbers, all punctuation symbols, etc. Take the example of Polish:

There is no way, even if you arrange the missing US-QWERTY keys on Meta and Shift+Meta in the most compact way, to accommodate something like the above just by assigning new Meta actions to unlabeled Meta keys.

My proposed layout has 17 unlabelled Meta keys, and still has all your dead-keys in place.   I only count  9 specific Alt-Gr symbols in that polish layout, so creating an optimised layout including them all should be no problem.   My suggestion is not to try to replicate the Alt-Gr layouts of the specific regions, as obviously the placement of the static portion of the  meta layer would block that, rather it is to allow people in different regions to have a layout that is tailored to that region.

Yes, but having the AltGr keys at their expected position (Ę at E, Ł at L, Ą at A, Ó at O etc) is what makes the Polish layout work. Mapping them to Meta+something else is in theory just as efficient, but it would be much harder to learn, especially if there are no labels on the keys themselves, just an on-screen cheat sheet.

Note that things are different for German and French: they have their extra letters as dedicated keys, separate from the letter keys. We have no room for that (though comradekingu disagrees with me on that), so they have to map their extra letters elsewhere anyway. I don't think it matters very much where we put them, it will be something the Germans and the French will have to get used to anyway.

If we would go with your proposal (only ASCII and dead diacritics labeled, no precomposed letters for German and French), then I think that a lot of French/German people would prefer to simply use the default, labeled layout (using dead diacritics, even though it's less efficient), instead of selecting a language-specific layout where they have to remember the locations of the keys (or look at on-screen cheat sheets).

For me personally, that would be fine (I rarely use French and I don't really use German at all), but I think that a lot of French/German people would only consider the device to really support their language if their (important) letters are actually labeled on the keys themselves.

 

[comradekingu]

You are making it less keys, its a consequence of choice, not of limitations. Within limits you can do it, but then you will have to have altGr on columnkeys.
 
With needing altGr and there not being one, my best guess would be the one keyboard alt, that isnt any better.
 
A lot of things are better than the pandora keyboard, in terms of saleability, i dont think another arbitrary way to type is a good idea.
 
I can pay whatever it costs for germans to get their keymat. Will you believe me then? Because for me, and everyone else that wants efficiency, reduced layout isn't an option.
 
Here is how it works, you type a language using the letters, notice how many letters there are in this post. Secondly the punctuation-sequences matter, with that out of the way, its smooth sailing.
 
Its easy enough to cut things out of the keymat and add them in other places. For things other than AZERTY-german, if thats the only additional keymat, this is a viable option.
 
ß is used a lot less than üöä in german. And the key used to do it, is the one two places to the right of 0, its not there. It is also not strictly mandatory. Thus a keymat made to omit it, wont look out of place.
 

Who are these people who dont know how to use a typerwriter/keyboard? They arent any of our users. Even my mum can use a british keyboard and type norwegian on it.

The space-bar idea for a non-centralized non-stabilized key is a misnomer. It is wobbly in any event, just like pressing tab on the pandora is. You dont need to make it dual action, but its preferable, etc etc. Lets hope it doesnt come to that.
 
Muscle memory isn't visual. Typing isn't visual. You can learn it visually, and that lowers the threshold of entry, but that's as far as it goes. In no known universe is a keyboard with A-Z only better for anyone who doesn't use A-Z only. That is at best an anti-typing argument made for novices, the kind of users I don't think an A-Z only layout appeals to, because given only the one option, it would have to have all sorts of cruft on it. The type of stuff that is supposed to be on the right.
 
The layout i propose
Has A-Z+3 extras  +4 if you can do without keyboardshift
All 15 US dead diacritics, and a one-press compose key
A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default
Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.
Fn available for everything besides F-keys and FN+power
 
What more is there to implement? Where can it be better?

 

[Saber]

This thread is like the movie Groundhog's Day. These "fresh" ideas and the ensuing comments to them are the stale regurgitated ones from days previous. Pat on the shoulder and a hear hear from the audience when the alarm clock goes off, again.  

 

[Eight Bit]

/me shamelessly plugs his own keyboards again and grabs popcorn

 

[Grench]

The layout i propose

Has A-Z+3 extras  +4 if you can do without keyboardshift

All 15 US dead diacritics, and a one-press compose key

A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default

Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.

Fn available for everything besides F-keys and FN+power

What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.

CK's layout is dead on arrival. It has 4 Alt keys. Only two can be mapped, Left Alt and Right Alt. Right Alt and AltGr are the same thing.

It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.

Four Alt keys or three shift keys are not minor things to get past. They are fundamental flaws.

 

[Neelix]

If we would go with your proposal (only ASCII and dead diacritics labeled, no precomposed letters for German and French), then I think that a lot of French/German people would prefer to simply use the default, labeled layout (using dead diacritics, even though it's less efficient), instead of selecting a language-specific layout where they have to remember the locations of the keys (or look at on-screen cheat sheets).

For me personally, that would be fine (I rarely use French and I don't really use German at all), but I think that a lot of French/German people would only consider the device to really support their language if their (important) letters are actually labeled on the keys themselves.

Well I can only speak for myself, but I use a keyboard with no international symbols printed on it at all. I use the US International layout which has É but no È. The latter I need to use dead-grave to compose. For the former, while I could compose it manually, I always use the unlabelled É that I know is on AltGr-E. Similarly, If I want ç I know I can find it on AltGr-,. I don't even type that much in French, but I learned those locations after only a couple of uses. My point is that the fact that these pre-composed letters are not printed on the keyboard doesn't make them any less useful.

I'm not saying don't have a default French/German letter layout on the dynamically assigned keys, just that those letters don't necessarily have to be printed on the keymat to be useful, and that not printing them gives us greater flexibility to cater to a wider audience.

- Neelix

 

[_wb_]

I guess there is something to be said for that, Neelix.

Something like this then?

http://www.keyboard-layout-editor.com/#/layouts/f602dae8275387d97e65ccc2a735639f

It has room for a German/Scandinavian triangle cluster at FCV, for ÜÖÄ (with ß at S which makes sense) or ÅÖÄ or ÅØÆ or ÅÆØ.

Iberians could have ç and ñ at their natural places. And so on.

I could certainly live with that.

 

[WizardStan]

CK's layout is dead on arrival. It has 4 Alt keys.

Remember, CK is defying wisdom and calling fnmetamodsym "AltGr". That is a problem but it's not why his keyboard fails.His keyboard fails immediately because he is treating the space bar as two distinct keys when ED has made it quite clear that it is going to be one wide key. Take that extra key away and he'll have a hard time maintaining his "clutter free" stance.

 

[Neelix]

I guess there is something to be said for that, Neelix.

Something like this then?

http://www.keyboard-layout-editor.com/#/layouts/f602dae8275387d97e65ccc2a735639f

It has room for a German/Scandinavian triangle cluster at FCV, for ÜÖÄ (with ß at S which makes sense) or ÅÖÄ or ÅØÆ or ÅÆØ.

Iberians could have ç and ñ at their natural places. And so on.

I could certainly live with that.

I could live with that too. (though my preference is still for making use of meta+shift to for the punctuation symbol pairs)

- Neelix

 

[_wb_]

I can live with Shift+Meta pairs, but I have some minor objections against it:

• 3 labels on some letters and 1 label on most other letters feels a bit "unbalanced", as in: why put all the symbols cramped together when there is plenty of room to spread them more evenly?
• two modifiers for some symbols, even if the modifiers can be mashed on the keyboard and easily chorded on the shoulders, is somewhat harder to do than just one modifier per symbol
• I would like the Pyra keyboard to be strictly better than the Pandora one in all respects, including the ease of typing symbols like _+:"?
• If we can cover ASCII with only three layers (primary, Shift, Meta) then the basic layout is conceptually somewhat simpler than if we need four layers
• for dead diacritics it is nice if Shift " ' - / are available for dead umlaut, acute, macron, stroke respectively

 

[Saber]

The layout i propose


Has A-Z+3 extras  +4 if you can do without keyboardshift


All 15 US dead diacritics, and a one-press compose key


A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default


Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.


Fn available for everything besides F-keys and FN+power


What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.


...


It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.


...

As I asked _wb_ here, prove it(with your Pandora) that we can't have two keyboard Shift keys, Left and Right, and another Right Shift on L1. Observe and report any conflicts with remaps and when pressing the two Right Shifts simultaneously. I would do this myself, but I no longer have a Pandora handy. Let's see if you can do more than sing it. 

 

[Grench]

The layout i propose

Has A-Z+3 extras  +4 if you can do without keyboardshift

All 15 US dead diacritics, and a one-press compose key

A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default

Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.

Fn available for everything besides F-keys and FN+power

What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.

...

It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.

...

As I asked _wb_ here, prove it(with your Pandora) that we can't have two keyboard Shift keys, Left and Right, and another Right Shift on L1. Observe and report any conflicts with remaps and when pressing the two Right Shifts simultaneously. I would do this myself, but I no longer have a Pandora handy. Let's see if you can do more than sing it. 

Not interested in applying the effort to testing someone else's bad idea. This falls into the category of, "Even if something is possible, that does not make it a good idea." Three shifts is bound to be confusing AND is a colossal waste of a key.

 

[WizardStan]

I don't know why you need a Pandora to prove it, the problem is pretty evident

1) Press right shift: a "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"

2) Press other right shift: another "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"

3) Release one of the shifts: a "R_SHIFT Up" event is sent. Game says "ahah, right shift is no longer being pressed"

The game is now no longer aware that one of the shifts is being pressed, whatever that shift may be supposed to do.

We can get into other possible problems, like if it assumes a specific state, and pressing and releasing the button changes the state, you could end up changing it twice. It's a recipe for confusion.

That being said, my keyboard layout had three shift keys as well. I acknowledged the problem and said that it wasn't the end of the world: the odds of it happening are already very small, and when it does happen it should be easily solved by simply letting go of the offending key and pressing it again so it's not like a deadly bug, worst case is you accidentally drop your shields for a moment or whatever that shift button is doing.

Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

 

[Neelix]

Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

I also have to agree with Grench that it's a waste of a good key, where we really don't have any to spare, so I reckon it would need to balance against that and the potential risk.

- Neelix

 

[Rockthesmurf]

I think Neelix has a good point about having default layouts without so much printed on the keys, I think having a simple as possible print makes it easier to find the basics. I also agree with the other chap about an attempt to support everything probably means for any specific language, the layout is almost certainly not ideal (meaning people will remap anyway). Therefore perhaps it is better to have a minimal amount printed on the keys and provide default layouts per language (for which I assume wb will be more learned than most about the best layout per country based on statistics) and just let the user switch between layouts.


At the end of the day, most people here live with the Pandora keyboard layout, so despite polls and boycotting, keeping the same amount of international printed keys would be fine and would certainly keep the device more in line with what I suspect most new users would expect from the device.

 

[_jr_]

Nobody has yet demonstrated that having lots of printed symbols does actually help any usecase, while it is obviously detrimental to the beginner (has to hunt even for standard US-QWERTY symbols in a jungle of unfamiliar symbols even with the best possible placement) and not very helpful to the heavy typist (doesn't look much at the keyboard). It isn't at all clear that there is any benefit to be gained compared to just using compose or a customized layout. Therefore just making the best possible US-QWERTY we can (e.g. like some of the proposals already on the table) with only few (or even none) international symbols is the best way to go. It can serve as a base for customized layouts that can be added to the OS at a later point.


The other alternative is a P+n, L+m layout that can easily support German and some Scandinavian languages. According to the poll that could be an acceptable compromise, since the romance languages are seemingly not that important.


And (since it cannot be repeated often enough): double width space is making this business just that little bit more difficult than it should be.

 

[comradekingu]

CK's layout is dead on arrival. It has 4 Alt keys.

Remember, CK is defying wisdom and calling fnmetamodsym "AltGr". That is a problem but it's not why his keyboard fails.
His keyboard fails immediately because he is treating the space bar as two distinct keys when ED has made it quite clear that it is going to be one wide key. Take that extra key away and he'll have a hard time maintaining his "clutter free" stance.

Im calling the button that does F-keys on 60% keyboards (the ones that dont have dedicated F-keys) Fn, since that is most common. It exists in the wild, and it works.


I call AltGr the button that xkbmap calls AltGr. I agree that dualwide space adds problems elsewhere, but what do you want me to do about it, its bad because it is. But it is possible to make it almost up to par, which i have done.

The layout i propose


Has A-Z+3 extras  +4 if you can do without keyboardshift


All 15 US dead diacritics, and a one-press compose key


A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default


Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.


Fn available for everything besides F-keys and FN+power


What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.


CK's layout is dead on arrival. It has 4 Alt keys. Only two can be mapped, Left Alt and Right Alt. Right Alt and AltGr are the same thing.


It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.


Four Alt keys or three shift keys are not minor things to get past. They are fundamental flaws.

So i mapped AltGr/ISO_Level3_Shift  to AltGr, right ctrl, and numpad enter. Along with +q they now all produce @.


altGr+q


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247955695, (-329,109), root542,632),


    state 0x10, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,

Spoiler

    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XmbLookupString gives 0 bytes:


    XFilterEvent returns: False


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247955859, (-329,109), root542,632),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XmbLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247955973, (-329,109), root542,632),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247955992, (-329,109), root542,632),


    state 0x90, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,


    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XFilterEvent returns: False

R_ctrl+q


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247841610, (-321,176), root550,699),


    state 0x10, keycode 105 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,

Spoiler

    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XmbLookupString gives 0 bytes:


    XFilterEvent returns: False


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247841734, (-321,176), root550,699),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XmbLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247841873, (-321,176), root550,699),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247841960, (-321,176), root550,699),


    state 0x90, keycode 105 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,


    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XFilterEvent returns: False

ENTER+q


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247802867, (-591,-224), root280,299),


    state 0x10, keycode 104 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,

Spoiler

    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XmbLookupString gives 0 bytes:


    XFilterEvent returns: False


KeyPress event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247802980, (-591,-224), root280,299),


    state 0x90, keycode 24 (keysym 0x40, at), same_screen YES,


    XKeysymToKeycode returns keycode: 11


    XLookupString gives 1 bytes: (40) "@"


    XmbLookupString gives 1 bytes: (40) "@"


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247803079, (-591,-224), root280,299),


    state 0x90, keycode 104 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,


    XKeysymToKeycode returns keycode: 92


    XLookupString gives 0 bytes:


    XFilterEvent returns: False


KeyRelease event, serial 37, synthetic NO, window 0x2a00001,


    root 0x2c0, subw 0x0, time 247803101, (-591,-224), root280,299),


    state 0x10, keycode 24 (keysym 0x71, q), same_screen YES,


    XLookupString gives 1 bytes: (71) "q"


    XFilterEvent returns: False