It's the keyboard layout.


Saber and WizardStan, now that you're here, would you mind assigning weights/priorities to a list of keyboard properties?

https://docs.google.com/spreadsheets/d/14mVNNzLhmhyA4sCIAPSoDv404xtctfLSiEMTtTlEzfw/edit?usp=sharing
Thanks for the invitation but from my standpoint the two layouts in my sig below embody my priorities. If it's in there, it's what I think should be committedly included. The exceptions are a dead key for Caron, which I've talked about placing at Shift + Fn(or likewise as always at Fn + Shift) + u, and, with some reservedness, number lock at Shift + Fn + m(or n if dead Grave is put on Shift + Fn + m).  :)
 
The Pandora's hardware Fn key with DOSBox doesn't work "correctly" there either without tricking it into seeing Shift + Fn level symbols usually solely bound under a Shift, like Colon or Underscore.
That's only because pandora's keys are not the same as the keyboard dosbox assumes, making Fn there only add to the number of keys, not make them the expected keys.
We'll know soon hopefully but the last tidbit on this subject(from ED) was no hardware modifier, like Fn, on the Pyra.
"fix" DosBox not the hardware... The hardware at its lowest level should only ever report exactly what actually happens - if some emulator doesn't work with a particular platform then you port it, not bodge the next release of hardware to suit just one piece of software! (porting isn't just getting it to compile)
This post deserves to be stickied.  :)
There have been quite a few attempts to fix this on the Pandora, and nothing has been able to do it yet. But that is one easily demonstrable instance of a wider problem.


The issue isn't just with DosBox. It translates over into QEMU, which impacts trying to run X86 Linux code on the ARM Pyra.


With ExaGear coming online, I see the X86 Linux code running on Pyra as a potential 'killer application' that needs to be supported well. HalfLife is running on the Pandora. The Steam client is running on the Dev boards. I see it as only a matter of time before HalfLife is running via the Steam Client on the Pyra. Again, only one example, but it's a framework for a much broader application set.
We know there is an issue but does anyone actually know the "why" DOSBox and QEMU misinterpret? Hiding shifted values like we've been doing in most of our proposed layouts for this predicament, at the Shift + Fn fourth level, seems to be an effective patch regardless of the undefined reasons behind the fickleness of this software though, until we know more officially about the limitations of the finalized keyboard.  
You know that I already explained what is happening with the mapping and that I have a fix for Qemu. It's lost somewhere in one of the many keyboard thread...
 
Shift + Fn isn't new though
It is for being the actual keys, label and all.
Saber and WizardStan, now that you're here, would you mind assigning weights/priorities to a list of keyboard properties?
Yeah, maybe I'll get around to it. I just don't really feel motivated to put more effort into it since ED has pretty much gone radio silent on the whole thing, even after multiple requests for clarification on what he wants.
 
The Pandora's hardware Fn key with DOSBox doesn't work "correctly" there either without tricking it into seeing Shift + Fn level symbols usually solely bound under a Shift, like Colon or Underscore.
That's only because pandora's keys are not the same as the keyboard dosbox assumes, making Fn there only add to the number of keys, not make them the expected keys.
We'll know soon hopefully but the last tidbit on this subject(from ED) was no hardware modifier, like Fn, on the Pyra.
"fix" DosBox not the hardware... The hardware at its lowest level should only ever report exactly what actually happens - if some emulator doesn't work with a particular platform then you port it, not bodge the next release of hardware to suit just one piece of software! (porting isn't just getting it to compile)
This post deserves to be stickied.  :)
There have been quite a few attempts to fix this on the Pandora, and nothing has been able to do it yet. But that is one easily demonstrable instance of a wider problem.


The issue isn't just with DosBox. It translates over into QEMU, which impacts trying to run X86 Linux code on the ARM Pyra.


With ExaGear coming online, I see the X86 Linux code running on Pyra as a potential 'killer application' that needs to be supported well. HalfLife is running on the Pandora. The Steam client is running on the Dev boards. I see it as only a matter of time before HalfLife is running via the Steam Client on the Pyra. Again, only one example, but it's a framework for a much broader application set.
We know there is an issue but does anyone actually know the "why" DOSBox and QEMU misinterpret? Hiding shifted values like we've been doing in most of our proposed layouts for this predicament, at the Shift + Fn fourth level, seems to be an effective patch regardless of the undefined reasons behind the fickleness of this software though, until we know more officially about the limitations of the finalized keyboard.  
You know that I already explained what is happening with the mapping and that I have a fix for Qemu. It's lost somewhere in one of the many keyboard thread...
Of course:  :)

http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=376967/URL]

and the fix:

http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=377239/URL]

but not the "why" it behaves the way it does so strictly.

Shift + Fn isn't new though
It is for being the actual keys, label and all.
I don't think we need to go that far. It's not too demanding to remember Shift + Fn + ; or [ or - coincide with : and { and _ symbols David. 
 
Last edited by a moderator:
You know that I already explained what is happening with the mapping and that I have a fix for Qemu. It's lost somewhere in one of the many keyboard thread...
Of course:  :) http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=376967/URL]


and the fix:

http://boards.openpandora.org/topic/17881-its-the-keyboard-layout/?p=377239/URL]


but not the "why" it behaves the way it does so strictly.


I don't think we need to go that far. It's not too demanding to remember Shift + Fn + ; or [ or - coincide with : and { and _ symbols David.
Oh, I though I had.

Ok, here is a short one.

Take a regular PC with a US keyboard. To make a ":", you press Shift and ";"

The point here is, there is no physical key ":", but only a ";" and a shift.

In an emulated system, with no specific keyboard driver, you have US Qwerty driver loaded, that also expect a ";" to be the combination of ":" and a shift.

On the Pandora, to get ";", you press Fn-",". And you have a physical key ";"

But that doesn't exist on a US-Keyboard, so you get a weird behavour because it expect a US Qwerty to be connected.

So, either you write a specific keyb driver or you hack the emulator.

This is what I have done. In case of the user pressed ":", I transform that to shift + ";" (but then you have to handle the current shift state to avoid side effect).

Not sure it was super clear...
 
Last edited by a moderator:
I don't really understand this "DosBox compatibility" thing. There are plenty of non-US keyboards, I cannot imagine that DosBox does not work on them.
It's been an annoyance for me ever since I got my Pandora and wanted to mess around with old DOS games on it. Master of Magic works great on the Pandora BTW - at least until you need to left-click with the stylus.
Is not left-click a mouse function? Did this interfere with keyboard combinations?

This is what I have done. In case of the user pressed ";", I transform that to shift + ":" (but then you have to handle the current shift state to avoid side effect).
Maybe I'm not quite understanding, but that seems backwards, at least for a regular US keyboard, where : is shift + ;
 
Some corrections to what I just read:

First:

The Fn-key in Pandora is not HW in the sense it's function were fixed. See the kernel source for Pandora for details. The tricks done are quite hacky in nature... is stuff like this even mergable to official kernel?

files: board-omap3pandora.c, twl4030_keypad.c, gpio_keys.c

Should be unique names, so paths omitted now. I modified them all to create my keylayout. In which Fn is rightshift, so clearly not hardwired to alter scancodes!

Essentially:Fn goes down, the kernel starts faking scancodes.

Bottom line: you can make the current Fn into an AltGr and see the hilarity as it unfolds... For example, operating on the console (before starting X) is going to be.... interesting :). You need to compensate for missing scancodes at some higher-than-kernel-level.

Second:

Problem for dosbox is as described above - it interpretes symbols as keys and handles modifiers by itself, BUT actually the problem also partially has its roots in SDL... which in turn, in the Pandora implementation reads keypresses not from X, but from kernel :). So whatever fancy stuff you got in your Xmodmap SDL says pfffft and practically checks your scancode. And to see which keys are available there: /usr/include/linux/input.h around line 175. If it aint there it aint a key. I hit this early on when I made Xmodmap changes that "dosbox just ignores wtf".

Third: in no way is the dosbox keymap problem just a Pandora problem. Back in the late 80s and early 90s you did not play a flightsim unless you knew how a US layout works - most games used scancodes and happily ignored your weirdo scandinavian layout. The bigger market areas got some games localized, but not all... So it was not + and - you pressed to increase and decrease speed, it was the keys you would have pressed had your keyboard been US... Text adventures same thing. And not just PC, I remember this from some Amiga titles too. No big issue you learn to live with that once you figure it out.

A Pandora specific problem was that some symbols could not be written at all in, for example, UAE. And the root cause was the same keylayout.
 
This is what I have done. In case of the user pressed ";", I transform that to shift + ":" (but then you have to handle the current shift state to avoid side effect).
Maybe I'm not quite understanding, but that seems backwards, at least for a regular US keyboard, where : is shift + ;
Yeah sorry, I inverted symbols in the last line. I corrected my post.
 
Last edited by a moderator:
I don't really understand this "DosBox compatibility" thing. There are plenty of non-US keyboards, I cannot imagine that DosBox does not work on them.
It's been an annoyance for me ever since I got my Pandora and wanted to mess around with old DOS games on it. Master of Magic works great on the Pandora BTW - at least until you need to left-click with the stylus.
Is not left-click a mouse function? Did this interfere with keyboard combinations?
Sorry - that was me making a typo. In Master of Magic, right-mouse-click is required to manipulate a unit/city and only left click (position pointer) is available with the touchscreen. It is/was RIGHT click on the screen that was frustrating.
I was able to get around this somewhat by tapping the stylus on the screen where I wanted to right click then re-positioning my right hand to right-click using the nub.

It would be good if we could use one of the keys as a 'stylus shift' to input modified on-screen presses as right mouse.
 
Some corrections to what I just read:

First:

The Fn-key in Pandora is not HW in the sense it's function were fixed. See the kernel source for Pandora for details. The tricks done are quite hacky in nature... is stuff like this even mergable to official kernel?

files: board-omap3pandora.c, twl4030_keypad.c, gpio_keys.c

Should be unique names, so paths omitted now. I modified them all to create my keylayout. In which Fn is rightshift, so clearly not hardwired to alter scancodes!

Essentially:Fn goes down, the kernel starts faking scancodes.

Bottom line: you can make the current Fn into an AltGr and see the hilarity as it unfolds... For example, operating on the console (before starting X) is going to be.... interesting :). You need to compensate for missing scancodes at some higher-than-kernel-level.

Second:

Problem for dosbox is as described above - it interpretes symbols as keys and handles modifiers by itself, BUT actually the problem also partially has its roots in SDL... which in turn, in the Pandora implementation reads keypresses not from X, but from kernel :). So whatever fancy stuff you got in your Xmodmap SDL says pfffft and practically checks your scancode. And to see which keys are available there: /usr/include/linux/input.h around line 175. If it aint there it aint a key. I hit this early on when I made Xmodmap changes that "dosbox just ignores wtf".

Third: in no way is the dosbox keymap problem just a Pandora problem. Back in the late 80s and early 90s you did not play a flightsim unless you knew how a US layout works - most games used scancodes and happily ignored your weirdo scandinavian layout. The bigger market areas got some games localized, but not all... So it was not + and - you pressed to increase and decrease speed, it was the keys you would have pressed had your keyboard been US... Text adventures same thing. And not just PC, I remember this from some Amiga titles too. No big issue you learn to live with that once you figure it out.

A Pandora specific problem was that some symbols could not be written at all in, for example, UAE. And the root cause was the same keylayout.
Thanks for the extra background info. It appears this was "fixed" eventually though, using the same Shift + Fn method as with DOSBox on the Pandora, for UAE4all: http://repo.openpandora.org/?page=detail&app=uae4all in August 2014. 
 
Last edited by a moderator:
Some corrections to what I just read:

First:

The Fn-key in Pandora is not HW in the sense it's function were fixed. See the kernel source for Pandora for details. The tricks done are quite hacky in nature... is stuff like this even mergable to official kernel?

files: board-omap3pandora.c, twl4030_keypad.c, gpio_keys.c

Should be unique names, so paths omitted now. I modified them all to create my keylayout. In which Fn is rightshift, so clearly not hardwired to alter scancodes!

Essentially:Fn goes down, the kernel starts faking scancodes.

Bottom line: you can make the current Fn into an AltGr and see the hilarity as it unfolds... For example, operating on the console (before starting X) is going to be.... interesting :). You need to compensate for missing scancodes at some higher-than-kernel-level.

Second:

Problem for dosbox is as described above - it interpretes symbols as keys and handles modifiers by itself, BUT actually the problem also partially has its roots in SDL... which in turn, in the Pandora implementation reads keypresses not from X, but from kernel :). So whatever fancy stuff you got in your Xmodmap SDL says pfffft and practically checks your scancode. And to see which keys are available there: /usr/include/linux/input.h around line 175. If it aint there it aint a key. I hit this early on when I made Xmodmap changes that "dosbox just ignores wtf".

Third: in no way is the dosbox keymap problem just a Pandora problem. Back in the late 80s and early 90s you did not play a flightsim unless you knew how a US layout works - most games used scancodes and happily ignored your weirdo scandinavian layout. The bigger market areas got some games localized, but not all... So it was not + and - you pressed to increase and decrease speed, it was the keys you would have pressed had your keyboard been US... Text adventures same thing. And not just PC, I remember this from some Amiga titles too. No big issue you learn to live with that once you figure it out.

A Pandora specific problem was that some symbols could not be written at all in, for example, UAE. And the root cause was the same keylayout.
Thanks for the extra background info. It appears this was "fixed" eventually though, using the same Shift + Fn method as with DOSBox on the Pandora, for UAE4all: http://repo.openpandora.org/?page=detail&app=uae4all in August 2014.
I would call using unlabeled key pairs from randomly arranged root keys more of a 'work around' than a 'fix'. We, right this instance, have an opportunity to do it 'right' and as a result have the key labels on the Pyra keyboard function in DosBox (and all other applications) as they are labeled.

It isn't hard to do - simply maintain all of the key pairs from a US standard keyboard and label them as such.
 
Some corrections to what I just read:


First:


The Fn-key in Pandora is not HW in the sense it's function were fixed. See the kernel source for Pandora for details. The tricks done are quite hacky in nature... is stuff like this even mergable to official kernel?


files: board-omap3pandora.c, twl4030_keypad.c, gpio_keys.c


Should be unique names, so paths omitted now. I modified them all to create my keylayout. In which Fn is rightshift, so clearly not hardwired to alter scancodes!


Essentially:Fn goes down, the kernel starts faking scancodes.


Bottom line: you can make the current Fn into an AltGr and see the hilarity as it unfolds... For example, operating on the console (before starting X) is going to be.... interesting :). You need to compensate for missing scancodes at some higher-than-kernel-level.


Second:


Problem for dosbox is as described above - it interpretes symbols as keys and handles modifiers by itself, BUT actually the problem also partially has its roots in SDL... which in turn, in the Pandora implementation reads keypresses not from X, but from kernel :). So whatever fancy stuff you got in your Xmodmap SDL says pfffft and practically checks your scancode. And to see which keys are available there: /usr/include/linux/input.h around line 175. If it aint there it aint a key. I hit this early on when I made Xmodmap changes that "dosbox just ignores wtf".


Third: in no way is the dosbox keymap problem just a Pandora problem. Back in the late 80s and early 90s you did not play a flightsim unless you knew how a US layout works - most games used scancodes and happily ignored your weirdo scandinavian layout. The bigger market areas got some games localized, but not all... So it was not + and - you pressed to increase and decrease speed, it was the keys you would have pressed had your keyboard been US... Text adventures same thing. And not just PC, I remember this from some Amiga titles too. No big issue you learn to live with that once you figure it out.


A Pandora specific problem was that some symbols could not be written at all in, for example, UAE. And the root cause was the same keylayout.
Thanks for the extra background info. It appears this was "fixed" eventually though, using the same Shift + Fn method as with DOSBox on the Pandora, for UAE4all: http://repo.openpandora.org/?page=detail&app=uae4all in August 2014.
I would call using unlabeled key pairs from randomly arranged root keys more of a 'work around' than a 'fix'. We, right this instance, have an opportunity to do it 'right' and as a result have the key labels on the Pyra keyboard function in DosBox (and all other applications) as they are labeled.


It isn't hard to do - simply maintain all of the key pairs from a US standard keyboard and label them as such.
The problem is many people will absolutely dislike having to press Shift and Fn together every single time they want to generate a ~ _ + { } | : " or ? symbol. That's not ideal nor is circumventing this by introducing an even greater problem(...for DOSBox): putting the common numbers under a modifier combo. We also shouldn't duplicate labels for these shifted values which leaves us with recollecting the standard shifted values of a U.S. keyboard under unlabeled Shift + Fn, like I have them in my layouts.    
 
Last edited by a moderator:
Or you could have a "normal" keymap and a dosbox keymap - with a little stencil/overlay you pop over the keyboard so you can see where the dosbox keys are.


Another advantage of this you would only have one primary single unshifted symbol on each key... Making for a very clean keymat
 
I get that you really like the idea of an overlay you can put on the keyboard,  but honestly I can't see that being useful on a portable device.  I could see such a thing getting lost very quickly.

- Neelix
 
I get that you really like the idea of an overlay you can put on the keyboard,  but honestly I can't see that being useful on a portable device.  I could see such a thing getting lost very quickly.

- Neelix
One of my favorite Atari 2600 games, Star Trek, had a joystick overlay. It took but a few seconds after application before it found itself back in the packaging. 

post-3154-1074484081.jpg
 
It isn't hard to do - simply maintain all of the key pairs from a US standard keyboard and label them as such.
And for those of us playing any flight sims (try Falcon3 on default Pandora layout...) it is still just a "half way there" solution, unless you account for every 101 keys on the keyboard.Do that and you run out of keys (shorcuts to exotic symbols?-) people actually want real quick. Plus you got a layout most people run away from screaming!

Its just a matter of where you want to draw the line, but there is no right way or solution: there just aren't enough keys to emulate 101 keys properly. In dosbox you can go around this by creating keymaps per game, but I found that soooooo... counterintuitive and a burden on my memory - basically you ended up pretty much documenting what you did so you remember it a week later when you have time the next time.

And that's another thing: having several, switchable keymaps definitely did not work for me... switching between them made me press wrong keys constantly. Of course, people who use any productivity apps on dosbox or UAE are bound to be a rare and dying breed. Besides, already the Amiga is bound to have some "neat" changes anyway... it will get worse if Pyra gets a Mac emu as all three home computers had their own vision of some keys :).

So yes, we're just talking about a very marginal problem: most users are unlikely to ever notice keys do not work in an emu, simply because if a GAME requires use of a keyboard then it's not on the radar.

Later PC games suffer more from mouse control issues anyway...

For the huge majority this can be fixed with some mapper capability changes to UAE, Dosbox, etc. Then it is the problem of the maintainer - depending on his workflow and tools this is difficult or trivial. Some, like me, will then have to undo those changes every time a new version comes out. Annoying, but if there's more than a handful of us, I'm amazed. As long as source is provided that is no problem. On the Pandora there is some software which I was not able to locate source for at a glance and would therefore have to ask around (Vice, DoxBoxFancyPantsEdition) - well, I skip them and that's it then.

Its pretty much the same thing with Linux console too: how many are affected by keylayout issues that only might occur before X is started? 1 (and that's not me)?

Like implied in my earlier messages: I'm not going to vote, because I'll go my own way anyway, but my vote goes to: create a layout most people find comfortable to TYPE on, something Android and iOS users can relate to and easily use. Because they will be the ones doing the Youtube reviews of the Pyra and they don't know or care what a Gunship 2000 is ;-)...
 
Okay I'm gonna say it (at the risk of the Inquisition arriving) DosBox games hurt my eyes make my ears bleed and are usually difficult to control.


I'd far rather be playing a nice SNES game or GBA or almost any other platform - when I'm not coding.


And yes this is my particular use case but I honestly question that all the pyras out there spend as a percentage the amount of time we've given consideration to an intractable problem, for a slim use case.


As previously stated the number of key pairs are unsustainable on such a small keyboard


You cannot expect all software from a modern (none specific) app store to just work 100% out of the box - if it needs more than joystick control its going to need porting and in any case what about the CPU/GPU load?


Trying to make a keyboard do the impossible will only compromise the design in a bad way.


@saber - do keep that joystick overlay, aside its probably a collectors item, its a nice piece of history... Sorry did I just call your childhood history.. Errm.. Errr....
 
Back
Top