On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote:
> Hi,
>
> I have a ThingM blink(1) USB RGB device that shows up as uhid(4).
> The tooling is "interesting", especially with all those libusb and
> HID libraries doing the abstraction. This introduces ublink(4), a
> dedicated kernel driver for that device. There are two LEDs on the
> device, which can be modified seperately. The firmware is impress-
> ive and provides features like playing sequences and adjusting how
> long it should take to fade from one colour to another. Obviously
> this also increases the complexity of the tools involved to toggle
> those RGB LEDs. Thus, the driver is kept simple (for now).
>
> In addition to providing a way to set RGB LEDs, we can also use it
> as a watchdog. If we don't "tickle" it in a specific timeframe it
> will play a (unless otherwise programmed) random sequence, which for
> instance can be used to see that the machine has paniced. This has
> been quite useful while debugging the USB stack, because once the
> magic sequence started you know that you're in deep trouble. All
> other features are unimplemented. Gamma correction would be nice
> to have.
>
> Since there is no abstraction layer for LEDs yet, this also intro-
> duces led(4), which attaches to ublink(4), and provides /dev/ledX.
There is the machdep.led_blink sysctl CPU_LED_BLINK implemented by
multiple architectures to blink based on load average.
See
man4.hppa/lcd.4:.Ar machdep.led_blink
man4.sparc64/auxio.4:.Ar machdep.led_blink
man4.sparc64/clkbrd.4:.Ar machdep.led_blink
man4.sparc64/fhc.4:.Ar machdep.led_blink
man4.sparc64/led.4:.Ar machdep.led_blink
man4.sparc64/ppm.4:.Ar machdep.led_blink
sys/arch/alpha/include/cpu.h: { "led_blink", CTLTYPE_INT } \
sys/arch/hppa/include/cpu.h: { "led_blink", CTLTYPE_INT }, \
sys/arch/landisk/include/cpu.h: { "led_blink", CTLTYPE_INT }
\
sys/arch/sparc64/include/cpu.h: { "led_blink", CTLTYPE_INT }, \
