LED Multicolor Keyboard Control Using Pascal Code

[Aruna]

I purchased a led multicoloured keyboard from Dollarama (Everything is a buck store) Keyboad cost $5.00 bucks. Instructions on the box said press Scroll Lock button to  turn on/Off LED.  After many key-presses and nothing lighting up I threw the keyboard away. Later on I suddenly remembered in Linux we have :

Code: Pascal  [Select][+][-]

1. /sys/class/leds/

So to confirm the scroll lock key on the keyboard was actually kaput I ran this from a root shell:

Code: Pascal  [Select][+][-]

1. root@debian:~# echo 1 > /sys/class/leds/input18::scrolllock/brightness

And voila it lit up just fine. As a learning experience I wrote a small program that controls the keyboard. This works fine. But I have a question.

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button2Click(Sender: TObject);
2. var
3.   result:Boolean;
4.   s:string;
5. begin
6.   result:=RunCommand('/bin/bash', ['-c', 'echo 0 | sudo tee /sys/class/leds/input18::scrolllock/brightness'], s); // Turn OFF
7. end;

For this to work it requires elevated priviledges (sudo) and the very first time I run it the console in the IDE says: (Screenshot is attached. )

Code: Pascal  [Select][+][-]

1. [sudo] password for aruna:

  I enter my password hit enter the keyboard lights up. From then on I can turn the keyboard led on or off at will. How can I suppress the initial one time sudo if that is possible at all?                       

[MarkMLl]

In the middle of trying to 'phone a bank... you probably need an appropriate file in /etc/udev/rules.d which can be used to set the device's owner. Much more on the Internet, if nothing else look for info on e.g. connecting a Teensy.

More later if you stay stuck.

Updated: that input18::scrolllock/brightness is at some point going to be a symlink to a real device. The ones that I've got on my system are all owned by root:root (i.e. user:group), but I'd expect a rules file to be able to either put the entire device into e.g. plugdev or to fudge the ownership of the LEDs (some distreaux appear to have an leds group for this purpose).

Once the device is in that group make sure that you're also in it (might need to logout/in to get that to take) and you should be able to control it. Don't fiddle with the input group, that's for low-level hooks as used by e.g. evtest.

MarkMLl

[Aruna]

In the middle of trying to 'phone a bank... you probably need an appropriate file in /etc/udev/rules.d which can be used to set the device's owner. Much more on the Internet, if nothing else look for info on e.g. connecting a Teensy.

You decide to help me in the middle of a call of all places the bank? This is not important, this can wait. Best focus on that banking matter :-) just a thought ok do not get mad, what if I don't want to use udev? What is wrong with fiddling with the input group?

More later if you stay stuck.

Finish that bank stuff that is important. This can wait. But much appreciated!

Updated: that input18::scrolllock/brightness is at some point going to be a symlink to a real device. The ones that I've got on my system are all owned by root:root (i.e. user:group), but I'd expect a rules file to be able to either put the entire device into e.g. plugdev or to fudge the ownership of the LEDs (some distreaux appear to have an leds group for this purpose).

Once the device is in that group make sure that you're also in it (might need to logout/in to get that to take) and you should be able to control it. Don't fiddle with the input group, that's for low-level hooks as used by e.g. evtest.

I tried pulling out the keyboard and plugging it back in a few times. Every time the input group changes. That is a new problem to try and solve through code. It does not remain static as input18 but changes each time I pull it out then plug it back in ( interesting stuff eh :-)

[MarkMLl]

You decide to help me in the middle of a call of all places the bank? This is not important, this can wait. Best focus on that banking matter :-) just a thought ok do not get mad, what if I don't want to use udev? What is wrong with fiddling with the input group?

30 minutes before they answered.

The input group is for intercepting and manipulating events, see evtest and something like mxk.

I tried pulling out the keyboard and plugging it back in a few times. Every time the input group changes. That is a new problem to try and solve through code. It does not remain static as input18 but changes each time I pull it out then plug it back in ( interesting stuff eh :-)

Yes, it would change. But find the symlink and follow it:

Code: [Select]

/sys/class/leds$ ls -l
total 0
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input0::capslock -> ../../devices/platform/i8042/serio0/input/input0/input0::capslock
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input0::numlock -> ../../devices/platform/i8042/serio0/input/input0/input0::numlock
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input0::scrolllock -> ../../devices/platform/i8042/serio0/input/input0/input0::scrolllock
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input11::capslock -> ../../devices/pci0000:00/0000:00:1c.2/0000:04:00.0/usb5/5-1/5-1.4/5-1.4.1/5-1.4.1:1.0/0003:0A5C:4502.0004/input/input11/input11::capslock
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input11::numlock -> ../../devices/pci0000:00/0000:00:1c.2/0000:04:00.0/usb5/5-1/5-1.4/5-1.4.1/5-1.4.1:1.0/0003:0A5C:4502.0004/input/input11/input11::numlock
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input11::scrolllock -> ../../devices/pci0000:00/0000:00:1c.2/0000:04:00.0/usb5/5-1/5-1.4/5-1.4.1/5-1.4.1:1.0/0003:0A5C:4502.0004/input/input11/input11::scrolllock
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input9::capslock -> ../../devices/pci0000:00/0000:00:14.0/usb2/2-5/2-5:1.0/0003:1532:0111.0002/input/input9/input9::capslock
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input9::numlock -> ../../devices/pci0000:00/0000:00:14.0/usb2/2-5/2-5:1.0/0003:1532:0111.0002/input/input9/input9::numlock
lrwxrwxrwx 1 root root 0 Aug 31 16:39 input9::scrolllock -> ../../devices/pci0000:00/0000:00:14.0/usb2/2-5/2-5:1.0/0003:1532:0111.0002/input/input9/input9::scrolllock

Somewhere in that devices...input sequence is something which a rules file could change to be owned by plugdev, or alternatively could give it mode 666 to allow anybody r/w access.

MarkMLl

[MarkMLl]

I spent a while trying to work out whether I've got anything which the kernel recognised as having a backlight, to no avail. The gamepad that I've got programmed up with Lazarus commands has LEDs but they're not under direct computer control (they indicate which profile is enabled as an internal operation), and I've got a Logitech gamer's mouse with LEDs but they're controlled using a proprietary Logitech protocol.

My IBM Model M's certainly don't have such a thing, and while I can see kernel support for its three LEDs I don't think that the USB converter implements those commands. I could possibly fiddle around with the device ownership, but am very reluctant to do that on what is basically my #1 business computer that I use to respond to customer problems.

MarkMLl

[Guva]

I was trying to do LED control on the keyboard. but in the end I gave up on it. And I just wrote a small program to turn on the backlight.
But it only works for x11. It doesn't work for wayland.

https://github.com/GuvaCode/LedKey

[MarkMLl]

I was trying to do LED control on the keyboard. but in the end I gave up on it. And I just wrote a small program to turn on the backlight.
But it only works for x11. It doesn't work for wayland.

https://github.com/GuvaCode/LedKey

The important thing that you're not telling us is that you're using xset to do it rather than going in at the kernel level (which would bypass X11, Wayland etc.).

MarkMLl

[Aruna]

I spent a while trying to work out whether I've got anything which the kernel recognised as having a backlight, to no avail.

Am sure you already tried :

Code: Pascal  [Select][+][-]

1. /sys/class/backlight

[Aruna]

I was trying to do LED control on the keyboard.

If you run:

Code: Pascal  [Select][+][-]

1. aruna@debian:~$ ls -1 /sys/class/leds
2. input1::capslock
3. input1::numlock
4. input1::scrolllock
5. input5::capslock
6. input5::compose
7. input5::kana
8. input5::numlock
9. input5::scrolllock
10. aruna@debian:~$
11.  

That is my system above and what I want is the:
 

Code: Pascal  [Select][+][-]

1. input1::capslock
2. input1::numlock
3. input1::scrolllock

You can control each led by doing, say you want CapsLock:

Code: Pascal  [Select][+][-]

1. sudo echo 1 > /sys/class/leds/input1::capslock/brightness

echoing 1 will turn on the led and to turn it off:

Code: Pascal  [Select][+][-]

1. sudo echo 0 > /sys/class/leds/input1::capslock/brightness

You can query the current status of any keyboard led by:

Code: Pascal  [Select][+][-]

1. aruna@debian:~$ cat /sys/class/leds/input1::capslock/brightness
2. 0

Which shows me at that time Capslock led was off.

[MarkMLl]

Am sure you already tried :

Code: Pascal  [Select][+][-]

1. /sys/class/backlight

Empty on my system, and I believe it's intended for LCD backlights on (originally) PDAs etc.

The interesting thing about using xset is that it talks to the (strictly, an) X11 server which is running as root. Hence I think an xref is in order to https://forum.lazarus.freepascal.org/index.php/topic,68389.msg529223.html#msg529223 which is about doing "clever things" via the X11 API (in this specific case, moving windows between workspaces).

MarkMLl

[Aruna]

Am sure you already tried :

Code: Pascal  [Select][+][-]

1. /sys/class/backlight

Empty on my system, and I believe it's intended for LCD backlights on (originally) PDAs etc.

Yes, empty on my desktop too. Let me find my lap-top and double check ...

The interesting thing about using xset is that it talks to the (strictly, an) X11 server which is running as root. Hence I think an xref is in order to https://forum.lazarus.freepascal.org/index.php/topic,68389.msg529223.html#msg529223 which is about doing "clever things" via the X11 API (in this specific case, moving windows between workspaces).

And if you scroll down a bit you will see somoen you know testing that move window between workspaces 

[MarkMLl]

And if you scroll down a bit you will see somoen you know testing that move window between workspaces 

Yes, but I'm trying to make sure that the threads are cross-referenced for anybody who gets here via Google etc. Also if controlling the LED uses xset then I think it's worth making the point explicitly in this thread that the other one's probably relevant (for the same reason).

Using X11 does, of course, assume that X11 is running and that the user has an authentication token for the main-console server (I vaguely remember having to handle a file for that in the context of Docker containers).

And if using X11 to manipulate a keyboard you also have to consider that you can have remote connections, at which point many of the same considerations apply as generating sound (PCM, MIDI etc.) for a remotely-connected application program.

MarkMLl