It's the keyboard layout.

[codifies]

Here's a small quote from ED's latest post


The keys will be flat, the printing will be on the inside of the cap,


so it can not rub off.


So does that mean after switching off the silly keymap light I'll be able to put my own labels between mat and caps? ...let's hope!

 

[bzar]

@comradekingu: I believe the issue is one level lower. There's no concept of altgr on the kernel driver level. So you'd have to output some other key event, like meta, in its stead and then interpret the meta keys as iso_level_3_shift. At which point you are making a hacky workaround. If it emits a meta event, why not call it meta?

 

[comradekingu]

So if we consider the reason for there not being an AltGr abitrary, its not when you print it on a keyboard. Even if Fn may not be Fn, and AltGr might not be AltGr in the implementation technically, its that way to the user. That is important.

I actually think thats the way it is already, in xmodmap

mod1        Alt_L (0x40),  Meta_L (0xcd)

Which i think comes from /usr/include/X11/keysymdef.h

#define XK_Meta_L                        0xffe7  /* Left meta */
#define XK_Meta_R                        0xffe8  /* Right meta */

#define XK_Alt_L                         0xffe9  /* Left alt */
#define XK_Alt_R                         0xffea  /* Right alt */

I really just wanted to distinguish my way of thinking about it from writing meta on a key, and making it do a mix of things. I have a problem with the mix.

If you only have one key marked meta, in my head it shouldn't be doing shift type things. It wasn't that way on knight or space cadet, and it hasn't been that way since.

I suppose things are different for Meta_R.

Edit: I think the way to avoid problems is having the shoulder altGr be ISO_level5_shift, like neo does

wiki.neo-layout.org/export/2440/linux/X/symbols/level5

// these variants assign various XKB keycodes to ISO_Level5_Shift so that
// the third shift level can be reached

 

[WizardStan]

I agree that dualwide space adds problems elsewhere, but what do you want me to do about it

Stop creating keyboards that treat it as two distinct keys. None of your proposals that do so will work, period. This is not a case of "ED said something but we didn't really discuss it so maybe he doesn't know about how great the alternative is". It has been discussed, arguments have been presented, at the end of it all he has flat out said the double wide spacebar stays. You can claim it's bad design but that is only your OPINION, not fact, and according to polls you are in a minority that believes that.

 

[Saber]

The layout i propose


Has A-Z+3 extras  +4 if you can do without keyboardshift


All 15 US dead diacritics, and a one-press compose key


A language-layer with every letter used for all western-european languages, +shift for big and small versals, no caps needed, and it has the +3 keys by default


Default AltGr available with regional mappings, no imposed anything, this avoids a lot of issues.


Fn available for everything besides F-keys and FN+power


What more is there to implement? Where can it be better?

CK and Saber's layouts have something common at their core that flunks them both.


...


It is just as bad as Saber's having 3 shift keys - also dead on arrival. Only two can be mapped, Left Shift and Right Shift.


...

As I asked _wb_ here, prove it(with your Pandora) that we can't have two keyboard Shift keys, Left and Right, and another Right Shift on L1. Observe and report any conflicts with remaps and when pressing the two Right Shifts simultaneously. I would do this myself, but I no longer have a Pandora handy. Let's see if you can do more than sing it. 

Not interested in applying the effort to testing someone else's bad idea. This falls into the category of, "Even if something is possible, that does not make it a good idea." Three shifts is bound to be confusing AND is a colossal waste of a key.

I expected you’d too squirm out of it.  

It’s not a waste of a key to have both Left and Right Shifts on the keyboard if some people by admission don’t like or want to be forced to use the shoulder Right Shift. 

I don't know why you need a Pandora to prove it, the problem is pretty evident


1) Press right shift: a "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"


2) Press other right shift: another "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"


3) Release one of the shifts: a "R_SHIFT Up" event is sent. Game says "ahah, right shift is no longer being pressed"


The game is now no longer aware that one of the shifts is being pressed, whatever that shift may be supposed to do.


We can get into other possible problems, like if it assumes a specific state, and pressing and releasing the button changes the state, you could end up changing it twice. It's a recipe for confusion.


That being said, my keyboard layout had three shift keys as well. I acknowledged the problem and said that it wasn't the end of the world: the odds of it happening are already very small, and when it does happen it should be easily solved by simply letting go of the offending key and pressing it again so it's not like a deadly bug, worst case is you accidentally drop your shields for a moment or whatever that shift button is doing.


Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

So, no appreciable “risk” or “problem” to have two Right Shifts, under normal circumstances, since these(or any) Shifts aren’t sticky keys and most people won’t be pressing them in concert(and if they do, nothing measurably Earth shattering will happen as the doomsayers have professed).

 

If, upon the Pyra's arrival at a doorstep, the user were to remap this “other” keyboard Right Shift to something more to their liking, like Yen or Euro, nothing catastrophic would happen either.     

 

Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

I also have to agree with Grench that it's a waste of a good key, where we really don't have any to spare, so I reckon it would need to balance against that and the potential risk.


- Neelix

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

 

[WizardStan]

If, upon the Pyra's arrival at a doorstep, the user were to remap this “other” keyboard Right Shift to something more to their liking, like Yen or Euro, nothing catastrophic would happen either.

If, upon the Pyra's arrival at a doorstep, the user were to remap the Euro/Yen key to something more to their liking, like an alternate keyboard Right Shift, nothing catastrophic would happen either.

 

[_wb_]

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

I think it is evident that keyboard Meta should be sticky, just like Fn on the Pandora. So my layout does not depend on the shoulder buttons at all for / ? [ ] { }, just like it is possible to input F11, F12, £, ¥, € and Tab on the Pandora.

And I see no reason why keyboard Shift could not be optionally made sticky as well for those people who insist on not using the shoulder buttons.

 

[Saber]

If, upon the Pyra's arrival at a doorstep, the user were to remap this “other” keyboard Right Shift to something more to their liking, like Yen or Euro, nothing catastrophic would happen either.

If, upon the Pyra's arrival at a doorstep, the user were to remap the Euro/Yen key to something more to their liking, like an alternate keyboard Right Shift, nothing catastrophic would happen either.

As long as it's understood about having two Right Shift keys not being the problem some of you have distorted it out to be. 

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

I think it is evident that keyboard Meta should be sticky, just like Fn on the Pandora. So my layout does not depend on the shoulder buttons at all for / ? [ ] { }, just like it is possible to input F11, F12, £, ¥, € and Tab on the Pandora.

And I see no reason why keyboard Shift could not be optionally made sticky as well for those people who insist on not using the shoulder buttons.

Yes, keyboard Meta should be sticky. In your layout though, even if it's sticky, if the person doesn't use the shoulder trigger L2 for Fn/Meta, they would have to tap twice with their left thumb for these: / ? [ ] { }. That's poor implementation.

 

[WizardStan]

As long as it's understood about having two Right Shift keys not being the problem some of you have distorted it out to be.

Oh no, it absolutely is. I already demonstrated why it's a problem. If someone wants to take that risk they are perfectly welcome to.

 

[WizardStan]

no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?.

1) Yes they do2) There's a distinct difference between "this is a thing that *may* cause confusion" and "this is a thing that can be demonstrated to cause confusion"

edit: "they" being you and CK at least. Honestly _wb_ has bashed out so many keyboards in the last little while I stopped paying attention.

 

[Saber]

I don't know why you need a Pandora to prove it, the problem is pretty evident


1) Press right shift: a "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"


2) Press other right shift: another "R_SHIFT Down" event is sent. Game says "ahah, right shift is being pressed"


3) Release one of the shifts: a "R_SHIFT Up" event is sent. Game says "ahah, right shift is no longer being pressed"


The game is now no longer aware that one of the shifts is being pressed, whatever that shift may be supposed to do.


We can get into other possible problems, like if it assumes a specific state, and pressing and releasing the button changes the state, you could end up changing it twice. It's a recipe for confusion.


That being said, my keyboard layout had three shift keys as well. I acknowledged the problem and said that it wasn't the end of the world: the odds of it happening are already very small, and when it does happen it should be easily solved by simply letting go of the offending key and pressing it again so it's not like a deadly bug, worst case is you accidentally drop your shields for a moment or whatever that shift button is doing.


Now, THAT being said, it should still only be done if it legitimately brings something useful to the table, enough to balance out the potential risk.

As long as it's understood about having two Right Shift keys not being the problem some of you have distorted it out to be.

Oh no, it absolutely is. I already demonstrated why it's a problem. If someone wants to take that risk they are perfectly welcome to.

You have not demonstrated a "problem". Only traced the events, which as far as I can see don't justify this risk spoken of if we have two Right Shifts on the Pyra.

 

[codifies]

if you have to left feet shifts you could just OR the state of the key


Lshift1    Lshift2    OR'd (shift seen)
Up Up Up
  Up        Down     Down
 Down      Down     Down
  Up        Down     Down
  Up         Up        Up
here while left shift 2 is pressed left shift 1 is pressed - only up down up is seen...

However your trouble there is how does some game tell the difference between the shoulder button (a gaming button NOT a key) and the shift key....

mixing gaming buttons and keyboard keys... not a great idea....

The alternative would be to use some other type of shift that maps to the same key characters

so there would be a map of unshifted keys a map of shifted keys and a map of other shift keys which is the same as the shifted map...

 

[Saber]

if you have to left feet shifts you could just OR the state of the key


Lshift1    Lshift2    OR'd (shift seen)
Up Up Up
  Up        Down     Down
 Down      Down     Down
  Up        Down     Down
  Up         Up        Up
here while left shift 2 is pressed left shift 1 is pressed - only up down up is seen...

However your trouble there is how does some game tell the difference between the shoulder button (a gaming button NOT a key) and the shift key....

mixing gaming buttons and keyboard keys... not a great idea....

The alternative would be to use some other type of shift that maps to the same key characters

so there would be a map of unshifted keys a map of shifted keys and a map of other shift keys which is the same as the shifted map...

I don't think we need to go so far as to have a specialized other Shift key map. Assuming I understand you, why would someone press L1(Right Shift) and keyboard Right Shift together anyways and if they felt compelled to, would it even matter if they mistakenly did for these one and done keys? It's been talked before of not having keyboard keys mingling with shoulder modifiers but it never seemed to be more than a smoke without fire issue. 

 

[_wb_]

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

I think it is evident that keyboard Meta should be sticky, just like Fn on the Pandora. So my layout does not depend on the shoulder buttons at all for / ? [ ] { }, just like it is possible to input F11, F12, £, ¥, € and Tab on the Pandora.

And I see no reason why keyboard Shift could not be optionally made sticky as well for those people who insist on not using the shoulder buttons.

Yes, keyboard Meta should be sticky. In your layout though, even if it's sticky, if the person doesn't use the shoulder trigger L2 for Fn/Meta, they would have to tap twice with their left thumb for these: / ? [ ] { }. That's poor implementation.

Not for /, that one can be mashed, much like Tab on the Pandora. But yes, keyboard-only users need two same-thumb taps for ? [ ] { } in my proposal. I don't think that is a big issue, since those symbols are not very important for efficient typing. In natural language, [ ] { } are barely used at all. Question mark is of course used, but not that frequently according to http://homepage.ntlworld.com/vivian.c/Punctuation/PunctFigs.htm :

. full stop: 65.3 per 1000 words

, comma: 61.6

" double quote: 26.7

' apostrophe / single quote: 24.3

- hyphen: 15.3

? question mark: 5.6

: colon: 3.4

! exclamation: 3.3

; semicolon: 3.2

(note that [ ] { } \ | / _ = + ~ are not in this list, presumably because they're too rare in normal text)

By contrast, your layout has the same problem with the diacritics (acute, grave, circumflex), which is a bigger issue since accented letters are pretty common in the languages that use them, and also for F7-F12, which could be annoying because e.g. F11 is often used to toggle full screen, which might be something you frequently need on a small-screen device.

Anyway, I don't think it matters much at all, since all of this only applies to that stubborn subset of people who refuse to use the shoulder button modifiers.

 

[Saber]

Again with the word “risk”. Outright, there is none, only the subjective agenda’s toward favored layouts here spoken by a few. Interestingly, no one rallies against ineptitude in proposals that are built on L2 dependance for common symbols / ? [ ] { }, or require by sustainably flawed design both Shift and Fn/Meta to be pressed for symbols like say _ + : { } ?. 

I think it is evident that keyboard Meta should be sticky, just like Fn on the Pandora. So my layout does not depend on the shoulder buttons at all for / ? [ ] { }, just like it is possible to input F11, F12, £, ¥, € and Tab on the Pandora.

And I see no reason why keyboard Shift could not be optionally made sticky as well for those people who insist on not using the shoulder buttons.

Yes, keyboard Meta should be sticky. In your layout though, even if it's sticky, if the person doesn't use the shoulder trigger L2 for Fn/Meta, they would have to tap twice with their left thumb for these: / ? [ ] { }. That's poor implementation.

Not for /, that one can be mashed, much like Tab on the Pandora. But yes, keyboard-only users need two same-thumb taps for ? [ ] { } in my proposal. I don't think that is a big issue, since those symbols are not very important for efficient typing. In natural language, [ ] { } are barely used at all. Question mark is of course used, but not that frequently according to http://homepage.ntlworld.com/vivian.c/Punctuation/PunctFigs.htm :

. full stop: 65.3 per 1000 words

, comma: 61.6

" double quote: 26.7

' apostrophe / single quote: 24.3

- hyphen: 15.3

? question mark: 5.6

: colon: 3.4

! exclamation: 3.3

; semicolon: 3.2

(note that [ ] { } \ | / _ = + ~ are not in this list, presumably because they're too rare in normal text)

By contrast, your layout has the same problem with the diacritics (acute, grave, circumflex), which is a bigger issue since accented letters are pretty common in the languages that use them, and also for F7-F12, which could be annoying because e.g. F11 is often used to toggle full screen, which might be something you frequently need on a small-screen device.

Anyway, I don't think it matters much at all, since all of this only applies to that stubborn subset of people who refuse to use the shoulder button modifiers.

The stubborn subset as you call it includes this guy. Let's not forget he's an important person when it comes to the Pyra.

As for ? { } [ ], they are sort of important too for non-coders and especially coders. The dead diacritics at u, n, and m in my layout are easy to semi-easy to activate depending on which Fn key is pressed. Same for F11 which I admit is effortless with L2. 

 

[WizardStan]

You have not demonstrated a "problem". Only traced the events, which as far as I can see don't justify this risk spoken of if we have two Right Shifts on the Pyra

Then I haven't adequately explained the problem. Sorry, this is my fault.This is the problem: if you hit both at the same time and then release one there is a potential that an application listening for keydown/keyup events, unaware that there are in fact two keys with the same sym, will simply consider the key as released. The problem then is that you are still holding the other key but the application, whatever it may be, does not recognize that it is being held.

I'm sorry, I thought walking through the events leading to the problem made the problem self evident. Does this explain things well enough now?

 

[Saber]

You have not demonstrated a "problem". Only traced the events, which as far as I can see don't justify this risk spoken of if we have two Right Shifts on the Pyra

Then I haven't adequately explained the problem. Sorry, this is my fault.
This is the problem: if you hit both at the same time and then release one there is a potential that an application listening for keydown/keyup events, unaware that there are in fact two keys with the same sym, will simply consider the key as released. The problem then is that you are still holding the other key but the application, whatever it may be, does not recognize that it is being held.


I'm sorry, I thought walking through the events leading to the problem made the problem self evident. Does this explain things well enough now?

No need to resort to that tone. It's not clever nor through it's contrived humility does it show maturity.  

It's the risk potential here I consider trivial and not worthy of being a "problem", more of a nuisance, if it ever is realized in execution.   

 

[WizardStan]

No need to resort to that tone. It's not clever nor through it's contrived humility does it show maturity.

Sorry, I'm not trying to be clever. I genuinely thought you didn't understand what I'd said. This happens a lot with me, I'll explain something and it makes sense to me but the person I'm talking to just doesn't get it, so I need to try again. One of the things I hate is a bad argument and if you can't explain something simply enough that the other person understands it (whether they agree or not is besides the point) then it is a bad argument, thus I correct myself whenever possible.

It's the risk potential here I consider trivial and not worthy of being a "problem"

It's demonstrable risk. Whether you think the risk is low enough to consider trivial or not is irrelevant. It exists, can definitely happen, and is therefore, by definition, problematic.As I said, I also agreed that it's such a low risk that we shouldn't really worry about it but at least acknowledge that it is a problem. If you're going to be introducing problems, no matter how insignificant, they had better come with enough features to compensate.

As Neelix said, though, in addition to this risk of missed key presses there's also the problem of taking up a precious key which could be used for something else.

 

[comradekingu]

For me its not even the missed key, its the problem of not doing anything useful. For case of argument the backspace from colemak is a better key. The familiarity is only something that steals efficiency, because its implying that two thumbs are 10 fingers, in a way that it isnt.

When i tried the three altGrs and looked at the things it produced, i was able to nest them within eachother, up until a point. I suppose thats fine since its always singular altGr. It looked like it wasnt possible to truly have both at the same time. Could test with neo, since that has modifiers that arent strung together like shift+altGr is. But i think unless you make multiple layers of the same modifer into something new, it will just be the same you started with.

Todays tidbit shared from IRC

TrashyMG|Work: the Pyra shoulders are on gpios separate from the keyboard matrix, one cool thing that could be done is that they could be put into a gamepad button mode

TrashyMG|Work: actually all the game buttons except for the two smaller game buttons have dedicated gpios

TrashyMG|Work: the two smaller ones are on the keyboard matrix.

Me and wb confirm, along with someone I talked to that proposed this from a developer point of view.

And if your thing isnt games, an always mediabuttons mode, or just a mediabutton mode in general, would be sweet.

High end media devices sell for lots of money, here you can connect your own usbdac and amp. No other thing provides that in a small laptop. For me thats on par with games with photography on a nice second.

 

[_jr_]

It's the risk potential here I consider trivial and not worthy of being a "problem", more of a nuisance, if it ever is realized in execution.

You are obviously entitled to your opinion, but have until now failed to demonstrate that it is relevant or even informed. That you cannot see a serious problem may well be a deficiency on your side. Perhaps considering that some are intending to run closed source software (with or without emulation) that canot easily (if at all) be modified to cater to arbitrary design decisions makes it easier to understand where actual problems could arise. This applies equally to so called dosbox compatibility.