It's the keyboard layout.

[_wb_]

So does this also mean that DosBox can only work correctly if we have a hardware Fn modifier then?

I thought it was agreed that we would have to have at least a quasi-hardware Fn modifier, even beyond just DosBox compatibility, for a lot of technical reasons. Do we need a new thread to discuss the pros and cons and solutions to problems?

What is a "quasi-hardware" Fn modifier?

I thought we agreed that we wanted Fn/Meta/whatever on a shoulder button, which means that its key events should be visible. Is that what you mean by "quasi-hardware"?

Here is one more proposal: ("_wb_ 3b" in the big matrix)

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

It does not have Shift+Meta keys explicitly labeled, but the idea is that e.g. both Shift+Meta+V and Meta+G produce the { symbol.

The Shift+Meta labels are not printed, but they are easy to remember because the shifted symbol key is above the primary symbol key (except for `~ and \|, where the shifted symbol is to the right). So it is, in a sense, "mnemonically optimized" for DosBox.

Would that be good enough for the DosBox people?

 

[WizardStan]

Is that what you mean by "quasi-hardware"?

Yes, a modifier that still produces a key code but also produces the keycode of the modified key, not the original. Like, pressing "fn"+"1" will give the "fn" keycode and the "f1" keycode, it doesn't give the "1" keycode. Most things will simply ignore this "fn" (or meta, sym, whatever) keycode.A pure software modifier would give "fn" and "1" while a pure hardware modifier would simply give "F1". I thought we agreed we needed something in between, an Fn modifier that just "does the right thing".

 

[_wb_]

Is that what you mean by "quasi-hardware"?

Yes, a modifier that still produces a key code but also produces the keycode of the modified key, not the original. Like, pressing "fn"+"1" will give the "fn" keycode and the "f1" keycode, it doesn't give the "1" keycode. Most things will simply ignore this "fn" (or meta, sym, whatever) keycode.
A pure software modifier would give "fn" and "1" while a pure hardware modifier would simply give "F1". I thought we agreed we needed something in between, an Fn modifier that just "does the right thing".

Yes, I agree. I just wasn't sure about the terminology.

But can't we have a quasi-hardware modifier that "does the right thing" so that if you press the key corresponding to e.g. '?' (which could e.g. be at Meta+X), then it actually gives the "/" scancode with the shift bit set to 1, and the "?" keycode, in a way emulating a full keyboard? (and it would also send an "R_Meta" or "L_Meta" keycode, which would be ignored by most things).

Maybe I don't understand well enough how keyboard input actually works, or maybe I'm using the wrong words here. But can't we somehow solve the "DosBox problem" in software, instead of having to design the keyboard in a way that avoids the problem?

 

[WizardStan]

But can't we have a quasi-hardware modifier that "does the right thing" so that if you press the key corresponding to e.g. '?' (which could e.g. be at Meta+X), then it actually gives the "/" scancode with the shift bit set to 1, and the "?" keycode, in a way emulating a full keyboard? (and it would also send an "R_Meta" or "L_Meta" keycode, which would be ignored by most things).

...Damnit, yes we can. That is technically a thing that can be done and would solve the DosBox/QEMU compatibility issue, I think.

 

[codifies]

"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)

 

[WizardStan]

"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)

It's not just DosBox, that's just the big example. If we went with a straight software modifier like you're proposing then we would need to do a LOT of software changes.The DosBox compatibility discussion is a tack-on for ease of use, since we need to modify the keyboard anyway may as well make things easier.

Even removing DosBox from the picture entirely, having seen and considered Grench's layout, I'd still be championing Fn-Shift combos on the keyboard, so your argument doesn't really have any baring for at least some of us.

 

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

 

[Grench]

I don't have time to look at anything today. Arrived home from a 4 day festival, 6 days away from home... to find my mother had unplugged the ice cream freezer when packing one of the multiplugs... and our entire stock we had built up for while she's oversees for the next 5 weeks had melted.

So.

...

I will be busy today.



...

But I don't mind if numbers are on the fn layer, with dedicated symbols... I think such easy access would be fantastic. As long as fn is sticky.

Sorry to hear about your lost ice cream. That has to be a sticky mess to clean up. Maybe tie a red ribbon to each of the freezer plugs as a reminder that it's a bad idea to unplug them?

Thank you for the comment on the numbers on Fn layer. It frees up a lot of good things. I envision the behavior of the Fn key to be software configurable between sticky, Fn+Fn=Fnlock and non-sticky-nonlocking. By having the numbers and the F1-F12 keys both on the Fn layer with Fn+Fn=Fnlock, it means that games can have ready access to those for mapped functions while still being able to 'un-Fn-Lock' during game to access the keyboard for in-game communications. I envision the Pyra as a potential multi-player FPS and MMORPG client, and this functionality would be awesome.

 

[Grench]

"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)

It's not just DosBox, that's just the big example. If we went with a straight software modifier like you're proposing then we would need to do a LOT of software changes.The DosBox compatibility discussion is a tack-on for ease of use, since we need to modify the keyboard anyway may as well make things easier.

Even removing DosBox from the picture entirely, having seen and considered Grench's layout, I'd still be championing Fn-Shift combos on the keyboard, so your argument doesn't really have any baring for at least some of us.

 

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.

 

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

 

[WizardStan]

We'll know soon hopefully but the last tidbit on this subject(from ED) was no hardware modifier, like Fn, on the Pyra.

ED can want a lot of things, and he's managed to accomplish many of them, but he's frequently come to the community for their suggestions because he doesn't have the technical knowledge to put it together all by himself, and sometimes the community is going to push back with "bad idea" or sometimes even "not physically possible". He doesn't want a hardware modifier but so far there hasn't been anyone with a solution that didn't require it to act as one without breaking a lot of stuff.If you think it can be done, to have it be a pure software modifier as per shift or AltGr, then by all means explain how.

 

[Grench]

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.

Not really. The Pandora/Pyra are portable devices. We cannot assume that the end user has memorized let alone has access to or ever seen a US standard keyboard layout to look up symbol pairs on to figure out which key ~_+{}|:"<>? are mapped to on an unlabeled 4th layer.

 

[WizardStan]

We know there is an issue but does anyone actually know the "why" DOSBox and QEMU misinterpret?

Yes. It's because it's low level, checking key presses and flags, not characters. It was effectively solved in QEMU a long time ago and could easily be solved for DosBox as well.

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

Having seen it now and considered it hard, I actually think the Fn+shift is a good idea for a lot of reasons, perhaps the least of which is easy x86 emulation. It gives us more keys to play with, and works on muscle memory that has been developed over decades of use.

 

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

Not really. The Pandora/Pyra are portable devices. We cannot assume that the end user has memorized let alone has access to or ever seen a US standard keyboard layout to look up symbol pairs on to figure out which key ~_+{}|:"<>? are mapped to on an unlabeled 4th layer.

Well as I've said, ED last I heard nixed the hardware modifier. The U.S. standard seems to be the base he'll appropriate for the Pyra which syncs with our shifted + Fn values in our layouts. As long as users can recall where Colon and Underscore are on this level, it shouldn't haggard them too much.   

We know there is an issue but does anyone actually know the "why" DOSBox and QEMU misinterpret?

Yes. It's because it's low level, checking key presses and flags, not characters. It was effectively solved in QEMU a long time ago and could easily be solved for DosBox as well.

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

Having seen it now and considered it hard, I actually think the Fn+shift is a good idea for a lot of reasons, perhaps the least of which is easy x86 emulation. It gives us more keys to play with, and works on muscle memory that has been developed over decades of use.

It worked alright on the Pandora and with a little extra muscle it should work okay on the Pyra. 

 

[WizardStan]

It worked alright on the Pandora and with a little extra muscle it should work okay on the Pyra.

If it worked "alright" enough then we wouldn't even be having this discussion. It's quite obvious that the Pandora keyboard was far from perfect hence the number of people so keen to improve it. I've put forth arguments why I think utilizing the shift+fn combo is an improvement.

 

[Saber]

It worked alright on the Pandora and with a little extra muscle it should work okay on the Pyra.

If it worked "alright" enough then we wouldn't even be having this discussion. It's quite obvious that the Pandora keyboard was far from perfect hence the number of people so keen to improve it. I've put forth arguments why I think utilizing the shift+fn combo is an improvement.

Shift + Fn isn't new though:

*cough* http://pandorawiki.org/DOSBox#Keyboard *cough"

 

[_wb_]

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

 

[Saber]

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

 

[ptitSeb]

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

 

[WizardStan]

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.