Re: cygwin terminal window disrupts scroll-lock state

[Thomas Wolff <towo@towo.net>]

Am 15.09.2021 um 11:59 schrieb Eric Adams via Cygwin:
> Hi,
>
> In the last few days, I have noticed a new behavior. Activating or
> deactivating a Cygwin terminal window may change the state of my
> keyboard's scroll-lock light.
Keyboard LED management is a new feature as described in the manual 
page. The purpose is to keep the LEDs consistent with the state of the 
terminal window.

> Inside a terminal window, the keyboard scroll-lock key may not change the corresponding light.
If you assign a user-defined no-scroll or scroll-mode function to a key 
(regardless of whether it's the ScrollLock or another key), the 
ScrollLock will change accordingly.

> What I have:
> my startup icon command:  C:\cygwin64\bin\mintty.exe -i /Cygwin-Terminal.ico -
> my shell: tcsh
> my prompt:  '%m:%c3 \!> '
> my OS: Windows 10 Home / 21H1 / 19043.1237
> my keyboard: CoolerMaster Devastator II (illuminated)
>
> If I activate a terminal window, the scroll-lock light may (or may
> not) change state. If I press the scroll-lock key, the light may (or
> may not) change state.
It will be changed to the terminal state when the terminal window gets 
focus and restored to the system state when the terminal loses focus, as 
you noted below.

> Holding the key down causes the light to flicker, and on releasing the key the final state may be either on or off.
Auto-repeat may in fact confuse the state management, to be checked for 
a race condition.

> Returning focus to a windows application seems to restore the
> "desired" scroll-lock state.
>
> My observation is based on the use of the scroll-lock light to control the illumination of this keyboard.
What is your use case and how do you control the LEDs?
Anyway, if you do not wish mintty to manage the ScrollLock (or any) LED, 
try setting
ManageLEDs=3 or ManageLEDs=0

Thomas

> Thanks for your attention,
> Eric Adams.