QWERTZ on an ANSI Pok3r?

[trenzafeeds]

So if this is totally bat**** insane feel free to just tell me so.
I own an ANSI QWERTY Pok3r, and I'm wondering if I could somehow get the firmware from the QWERTZ Pok3r to work on it. I've imagined this in a couple of ways. Either I just install the firmware from the QWERTZ Pok3r on my ANSI Pok3r and it somehow works out all fine and dandy with the exception of my backslash not working, or I do some sort of (preferably simple) mod to the firmware to make it actually properly compatible with the ANSI layout. Are either of these options at all possible? Is there another way I could do this? Is Pok3r firmware even openly accessible?

[davkol]

Why would you do that? The sixth top-row alpha key should always send the scan code 21 and the leftmost bottom-row key should always send the scan code 44. ANSI keyboards don't have an extra key (scan code 86) compared to ISO, but apart from that, they're completely the same to the computer.

If the QWERTZ Pok3r swaps them, it's an utterly stupid design decision that breaks alternative symbol arrangements.

[UKKeycaps]

Why bother? Just use AutoHotKey to re-map the board

[againer]

or use a programmable layer to programm it the way you want. then you can use your pok3r on any pc and not only on the pcs where you have installed and configured autohotkey.
The only thing, that bothers me, when i use the pok3r this way. I did not find a way to programm the missing key on to a programmable layer.So in the end there are some symbols, I can NOT type at all with my pok3r.
is there any possibility, to solve this on the ansi pok3r itself?

[davkol]

Not platform-independent.

Changing symbol arrangement is _always_ better in software (esp. OS keymap), if non-ASCII symbols are required.

If you only ever use one UI toolkit (e.g., the native one in MS Windows), you can use firmware-level macros for Unicode input.

[trenzafeeds]

Not platform-independent.

Changing symbol arrangement is _always_ better in software (esp. OS keymap), if non-ASCII symbols are required.

If you only ever use one UI toolkit (e.g., the native one in MS Windows), you can use firmware-level macros for Unicode input.

But doesn't that still leave me with the problem of it not working on every computer? If you're using hex input for unicode, for example, that only works on Windows machines that have the registry key set up for it. I'm not saying my original idea was the answer (it was pretty crazy), but there's gotta be some way to program like an umlaut or an esszet on just the firmware, right?

[davkol]

Yes, it's Windows only (or whatever platform you use most). No, there's basically no way to have the keyboard send symbols. USB HID does allow sending Unicode symbols instead of "dumb" scan codes, but I've seen it work correctly only once, and that guy spent months writing and debugging his very own custom firmware.

You're much better off simply setting the OS keymap to German QWERTZ. It's about five clicks or one command on any modern mainstream desktop OS.