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).
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...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.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.We'll know soon hopefully but the last tidbit on this subject(from ED) was no hardware modifier, like Fn, on the Pyra.
This post deserves to be stickied.
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.
It is for being the actual keys, label and all.
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.
Of course: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...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.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.We'll know soon hopefully but the last tidbit on this subject(from ED) was no hardware modifier, like Fn, on the Pyra.
This post deserves to be stickied.
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.
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.Of course:
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.
Is not left-click a mouse function? Did this interfere with keyboard combinations?
Maybe I'm not quite understanding, but that seems backwards, at least for a regular US keyboard, where : is shift + ;
. You need to compensate for missing scancodes at some higher-than-kernel-level.. 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".
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.
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.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
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
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.
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.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.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
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
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.
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.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.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.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
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
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.
It isn't hard to do - simply maintain all of the key pairs from a US standard keyboard and label them as such.
By "Right", is solved, your layout, does not it.
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.
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!
.
