It's the keyboard layout.


As for shifted number-row, it also has this duality where it works in neither writing-mode nor ingame. Even modern games frequently feature the use of numbers as primary buttons. There are many ways to do it, some of which may work, but if its not the plain default, it will fail in many of them.
Grench's idea is to make an Fn lock readily available for exactly that purpose: enter a game, turn on the Fn lock, and not only do you get the common 1-0 keys but also the F1-F12 keys that a lot of games use. There's no need to do anything for either of those. It is arguably superior to having the numbers on the default row and the Fx keys on the Fn row, at least for gaming, because games will frequently use both and having them on different meta layers would mean extra keystrokes: by having them on the same meta layer there's no such requirement, just a lock and use them all.
 
The questions i ask myself are, What is Fn? For most people it stops there. You press the button with the number on it, no number, no dice.

For me its trying to put basic functionality on a button that never (?) does anything similar.

Fn-lock brings along with it Accidental-Fn-Lock, which isn't self-explanatory for anyone, with respect to the above.

Its like trying to have either 10finger similarity or be effective for two thumbs, do one of them, not fail somewhere in between.

Regular typing, in regular ways, cant be combined with regular US shift-pairs all over the place, it doesn't fit. Either its very complex with shift+AltGr, which is not derived from what we set out to replicate, or the keys are moved around.

In one scenario there was only familiarity to be had, and the latter only partly answers the question for obscure games. If you are dealing with orientation, its all sorts of wrong again.
 
Last edited by a moderator:
Regular typing, in regular ways
Cannot be achieved. Period. There is no way to make regular typing in regular ways a thing, the Pyra keyboard is not regular and should not be viewed as such: compromises need to happen. Arguing against one particular compromise because it "isn't regular" is a strawman.
 
As for shifted number-row, it also has this duality where it works in neither writing-mode nor ingame. Even modern games frequently feature the use of numbers as primary buttons. There are many ways to do it, some of which may work, but if its not the plain default, it will fail in many of them.
Grench's idea is to make an Fn lock readily available for exactly that purpose: enter a game, turn on the Fn lock, and not only do you get the common 1-0 keys but also the F1-F12 keys that a lot of games use. There's no need to do anything for either of those. It is arguably superior to having the numbers on the default row and the Fx keys on the Fn row, at least for gaming, because games will frequently use both and having them on different meta layers would mean extra keystrokes: by having them on the same meta layer there's no such requirement, just a lock and use them all.
Thank you - I'm glad someone actually understands what I'm trying to achieve with the numbers on Fn idea.

Regular typing, in regular ways
Cannot be achieved. Period. There is no way to make regular typing in regular ways a thing, the Pyra keyboard is not regular and should not be viewed as such: compromises need to happen. Arguing against one particular compromise because it "isn't regular" is a strawman.
I had figured comradekingu would have been jumping for joy in enthusiastic support of this one that finally gets him true P+1 and L+2 Germanic language support without compromise:

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

Numbers on Fn gives us the ability to do so many very cool things with this keyboard - and support everything that we set out to do.  It solves a half dozen different problems, has huge benefits, and one feature that some are seeing as a detriment - such that they're not willing to even consider the greater impact.

I'm not sure how else to explain the benefits beyond what I have above.  Thank you for showing that someone actually 'gets it'.
 
Saying it cant be perfect is no reason to throw all considerations out. Striking a compromise becomes impossible if you consider it to be compromised from the get-go, and in turn, the result will fall victim to the distinction. It is important to keep many concerns in mind at the same time.

A fuller keyboard is one thing, but it depends what trades are done in return. Doing away with backspace, or numbers, as dedicated buttons on the keyboard part, means a detriment a level of input that everyone utilizes, not just the international crowd. I should think having backspace on space is thematically more correct, and works better for the buttoncluster used for games, (see concern in earlier post.) But it is un-tested. New things are dangerous, because it brings implications to the whole slew of software in the world, and also it breaks with peoples expectations coming in.

Make it work for anglo users, in an efficient manner, and then add international support.
 
Saying it cant be perfect is no reason to throw all considerations out
You're the one throwing considerations out. Literally, that is exactly what you've done. Not in so many words, but basically "this is not 'regular' therefore it is not worth considering".Grench has an idea, he's presented arguments as to why he thinks his idea is good, and those arguments are sound. You've dismissed it because it is different.
 
... it just boggles the mind that people just don't seem to understand the difference between a compromise and compromised that one little letter is very significant...

there is just no doubt that good compromise actually leads to better solutions, without some kind of limitation or challenge there is no reason to apply brain power! 
 
there is just no doubt that good compromise actually leads to better solutions
No it doesn't. By definition a compromise is a tradeoff. A compromise will be better in some respect but it will necessarily be worse in a different respect. If there weren't something lost then it wouldn't be a compromise, it would just be a straight up improvement. A good compromise is one where the gains are deemed to be worth the losses.
 
Yes quite.

Compromise: an agreement or a settlement of a dispute that is reached by each side making concessions

If there is no concession it is not a compromise.
 
The Fn key is not a hardware key but software controlled this time. Does that have any impact on "Dosbox compatibility"?

I take it the Fn key behaviour needs to be handled fully in the driver such that the proper scancodes can be generated.

I.e. since the scancodes ignore XModmap completely (XModmap deals with keycodes), in order to have proper "Dosbox compatability"

any mapping would have to be fully implemented in the keyboard driver. That way a single keypress could be translated

to one or more scancodes (yuck, sounds like both a hack and a headache).
 
The Fn key is not a hardware key but software controlled this time.
The Pandora's Fn key wasn't hardware either, it just emulated a hardware key by changing things at the kernel level. They Pyra will need to do basically the same thing.
 
It's possible to lock input devices, preventing X11 etc. to open them.
I wonder if I could add this functionality to inputty :P . Would make it possible to add chording support and other stuff to any input devices :)
Thanks, slaeshjag :)
I just added EVIOCGRAB to QEvdev's capabilities (and hence inputty's). Nicely locked myself out of my keyboard except for the keys I had configured to do stuff. Luckily I could use my mouse to close the terminal :D
 
The Fn key is not a hardware key but software controlled this time.
The Pandora's Fn key wasn't hardware either, it just emulated a hardware key by changing things at the kernel level. They Pyra will need to do basically the same thing.
Except that of course that unlike the fn key on the Pandora it will also need to generate an input event of its own to be used on a shoulder button. 

-Neelix
 
Except that of course that unlike the fn key on the Pandora it will also need to generate an input event of its own to be used on a shoulder button.
Yes, and this is where some tricks are going to come into play.Will it go full software route? That is, if "Fn+B='>'" (random example) will a program see "fn" and "B"?

Or will it be a "hardware" modifier, will it see "Fn" and ">" and the "B" is lost?
 
Except that of course that unlike the fn key on the Pandora it will also need to generate an input event of its own to be used on a shoulder button.
Yes, and this is where some tricks are going to come into play.
Will it go full software route? That is, if "Fn+B='>'" (random example) will a program see "fn" and "B"?


Or will it be a "hardware" modifier, will it see "Fn" and ">" and the "B" is lost?
OR...  The Fn buttons ARE two different buttons with TWO different actual applications.

Have the Fn on the keyboard be an "emulated hardware Fn".  It can and needs to always be "Fn".

Have the Fn on the shoulder be an "emulated software Fn".  It can and needs to change definitions to joystick buttons.

That would mean that DosBox compliance would only 'work' using the keyboard Fn.  That is acceptable to me.

Would that work?

Don't fear different.  Sometimes different can be far more flexible and efficient than attempts to fit "normal" into an abnormal construct.

http://www.keyboard-layout-editor.com/#/layouts/ee8d3bc8b446f99c027105d3810f8d07
 
Have the Fn on the keyboard be an "emulated hardware Fn".  It can and needs to always be "Fn".

Have the Fn on the shoulder be an "emulated software Fn".  It can and needs to change definitions to joystick buttons.

... 

Would that work?
Seems like a bad idea to me. If the buttons behave so fundamentally different, they should not be called the same.This way you are just introducing another modifier key which you map, by default, to Fn-like behaviour.

I'm not yet sure how, but I'm confident we can find a better solution than this.
 
Have the Fn on the keyboard be an "emulated hardware Fn".  It can and needs to always be "Fn".


Have the Fn on the shoulder be an "emulated software Fn".  It can and needs to change definitions to joystick buttons.


... 


Would that work?
Seems like a bad idea to me. If the buttons behave so fundamentally different, they should not be called the same.
This way you are just introducing another modifier key which you map, by default, to Fn-like behaviour.


I'm not yet sure how, but I'm confident we can find a better solution than this.
From the user's perspective, they won't actually behave differently - at least not until the shoulder buttons are taken over by a game.  Which is a behavior that pretty much every layout suggested must do.  I'm not inventing something in my earlier statement, I am simply stating what is the obvious required behavior if you think about the actual scenario.
 
Back
Top