And now for something completely different (Keyboard Option)


SysRq was requested by a couple of people
The problem is that SysRq is a non-key. It's an interrupt. It doesn't actually produce a keycode. The entire purpose behind the SysRq is that it cannot be captured by software. Putting it on the Pyra in order to have this functionality wastes a key, and especially can't be used as "start".
Or was the actual request for something that was SysRq-like? Not literally SysRq but something that could behave like it? If that's the case then the Pandora's menu button fits that bill, if the software had been handled better: it generates a keycode that can be captured but it also sits on a GPIO that can trigger an interrupt, and of course it's tied to the PMIC to allow you to do a hard reset.


I'm willing to bet that EvilDragon and Nikolaus have already carried over that same functionality, meaning that the decision is already made. If it's the same convention as the Pandora then the bottom of those three is the "SysRq" button by technical design.
SysRq at AltGr + Menu won't waste that key placement. No one will even know it's there unless they try to open Menu while in AltGr lock/mode. We could even leave it up to the user to map it themselves on their own. Absolutely we don't have to have a System Request key but others want one, as you much as we care for one, and like you said it's inert without combo'd with another key(which is Alt). ;)   

While we're at it can we add a run/stop button for commodore 64 emulation? </Sarcasm>
We need Complete and Repeat keys first. Sorry.  :p
 
How is SysRq caught by the kernel if it's a software modifier combo?
On a desktop it's caught by the BIOS which triggers an interrupt.On the Pyra I suspect it can be on a GPIO that triggers an interrupt and that interrupt checks the status of the altgrfnmetamodsymhwm key before doing whatever the SysRq interrupt needs to do.
 
Please excuse me while I laugh maniacally.

OK. Done.

I was debating between putting SysRq and ScrLk, but we can put just about anything there - even a pop up trigger for an overlay menu. We could have both actually as those buttons in the center are actually only half mapped.

Nearly every key in this layout is capable of handling 4 'keys'. Using this methodology, the Pyra's keyboard actually has a -surplus- of keys. Even with mapping the media playback keys onto Fn+7, Fn+shift+7 and Fn+8, Fn+shift+8, there are still more possibilities than I'm actually mapping.

This is the only keyboard methodology proposed that has a 'key surplus'.

Each of the center top keys could actually contain 2 additional mappings. The Diacritic DeadKey (yes, this needs some work and assistance from someone who actually reads/writes/speaks French) can hold 2 more. I still have a few 'excess' currency symbols, but I tried to keep the ones that might have the most widespread use potential.

So, if you don't want SysRq or would like something else in that spot - sure. We can do that. I'm not overly hung up on the actual symbol-key positioning beyond wanting the English symbols as close to their positions on a standard US keyboard as possible.

'What are Start and Select' was brought up in the primary thread. We don't have to put Alt and Ctrl up there where they require a Vulcan death grip to reach. So, for Start and Select, which will be interpreted behind the scenes, we can pick -anything-. Preferably something that -isn't- on the standard keyboard, but generates a code. Maybe Σ or π - let your dreams run wild.

'But but that doesn't work just like a Pandora does!' The Pandora keyboard was a pretty extreme compromise. The Pyra will be too - but it doesn't have to be as bad as the Pandora. All of the Pandora stuff that counts on those being an Alt and Ctrl buttons (what little of it there is) will still work even if they don't get re-mapped. There are, after all, Alt and Ctrl buttons present and they have their own names.

Yes, we certainly can move some symbols about and even do replacements/substitutions. I have never declared this 'done no changes'. This is about an idea that gifts us far more 'keys' than we really 'need' and can result in a highly usable device - even for people who want to be able to type without using the shoulder buttons (Apparently that's myself and EvilDragon).

I'm the first to admit that I really do not understand non-English keyboard requirements. I've learned what I can and put provisions as I understood them into the design.

This keyboard is a conceptual design. It relies heavily on having Fn+shift on the left shoulder AND on the lower right corner such that they can be chorded with the left index finger OR the right thumb. By being able to make those combined presses, it opens up a -lot- of possibilities.
 
Am i correct if i think ctrl+plussign   is         Ctrl+Fn+Shift+0   Without shoulders that looks fairly hard to do.

Implementing a convention that works for the french as the last thing strikes me as very optimistic.

https://en.wikipedia.org/wiki/Compose_key#Software_support

The dedicated diactric key, is one of the 4 keys you need to implement language support in an efficient manner.

It is right next to ctrl+alt, which is a alternative standard way of doing what that key does. I see the combo-press potential of shift+fn, just not why the same isnt the case for ctrl+alt.

AltGr is the key you could have used to able to do fourth level modifiers in a standard way (AltGr+shift)  or even compose (shift+AltGr)

for those who doesnt have this as one of their 4 keys already.
 
Last edited by a moderator:
Am i correct if i think ctrl+plussign   is         Ctrl+Fn+Shift+0   Without shoulders that looks fairly hard to do.
It sure is, but at least it IS possible.  

Ctrl++ is used widely to change the displayed font size in browsers.  

Making this press on this layout using the shoulder buttons is pretty simple.

If you're not using the shoulders then the Pyra is assumed to be on a desk/table/lap.  At that point the user is no longer thumb typing.  So, yes, that needs 3 fingers to do without using the shoulder buttons.

I had a layout at one time that fixed that exact issue, but it required a centered space bar.  It had NO modifiers on the shoulder buttons.  It simply didn't need them there.  All modifiers were chordable with either thumb meaning that all 4 symbols and their derivatives were essentially 1.5 'keystrokes' away.  The old version did not have DosBox compliance.  If EvilDragon were to ask for a centered space bar version, I would re-map this to DosBox compliance.  It would be very cool.

http://www.keyboard-layout-editor.com/#/layouts/6c9d72c0045002506e532daaa5f2f7b4
 
Am i correct if i think ctrl+plussign   is         Ctrl+Fn+Shift+0   Without shoulders that looks fairly hard to do.
Doesn't your layout depend on AltGr being on shoulders? Doesn't that make it entirely impossible to type "Ctrl"+"+" without shoulders? I don't think you're in a position to complain about something going from "impossible" to merely "hard to do".
 
Yes, true, that is hard to do, but i think 3 shoulders is harder than 2. Is it possible to change the fourth level modifier to fn+shift. In the sense that fn is altGr, atleast that is a bit closer.
 
Last edited by a moderator:
Cleaned it up a bit.

Changed SysRq to ScrLk.  If people really really need a SysRq button, we could hide it on Pause/Break as Fn+Shift = SysRq.  I'm disinclined to try to write that in on the key though.

I think I have the 'Diacritics Dead Keys' set up properly now.  It is actually 4 'keys' all mapped on one physical key.  The idea being that this is a sticky-modifier key.  Press it for the diacritic you want to trigger, then the key that it should be applied to.  Much like a French keyboard will have two symbols that look like ^ and ˆ.  The first is shift+6.  The second is the diacritic dead key.  Although this theoretically makes the Ä, Ö, Ü redundant, I'm inclined to leave them in to ease German input - then placing the diacritic for those as the 4th Fn+shift 'key'.  Someone, preferably someone French, please let me know if this is a workable solution?

http://en.wikipedia.org/wiki/Dead_key

http://en.wikipedia.org/wiki/AZERTY

I ended up removing the 'Stylus mod' shoulder button definitions, though I would still like to do something for that.  My thoughts are that Fn+stylus click on the screen should equate to 'Right mouse button click' at that position.  Any thoughts on this?

Current version:

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

Current version with BOTH diacritic dead keys AND Compose (Comp on Fn+Backspace).

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

Any thoughts?
 
Last edited by a moderator:
I have 97 symbols on my layout. You have 162. Give or take a few.

Try to actually fit that onto the rendered picture of the pandora. The buttons are a lot smaller. Lets say this exercise is smooth sailing. If you then show this to regular people you will have better feedback than any of us can provide.
 
I have 97 symbols on my layout. You have 162. Give or take a few.

Try to actually fit that onto the rendered picture of the pandora. The buttons are a lot smaller. Lets say this exercise is smooth sailing. If you then show this to regular people you will have better feedback than any of us can provide.
It sounds to me like you better get busy and get the rest of the symbols onto your keyboard.  It will be very confusing for end users to need to use keys that have no labels.  Combine the missing symbols with the structural flaws of no DosBox compliance, inability to use it without the shoulder buttons and having all of the non-letter symbols scrambled around the keyboard at random, yours is a usability nightmare.

Now, you can go discuss and promote your keyboard in your thread please.  If you want to discuss and help improve on the keyboard being discussed in THIS thread, you're welcome to do that as well.
 
Last edited by a moderator:
Saber created a 'chance in hell' dream keyboard, and I thought it was a good idea.  So, I'm revisiting the idea of a centered space bar with the embedded number and function pads.

Re-created to allow for DosBox compatibility.

No modifiers on shoulder buttons.  All modifiers can be chorded with opposing thumb.  Shoulder buttons are mouse - as is intuitive to anyone who picks up a Pyra for the first time.  Nub-clicks also double as mouse.

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

Any thoughts?

/* Edit 20/4/2015 to add some interesting bits I thought up in the other thread. */

There IS a keyboard layout option that:

1.  Does not require any sticky keys.

2.  Does not require any shoulder modifiers (shoulders can then be mapped to whatever you desire).

3.  Has no left/right side disadvantages to chord+keypress combinations.

4.  Is -REAL- AltGr compatible (Turn on an AltGr language keyboard definition and the right Alt becomes AltGr).

5.  Is DosBox and QEMU compliant (key pairs retained)

6.  Has easily understood diacritics AND a dedicated 4-function media key.

7.  Has true left shift, right shift, left control, right control, left alt, right alt (AltGr if needed), left Fn and right Fn while freeing up the shoulders for mouse buttons or whatever else the user fancies - including over mapping modifiers.

8.  Key locations are relatively close to where an end user would expect them to be.

9.  Top level comma , and period . and [ and ] and ' and ` keys.

10.  Dedicated top level Esc key.

11.  All keys and levels of modifiers are chord capable by either thumb, including Fn+shift, Fn+alt, Fn+Ctrl, etc...

12.  Has the advantage of being able to lock both the number pad and the F1-F12 buttons to the foreground for games.

Right now it doesn't stand much of a chance in hell since it relies on a centered space bar.  However, I think it CAN meet all of our needs and want to haves.  It is built from the ground up for functionality.

http://www.keyboard-...89d24608b7a5de9

 

OK, so some think it's ugly.  IMHO it's so ugly it's cute...
 
Last edited by a moderator:
On forum feedback I have swapped sides for the modifier pairs and removed the '_lock_' suggestion for Alt and Ctrl.  This is being done to ease English punctuation entry for non-shoulder users.  I.e. the Fn key is now on the left to make it easier to get to the punctuation with the right thumb.  It's a pretty good idea.

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

An added benefit to this is it allows for a 'real' AltGr on the right-alt key on the lower right of the keyboard, should a user enable it by choosing a language layout in Debian that would enable it.

You're welcome to make suggestions in:

http://boards.openpandora.org/topic/16872-and-now-for-something-completely-different-keyboard-option/page-10

Thank you.
 
Last edited by a moderator:
I have 97 symbols on my layout. You have 162. Give or take a few.

Try to actually fit that onto the rendered picture of the pandora. The buttons are a lot smaller. Lets say this exercise is smooth sailing. If you then show this to regular people you will have better feedback than any of us can provide.
It sounds to me like you better get busy and get the rest of the symbols onto your keyboard.  It will be very confusing for end users to need to use keys that have no labels.  Combine the missing symbols with the structural flaws of no DosBox compliance, inability to use it without the shoulder buttons and having all of the non-letter symbols scrambled around the keyboard at random, yours is a usability nightmare.

If you want to discuss and help improve on the keyboard being discussed in THIS thread, you're welcome to do that as well.
I am trying to help out.

You had more visual symbols on your layout than i have on my real 105-key keyboard. Whats missing or in excess is a matter of interpretation. What symbols do you miss, and why isnt it ok to have it hidden under AltGr as per usual? 

Right now my gripe is no dot and comma as dedicated buttons.

I added the AltGr, lost the printscreen.

If you are talking about the "full"(er) layout, people already use keys like that without prints. A lot of keyboards are combined scandinavian, meaning the three extra letters are printed in a confusing manner. Doesnt bother people much because they are typing.

The same is not true for ABXY, because you arent typing then, also the connection isnt that strong, and if it is, its divided. Atleast between two camps of people.

Typing norwegian on a british or any other ISO keyboard is just the same if you know how to type.

However using reduced layout if you know how to type, and have use for more than reduced layout, is a pain. And very much half the demographic falls under that description.

The symbols on the full layout keys are from US/UK layout.

Dosbox was never hardcoded. It can be changed in config. Changing the actual layout just so that it will work with the default locale is strange.
 
Last edited by a moderator:
I have 97 symbols on my layout. You have 162. Give or take a few.

Try to actually fit that onto the rendered picture of the pandora. The buttons are a lot smaller. Lets say this exercise is smooth sailing. If you then show this to regular people you will have better feedback than any of us can provide.
It sounds to me like you better get busy and get the rest of the symbols onto your keyboard.  It will be very confusing for end users to need to use keys that have no labels.  Combine the missing symbols with the structural flaws of no DosBox compliance, inability to use it without the shoulder buttons and having all of the non-letter symbols scrambled around the keyboard at random, yours is a usability nightmare.

If you want to discuss and help improve on the keyboard being discussed in THIS thread, you're welcome to do that as well.
I am trying to help out.

You had more visual symbols on your layout than i have on my real 105-key keyboard. Whats missing or in excess is a matter of interpretation. What symbols do you miss, and why isnt it ok to have it hidden under AltGr as per usual? 

Right now my gripe is no dot and comma as dedicated buttons.

I added the AltGr, lost the printscreen.

If you are talking about the "full"(er) layout, people already use keys like that without prints. A lot of keyboards are combined scandinavian, meaning the three extra letters are printed in a confusing manner. Doesnt bother people much because they are typing.

The same is not true for ABXY, because you arent typing then, also the connection isnt that strong, and if it is, its divided. Atleast between two camps of people.

Typing norwegian on a british or any other ISO keyboard is just the same if you know how to type.

However using reduced layout if you know how to type, and have use for more than reduced layout, is a pain. And very much half the demographic falls under that description.

The symbols on the full layout keys are from US/UK layout.

Dosbox was never hardcoded. It can be changed in config. Changing the actual layout just so that it will work with the default locale is strange.
I suspect you're confusing two things.

1.  How the Fn non-English provisions in my keyboard layout work.

2.  What would happen to it if someone picked a Non-English keyboard definition in Linux and used it anyway.

I'm not changing the layout so that it will work with any locale.  However, I'm not stopping someone else from doing so either.

Surely you have installed Linux before.  You know that screen where it asks for your keyboard layout?  If you have a US English keyboard and select a Dutch Linux keyboard definition, it activates the right alt as AltGr and software over-maps the US keyboard as:

http://en.wikipedia.org/wiki/QWERTY#Dutch_.28Netherlands.29

It doesn't actually change the root keycodes that the keyboard itself is sending to the computer.  What it does is intercept anything using RightAlt+US Standard key and interpret it to generate the AltGr result.  This is why you can plug a (insert nearly any language here) keyboard into a computer, tell it you have a US standard keyboard and type away - regardless of AltGr and it's associated symbols being printed on the keys.

AltGr is resolved in software one step past where Fn has to work on the Pyra keyboard.

Key or Fn+key has to yield different specific keycodes.

AltGr+key yields RightAlt+key where the key's keycode is the same as it would otherwise be (IFF AltGr is turned on by selecting an appropriate keyboard definition in Linux.)

Does it make better sense now?
 
Back
Top