Linux Kernel Interface To Finally Allow For Programmable LED Patterns

[M@GOid]

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

On the Sapphire card I have, there is a button near the leds that controls it. Pressing it circles between patterns them turn the leds off.

[Weasel]

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

Userland drivers? Really?

[Weasel]

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.

Nobody cares the opinion for a "justification" of someone technically illiterate. Why do people comment on stuff they've no clue of?

If you want userland drivers then use FreeDOS or a similar OS with no protection for userspace vs kernel.

Drivers are in the kernel for a reason. You don't want userspace to be able to control hardware directly (without kernel calls), that's retarded from a security standpoint.


Just because "you feel" that it shouldn't be part of the kernel doesn't mean you know what you're talking about. Computers don't work on feelings, despite what SJWs like to think.

[schmidtbag]

I for one have actually been really looking forward to this, and I'm really glad it's been implemented in the same way that other LEDs have been controlled.

Although I only have 1 RGB LED in my computer (built into the motherboard), I wanted to use it as a status indicator, having it phase from blue to red depending on temperature, and maybe blink green for certain notifications. The LED is bright enough to be seen through the fan vents.

Depending how well this works, I might use the other 2 RGB headers for other status indicators.

[cRaZy-bisCuiT]

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

+1 ! Maybe not just turn it of, make it shine red when a certain temperature limit is reached!?

[ddriver]

People are missing the issue here.

Status indicating LEDs don't really have any place in the kernel, because those are supposed to work even before any boot up or kernel loading takes place. That is why they are implemented in hardware, using MCUs.

The reason drivers are typically implemented in the kernel is not security. A secure system is defined by security that extends to user space as well. In fact, there is a lot more harm to be done by code that runs in kernel space, and running things in user space is far safer, because this code is isolated from the most critical system components. That's why only the system's inner workings are supposed to run in kernel space.

The reason they put drivers in the kernel is performance. And yes, there are many drivers in the kernel for things that don't really mandate running in kernel space, mostly for historical reasons. But something as trivial as controlling LEDs definitely doesn't justify getting crammed into the kernel, it can absolutely run in user space and make the occasional system calls just like any bit of software. The kernel is where critically important things should be going, and of lately, the Linux kernel has gotten a terrible amount of pollution from things that don't really belong there.

My bet is this functionality was submitted by some short green haired non gender binary overweight individual and rejected for obviously valid reasons, but now that the code of conduct has changed to put "diversity" before "code quality", they have no choice but to let that junk in. Otherwise poor old Linus will risk hurting his daughter's feelings...

[V10lator]

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

AFAIK the LEDs hardly depend on the manufacturer of the card. For example on Sapphire cards the LED should be driven by an EM88F758N 8-BIT Microcontroller. Data sheets for these chips are available and I'll bet it's wired to one of the cards I2C busses but I'm too lazy to dig deeper just for some LED fun.

On the Sapphire card I have, there is a button near the leds that controls it. Pressing it circles between patterns them turn the leds off.

You have a RX 4X0, right? AFAIK on the 5X0 series the button has been removed (yes, website and even the manual says otherwise). So the only options are full bright or off (plugging the LED from the PCB).

[M@GOid]

You have a RX 4X0, right? AFAIK on the 5X0 series the button has been removed (yes, website and even the manual says otherwise). So the only options are full bright or off (plugging the LED from the PCB).

The RX470 is not with me right now. The other I have, a RX570, does not have leds.

[caligula]

Nobody cares the opinion for a "justification" of someone technically illiterate. Why do people comment on stuff they've no clue of?

If you want userland drivers then use FreeDOS or a similar OS with no protection for userspace vs kernel.

Drivers are in the kernel for a reason. You don't want userspace to be able to control hardware directly (without kernel calls), that's retarded from a security standpoint.

Just because "you feel" that it shouldn't be part of the kernel doesn't mean you know what you're talking about. Computers don't work on feelings, despite what SJWs like to think.

Not really sure what's your stance on this. The LED abstraction layer is pretty nice to have, but parsing and executing some animation state machine for flashing the LEDs has nothing to do with the hardware per se (unless you offload these patterns). You could do some LED flashing even before this from the userspace. You could also set up bindings from device status values to leds (e.g. ethernet/usb network load -> led activity).

[coder]

Or you can date a gothic|voodoo girl and borrow her black nail polish.

Lol. I'd just be goth for a day an buy a small bottle at the pharmacy. I almost dyed my hair black, once upon a time. I even bought the dye.

Anyhow, that would've also been an easier way to combat light leakage from a light pipe in one of my cases. Light from the power LED leaked out around the edge of the front cover, so I used an interlocking pair of heat shrink tubes to cover the light pipe. Painting it with black nail polish would've been much easier.