Placement of ASUS Aura and platform/x86 ASUS files relocation

Placement of ASUS Aura and platform/x86 ASUS files relocation

[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).

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?

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?

Thank you all for your time.

Best regards,
Denis Benato

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

[Armin Wolf]

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.

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.

>
> 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.

> 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.

Thanks,
Armin Wolf

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

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

[NB Group]

> If the SCSI commands are used to issue i2c/smbus requests, then you should
> also place the i2c controller driver under /drivers/i2c/busses.


Hi Armin, Denis,

Armin, agreed on drivers/leds/ for the LED side. The enclosure isn't a platform
device and the interface is the multicolor LED sysfs, so that's the right home
for it. SCSI transport stays in drivers/scsi/.

On whether the SCSI commands wrap i2c/smbus: they don't, at least not on the
ROG STRIX Arion I reversed. The ENE controller speaks a flat register protocol
over the vendor CDB (0xec 'A' 'S' <reg_hi> <reg_lo> ... <arg_count>), with
registers for mode (0x8021), per-LED colours (0x8160), apply (0x80a0) and so on.
No i2c slave addressing shows up in the vendor CDBs, no sign of tunneling, so
there's nothing for an i2c-bus driver to model. A SCSI transport helper
in drivers/scsi/ feeding an Aura LED driver in drivers/leds/ is the shape
that matches the hardware.

I've got a working prototype that picks the enclosure up via a SCSI bus notifier
and exposes the multicolor LED; haven't posted it yet. I'll split it the way
above and send it for review.

One thing worth flagging on the transport, because it dictates how the helper
gets written. scsi_execute_cmd() sizes the CDB via COMMAND_SIZE(opcode), i.e.
scsi_command_size_tbl[(opcode >> 5) & 7], which is 10 for 0xec (group 7). The
ENE CDB is 16 bytes with arg_count in cdb[13], and the execute path does
memcpy(cmnd, cmd, cmd_len), so cdb[13] is never copied and the device just
ignores the write. I end up building the block request by hand and forcing
cmd_len=16. Anyone writing a driver that sends a vendor CDB whose real length
doesn't match COMMAND_SIZE(opcode) is going to hit the same thing.

Liang Haowen

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

[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.
> Thanks,
> Armin Wolf 
>
Best regards,
Denis Benato
>> Thank you all for your time.
>>
>> Best regards,
>> Denis Benato
>>
>>