Announcement

Collapse
No announcement yet.

Linux Kernel Interface To Finally Allow For Programmable LED Patterns

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

  • #31
    Originally posted by f3nr1l View Post
    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.

    Comment


    • #32
      Originally posted by caligula View Post
      You could do some LED flashing even before this from the userspace.
      But that's not a userspace driver. Just userspace commands to the kernel via some interface (sysfs...), which sends them to the driver proper.

      Comment


      • #33
        Originally posted by Weasel View Post
        But that's not a userspace driver. Just userspace commands to the kernel via some interface (sysfs...), which sends them to the driver proper.
        The control logic comes from userspace and seems rather trivial when flashing LEDs. I'm not saying these should not be in the kernel. I'm just arguing that in this case, the operation might not be hard real-time in such a way that a pure kernel side implementation is needed. I've programmed some ws2811 strips and the bandwidth/latency requirements aren't that high even for some fancy patterns. Even now, to set up the kernel IIO sensor drivers etc., you might need to know how to deal with device trees while a pure userspace solution might just work out of the box. It's less demanding than slower serial ports. For example, consider FUSE & NVMe drives. It needs to feed the kernel 2 GB/s.

        Comment


        • #34
          Originally posted by caligula View Post
          The control logic comes from userspace and seems rather trivial when flashing LEDs. I'm not saying these should not be in the kernel. I'm just arguing that in this case, the operation might not be hard real-time in such a way that a pure kernel side implementation is needed. I've programmed some ws2811 strips and the bandwidth/latency requirements aren't that high even for some fancy patterns. Even now, to set up the kernel IIO sensor drivers etc., you might need to know how to deal with device trees while a pure userspace solution might just work out of the box. It's less demanding than slower serial ports. For example, consider FUSE & NVMe drives. It needs to feed the kernel 2 GB/s.
          Again, my comment was about people asking for userspace drivers. What you described is not a driver.

          Unless, of course, it uses a specialized hardware thing (i.e. the pattern itself is engraved in the hardware). If that's the case, then yeah, I can see why it's in the kernel, since it needs to be a driver rather than a mere "controller from userspace".

          Comment

          Working...
          X