geekhack
geekhack Projects => Making Stuff Together! => Topic started by: alaricljs on Wed, 05 September 2012, 15:57:39
-
So I hacked together a GUI to make remapping the Phantom a little easier. It can handle all the layout possibilities that are available as plates and some that aren't.
[attach=1]
Let's start with the options on the right, they should be self explanatory. The top 2 check boxes turn on and off 7bit's F-row (15 1x keys solid), and 7bit's nav block (extra keys over the arrows). The next grouping is basic layout allowing ANSI or ISO or 7bit. The next grouping allows you to specify the modifier row for 1.25x, 1.5x, or 7bit's modifiers. Note that choosing 7bit's layout makes all the extra options disappear since they are extraneous.
On the bottom right you can load or save phantom layout .c file as provided by bpiphany's firmware found at github (https://github.com/BathroomEpiphanies/AVR-Keyboard).
Underneath your keyboard layout is a single button showing the legend of the current button with the exact key_code underneath. To the right of that is an entry box where you can press any of these keys: [a-z] [0-9], all un-shifted punctuation, spacebar and tab to set the current button. Pushing any of the buttons in the layout will focus the input box so you can easily map all the letters/numbers with a mouse and KB.
To the right of that block are 9 drop-down boxes containing different groupings of key codes. If you need to UNSET a key, select NA in the Special list. Note that I allowed ALL the key codes and do NOT have any idea if they all work. For instance there is a left and right Ctrl keycode, but there is also a non-specific Ctrl keycode.
Please note that the layout settings do not change as you load your layout file. You must select the appropriate layout to see it correctly. Once you have saved your layout loading it again will set the GUI to the layout you saved as.
Now at v.11 of Phantom Remap
Implemented:
v.11 Tracking bpiphany's change to layout files:
Now outputs .c and .h using your filename, does NOT require writing over an existing layout.
v.10 (no version bump) added Colemak and Dvorak ANSI 125x layouts to the zip and separately
v.10 Resize bug fixed, code cleanup
v.9 Saving/loading of layout settings to the phantom.c file
v.8: Window Resizing (2 tiny buttons at top left corner, or Ctrl-MouseWheel)
This change removed Ctrl from the list of keys that can be directly input for code assignments
The program will now save an ini file containing x/y window coords and button size, the button size directly effects window sizing. You can directly edit the ini when the program is not running.
v.7: Additional keys for direct input (every key on my Filco TKL)
v.6: Sorting of the key code lists (remarkably easy since I wasn't using the key:values for anything)
I've included ANSI, ISO, ANSI Colemak, ANSI Dvorak (all in 1.25x) layouts and a 7bit layout in the zip file.
Features I'd like to implement:
Suggest something? Please understand that I won't implement a feature in the GUI that is not present in the master git repo linked above.
-
Fantastic!
-
Very nice.
-
So I hit v.6 since after doing some code review I found that I wasn't using the key:value pairs like I planned to. The key code drop down lists are now sorted somewhat more intelligently. Anyone want to take a stab at the Punctuation list? :)
-
Looks good. Will this work on the GH60 since it's kinda like a phantom?
-
This is specifically coded to fiddle the is_modifier[] and layout[] arrays. I honestly haven't even looked at the firmware other than knowing how those arrays relate to the physical switches on a Phantom PCB. If somehow the relationship between the arrays and physical switches can be maintained then yes, this can work with the GH60.
Since the GH60 doesn't yet exist it could be a design goal.
-
Awesome, alaricljs.
now, firmware modders, please keep the firmware compatible with alaricljs's tool. If you need to change the mapping array, please let alaricljs know so matching changes can be coordinated.
-
Awesome tool. Need this in a .deb package. :D
-
Okey, v.7 up - Every key on my TKL can be used for direct-input to set a key code, so click a button press a key, assignment done.
-
Awesome, alaricljs.
now, firmware modders, please keep the firmware compatible with alaricljs's tool. If you need to change the mapping array, please let alaricljs know so matching changes can be coordinated.
Yes, nice work, and I already moved the key matrices to their own file. I don't think the shape of the matrices will change much. If there are more layers, there will just be more of them =)
-
v.8 - Window Resize controls are now in the top left corner, also Ctrl-MouseWheel will change window sizing. This has the side effect of removing the Ctrl key from the list of keys that can be directly input to assign key codes.
Some input on if you'd prefer keeping the direct input of Ctrl and losing Ctrl-MouseWheel resizing would be appreciated.
Also implemented an INI file to save window size and position. The button size is how window size is saved since everything is derived from button size.
-
THANK YOU. I saved a copy, will put this to use when I finally get the chance to build my phantom.
-
I don't even have a Phantom :) You can play with this all you want without the hardware.
-
Will this eventually support layers
-
I'm tracking bp's github repo. If layers get pushed to there I'll figure out how to implement them in the GUI.
-
v.9 - Saving and Loading of layout settings to the phantom.c file.
These are saved as a standard C 1-line comment directly preceding the layout[] array. I also updated the included layouts so that they include this comment so you can see it in action easily.
-
The zoom makes the layout wacko, it overlays both ISO and ANSI as well as make the space bar 1u and moves some switches around. I don't see the use in zooming so it isn't a big problem, but it is broken in v9. Just fyi
I could post a pic if it helps or you don't have these issues.
Edit: ÅÄÖ behaves weird as well, but that I had expected.
-
That was an irritating bug. On the other hand it induced some serious code cleanup.
BTW - any idea how I might debug those non-US characters for you?
-
I could perhaps check the codes they are supposed to generate in autohotkey, sharpkey or something? I don't know if that helps.
Are media keys that different? My previous boards used to send something like MM_PREVIOUS, MM_PLAYPAUSE etc. I have also seen E0_22 mentioned for the play pause button. I have no idea if those codes are at all relevant or even help at all though.
I am going to have a look to see how this works, because I really don't have a clue atm. I am wondering if it is supposed to be something else and the remapping is done in the OS or something. Gonna read up a bit and return to ya on that.
Edit: Nice software btw, it could become very useful. If you want to make large changes it is much easier to get an overview than texediting the c file. Are those labels in .c, "KEY_L" for instance, translated to a lower level code somewhere or is that what is sent to the OS?
I think some people (not me though) would appreciate colemak and dvorak to be pre-made alternatives which you could select.
-
Phantom firmware is not setup for media keys as yet. Since I haven't mangled firmware yet I don't know what's required but I do know that most boards with media keys actually register a 2nd device just for the media keys.
The KEY_* are macros that are hex numbers that directly correlate to the scan code.
-
Apparently the L key is 26, and 27 is to the left of it, where Ö should be. I am thinking nothing at all is really done in the keyboard level and it is all managed at OS level.
-
Yes, the scan-codes are fixed and the OS needs to interpret the scan-code to be the region-correct result. As an example, the right Alt is just Alt in a US layout, it's AltGr in foreign layouts, but the scan-code is the same.
I tossed Dvorak and Colemak layouts into the zip and also they can be pulled separately.
-
My bad, nothing for you to fix there then. Do you happen to know if outputting multiple characters have been implemented yet, something like macros?
-
No macros in the firmware yet.
-
Wow, so excited about getting a phantom about ;D. Does the phantom lose all setting when I unplug it and plug to another computer?
-
Nothing in the phantom firmware is volatile at this point. The remap GUI above modifies the firmware source, you must then compile it and load it to the Phantom controller.
-
I would guess that the memory on the teensy is rated for a number of write/erase cycles that is way larger than what these keyboards will see in their lifetime.
I will look at the source and see if I can get myself into it a bit.
Edit: I can't seem to save the layout in the gui. I assume it was going to save a "phantom.c" file (or whatever you decide to name your layout)
-
The flash memory is rated for 10000 write cycles, and the EEPROM at 100000. The EEPROM is where stuff would be stored between resets of the keyboard (unplugging it). So not quite infinite, but pretty good.
-
Edit: I can't seem to save the layout in the gui. I assume it was going to save a "phantom.c" file (or whatever you decide to name your layout)
Are you saving it *on top* of a phantom.c file as it says in the instructions above? :)
-
Edit: I can't seem to save the layout in the gui. I assume it was going to save a "phantom.c" file (or whatever you decide to name your layout)
Are you saving it *on top* of a phantom.c file as it says in the instructions above? :)
Whoops, my bad
-
truly impressive. i can't wait to get mine to the state where i can load firmware and start testing it.
-
So I did change how layouts are defined :) I think the changes are all pretty well motivated, and regarding the layouts I mostly did away with the is_modifier array, which I don't think you will mind too much.. There will probably always be a layout array in pretty much the same shape as the current one. Adjusting the GUI software to keep up shouldn't be too hard. I am bound to keep learning more c and be unsatisfied with the current mess of files :) Since I reworked the firmware a fair bit I created a new repository, not specifically refering to the Teensy. https://github.com/BathroomEpiphanies/AVR-Keyboard
-
If I need some road signs stuck in your new file I'm sure you won't mind ;)
-
Hello
could you add some bépo layout ?
http://bepo.fr/wiki/Accueil
If it's just a file to write i can do it, but i'm an absolute noob in this kind of programming...
-
You can just use the GUI and make it yourself. I would recommend waiting for me to release the new version supporting the new revision of the firmware where the layout is in a separate file. BTW - it's done but I won't be posting it til I get home this weekend.
-
OK
i didn't think it was so easy. I'll wait for the final release.
Thanks
-
wow this looks awesome, one tiny request though. For all scandinavian vikings would it be possible to add the åäö letters?
-
Keypresses are apparently switched out for ÅÄÖ at the OS level and as such aren't needed in this gui.
-
If I had any idea which keycode is translated to which funky letter/symbol I might be able to work up a language switch so that you can see the legends you expect. I also don't know anything about how AHK deals with i18n and whether a hotkey set for english would fire on the same keycode from another language which is represented by another symbol.
-
I've taken the pragmatic approach to keymappings. Simply learn what the keys say on the US layout and translate on the fly. They are going to be different for different languages anyway. Perhaps it would be possible to add translation tables to the software, and people could write up their own.
-
Okey doke, managed to lose the previous v11 changes I did, and have only just had the time to redo them. Needless to say, 2nd time is even better.
v11 is now in-line with bpiphany's changes to layout .c files. It will output both the .c and .h for a particular layout, it's up to you to integrate that for compilation if you choose a different name than bp's stuff. This also does not require that the output file already exist. If it does exist, it will be over written.
I've also included all the previous layouts redone with the new format. So, ANSI and ISO in 1.25x and 1.5x mods, 7bit, and ANSI 1.25x Colemak and Dvorak.
-
I'm not sure if i've missed it here, or if it's in the building thread, but how do we go about doing function layers? Do we need to build separate layouts, and the manually combine them afterwards? what's the appropriate way to specify the modifier?
i should probably go read the build thread again, it's likely in one of the 2 pages of posts i've not seen yet.
-
AFAIK, Phantom Teensy firmware doesn't support layers yet. Separately, ErgoDox's Teensy firmware does support layers, but it is different firmware than Phantom and can't be used on Phantom.
-
Someone did a mod to bp's firmware that did layers, it was a bit of a hack and at this point I think bp has been moving in that direction with a cleaner design. From the coder point of view the layout array has already been renamed from layout to layer0. layer1-## would just be additional layers and consist of the exact same format.
For the GUI it should end up being a simple tabbed layout, one per layer. The difficulty is going to be dealing with how layers get changed when the KB is live. There's going to be a key or key combo or something and I'll need to handle assigning that in the GUI.
-
Everyone seems to be worried about toggleable layers im more worried about temporary layers like for my Fn key.
-
Here is the guy who added some layer functionality to the code https://github.com/Tranquilite0/Teensy-Keyboard It was also his idea to simplify the layout arrays using only one 16-bit array for both the key codes and the modifier key flags.
Layer functionality is very simple really. You more or less only need a variable that points to the current layer vector in the program. And then some routine that changes this pointer when function keys are pressed or just held momentarily. There are some special cases to look out for. For example, what happens if some keys are already pressed when the layer is switches?
-
I know this is a major necro bump but is this still viable to use?
-
It will probably still work just fine as long as you don't want any bells and whistles. I'm fond of bells and whistles, so I prefer to use hasu's tmk_keyboard firmware.
-
I'll try both once I get my phantom built.
-
for a full list of commits to hasu's firmware...
https://github.com/tmk/tmk_keyboard/commits/master
tldr:
the first commits of the macro implementation that he is working on (boss!!!).
nkro over the lua hex. you can still flash the lua hex on the teensy even though it is pjrc.
mx lock switch support
scroll lock LED is correctly mapped.
SLEEP LED