Announcement

Collapse
No announcement yet.

A Linux Kernel API For Today's Complex RGB Devices Is Being Devised

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

  • #11
    Originally posted by ddriver View Post
    FGS, the OS kernel is for OS/system integration, not for eye candy! Sheer insanity!
    I'm guessing there may be other interested parties, thinking in terms about status indicators for embedded devices.

    Comment


    • #12
      Originally posted by Serafean View Post

      So no HDR and VRR support either?
      I mean, the programmable LED spacers on the framework laptop could actually be useful for some kind of notifications. Same could have gone for the macbook touchbar (that was screwed up though)
      Ummm... learn the difference between functional and decorative lightning.

      And ummmm... "RGB peripherals" has nothing to do with display backlighting, which BTW monitors are handling internally with dedicated hardware controllers.

      Comment


      • #13
        I don't see any benefits in moving this into the kernel but many disadvantages. Kernel bloats like these mean increasing the surface area for attacks and errors. Common open source standards can also be established outside of the kernel. Something trivial like RGB control seems more like a trend phenomenon than a technical necessity with real benefits. Yes this idea is for the worse.

        Comment


        • #14
          All for it.

          Are you guys really going on about attack surfaces? If I seen my RGB lighting suddenly blinking out codes it might freak me out a little.... But I digress...

          Comment


          • #15
            I have a keyboard with QMK firmware and I think the RGB options are: pattern, speed and brightness. We are not talking about a 2d framebuffer here.

            Comment


            • #16
              Originally posted by M.Bahr View Post
              I don't see any benefits in moving this into the kernel but many disadvantages. Kernel bloats like these mean increasing the surface area for attacks and errors. Common open source standards can also be established outside of the kernel. Something trivial like RGB control seems more like a trend phenomenon than a technical necessity with real benefits. Yes this idea is for the worse.
              The very term KERNEL is orthogonal to whatever the "linux kernel" is. It implies something small, central and simple, out of which complexity emerges.

              There is an actual technical term for what the "linux kernel" is, and it is called a "god object". I mean that conceptually, in the context of "everything goes in there". But at the same time, that design is implemented in the form of an unholy amalgamation of "spaghetti" and "ravioli" code, making the holy trinity of bad software design....

              The linux kernel is not good software design, it is messy, very dated, legacy burdened, hard-cody and overly bloated, it still manages to get away with that because of the increasing amount of bloat m$ is throwing at its own platform in order to better "utilize" the user base. This is a side effect of all that excessive, unhealthy amount of "freedom" I guess.

              Why also not a smart dildo API in the kernel while we are at it? Let's put the penguin on every dildo! More market share and exposure
              Last edited by ddriver; 22 February 2024, 01:50 AM.

              Comment


              • #17
                Sure are a lot of nattering nabobs of negativism in here.

                As long as it's in mainline and not a perpetual out-of-tree module like OpenRazer, I'm all for it.

                Comment


                • #18
                  I think a unified kernel API for this stuff is a great idea! There are many hardware interfaces for rgb leds, and some of them I *really* don't want exposed read-write to userspace in raw form. Think shared busses like the SMbus (motherboard leds, but also TPM modules, temp sensors, fan control) or i2c (ram leds, but also dimm spd timing info, peripheral configure, case intrusion, voltage regulators).

                  You can cause literal hardware damage by writing the wrong bytes to the wrong addresses on those shared buses, so hiding them behind a controlled kernel API is very much a good thing!

                  note that I still think the patterns, animations, etc belong in userspace. The kernel should only be "now set these leds to these rgb bytes"

                  Fürther reading: Linus Tech Tips forum on wildly insecure gigabyte windows driver: (tldr: rgb driver gave raw user-write access to motherboard firmware, every rootkits dream! )
                  A guy just discovered that all the RGB controls on motherboards are designed so poorly that people can use it as a backdoor into the motherboard. Quote I got frustrated at Gigabyte's RGB control stuff (I just REALLY want to turn my GPU LEDs off!) so I caved in and started reverse engineering RGB ...

                  Last edited by Juke1349; 22 February 2024, 05:06 AM. Reason: Add further reading link

                  Comment


                  • #19
                    I'm not a fan of all this RGB hype.
                    There are some useful applications like keyboard backlight that adjusts automatically to surrounding light conditions and on laptops it would be nice to be able to dimm the power LED and similar stuff much like redshift does for the monitor.

                    Comment


                    • #20
                      I also don't like RGB on my stuff, and I deliberately chose (more expensive) components in my most recent build, to avoid the RGB craze.

                      That is the exact reason I am in favour of a secure, unified way to switch it off.

                      Comment

                      Working...
                      X