B
bored with dosbox
Guest
Maybe this shows the actual interest in obsolete difficult to use software, especially where there are much better more playable retro experiences to be had....
It's the keyboard layout.
- Thread starter Silent-Hunter
- Start date
pmprog
DNF (Did Not Finish)
- Joined
- Apr 25, 2011
- Messages
- 4,150
I'm not reading all these posts, there's way too many. Anyway, this one I think looks pretty good, but I have a suggestion regarding the compositor key.
Instead of Meta+Enter, why not move the two Brightness keys onto the same:
Brightness: Brightness Up
Shift+Brightness: Brightness Down
Meta+Brightness: F11
Composite: Composite
Meta+Composite: F12
Won't having a dedicated composite key appeal to the diacritic crowd? Also, the brightness is rarely adjusted in such a manner that it requires two dedicated keys IMO
Edit: Fixed my really shocking grammer and made things a bit clearer
Last edited by a moderator:
Neelix
Insecticidal Maniac
Except that there are two separate brightness settings to be adjusted, Keyboard backlight and LCD backlight.
- Neelix
- Neelix
MrConfusion
Very Active Member
- Joined
- Apr 11, 2013
- Messages
- 331
(
Wait, wait, wait, I remember this game... I can still play too... /me clears his throat and builds up a really trolly snarl...
"So, lets just leave out the keyboard entirely then? After all those "oh so very playable" console games never needed one, eh (after all, games targeted at 10 year olds can hardly place high demands on... well, anything really?-). I'll take Wasteland over you Zelda anytime, yeah?"
"Oh yeah?"
"YEAH!"
"OH YEAH?!"
*fisttime!*
)
Oh the glory days of computers vs. consoles... takes me back to the schoolyard... Lets do Amiga vs. Atari next...
So much for the fun, now I'll try to explain the DOSBox problem and I assume QEMU suffers from the same:
Assume you got symbol ~. That's keycode 49, state 0x1 (0x1 meaning SHIFT is down).
Then you got symbol `. That's keycode 49 (YES, SAME), state 0x0 (meaning no SHIFT).
With me so far? Fear not, you soon won't be ;-).
So, keycode and state are interpreted by X to mean a character, this is called a keySYM, instead of "code". You can tell X to map CODES to whatever SYM you want, like ½ instead of ~ like in some international keyboards. So, depending on your mapping keySYM for keyCODE 49 with SHIFT can be ½. Or it can be ~ like in the US.
Whatever, in this example we now got ~ from X.
Apps can use either keySYMs (portable across platforms) or keycodes (you pretty much need to know the target platforms, they're not as arbitrary as they seem, but still are).
Most apps use keySYMs for the obvious reason of portability.
So that ~ is passed to SDL, then to DOSBox (in the Pandora, SDL actually does the keycode-->~ mapping, but I'm "guessing" how it might go in Pyra, so...).
DOSBox checks that the keySYM ~ is mapped to a PCkeyCODE in a PC... in a PC that SYM is mapped... tada: nowhere (by default). So let's ignore it, such a key does not exist in the US layout which is used as a "base" in DOSbox! Similarly ½ does not exist --> ignore it.
However, keySYM "`" would be mapped to PCkeyCODE 41 (<-- note, DOS has different numbering from X). The keymapper can be used to do more such mappings: You can map a XkeySYM to mean a PCkeyCODE. PCkeyCODEs always represent a BUTTON, not symbol.
So, DOSBox passes the PCkeyCODE 41 to DOS, which then looks what DOS character that CODE should be mapped to. In the US it produces a `... except if, at the same time, DOSBox tells DOS SHIFT is down, in which case it produces a ~.
OR, no matter what nationality you have set X to, if you have loaded a SW keymap in DOS, then SHIFT+` produces a ½!!!
If this is not confusing enough, you can also set ~ to mean the `-key. Then pressing the Fn combination for ~ will produce `, and pressing shift-Fn-~ will produce ~. But because DOSBox only allows you to map unaltered keys (no shift, no alt, etc.), you CANNOT MAP ~ to directly be SHIFT-` in DOSBox. Not with the existing mapper.
So, Comradekingu, you say, "fix DOSbox". That's just it: What _exactly_ is the better mechanism for this in your opinion? If you can't code it, then at least specify it, technically? Simply saying "so it produces the symbol I happen to want" is not specs. Where do you want the surgery done, where can it be without causing trouble? DOSBox is actually easy - full source. How about QEMU? Load DOS in that - the DOS layer is now closed source! Definitely no surgery there? Code a custom Win3.1 kbd-driver? In this day and age? Oh please...
The only way to fix this that I know of, is what has been done on the Pandora: Make the keySYM ~ produce a "Shift down + `" in DOSbox. That's not issueless. Lesser problem: what if the user is pressing the SHIFT trigger down at the same time? Is that then a `? Bigger problem: after you've laboriously encoded the whole ****ing keyboard into DOSBox, what happens? Someone loads the SW keymap. And suddenly your ~ is a ½ and everything else is completely messed up too, because now you really have to deal with not just doubleshifts, but also doublealtgrs. Once again keys on Pandora keyboard have different symbols from what appears on screen.
The DOSBox team cannot fix this either: it is a PC emulator. It HAS to emulate keyboard buttons, not letters!
And that messed up "fix" is supposing you got the inclination to waste your time on something as boring as remapping keys, while at the same time there are more technically INTERESTING challenges to take. No, what happens is pretty much what happened to me: I fixed this issue by switching the device to a keyboard layout that is fully PC101 compatible... Pretty much only numbers and QWERTY now do what they say on my Pandora.
And then I proceeded to the interesting bits: boxed joystick (PC joysticks are not "circles", they are "boxes" - fix in SDL), pan following mouse cursor at 800x640 resolution (playing original Wonderland is cool now). And so on. It's not like the Pandora devs are actually PAID for their work, so the work has to have some mental arithmetic to it. Creating doubleshift-maps for every keycombination is anything but. And here's the kicker: because I've totally diverted from Saxxon env. pretty much nothing I've done for myself is easily transferrable to Saxxon now, even if someone wanted to spoon the puke I call code for the useful bits...
Rant done, long DOSbox explanation given, proceed
.
ible
professional vim user
I've trimmed down my "final keyboard proposal" list to three, though they all come from some base layout (ible 3). The first one is my take on _wb_'s international layout. The second one is most "Saber" compliant, if ED wants two keyboard shifts and only hardware buttons up top. The third one allows some non-hardware buttons up top (Dedicated Esc and some extra mouse buttons).
- [Main proposal][ible 3 intl new: /? and \| paired up]http://www.keyboard-layout-editor.com/#/layouts/81113d4bd6bfadaa66dd9e913025ed7c
- [ible 3 squared: two keyboard shifts like Saber]http://www.keyboard-layout-editor.com/#/layouts/89c144f2541d0f15af6d627bc9e6ae74
I've manuevered ` ' and " next to each-other, which presumably would be dead keys with shift, so that it's quicker to combo e.g. é and è.
- [ible 3 intl new soft -- with software buttons up top (dedicated Esc)]http://www.keyboard-layout-editor.com/#/layouts/5d15be6cd1e9c0a7d76a7d3f223a1743
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
What about us non-DosBox-users that still think maintaining shift pairs is a good idea? Where's my apology?
About 20 pages back, ptitSeb described how he "fixed Qemu" (see quote below). Exactly the same thing can be done for DOSBox. I don't know if it has already been done or not, but it can be done. Not using the built-in keymapper tool in DOSBox though, so it'll take some effort. But if it can be done for Qemu, then it can also be done for DOSBox.
It could probably even be done in general, e.g. at the level of SDL or some kind of "keyboard event transformation daemon". Possibly xkb can be configured to do just this, I don't know. Something like "translate Meta+P (which could be labeled as "+" on the Pyra) to Shift+=", and so on. "US-QWERTY compatibility mode" it could be called, and it would of course be useful.
It could probably even be done in general, e.g. at the level of SDL or some kind of "keyboard event transformation daemon". Possibly xkb can be configured to do just this, I don't know. Something like "translate Meta+P (which could be labeled as "+" on the Pyra) to Shift+=", and so on. "US-QWERTY compatibility mode" it could be called, and it would of course be useful.
Oh, I though I had.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.
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:
A dedicated compose key would not really be necessary since almost everything is already covered by more efficient dead diacritics.
For shoulder modifier people, Meta+Enter is probably more efficient than reaching for a key up top.
I don't want to label the Compose key explicitly, so you can easily move it to where you like it. E.g. I personally like to put Compose at the right Windows logo (Super) key, or on a laptop that doesn't have two Super keys, I put it at R_Alt or R_Ctrl (depending on whether I want to use AltGr or not).
On the Pyra, I would probably not use keyboard Meta and keyboard Shift much (shoulder buttons are more efficient), so if I would want an efficient Compose key, I would probably put it on keyboard Meta or Shift.
But again, there is little need for an efficient Compose key if all of these are already covered by dead diacritics, so they can be done in two thumb presses (accent + letter) instead of three (Compose + symbol + letter) :
Last edited by a moderator:
MrConfusion
Very Active Member
- Joined
- Apr 11, 2013
- Messages
- 331
Same problem, same solution I described.
Like I mentioned, I find that fix tedious to do, but of course that's SomebodyElse'sProblem
.With Windows (QEmu on Pyra would pretty much spell "Windows" in my book) the solution would also practically have to support national keymaps, which means several translations and configuration. I'm almost positive someone will have other things than games in their mind for a Win95 onwards emu...
Externalizing this to, for example, xkb or some other "wrapper" is an interesting idea. Shift-handling might pose a problem then, though.
In DOSbox the keymapper will behave funny, but it won't die from this even if left alone
.I personally like it when I can just compile-and-go pretty much anything, and the Pyra will have the muscle for that far better than the Pandora. So, it's lucky that thanks to the Pyra being OSS, people can map their own maps just like with the Pandora --> those who want the US101 keypairs can have them, just not printed on the plastic.
I don't know what “Je ne sais quoi” you are talking about
, but would this one have more of it?http://www.keyboard-layout-editor.com/#/layouts/3c7ff5578e7325fd028bb40837ae7cda
It is an attempt at improving the one you like.
Rationale for the Meta-layer:
- all diacritics and punctuation symbols needed for normal language (and simple command line stuff) are on the left
- , < . > / ? ; : ' " are all on their 'normal' row, but 'wrapped around' to the left because there was no room on the right; they are also not far from their Pandora positions (though now ' " is a dedicated key, and ; : are not on , . anymore because I want those four dead diacritics there
- - + are on D F like on the Pandora
- = between - and +, which semantically makes sense
- ° and € are not on US-QWERTY but they are "upgraded" to the status of "real" symbols (with a full-size label and in an expected location) because they are not language-specific. Even Americans may want to talk about temperatures and angles.
- on the right hand side (not very efficient if you don't use shoulder meta) are the symbols typically used only for coding, or at least not often used in normal natural language. They are arranged in a pattern below the regular brackets: ( )
{ | }
[ ]
This arrangement looks nice and symmetric, and it also makes a bit of sense because of set-builder notation {x | foo } and for Prolog lists of the form [ H | T ]. But if people don't like that, the { | } could also be { } |, which is closer to US-QWERTY.
- the middle section (TYU GHJ CVBN) is used for the German/French/Spanish letters
And here is another one:
http://www.keyboard-layout-editor.com/#/layouts/cf1d0dac652fba14eaeca6898e6b8244
You can call it "the HÖJÄKÈLÀ" layout if you want.
Here is its MES-1 coverage chart: https://docs.google.com/spreadsheets/d/1nheonihrk9vZkKvZiKUt1dv9NCVKv3YV33hR01troys/edit?usp=sharing
Features:
(closer to US-QWERTY)
http://www.keyboard-layout-editor.com/#/layouts/cf1d0dac652fba14eaeca6898e6b8244
You can call it "the HÖJÄKÈLÀ" layout if you want.
Here is its MES-1 coverage chart: https://docs.google.com/spreadsheets/d/1nheonihrk9vZkKvZiKUt1dv9NCVKv3YV33hR01troys/edit?usp=sharing
Features:
- All of the ASCII stuff is on the left now (opposite keyboard Meta), except for underscore _ which is still a mashable combo at Meta+Space.
- üöä still under U, çèà near their Canadian positions
- added µ and £, so now all the symbols you would find on a German or French keyboard are labeled
- § at Shift+µ and £ at Shift+€, it adds some clutter though
(closer to US-QWERTY)
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
Thank you for that explanation. I wasn't fully aware of the exact mechanisms involved, but it sounds like I have a good understanding of the effect that it had on the Pandora and why it would remain an issue on the Pyra if we don't pair the symbols appropriately.( Wait, wait, wait, I remember this game... I can still play too... /me clears his throat and builds up a really trolly snarl...
"So, lets just leave out the keyboard entirely then? After all those "oh so very playable" console games never needed one, eh (after all, games targeted at 10 year olds can hardly place high demands on... well, anything really?-). I'll take Wasteland over you Zelda anytime, yeah?"
"Oh yeah?"
"YEAH!"
"OH YEAH?!"
*fisttime!*
)
Oh the glory days of computers vs. consoles... takes me back to the schoolyard... Lets do Amiga vs. Atari next...
So much for the fun, now I'll try to explain the DOSBox problem and I assume QEMU suffers from the same:
Assume you got symbol ~. That's keycode 49, state 0x1 (0x1 meaning SHIFT is down).
Then you got symbol `. That's keycode 49 (YES, SAME), state 0x0 (meaning no SHIFT).
With me so far? Fear not, you soon won't be ;-).
So, keycode and state are interpreted by X to mean a character, this is called a keySYM, instead of "code". You can tell X to map CODES to whatever SYM you want, like ½ instead of ~ like in some international keyboards. So, depending on your mapping keySYM for keyCODE 49 with SHIFT can be ½. Or it can be ~ like in the US.
Whatever, in this example we now got ~ from X.
Apps can use either keySYMs (portable across platforms) or keycodes (you pretty much need to know the target platforms, they're not as arbitrary as they seem, but still are).
Most apps use keySYMs for the obvious reason of portability.
So that ~ is passed to SDL, then to DOSBox (in the Pandora, SDL actually does the keycode-->~ mapping, but I'm "guessing" how it might go in Pyra, so...).
DOSBox checks that the keySYM ~ is mapped to a PCkeyCODE in a PC... in a PC that SYM is mapped... tada: nowhere (by default). So let's ignore it, such a key does not exist in the US layout which is used as a "base" in DOSbox! Similarly ½ does not exist --> ignore it.
However, keySYM "`" would be mapped to PCkeyCODE 41 (<-- note, DOS has different numbering from X). The keymapper can be used to do more such mappings: You can map a XkeySYM to mean a PCkeyCODE. PCkeyCODEs always represent a BUTTON, not symbol.
So, DOSBox passes the PCkeyCODE 41 to DOS, which then looks what DOS character that CODE should be mapped to. In the US it produces a `... except if, at the same time, DOSBox tells DOS SHIFT is down, in which case it produces a ~.
OR, no matter what nationality you have set X to, if you have loaded a SW keymap in DOS, then SHIFT+` produces a ½!!!
If this is not confusing enough, you can also set ~ to mean the `-key. Then pressing the Fn combination for ~ will produce `, and pressing shift-Fn-~ will produce ~. But because DOSBox only allows you to map unaltered keys (no shift, no alt, etc.), you CANNOT MAP ~ to directly be SHIFT-` in DOSBox. Not with the existing mapper.
So, Comradekingu, you say, "fix DOSbox". That's just it: What _exactly_ is the better mechanism for this in your opinion? If you can't code it, then at least specify it, technically? Simply saying "so it produces the symbol I happen to want" is not specs. Where do you want the surgery done, where can it be without causing trouble? DOSBox is actually easy - full source. How about QEMU? Load DOS in that - the DOS layer is now closed source! Definitely no surgery there? Code a custom Win3.1 kbd-driver? In this day and age? Oh please...
The only way to fix this that I know of, is what has been done on the Pandora: Make the keySYM ~ produce a "Shift down + `" in DOSbox. That's not issueless. Lesser problem: what if the user is pressing the SHIFT trigger down at the same time? Is that then a `? Bigger problem: after you've laboriously encoded the whole ****ing keyboard into DOSBox, what happens? Someone loads the SW keymap. And suddenly your ~ is a ½ and everything else is completely messed up too, because now you really have to deal with not just doubleshifts, but also doublealtgrs. Once again keys on Pandora keyboard have different symbols from what appears on screen.
The DOSBox team cannot fix this either: it is a PC emulator. It HAS to emulate keyboard buttons, not letters!
And that messed up "fix" is supposing you got the inclination to waste your time on something as boring as remapping keys, while at the same time there are more technically INTERESTING challenges to take. No, what happens is pretty much what happened to me: I fixed this issue by switching the device to a keyboard layout that is fully PC101 compatible... Pretty much only numbers and QWERTY now do what they say on my Pandora.
And then I proceeded to the interesting bits: boxed joystick (PC joysticks are not "circles", they are "boxes" - fix in SDL), pan following mouse cursor at 800x640 resolution (playing original Wonderland is cool now). And so on. It's not like the Pandora devs are actually PAID for their work, so the work has to have some mental arithmetic to it. Creating doubleshift-maps for every keycombination is anything but. And here's the kicker: because I've totally diverted from Saxxon env. pretty much nothing I've done for myself is easily transferrable to Saxxon now, even if someone wanted to spoon the puke I call code for the useful bits...
Rant done, long DOSbox explanation given, proceed
If we were to maintain key pairs from a US standard English layout, would it 'solve' the problem? It's admittedly more of a work-around. But would the symbols on the keyboard at least match what DosBox shows on the screen when a shift+`=~ is called for by the end user?
I'm sorry. I had overlooked that very basic aspect in voicing my concerns for this feature. Clearly you're right. Keeping the key pairs increases usability for English users as the shifted keys are paired with their root key and that will make them easier to find.
MrConfusion
Very Active Member
- Joined
- Apr 11, 2013
- Messages
- 331
Yes, for users of US keyboard layout... Switch DOSbox to swedish map to get öäå and you're out in the wild woods again, because now when you press ~ on the Pandora, you get ½ onscreen. Then again, if DOSbox is properly adapted to support a Pyra keylayout, then § has to be in the layout proposal if you want to use SW map in DOSbox (unless you do real nasties...), because in SW keyboard § is code 49 unshifted.
So things are really not straightforward at all when you want intl to properly work.
In the end, I personally feel this is not a problem on DOSbox, or DOS in general, because people won't be using either for anything requiring those yucky international symbols. Many (most?) games never supported anything other than US keycodes. Their manuals, keyboard overlays, etc. always assumed the US keyboard! So people with intl keyboards lived with it and that was that.
Therefore: if emulated US101-support is enough, then yes: The paired symbols are a working fix.
But... (hey, it's "Confusion", OK, there has to be a "but"?) if you need to use any of the internationalization features of emulated OSs... then not even that pairing will do: coding is basically required and it can get both ugly and complex. Don't forget that the use case and "basis" for doing this locale switch on a normal PC would be switching the physical keyboard to non-US! You don't do that on a Pandora. Even here, having US101 helps, because you got most symbols where you can figure them out. But you definitely stop getting the symbols you press on the plastic.
Ignoring DOS, Windows really is another matter. I gave this some thought today after I wrote The Blurb and it just "hit me" that Windows might even run almost conveniently on the Pyra.
No, sorry, I didn't perceive it as such on the Pandora...
Assuming some software I purchased in the early 2000s could be run (currently on my laptop) I might even have use for inputting names with öäå occasionally...
So, from this point of view: If someone would take the task to "just fix qemu and dosbox properly by adding a configurable extra layer to keymapping", I'd be really grateful (assuming they put the sources somewhere). And having a (from my point of view) totally messed up non-symbol-paired keyboard is a great way to push things in that direction :-D.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
So, two ways to make it work.
One:
Requires that we pair keyboard symbols in the US101 fashion and should be effective out of the box at 8 AM day 1 for the vast majority of the likely use cases.
Two:
The other means that we're deliberately going to break compatibility with this usage in order to try to force someone somewhere to be named later to invent a very time consuming and tedious to implement fix that might work for most applications.
To me, option one feels far more likely to work.
comradekingu
Glowing ember
There arent enough keys to do US-international language-modifcators in that fashion, meaning less people will have an expected way to type letters. Resulting in less language support.
Similarly, there arent enough keys to put the US pairs _not_ on thirdlevelshift numbers, meaning you end up with symbols on the letters.
Language and visuals is important to huge groups.
Similarly, there arent enough keys to put the US pairs _not_ on thirdlevelshift numbers, meaning you end up with symbols on the letters.
Language and visuals is important to huge groups.
Eight Bit
Hardcore Member
I noticed some mistakes in my "mother knows best" layout, I think it's okay now and I have put it in the final keyboard proposals thread.
http://www.keyboard-layout-editor.com/#/layouts/2112c814f58ee6efe94dca5a3fed34db
Language specific letters (German and French) are on- or near the keys where they are expected by german or french keyboard users.
All US standard symbols are on there as well as some extra diacritics, which should be useful for other languages too.
http://www.keyboard-layout-editor.com/#/layouts/2112c814f58ee6efe94dca5a3fed34db
Language specific letters (German and French) are on- or near the keys where they are expected by german or french keyboard users.
All US standard symbols are on there as well as some extra diacritics, which should be useful for other languages too.
I like this out-of-the-box thinking of your mother: it's an original way to combine English, German and French.
So it does make sense, in a way, but in another way, I think it will be weird for a French speaker who is used to AZERTY to find éèàç exactly where they should be (behind Meta though), but still have QW where AZ should be and M in the wrong place. I think they might experience a kind of 'uncanny valley' phenomenon: they might experience more trouble switching between the Pyra and the other keyboards they use, because they are 'too much alike' (but still different). In that way it might be better to deviate more from the French layout as used in France, and go more in the direction of the Canadian French layout:
Other than that, I think that if you're going to sacrifice the Meta+numberrow F-keys, then you should put F11 and F12 at P and Enter.
Also the æ, œ and ù are not very useful in my opinion -- no Scandinavian can type with æ alone, and œ can be safely delegated to Compose key for French. The ù is only used in one French word (ok, it's an important one, but still), so needing two thumb presses (grave + u) is not a big problem.
Eight Bit
Hardcore Member
Thanks for the feedback, she will be staying at my place until Sunday so I'll ask her what she thinks and if she wants to put in some more effort.
Also maybe some French users can give their opinion about it?
She had some other unconventional ideas too but I figured they were too out there to get any support on this board.
Also maybe some French users can give their opinion about it?
She had some other unconventional ideas too but I figured they were too out there to get any support on this board.
Grench
Forum Addict!
- Joined
- Oct 3, 2008
- Messages
- 6,629
A few of us are not afraid of the unconventional. Let her try out the ideas. Who knows? She might stumble on something that the rest of us wouldn't have thought of.Thanks for the feedback, she will be staying at my place until Sunday so I'll ask her what she thinks and if she wants to put in some more effort.
Also maybe some French users can give their opinion about it?
She had some other unconventional ideas too but I figured they were too out there to get any support on this board.
Xcl4m4t10n
Advanced Member
- Joined
- Dec 18, 2009
- Messages
- 1,209
Ñ. .
.
