Catting the VT100 Torture Test toggles Keyboard States

[ElvenSpellmaker]

Hey,

Using the VT 100 Torture test file, if I cat this file out to the terminal it does the following things:

• Toggles Num Lock off
• Toggles the state of Caps Lock (On --> Off / Off --> On)
• Toggles the state of Scroll Lock (On --> Off / Off --> On)
• All three lights briefly flash on and off a few times in the process

Attached is the test I'm using.
vt100test.txt

[mintty]

The file contains the respective escape sequences a number of times, so it's correct that mintty acts on them. No issue.

[ElvenSpellmaker]

The test isn't meant to toggle the states and it didn't do it previous versions of mintty, and doesn't in other terminals either.

I'm wondering if there's a sequence missed to not restore states after?

[BrianInglis]

You have leds on your keyboard? ;^>
What state do you see the leds in before the start and after the end?
There may not be save and restore key state or led commands, so things may be left in some expected state, which may not be your norm, e.g. all off, or all but num lock off.

[mintty]

The DEC sequences are defined to manipulate the LEDs only, not the state. The Windows API does not match that right away, so mintty makes additional calls to compensate for that. This used to work.
To be checked.

[mintty]

I guess the actual change of state is applied in interaction with the program, so it would need mintty to go through its idle loop in order to restore the key states properly. If you output these escape sequences in one quick bunch, that would not work, so it's also a timing issue.
Using the sequences "normally", i.e. in single instances, works. The issue can be fixed but I'm not sure whether it's worth the effort. After all, people might as well request to remove the feature altogether, because the 4 programmable LEDs of VT100 (https://vt100.net/docs/vt100-ug/chapter3.html#DECLL, https://vt100.net/docs/vt100-ug/chapter1.html#S1.1) are not really the NumLock, CapsLock, ScrollLock LEDs of modern keyboards.

[ElvenSpellmaker]

IMO I'd say if it's not possible to toggle the lights without also toggling the actual states of a modern keyboard then it might unfortunately be worth removing the feature as you mention. It's probably going to cause more problems than it's worth to be able to toggle some lights which modern keyboards don't even have.

[mintty]

@BrianInglis, your opinion or vote?

[BrianInglis]

For a demo or test, this feature is amusing.
If there are LEDs,and the LED state is independent of the keyboard state, you would not want to leave keyboard state different from that indicated by the LEDs.
If save/restore is not possible, easy, or reliable, you would probably want to ignore LED setting independent of keyboard state setting: the former should always reflect the latter; nicht wahr?

[mintty]

Aye, and that's in fact how it works (I got it wrong above).
The problem is, the respective Windows functions apply globally, while the escape sequence should affect the window only. To compensate that, mintty does some tricky things, which fail probably as described above...

[BrianInglis]

If the Windows OS, console or GUI environments do not provide native support for per-window keyboard state and automatic save/restore, the application should not, as that breaks the expected system keyboard state model, which I assume and expect is global.
If an application wants to support their own virtual keyboard states and virtual indicators a la e.g. gvim modeline, that's a better approach, but requires implementation and documentation.

[mintty]

Released 3.0.3.