Linux Kernel Interface To Finally Allow For Programmable LED Patterns

[Tomin]

So when can I control the led on my Polaris card? I want to turn it off.

[Uqbar]

But, do we really-really need this to reside inside the kernel?
Can't that be userland?

[c117152]

it's not just pimp-my-PC nonsense. leds are often used as indicators on networking devices and the likes. Openwrt's wifitoggle package, for instance, lets you reprogram a button and turn a led on and off (via /sys/devices/platform/leds-gpio/) for the purpose of switching the wifi on/off and so on...

with this sort of in-kernel feature you'd be able to give error codes during boot using the leds. like, designate "corrupted file system" as a certain pattern or "no video output" as another. A few motherboards do that via the bios but for ARM you'd want the kernel to be able to do that I guess.

[ddriver]

Finally, some desperately needed, critically important stuff making its way into the kernel, where it belongs!

It is probably a side effect of moving to that new, colorful diversity over code quality putting code of conduct.

And of course, this is the kind of nanosecond critical, high performance requirement stuff that can only property be implemented in the kernel, a user space driver couldn't have possibly cut it. It should really take priority over other, less essential kernel components, like thread scheduling, memory allocation or cpu governors. Otherwise, it will just not deliver an aesthetically pleasant eye candy experience.

[Uqbar]

Finally, some desperately needed, critically important stuff making its way into the kernel, where it belongs!

It is probably a side effect of moving to that new, colorful diversity over code quality putting code of conduct.

And of course, this is the kind of nanosecond critical, high performance requirement stuff that can only property be implemented in the kernel, a user space driver couldn't have possibly cut it. It should really take priority over other, less essential kernel components, like thread scheduling, memory allocation or cpu governors. Otherwise, it will just not deliver an aesthetically pleasant eye candy experience.

Ah ah ah ah!

[M@yeulC]

Guys please stop ranting because it's a feature you don't use or want. It has its uses, and belongs in the kernel.

But, do we really-really need this to reside inside the kernel?
Can't that be userland?

Yes, this needs to be in the kernel. You really want a standardised interface to control these LEDs, and the kernel's role is, among other things, a hardware abstraction layer. Plus, where would you like to put drivers otherwise? It also allows to handle permissions the regular way, multiseat, etc.

This will not only be useful for fancy RGB lighting on motherboards, but also for LEDs everywhere else: general purpose LEDs on ARM SBCs, development boards, NICs...

But most of all, I am thinking about the notification LED on Android phones. Until now this had been a real mess, with incompatible implementations between vendors, and no clear way to support them with an upstream kernel. This is one of the issues PostmarketOS faces when mainlining phones. I guess this will now be an issue of specifying the LED hardware path in the dts, and the patterns it supports.

An interface for controlling vibration motors and its patterns already exists, and that stuff is now pretty easy to add support for...

But RGB LEDs as implemented in downstream kernels typically vary from one LED device per color, to completely custom implementations. No clear way to set patterns either. IIRC, the xpad kernel driver uses one different LED device per pattern the xbox 360 controller can display.

Edit: IMHO the only downside is that you usually can't compile a custom firmware for the RGB controller and send it over with custom patterns, but are stuck with the predefined ones... Whatever, that's just a "hardware" feature (OTOH, you don't need to supply firmware blobs).

[Uqbar]

Guys please stop ranting because it's a feature you don't use or want. It has its uses, and belongs in the kernel.



Yes, this needs to be in the kernel. You really want a standardised interface to control these LEDs, and the kernel's role is, among other things, a hardware abstraction layer. Plus, where would you like to put drivers otherwise? It also allows to handle permissions the regular way, multiseat, etc.

This will not only be useful for fancy RGB lighting on motherboards, but also for LEDs everywhere else: general purpose LEDs on ARM SBCs, development boards, NICs...

But most of all, I am thinking about the notification LED on Android phones. Until now this had been a real mess, with incompatible implementations between vendors, and no clear way to support them with an upstream kernel. This is one of the issues PostmarketOS faces when mainlining phones. I guess this will now be an issue of specifying the LED hardware path in the dts, and the patterns it supports.

An interface for controlling vibration motors and its patterns already exists, and that stuff is now pretty easy to add support for...

But RGB LEDs as implemented in downstream kernels typically vary from one LED device per color, to completely custom implementations. No clear way to set patterns either. IIRC, the xpad kernel driver uses one different LED device per pattern the xbox 360 controller can display.

Edit: IMHO the only downside is that you usually can't compile a custom firmware for the RGB controller and send it over with custom patterns, but are stuck with the predefined ones... Whatever, that's just a "hardware" feature (OTOH, you don't need to supply firmware blobs).

I am sorry but I don't see all this as a justification for this feature to stay inside a kernel. It looks like more userland stuff maybe on top of a thin kernel exposure of the I/O interface.

[uid313]

Perhaps something like this could be used for vibrations too?
Phones have a vibration motor that you can activate in patterns.

In Android:

https://developer.android.com/reference/android/os/Vibrator

https://developer.android.com/reference/android/os/VibrationEffect

[ddriver]

But most of all, I am thinking about the notification LED on Android phones.

Oh yeah, because you couldn't possibly make a LED blink on events without deep kernel integration. Sure, people have done this for decades now, but it was such an excruciating effort, and now we can all rest relieved...

That's what it's truly all about. Not about painting animated LGBT flags on your keyboard. And the timing is entirely coincidental, it has nothing to do with Linux embracing "gender diversity"...

Make room LTS releases, here come the LGBT release, now that code quality is no longer a primary goal, it is time to integrate all them long overdue "uniqueness of humanity" features. It is no longer about how good Linux is, it is about how good we can force ourselves to believe it is! And nothing beats the benefits of flashing colorful lights, that's really what live is truly all about.

Perhaps something like this could be used for vibrations too?

Ahhh, having Linux finally put to good use driving dildos. The future is now!

[AdamOne]

Probably means RGB memory modules and motherboards such as the Gigabyte Aorus line, or fans like those found in the Corsair Obsidian cases.

Nice pun.