It's the keyboard layout.


I wouldn't have a problem either way but I can think of a possible problem.  If you had a program that used the gaming buttons as joystick buttons and also used the keyboard, you would no longer have backspace.  Like when using PNDManager now on the Pandora, you cannot use the shoulder button for shift because that button changes pages.  It may not be a problem but it is something to think about.
True. But of course you already don't have cursor movement and home/end, so text editing is tricky anyway if you want to consider the gaming buttons exclusively as gaming buttons. I don't think it's a problem in practice, because most games that require text input don't require text input mid-game: if it's just something like multiplayer chat or highscore name entering, then the game will typically be in some kind of "text entry" mode, where the game actions don't work anyway.
 
True. But of course you already don't have cursor movement and home/end, so text editing is tricky anyway if you want to consider the gaming buttons exclusively as gaming buttons. I don't think it's a problem in practice, because most games that require text input don't require text input mid-game: if it's just something like multiplayer chat or highscore name entering, then the game will typically be in some kind of "text entry" mode, where the game actions don't work anyway.
Just because game actions don't work in that mode doesn't necessarily mean that the text editing effects of those keys would be restored. Also, while the other keys are often used for text editing, backspace is most frequently used during text entry, so it has a slightly different function that I feel should not be separated from the main keyboard.


-Neelix
 
True. But of course you already don't have cursor movement and home/end, so text editing is tricky anyway if you want to consider the gaming buttons exclusively as gaming buttons. I don't think it's a problem in practice, because most games that require text input don't require text input mid-game: if it's just something like multiplayer chat or highscore name entering, then the game will typically be in some kind of "text entry" mode, where the game actions don't work anyway.
Just because game actions don't work in that mode doesn't necessarily mean that the text editing effects of those keys would be restored. Also, while the other keys are often used for text editing, backspace is most frequently used during text entry, so it has a slightly different function that I feel should not be separated from the main keyboard.


-Neelix
Good point, the distinction between text editing and text entry. But of course the two extra game buttons don't have to be used for game actions; e.g. Pandora games would not use them by default.

Are there examples of games that require text entry and that would also benefit from the full 6 action buttons (and 4 shoulders etc)? I'm not really a gamer so for me it's a bit hard to estimate whether this (putting Backspace on SouthWest) would be problematic for an important subset of games, or if it's only an academic issue.
 
Good point, the distinction between text editing and text entry. But of course the two extra game buttons don't have to be used for game actions; e.g. Pandora games would not use them by default.

Are there examples of games that require text entry and that would also benefit from the full 6 action buttons (and 4 shoulders etc)? I'm not really a gamer so for me it's a bit hard to estimate whether this (putting Backspace on SouthWest) would be problematic for an important subset of games, or if it's only an academic issue.
I suppose that depends how it's implemented...  One of the issues that came up with pandora though was that the nubs were treated as different joystick devices and the buttons were not treated as part of the joystick devices at all.  In some games which were designed to use either joystick or keyboard control (but not both at the same time) this made control mapping...  tricky,  especially if it was closed source software running through something like DosBox.   To avoid such an issue it makes sense to offer an input mode where the nubs and all the gaming buttons all act as a single joypad device.   Switching to and from such a mode would probably have to be done on program start and exit, like switching the nubs to joystick mode is done now on the Pandora.     That being the case those keys would be unavailable for the duration of that time regardless of whether the game actually uses the entire set of buttons or not.

-Neelix
 
Last edited by a moderator:
Full 6button is atleast appropriate, in the arrengement they are in, for native inhouse pyra games. Some of which will undoubtably feature chatting (or commands) as a way of playing. Already there having backspace at buttoncluster makes it a though sale.

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. Given the many ways to do it, some of which may work, if its not the plain default, it will fail in many of them.

Almost normal or not that changed, is still a deviation from the norm. Makes it harder to appreciate the keyboard as a keyboard, and not a whole lot of invented-here concepts.

Some things just instantly tell you there was a lack of resources.
 
Last edited by a moderator:
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
 
Back
Top