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.
Good point. I just added a "blank keymat" option as a sanity check, and it scores incredibly well
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.
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?
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.
...Damnit, yes we can.
That is technically a thing that can be done and would solve the DosBox/QEMU compatibility issue, I think.
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.
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.
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?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.
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.
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.
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.
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.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.
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.
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.
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.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.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 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.
