Open snhirsch opened 11 months ago
That would be somewhat tricky. Keep in mind that this is basically a scan code translator. So when you press F7 it sends the keycode for that; when you press a shift key it sends the keycode for shift. The converter doesn't care about the shift state when it generates the keycodes; the host driver is responsible for that aspect. While it may be that shifted function keys have no standard meaning in typical DEC products, there certainly isn't anything that prevents that from being done, at least not in systems where that processing is in software (like the DEC Pro).
Ah - ok. I definitely see your point. Didn't realize the converter held no state! But as you say that is definitely the safest and most compatible approach.
It does have some state, because it has to send "all up" when the last of the up/down keys is released, rather than the keycode for that key. But other than that the coding of the keys does not depend on shift or other modifier state.
First of all, thanks for your efforts in developing these devices. I built a USB converter and everything went quite well.
I do have a suggestion / wish-list item: Why not map Shift + Fn to F(n+10)? That's somewhat common in both the Windows and Linux ecosystems. Rather than move to the bottom right for, e.g. F17 one could just do Shift+F7. Is there a technical reason that would prevent this from working?