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.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
