Re: [PATCH] HID: ayaneo-flip-kb: Add driver for keyboard backlight

[Antheas Kapenekakis]

On Sun, 8 Nov 2026 at 15:26, Antheas Kapenekakis <lkml@xxxxxxxxxxx> wrote:
>
> On Sun, 8 Nov 2026 at 14:55, Hijae Song <hijae99@xxxxxxxxx> wrote:
> >
> > Hi Antheas,
> >
> > Thanks for the feedback.
> >
> > > If this is an actual keyboard product on the market and Ayaneo is
> > > sourcing the part for their device, look-up similar devices and kernel
> > > drivers.
> >
> > I checked. hid-sigmamicro only fixes the 0x0059 report descriptor, and
> > I found no SiGma Micro backlight driver on lore.
> >
> > > The name of the driver cannot be -flip-kb. You need to make sure it is
> > > generic enough to match most Ayaneo devices.
> >
> > 1c4f:007c also appears on the AYANEO Slide in hhd-dev/hwinfo, with the
> > same vendor interface (report ID 0x41, 7-byte feature report). I only
> > have a Flip KB, so I can only test the byte layout there.
> >
> > Matias's hid-ayaneo already claims 1c4f:0002 behind a DMI check for
> > AYANEO 3. Would you prefer that I add 007c backlight support to
> > hid-ayaneo once it is merged, or keep a separate driver named after
> > the chip? I lean towards hid-ayaneo, since the Slide may work the same
> > way, but I would like your view first.
>
> Mmmm so Ayaneo does not have a vid and may trample the pid of another
> device. That is not good. There is no guarantee this led profile is
> used by a different vendor.
>
> There are two options:
>  - Adding the keyboard to the hid-ayaneo driver
>      - This would happen after it merges
>      - There is 0 common logic between the rgb device and the keyboard device
>      - Driver registers a different led sysfs ABI and has convoluted
> dmi handling
>      - The driver would devolve
>  - Adding a scoped driver for the keyboard
>      - You can start now
>      - Can tightly scope to keyboard device
>      - name can be hid-ayaneo-kbd unless other vendor is found
>
> I would tend towards the latter. hid-ayaneo has plenty of work to
> merge. The controller firmware is quite unstable. Even my
> implementation in userspace is buggy. But that's fine... Windows is
> buggy too.
>
> I have two comments for your current version:
>   - remove all flip kbd references, name AYANEO_KBD
>   - use brightness values of 0 and 1, no scaling. DEs know how to
> handle these values by toggling.
>      - another option is 0-3, which looks nicer, but let's not get too
> deep into this
>   - use devm to register the led structure, drop remove entry point.
> Use devm prior to starting the device so that register code stays with
> initialization
>   - check if led subsystem is appropriate. I am not sure of the
> correct place. If not, current location is fine
>   - initialize host values to ff ff ff so on first write we get a nice
> white color
>   - if there is only one effect, brightness 0 is off. Do not add an
> effect handler

Ah yes, if the device supports Fn+Space, for this driver to merge you
need to send the correct hw notify and have at least KDE report the
cycling correctly. You will also need to read the values currently in
the device instead of hardcoding them. If it is a feature report, a
get_report should return current values

I am not sure what your current comment means about sending 0 breaking
the toggle.

Best,
Antheas

> With 2-3 revisions this should be good to go. While at it, try to find
> a Slide user
>
> Best,
> Antheas
>
> > I will also fix the two sashiko comments in v2.
> >
> > Thanks,
> > Hijae
> >