Re: Placement of ASUS Aura and platform/x86 ASUS files relocation

[Armin Wolf]

Am 05.08.26 um 14:20 schrieb Denis Benato:

> On 8/4/26 20:22, Armin Wolf wrote:
> > Am 04.08.26 um 19:46 schrieb Denis Benato:
> >
> > > Hi all,
> > >
> > > I write this mail to ask a few questions related to the various ASUS devices in the kernel both present and futures and how to organize that work.
> > >
> > > To understand this mail one needs to know that AURA is the name of the lighting ASUS gave to its
> > > products: each device is divided in one or more zones and each zone supports setting an effect like
> > > static (1 color), strobe (2 colors and speed), rainbow (0 colors), rain (0 colors and speed), laser (1 color and direction) and these, to be represented in such a way features are not being lost requires a ned interface
> > > that Derek said he wanted to develop as many other hardware would benefit from it: I will therefore need
> > > to specialize it for ASUS things: where is it better to put any .c/.h file related to this interface? Is platform-x86 OK?
> > >
> > > The Aura interface has components (all or only certain aspects) working via: scsi, (hid) usb + i2c and wmi.
> > >
> > > 1. Liang Haowen has an ASUS nvme enclosure that supports the AURA protocol as scsi commands:
> > > we want those to be in the kernel, but we don't know where to put the aura userspace interface (see above).
> > Hi,
> >
> > it depends on the userspace interface. If you use the LED sysfs API (with some extensions for the effects), then i suggest
> > that you place the driver in drivers/leds, because the NVME enclosure is not a platform device.
> Yeah we will have to bind the LED interface once to the nvme enclosure, up to 8 different interface to the keyboard (one per zone so we can set the physical keyboard in rain and the rear logo in static for example)
> and also TUFs manage power states via asus-wmi so one interface spawned by i2c will need to be bound
> to asus-wmi too.
>
> The userspace interface will need to be used by different drivers, in different instances and even more than
> one driver on the same instance.
> > I assume you refer to the ROG Arion? If the SCSI commands are used to issue i2c/smbus requests, then you should also
> > place the i2c controller driver under /drivers/i2c/busses.
> It is indeed a ROG Arion.
> > > 2. ASUS has product called "RTX Spark" coming that are arm and will support acpi: I have no idea if the asus-wmi
> > > interface would be reused, but if they decide to do so (and the kernel can be made to boot lol) would platform/x86 still be the best place for ASUS drivers?
> > In such a case, moving the affected drivers to drivers/platform/asus/ would be a good idea. There is currently a patch series pending
> > for enabling ACPI-WMI on arm, so _theoretically_ the asus-wmi driver should work.
> Splendid news!
> > > 3. During the upstreaming of asus-armoury Hans de Goede asked if it's preferred to have an asus directory containing asus drivers, but the discussion died there. Now that I see there is a patchest that will also move asus files
> > > would it be a good time to spawn this discussion?
> > IMHO having a separate asus directory for all asus-related platform drivers would indeed be very nice. You could reuse the drivers/platform/asus directory
> > for that, and leave the older asus-related drivers inside drivers/platform/x86 for the time being.
> >
> > Alternatively, you could move all the affected drivers to drivers/platform/x86/asus, and after that move this directory to drivers/platform.
> This looks cleaner to me if ASUS will produce ARM products that actually use that interface,
> but will wait to hear what others think.
>
> If I do that will platform/x86 still be the correct place to send patches? I don't want to "move" the driver away from platform/x86 mailing list just because the directory changed.

Sorry for the delay.

AFAIK as long as the driver is still heavily connected to the x86 platform, you can continue to use this mailing list.
That is what i am doing with the core ACPI-WMI driver.

Thanks,
Armin Wolf

> > Thanks,
> > Armin Wolf
> Best regards,
> Denis Benato
> > > Thank you all for your time.
> > >
> > > Best regards,
> > > Denis Benato