Pyra keyboard scancodes?

[Pyramancer]

I'm looking for the scancodes produced by the keys on the Pyra.

I found the keyboard page in the Pyra wiki (https://www.pyra-handheld.com/wiki/index.php?title=Keyboard) but I don't see scancodes there (just the keycodes under a mapping in letux-4.5.0, it says).

Any pointers to the actual scancodes would be much appreciated.
[doublepost=1494868548,1494867683][/doublepost]If letux-4.5.0 uses udev, then the .hwdb file (or equivalent) used on Letux would be useful.

 

[TrashyMG]

There is a bit of fuzziness in my mind of where scancodes come into play, the i2c TCA8418 chip directly sends out "key codes" these key codes may be the same as the scancodes... I think the tca8418 kernel driver most likely handles the translation and without real hardware it's hard to find out for sure. However I'm close to a hacking together a functional mechanical Pyra keyboard to use on my OMAP5 devboard, just waiting on some QFN-24 breakout boards to solder the small 4mm TCA8418 chip, then hack together a new Device Tree Binary. If everything works the way I want it I'll have a test keyboard that behaves the same as it does on the Pyra.

 

[ible]

that is some dedication!

is it worth the extra inch or two shaved off, width wise? (but we do have quite a bit of vertical additions...)

 

[Grench]

There is a bit of fuzziness in my mind of where scancodes come into play, the i2c TCA8418 chip directly sends out "key codes" these key codes may be the same as the scancodes... I think the tca8418 kernel driver most likely handles the translation and without real hardware it's hard to find out for sure. However I'm close to a hacking together a functional mechanical Pyra keyboard to use on my OMAP5 devboard, just waiting on some QFN-24 breakout boards to solder the small 4mm TCA8418 chip, then hack together a new Device Tree Binary. If everything works the way I want it I'll have a test keyboard that behaves the same as it does on the Pyra.

View attachment 30410View attachment 30409

That is amazing!

Do you plan to put nubs on it?

You are building what could be a prototype of exactly what I had in mind when I started this thread:
https://pyra-handheld.com/boards/th...nbox-branded-keyboard-using-pyra-parts.80003/

Amazing - great work!

@EvilDragon &/or @TrashyMG : If you productionalize this properly in a nice case with nubs, I would buy five of them and replace all four keyboards I normally use and get one as a spare. I still think there is a market for this.

 

[TrashyMG]

Do you plan to put nubs on it?

Not sure yet, I do have some analogs.. I'm also missing the two smaller game buttons those I'll need to hack in.

Well this project originally started a few years ago as a way of actually trying people's keyboard layout ideas and give some constructive feedback, but I slacked off and an official layout was decided on, so I put it to the side. This keyboard will now serve to help me make the pyra xkb keymap file as it's considerable more complicated to deal with than the old xmodmap method.

@EvilDragon &/or @TrashyMG : If you productionalize this properly in a nice case with nubs, I would buy five of them and replace all four keyboards I normally use and get one as a spare. I still think there is a market for this.

Honestly this layout kind of blows for touch typing, but if you mean a small Pyra like keyboard I'm wiring it up exactly like the Pyra, just to one of the uEVMs i2c connector. So I don't think I'm breaking new grounds here.

Not entirely sure what I will do with this after I'm done with it, It's not entirely practical to use.

 

[Grench]

Honestly this layout kind of blows for touch typing

Is it a 'not used to it' or is there a mechanical reason why? Would it be necessary to relocate/add a normally placed space bar to 'fix it' for touch typing? Something more?

but if you mean a small Pyra like keyboard I'm wiring it up exactly like the Pyra, just to one of the uEVMs i2c connector. So I don't think I'm breaking new grounds here.

No, I'm actually meaning a compact full sized keys keyboard using mechanical Cherry MX Brown switches with the Pyra's nubs and controls on the top left/right corners of the top 1/3 of the unit - complete with shoulder buttons.

Not entirely sure what I will do with this after I'm done with it, It's not entirely practical to use.

It may sound odd, but what city is closest to you? I may have some travel coming up in a few months. If I happen to have a Pyra Prototype, would you be willing to meet in a bar or restaurant? You could try out the Pyra and I could try your experiment to see if my keyboard dream is stupid?

 

[TrashyMG]

Is it a 'not used to it' or is there a mechanical reason why? Would it be necessary to relocate/add a normally placed space bar to 'fix it' for touch typing? Something more?

Most likely moving the spacebar would fix some things, but if it's left centered in same row, then finding the other keys that are displaced would make it just as difficult to use.

It may sound odd, but what city is closest to you? I may have some travel coming up in a few months. If I happen to have a Pyra Prototype, would you be willing to meet in a bar or restaurant? You could try out the Pyra and I could try your experiment to see if my keyboard dream is stupid?

Closest "city" with an Airport would be in Burlington Vermont actually not too far from @Link, however I can make it up to Montreal Canada in about an hour and a half, or Boston in ~4 hour drive.

 

[Grench]

Most likely moving the spacebar would fix some things, but if it's left centered in same row, then finding the other keys that are displaced would make it just as difficult to use.

Hmm... The solution may be to add another row for the space bar. I may have to give this more thought and create a layout - Pyra keyboard derived but modded to suit touch typing needs. Alternatively, a regular compact keyboard layout plus Pyra gaming controls tacked to the top of it. But - what you have created is the closest I've seen yet to my 'dream'.

Closest "city" with an Airport would be in Burlington Vermont actually not too far from @Link, however I can make it up to Montreal Canada in about an hour and a half, or Boston in ~4 hour drive.

It was worth a shot. The travel I have coming up could potentially include Eastern Nebraska, Iowa, Eastern Kansas, Missouri, Southern Illinois, Northern Arkansas, Western Kentucky, Western Tennessee, Alabama, and Georgia. I occasionally make it to New York - once or twice per year, but nothing planned for now. I have been to Toronto a handful of times, but that is a pretty rare trip for me. But, sorry, wrong region to meet up with you - at least for now.

 

[TrashyMG]

Well If you're interested this is the openscad file I created to make the keyboard plate to insert the MX Cherry key-switches, due to the price reasons and limited materials I had when laser cutting ( https://www.ponoko.com/ ). I used two layers one to fit the key switches and another reinforcement layer as I used. I imported this to a cad program to add mounting holes, then exported it as an SVG file for laser cutting.

https://www.dropbox.com/s/i184eivfrmhjqjv/Pyra-plate.scad?dl=0

 

[hns]

This https://www.pyra-handheld.com/wiki/index.php?title=File:PyraKeycodeAssignment.png shows the key codes the Linux kernel sends as input events (you can check and see them by

evtest /dev/input/keyboard

For example pressing the A key sends code 30 which is KEY_A in Linux kernel: http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/input-event-codes.h#L104
Or pressing the power key sends code 116 (KEY_POWER).
This more or less maps to a QWERTY keyboard and since the control and shift keys already send the right code, you can also type ctrl-C or get upper and lower case characters. If you want a different mapping, this has to be done in user-space (e.g. setting some xmodmap).
[doublepost=1494957246,1494957174][/doublepost]

There is a bit of fuzziness in my mind of where scancodes come into play, the i2c TCA8418 chip directly sends out "key codes" these key codes may be the same as the scancodes... I think the tca8418 kernel driver most likely handles the translation and without real hardware it's hard to find out for sure. However I'm close to a hacking together a functional mechanical Pyra keyboard to use on my OMAP5 devboard, just waiting on some QFN-24 breakout boards to solder the small 4mm TCA8418 chip, then hack together a new Device Tree Binary. If everything works the way I want it I'll have a test keyboard that behaves the same as it does on the Pyra.

View attachment 30410View attachment 30409

Cool!!!

 

[Pyramancer]

This https://www.pyra-handheld.com/wiki/index.php?title=File:PyraKeycodeAssignment.png shows the key codes

Aha! Thank you. Yes, these are the (in my parlance) scancodes that I was looking for. I had confused myself by expecting to see them as hex values. And also because of the "keycode" in the caption.

[Although, I'm still somewhat puzzled as the scancodes reported in the `value' field of evtest are just the hex values of the keycodes reported in the `code' field, and they seem to me to be just the keyup codes. Maybe. I need to do more homework!]

If you want a different mapping, this has to be done in user-space (e.g. setting some xmodmap).

The disadvantage of remapping them with xmodmap is that the settings only take affect in X, and are not available in a Linux console. I hope to use custom udev hwdb rules so that my new mappings are available in both a virtual console and in X. This assumes a system that uses udev, but IIUC Debian does, since (like it or not (I don't)) it uses systemd.

 

[Eight Bit]

https://www.pyra-handheld.com/wiki/index.php?title=File:PyraKeycodeAssignment.png

I'm wondering why the Left Shift and Left Meta are on the Right and the Right Shift and Right Meta are on the left...

 

[ible]

@Eight Bit all keyboard modifiers are "LEFT" and all shoulder modifiers are "RIGHT".

 

[TrashyMG]

@Eight Bit , Plus it's an artifact of how the Pandora does it... so there is that.

 

[Pyramancer]

I'm wondering why the Left Shift and Left Meta are on the Right and the Right Shift and Right Meta are on the left...

I wondered that too. And I concluded (speculated), given that all the shoulder buttons were to be right modifiers, that the bottom right was the only place remaining on the keyboard to put those two left modifiers after the "more important" keys were given their position.

But maybe it's simply that the keymap designer doesn't know their right from their left.

 

[Grench]

I wondered that too. And I concluded (speculated), given that all the shoulder buttons were to be right modifiers, that the bottom right was the only place remaining on the keyboard to put those two left modifiers after the "more important" keys were given their position.

But maybe it's simply that the keymap designer doesn't know their right from their left.

It was always considered that in order to maintain as much control compatibility with the Pandora that we kept the Right modifiers on the shoulders. There were many keyboard layout proposals that put the keyboard Fn & Shift on the left, but doing so results in other compromises. With the keyboard modifiers on the bottom right, I/we put the most commonly used Fn layer combinations on the left to make them an easier reach for the left thumb. There was a ton of thought that went into the layout. There will always be someone who can find something to complain about on it no matter what the layout would have been.

It is done. Like it (my hope) or hate it (sorry), it is done.

 

[levi]

I've only just noticed there's a shift symbol on the tab key, fn-modified, as well as a dedicated shift key on the right of the keyboard, below enter (as well as the one on the shoulder button). I hope whatever's being used to map the function keys can cope with multiple keys mapping to the same keycode.

 

[Grench]

I've only just noticed there's a shift symbol on the tab key, fn-modified, as well as a dedicated shift key on the right of the keyboard, below enter (as well as the one on the shoulder button). I hope whatever's being used to map the function keys can cope with multiple keys mapping to the same keycode.

Wow - that isn't right. It is supposed to be é. Like this:
https://www.pyra-handheld.com/wiki/images/7/7a/PyraKeymatAndButtonsFunctions.png

@EvilDragon Did a typo slip through to the printing process?

Edit: It looks like there is a lot of inconsistency in the layouts on the Wiki Keyboard thread.
[doublepost=1495050970,1495050506][/doublepost]

Wow - that isn't right. It is supposed to be é. Like this:
https://www.pyra-handheld.com/wiki/images/7/7a/PyraKeymatAndButtonsFunctions.png

@EvilDragon Did a typo slip through to the printing process?

Edit: It looks like there is a lot of inconsistency in the layouts on the Wiki Keyboard thread.

Edit 2: I have it sorted. That is the Caps Lock, not a 3rd shift. Whew - had me in a searching panic. The Wiki should be cleaned up though.

 

[levi]

Ah, I can see here that it actually uses the symbol that I have only ever seen on Apple keyboards. On any actual photos of the manufactured keyboard on that wiki page it's indistinguishable from the shift icon on other actual shift keys, so I worry how identifiable it'll be in real life, but I guess it's a bit late to fix it now.

It's also true that the only times I've recently used caps lock, it's been in error, so it's not a key I'm ever likely to search for assuming I never hit it error and need to clear it.

 

[Pyramancer]

It was always considered that in order to maintain as much control compatibility with the Pandora that we kept the Right modifiers on the shoulders. There were many keyboard layout proposals that put the keyboard Fn & Shift on the left, but doing so results in other compromises. With the keyboard modifiers on the bottom right, I/we put the most commonly used Fn layer combinations on the left to make them an easier reach for the left thumb. There was a ton of thought that went into the layout. There will always be someone who can find something to complain about on it no matter what the layout would have been.

Thank you for the additional insight into Pyra keyboard lore.

To be clear, I wasn't complaining about the final keyboard layout (and it didn't sound to me like Eight Bit was either) -- just wondering about it. Anomalies spark questions in this curious mind. I wasn't here for the keyboard threads, and haven't read them (that would be a thesis research project!), but I have studied the penultimate round of layouts from which the final one was derived, and they're _all_ good. I'm happy with what we've ended up with.