Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-standard shifted keys #36

Open
tschulte opened this issue Jan 30, 2014 · 26 comments
Open

Non-standard shifted keys #36

tschulte opened this issue Jan 30, 2014 · 26 comments

Comments

@tschulte
Copy link

Somewhat related to issue #35: If I understand correctly, it is supported to move every key to every place. But the default for all keys is to keep their meaning, i.e. 2 becomes @ when shift is pressed on a US keyboard, and " on a German keyboard.

But is it possible to use shift for the normal keys (a-z), but define the shifted meaning exactly for the other keys? --> Shift+2 with the neo layout should become §.

One workaround I see would be to define the first layer without shift and use use a layer switch instead, defining a-z on the first layer and A-Z and all the other keys explicitly on the second layer. Problem: Shortcuts with shift will not work any more.

@jave
Copy link

jave commented Jan 30, 2014

I have a similar issue with my own version of the ergodox firmware(see my profile for the friendly fork)

I have an Emacs layer that generates the layout C files from lisp, and in lisp its not hard to remap characters to sequences. I use the swedish layout at the os level, so its the same mapping issue you have with german.

Then at the ergodox firmware level you can implement a c function that both sends shift, and a level switch. I havent gotten around to trying that yet though.

@jave jave mentioned this issue Jan 30, 2014
@benblazak
Copy link
Owner

So, the thing about the USB HID boot keyboard specification is that it requires us to send keycodes, not characters. There is one keycode for "shift", another for "2" and "@", and so on. It's doesn't make much sense, but there's nothing we can do about it. This is why strange workarounds are necessary to separate a character from its standard shifted character.

For historical and economic reasons, keyboards send more or less the same keycode for a given physical key (if I understand correctly) regardless of which country's layout they have printed on the keycaps. This makes mass producing keyboards easier (no need to program controller chips differently for keyboards being sent to different countries) but it does make things more difficult for us.

The code I implemented to send utf-8 character strings uses the fact that on most systems it's possible to type a unicode character by typing some special sequence or holding some key and then typing its hex code. This is done differently on different systems however -- and, of course, what the keyboard code is really doing is sending the keycodes for the alphanumeric string that represents a given hex code, not sending the actual characters -- so if you have your keyboard mapped in software to a language other than english (or even a non-QWERTY english layout) the OS may interpret this string improperly.

So there are a few different workarounds, I'm sure, and I think some of them have been discussed on GeekHack at various times, or elsewhere. I think a few people there were interested in a neo layout at some point, and I'm pretty sure someone implemented one (though, I didn't keep track of it). I think Jave's idea, as I understand it, is a good one. Ultimately, I'm not sure what the easiest thing to do would be.

I'll leave the issue open, for discussion -- sorry though, I don't have time to do much more. As I said in the other thread, school just started. Hope you get it worked out :) . Maybe post back, if you like, if you find a good solution.

@tschulte
Copy link
Author

I was aware that the keyboard does only send keycodes, not chars.

As I can see, I could redefine the keys in lib/usb/usage-page/keyboard.h. Then at least type_byte_hex would work. type_string would work for a-z0-9 and enter, escape, etc. but not for @ and # and some other chars. And some of the characters above 0x127 are directly usable on some non-us layouts, e.g. German umlauts (üöä), sharp s (ß). I am not sure for dead keys (é and è on a German keyboard). When dead keys are deactivated in the OS, this would not work.

Alternatively I could define some KEYS_DEFAULT() and KEYS_SHIFTED() Methods like it is done with a-z and A-Z in keys.h

KEYS__DEFAULT(sz, KEYBOARD__RightBracket_RightBrace);
KEYS__DEFAULT(ue, KEYBOARD__z_z);
KEYS__DEFAULT(oe, KEYBOARD__x_X);
KEYS__DEFAULT(ae, KEYBOARD__c_C);
[...]
MATRIX_LAYER(
[...]
nop, ue,oe,ae
[...]
[...], sz,

In that case the definition of the layout would be nicer.

I will try to find a solution for the problems, but my little C knowledge I once had is rusty at best. And my time is limited as well, since I have two little kids.

@benblazak
Copy link
Owner

Actually, either (or both) of those solutions sounds promising. I'm not sure which I'd choose if I were doing it.

Yeah, kids, I've heard, are even more time consuming than school -- though I imagine the time spent is more fulfilling as well... :) .

@Thanatermesis
Copy link

If im not wrong, the "dead" keys are something set/managed in the OS, when you use the spanish layout (similar to english qwerty), the keycode for dead keys are:

  • keycode 48 , keysym 0xfe51

when you press then (after to have released the dead key) the character "e" for example, it is triggered the keycode 26, which then automatically triggers later:

  • keycode 0, keysym 0xe9

@tschulte
Copy link
Author

AFAIK, hat is correct. A normal keyboard is dumb in that it only sends which keys are pressed. The os does translate these events to the correct key events. E.g. in linux you can set 'nodeadkeys' to be able to enter for example backticks directly on a German keyboard.

tschulte added a commit to tschulte/ergodox-firmware that referenced this issue Apr 6, 2014
tschulte added a commit to tschulte/ergodox-firmware that referenced this issue Jun 26, 2014
tschulte added a commit to tschulte/ergodox-firmware that referenced this issue Jun 26, 2014
tschulte added a commit to tschulte/ergodox-firmware that referenced this issue Jun 26, 2014
@xstable
Copy link

xstable commented Dec 20, 2014

Hi tschulte,
i've fork your neo2 Layout and modify a bit for my needs. Great Work. Thanks a lot for this.
Did you have an Idea, how we could got the special-Keys to work like mod4+mod2+"." (to make an right-arrow ).
Is there a way to got unicodes to run with ergodox firmware and some kind of macro?
Would be great, if you wan't to join the google plus group "ergodox".

@tschulte
Copy link
Author

To enter any chars that are not directly available with standard quertz, have a look at https://en.wikipedia.org/wiki/Unicode_input

For example to enter ❅ I did hold down Ctrl+Shift, then typed u2745, then released Ctrl+Shift (I'm on Linux right now). On Windows it would have been holding down Alt, then typing +2745, then releasing Alt.

AFAIR the key_function type_string, but this does assume your OS is configured for US-English and Windows. For being able to use that function on a PC configured to German on Windows, you would need to change something there. See #35.

I am currently just not using any special chars, since I am mostly programming in Java or writing documentation and emails, this has been no problem so far.

@xstable
Copy link

xstable commented Dec 22, 2014

Thank you for your reply tschulte. I think it's hard to remember all those unicode-strings (like u2745), or watch on a cheatsheet every time. Would be great, if there where a makro to enter unicode (maybe on another, own ergodox-layer).

BTW:
Could you add "Issues" -Section to your github-Project (https://github.com/tschulte/ergodox-firmware) in this way I could send you messages specially for neo2-Layout.
At the moment I've trouble with "Eclipse IDE" and German Umlauts. If I enter ü,ö,ä,ß Eclipse crash without any feedback.
Did you have an Idea, what this may be?

@tschulte
Copy link
Author

I did not mean to type the unicode strings yourself. The firmware could do this:

#define TYPE__UNICODE_LINUX(name, k1, k2, k3, k4)                   \
    void P(name) (void) { \
                          KF(press)(KEYBOARD__LeftControl); \
                          KF(press)(KEYBOARD__LeftShift); \
                          usb__kb__send_report(); \
                          KF(press)(KEYBOARD__u_U); \
                          usb__kb__send_report();              \
                          KF(release)(KEYBOARD__u_U); \
                          usb__kb__send_report();              \
                          KF(press)(k1); \
                          usb__kb__send_report();              \
                          KF(release)(k1);  \
                          usb__kb__send_report();              \
                          KF(press)(k2); \
                          usb__kb__send_report();              \
                          KF(release)(k2);  \
                          usb__kb__send_report();              \
                          KF(press)(k3); \
                          usb__kb__send_report();              \
                          KF(release)(k3);  \
                          usb__kb__send_report();              \
                          KF(press)(k4); \
                          usb__kb__send_report();              \
                          KF(release)(k4);  \
                          usb__kb__send_report();              \
                          KF(release)(KEYBOARD__LeftControl); \
                          KF(release)(KEYBOARD__LeftShift); \
}   \
    void R(name) (void) {}

[...]
TYPE__UNICODE_LINUX(rightArrow, KEYBOARD__2_At, KEYBOARD__1_Exclamation, KEYBOARD__9_LeftParenthesis, KEYBOARD__2_At);
[...]
MATRIX_LAYER([...], rightArrow, [...]

The mentioned key_functions__type_string in special.c tries to do this automatically, but it only works on Windows configured to US-querty. One could alter my macro from above to use key_functions__type_byte_hex from special.c. Or One might have a look at key_functions__type_string to take into account the OS and keyboard layout of the OS (although, both are IMO not known at runtime, because the OS does not tell the keyboard about it -- so must be set at compile time).

About the issues section: Until recently I thought Ben was the owner of the firmware, and I did only try to poke around to enable my keyboard to do what it was bought for: using neo2 without altering the PC (i.e. plugging it into a notebook in a meeting room and being able to use my layout of choice immediately -- I do suck at quertz after using neo2 fulltime for over 6 years now). I don't know the code inside out, nor do I master C (last time I did serious work in it was 12 years ago).

I can enable the issues section, but I can't promise to put much effort into the project, because I have 2 little kids eating pretty much all of of my free time.

Regarding your problems with Eclipse. I am coding in Eclipse 4 all the time -- but until now only on Windows -- without having any problems. Maybe this is a problem with a plugin. Have you tried a vanilla eclipse-distro without custom plugins?

@xstable
Copy link

xstable commented Dec 24, 2014

Thank you for your response.
Nice macro. I'll give it a try. It would really nice to have all the unicode-Chars from neo2 on ergodox firmware.

Another problem I have at the moment... if I press a letter (a,b,c) and hold it for a while, it will not repeat. If I press mod4 and arrows, moving the cursor by hold the key down work.
Did you have an Idea, why keyrepeat on letters not work?

Seems that eclipse only have trouble with umlauts on a special file, I've open. Maybe a validator or rebuild Problem on eclipse. Now it seems to solve without doing anything.

@Thanatermesis
Copy link

Did you have an Idea, why keyrepeat on letters not work?

are you sure that this is a problem of your ergodox? try to connect another
keyboard, because if im not wrong the repeating is a feature of the
consoles / gracphial system

2014-12-24 10:34 GMT+01:00 Samuel Suther notifications@github.com:

Thank you for your response.
Nice macro. I'll give it a try. It would really nice to have all the
unicode-Chars from neo2 on ergodox firmware.

Another problem I have at the moment... if I press a letter (a,b,c) and
hold it for a while, it will not repeat. If I press mod4 and arrows, moving
the cursor by hold the key down work.
Did you have an Idea, why keyrepeat on letters not work?

Seems that eclipse only have trouble with umlauts on a special file, I've
open. Maybe a validator or rebuild Problem on eclipse. Now it seems to
solve without doing anything.


Reply to this email directly or view it on GitHub
#36 (comment)
.

Do you want a new linux experience? Just follow my legacy...
Got my signature from http://main.elivecd.org/misc/key.gpg

@Thanatermesis
Copy link

@tschulte that function looks nice! can you tell me if it works also on console mode or terminals like xterm / urxvt ? (if im not wrong this only works on GTK based applications, like gnome-terminal)

@xstable
Copy link

xstable commented Dec 24, 2014

are you sure that this is a problem of your ergodox? try to connect another
keyboard, because if im not wrong the repeating is a feature of the
consoles / gracphial system

Yes, I'm sure, cause cursor, delete, backspace.... working well with keyrepeat.
I think the problem cause in the firmware.

@tschulte
Copy link
Author

@xstable regarding your problem with non-repeating keys: This is because you use the TYPE__DEFAULT instead of KEYS__DEFAULT macro in your definition. This is most probably because you copied it over from my definition.

The TYPE__ and the KEYS__ macros are defined in keys.part.h. The KEYS__ macros do trigger 'press' events on key press, and 'release' events on key release. The TYPE__ macros do a full sequence of PRESS and RELEASE on key press and nothing on release. This is why you don't get a repeating char on pressing any char.

The firmware is designed to arrange the keys freely, but still using the default semantics of the default keyboard, i.e. having a shift key, defining a-z and the number keys on layer 1. In doing so, you really get 2 layers by only defining one. The problem with this is, you would still get a ! when pressing shift+1, " when pressing shift and 2, ... This is not what neo2 suggests. This is exactly what I described in this ticket, just scroll up to the first entry.

A workaround would be to define 2 layers instead of just one, and not defining a shift key. I am currently not doing this, but I think I do not use the number row anyway -- I type all my numbers on layer 3, and it seems I did not need the euro sign in the last year.

The original firmware already defined KEYS__DEFAULT and KEYS__SHIFTED. I introduced KEYS__ALT_GR (for being able to type in {, }, [, ], , @, € and ~). Later I created TYPE__NON_DEAD, TYPE__NON_DEAD_SHIFTED and TYPE__NON_DEAD_ALT_GR to type in chars, that are dead an a default German Windows machine (to type in `, you would need to press the key, release it again, then type the space bar). (On Linux you have the choice whether you want the non-dead driver.)

The TYPE__NON_DEAD macros perform the whole sequence on key press, and nothing on release and do therefore not repeat. Later I stumbled onto a bug with the KEYS__ALT_GR. I was not able to type in [], I needed to type [, then wait a little bit, then type ]. I don't know why, {} was possible. That's the reason I introduced all the other TYPE__ macros and used these for [, ], { and }

Another problem was <>. On the German keyboard they are on the same key, therefore it is not possible to type both at the same time. But with neo2 this it possible, because they are on two separate keys on the same layer. For these I needed the TYPE__ variants as well.

And speaking of problems. What if one key uses a KEYS__ macro, one other a TYPE__ macro. Or one uses KEYS__default, and another the KEYS__SHIFTED or KEYS__ALT_GR macro? In that case ALT_GR or Shift would win.

Because I personally do not rely on the repeating behaviour, I decided for my layout to be more consistent and just use TYPE__ instead of KEYS__ for nearly everything.

@xstable
Copy link

xstable commented Dec 26, 2014

@tschulte Thank you for your response.
I've played arround a bit with TYPE__ and KEYS__, but don't see exactly, why you use TYPE__ instead KEYS__ for the a-z & A-Z.
I've switch the function for a-z (not A-Z, I leave them to TYPE__SHIFTED) back to KEYS__, the lowercase chars work as well as the uppercase one - include the keyrepeat.

So I doesn't see any benefit at the moment to use TYPE__ instead of KEYS__ for a-Z. Can you explain, why you choose to use this function for those keys?

I understand the problem with shifted Keys and default-setting for them (shift + 2 = "; shift+4=$...).
I've think about to create an own Layer for unicode-Chars and the currency Symbols (¥$€). I'd like to use Symbols like –,•,←,↑,↓,→,⇒, too . I would like to have them on mod4+mod3+numBlock-keys.
Did you have an Idea, to got them to those keys?

@xstable
Copy link

xstable commented Dec 26, 2014

@tschulte: Ok, seems your Macro works now. Here the Key you've defined above 👍

→ = TYPE__UNICODE_LINUX(rightArrow, KEYBOARD__2_At, KEYBOARD__1_Exclamation, KEYBOARD__9_LeftParenthesis, KEYBOARD__2_At);

Here I found this Page with many unicodes listed: http://en.wikipedia.org/wiki/Category:Unicode_charts

How can I got this created arrow key assign to mod4 (ergo-layer 3), + shift + numpad2?

@xstable
Copy link

xstable commented Dec 29, 2014

The Unicode-Macro not work everywhere.
Here in the textarea of a Browser it works: ❤♂✆✉≠☢✘✔§... no problem!

BUT on other Programms (like konversion, kate, kontact... ) it does't work.

For example the rightArrow (⇒) you defined, output only this String: "!"

How can I got unicode worked in every Programm?

@tschulte
Copy link
Author

As @Thanatermesis already said, there is no platform independent way of inputting unicode characters. And even within Linux, the way to input unicode varies: https://en.wikipedia.org/wiki/Unicode_input#In_X11_.28Linux_and_other_Unix_variants.29. Can you try the second way as described on wikipedia? But maybe this method does not work for KDE applications, as stated in the wikipedia article as well.

@xstable
Copy link

xstable commented Dec 30, 2014

I found out, what's may the problem. Unicode only work on GTK-Applications, cause KDE-Applications are QT, CTRL+SHIFT+ not work.
I have describet (in german language) this problem here: xstable#3

There is a little Daemon for KDE which catch this shortcut: https://gitorious.org/ucode/ucode/source/59229d2f7aa808bf623405f4c56ad076e4247e4e:

It's not really stable, but a good step forward to solve this old (since 2010) Problem with KDE-Applications and Unicode input.

@Alexander-Shukaev
Copy link

@tschulte, so is it already possible to separate keycodes for keys pressed without shift and with shift?

@tschulte
Copy link
Author

I have not invested any time for about half a year into this. But I think it is not really possible -- at least not without consequences.

The only way to archive this is to not use shift at all, but only use macros. Shift+A is sent as Shift+A, Shift+6 ($ on Neo2) sends Shift+4($ on QUERTZ), Shift+7(€ on Neo2) sends AltGr+E (€ on QUERTZ).

But this is not platform independent. There is no bi-directional communication between the keyboard and the pc. The OS of the pc is unknown to the keyboard. The keyboard layout as configured in the OS is unknown to the keyboard.

And using this approach you loose some other features like keyboard shortcuts (e.g. Ctrl+Shift+6) or key repeating. E.g. Shift+7 must send Press AltGr, Press E, Release E, Release AltGr. Shift+6 should send Press Shift, Press 4, Release 4, Release Shift.

@hamilyon
Copy link

I am trying to type underscore with Shift+- but it still sends - (xev says so). '-' is mapped to nonstandard location.
I don't know if it is related to this thread, just need some help

@hamilyon
Copy link

kb

@benblazak
Copy link
Owner

Cool to seen an ErgoDox EZ :) -- the founders contacted me when they were first starting (or around then) and they seemed like nice people.

If you're using their web configurator, you should probably contact them / post to their forum. If you're willing to mess with the code, you're in the right place :) but no telling when i'll be able to get to it. Often others are willing to help though, if they see the issue.

@niico100
Copy link

This is also an issue for UK English, if you want to type a pound sign £ - that isn't present on US keyboards obviously.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants