It's the keyboard layout.

[Saber]

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. 

 

[ptitSeb]

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...

 

[szr]

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 + ;

 

[MrConfusion]

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.

 

[ptitSeb]

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.

 

[Grench]

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.

 

[Saber]

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. 

 

[Grench]

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.

 

[Saber]

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.    

 

[comradekingu]

'Right' in this instance, being fully compatible with 'consistently wrong'

 

[codifies]

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

 

[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

 

[Saber]

'Right' in this instance, being fully compatible with 'consistently wrong'

By "Right", is solved, your layout, does not it. 

 

[Saber]

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. 

 

[MrConfusion]

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 ;-)...

 

[codifies]

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....

 

[WizardStan]

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

As previously demonstrated it really is possible.

 

[MrConfusion]

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

As previously demonstrated it really is possible.

But user friendly also for those who wouldn't touch a legacy computer with a ten foot pole? Is it "logical" in their point of view? OK, wont argue further points made...

Two more aspects came to my mind:

The Majority, i.e. console gamers, are somewhat spoiled with choices in gaming devices: Android phones with or without extra controllers, Shield, Chinese junk, you name it...

In contrast, legacy computer people really have only one option at the sub-netbook level (ignoring eBay hunts for old palmtops...).

So from a business perspective the later guys are already won over and are a minority, the majority must be competed for... do the math... :-D. (And before anyone barks, I'm strictly in this minority, so "I got me rights to say so..." ;-)

Second matter: Like I've said in other threads, DOS specifically suffers from an even more pressing issue: Mousing. And this in many of the games that would have wider appeal in the eyes of people who "were not there back then". Pre mid 90s DOS games are not only difficult to control (as codifies said), but often impossible, typically exotic to navigate without having the manual.

And then those who have the manuals and all there's another issue: I hoped to use the Pandora for many games which I've since given up on and simply resumed playing in my HW DOS BOX (Pentium2, SBAWE32ISA,Roland LAPC-1 and most importantly: MOUSE --> its a very different experience imo...).

I say again: go after the crowds, solve minorities later with some hacknugly... like with the Pandora

 

[WizardStan]

But user friendly also for those who wouldn't touch a legacy computer with a ten foot pole?

Yes.

 

[_wb_]

My position/reasoning about the DosBox / US-QWERTY symbol pairs is as follows:

1. The software issues with DosBox are just software issues and can be solved.

2. Still, I think it makes sense to let the Pyra keyboard resemble one standard as closely as possible. US-QWERTY is a natural standard.

3. Shift+Meta is certainly possible (we want Shift-F-keys for example), but it is slightly less convenient than just one modifier.

4. Because of point 3, I prefer to have {}|:"?_+~<>!@#$%^&*() behind only one modifier (Shift if the unshifted key is available as a dedicated key, Meta otherwise), but because of point 2, I want the shifted symbols near the unshifted symbols so they still form pairs in a systematic way.

5. Duplicating the labels for the shifted symbols looks ugly and weird, and it feels wrong. There is nothing wrong with making Shift+/;'[]`-= produce the corresponding shifted symbols by default though.

I made yet another layout proposal in this spirit:

http://www.keyboard-layout-editor.com/#/layouts/16c6d036ba4e34ef2b8e3008c3c8cc89

(it's called "_wb_ diacritics" in the big comparison table)

The idea is that all symbols which did not get a dedicated key are on the Meta+ASDF row, and the corresponding shifted symbol is diagonally on top in the Meta+QWER row.

This layout deviates quite a bit from my other proposals in that no longer has Meta+vowels available for language-specific letters like äüö. So that's a downside. On the other hand, it has a lot of dead key diacritics (indicated with ◌ ) so you can still input accented letters in only two thumb presses. Alternatively you can set R_Alt to AltGr and have a layer available for whatever special letters you need to have in just one thumb press.

I also 'freed' the 'special' keys Backspace, Enter and Tab from Meta-symbols. I think that looks cleaner. F11 and F12 were moved to Meta+ZX (they were on Meta+Backspace and Meta+Enter), which is perhaps a bit odd, but it also means that F11 (often used to toggle full-screen) becomes a mashable key.

This proposal does not include just the standard ASCII symbols, but also all of the special symbols found on a German keyboard: § ° µ ² ³ € ß (on a French keyboard, you also have § ° µ ² € by the way). I don't really need those symbols, but it's a nice little extra feature for Germans, I guess. Perhaps they rather like to have dedicated Ü Ö Ä keys though. In the proposal as it is now, they would need to use dead diacritics for that (just like any other language), in this case Meta+" to get the dead umlaut, followed by U O or A. Dead umlaut is presumably a mashable action, although that would have to be tested.