Announcement

Collapse
No announcement yet.

Linux Kernel Developers Discussing Generic RGB LED Interface

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux Kernel Developers Discussing Generic RGB LED Interface

    Phoronix: Linux Kernel Developers Discussing Generic RGB LED Interface

    With the ever increasing usage of RGB LEDs on modern computer systems, Linux kernel developers have begun discussing a formal RGB LED user-space interface...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Hopefully we can have a kernel command line parameter rgb_off=1!

    Comment


    • #3
      Seems like over-engineering into specific function. What does the kernel care about specific color?
      You encode your LEDs and let whatever userspace function mix appropriately.
      Maybe someone can educate me why the kernel needs to know RGB LED intrinsics beyond basic level and pulsing?

      The author details problems with a RGB LED interface. Including specific knowledge on LED-types on how to mix into specific colors.
      That kind of idiocy really does not belong in a kernel.

      Comment


      • #4
        The problem lies in the individually addressable LEDs. Each one needs a chip to talk to the outside and there are quite a few different chips with different specifications. Just look at the FastLED library for Arduino.

        Additionally, each manufacturer of RGB-lid products seems to have their own (proprietary!) software to control their products. Sometimes you even need different software for different products from the same manufacturer.

        If you had one interface to control all the RGB-LEDs in your system with only one piece of software that would be a great deal for some. Since it's only of aesthetic I understand the hesitation. But from a technological stand point the OS should take care of the different hardware and offer a unified interface to user space. In essence, this is what OpenGL does, too.

        Comment


        • #5
          Originally posted by milkylainen View Post
          Seems like over-engineering into specific function. What does the kernel care about specific color?
          You encode your LEDs and let whatever userspace function mix appropriately.
          Maybe someone can educate me why the kernel needs to know RGB LED intrinsics beyond basic level and pulsing?

          The author details problems with a RGB LED interface. Including specific knowledge on LED-types on how to mix into specific colors.
          That kind of idiocy really does not belong in a kernel.
          While there seems to be a bit of nitpicking on that mailing list, it would greatly simplify everything to only have one interface for each RGB LED. Nowadays, there's no real standard that I know of, and it's hard to guess which LED goes with which one.
          So, from a practical point of view, it would be nice to let the kernel handle this, so that userspace apps can auto-discover LEDs. I had a bit of trouble with various vendor-dependent implementation of the RGB LEDs controls when writing a piece of software for postmarketos (and keeping it simple), for instance. Here, LEDs would be specified trough the DTB, for instance.

          Also, LEDs are mostly cosmetics, but I like to have a power indicator, disk indicator (also for failed disks, etc...), and like having more for temperature or failure indication, etc.

          Comment


          • #6
            Honestly I don’t buy this idea that this is a kernel problem or should be something kernel developers should worry about. Force the developers of this hardware to use serial over USB interfacing and avoid cluttering the kernel even more.

            Comment


            • #7
              So there is a point to cleaning this up now (or 10 years ago but..) as the trash RGB keyboards like Razer etc. provide their own damn kernel modules for this. Modules that are so poorly written and designed to the point that it's easier to exploit them for privilege escalation than it is to use them correctly.

              Stranger still, the kernel already has a LED interface via evdev; it turns out lots of input devices also has indicator leds to be managed; something like feature-bit for additional colour channels seems much more reasonable than designing another sysfs interface. The few application areas that need accurate color representation out of these things need to do their own colorimeter based calibration per device/project anyhow.

              Comment


              • #8
                Originally posted by M@yeulC View Post
                So, from a practical point of view, it would be nice to let the kernel handle this, so that userspace apps can auto-discover LEDs.
                While that sounds like a good idea, it is of course up to the hardware vendors to document correctly and put it in their firmware using some mechanism that reports these details and then they have to decide on a formal format for reporting the details between vendors etc etc

                Most of the RGB LEDs I've played with have driver hardware that's pretty dumb - way lower level than i2c or spi or anything that could have a hardware ID you could read.

                Comment


                • #9
                  Cool, I always wanted to configure my LED to pulse like a heartbeat, as the load increases the pulses would get faster, like my PC is running haha

                  Comment


                  • #10
                    I think this makes sense, most "intelligent" RGB LEDs take all color values in a single command. Setting three colors separately theoretically either uses three times the bandwidth and/or introduces a race condition where userspace competes with bus commands to beat the next refresh cycle.

                    Comment

                    Working...
                    X