Add DMI quirk for Acer Predator Triton 300 SE (PT316-51s)

[GbrFrn]

Summary

Adds a DMI quirk entry for the Acer Predator Triton 300 SE — Predator PT316-51s, board Roadster_ADH. Introduces a small dedicated quirk struct (quirk_acer_predator_pt316_51s) that combines .predator_v4 = 1 with .four_zone_kb = 1, placed right after the PH18-71 entry.

Why

Without a DMI match this model has no working configuration:

• Loading the module bare (modprobe linuwu_sense) produces no sysfs directories at all — find_quirks() ends with quirks = &quirk_unknown, no caps get set, no predator_sense/ or nitro_sense/ is created.
• The only workaround was enable_all=1 in /etc/modprobe.d/. But the secondary cap block at lines ~4863-4872 OR-s in all of PREDATOR_SENSE | NITRO_SENSE | NITRO_SENSE_V4 whenever any of {enable_all, predator_v4, nitro_v4} is set as a module param. That routes sysfs into nitro_sense_v4_attr_group (which has .name = "nitro_sense"), so a Predator ends up exposing a directory misleadingly named nitro_sense/. Worse, it enables WMI codepaths the firmware doesn't fully implement and pollutes the cap mask.

With this DMI quirk, the struct fields are set via set_quirks() (not the module param), the secondary block stays inactive, and the clean predator_sense/ directory is created alongside four_zoned_kb/ with only the caps the firmware actually supports.

Probed on real hardware

Tested with /etc/modprobe.d/ empty and module params at defaults. After this patch, on PT316-51s:

$ ls /sys/devices/platform/acer-wmi/
predator_sense/   four_zoned_kb/   platform-profile/

All eight predator_sense attrs read cleanly:

backlight_timeout    = 0
battery_calibration  = 0
battery_limiter      = 0
boot_animation_sound = 1
fan_speed            = 100,100
lcd_override         = -1
usb_charging         = 30
version              = 25.701

Platform profile registered with quiet balanced balanced-performance performance (firmware advertises bitmap 0x33; no ECO/low-power on this model). Selecting performance correctly maps to ACER_PREDATOR_V4_THERMAL_PROFILE_TURBO (0x05).

RGB keyboard caveat

This laptop has a four-zoned RGB keyboard that does work in terms of writes — echo "ff0000,00ff00,0000ff,ffffff,80" > /sys/.../four_zoned_kb/per_zone_mode correctly changes the lights. However, the firmware's get-method has a bug: reading per_zone_mode back returns a malformed zone4 value (7 hex chars instead of 6), and on some module-load attempts acer_keyboard_state_load() logs failed to set keyboard rgb: 134283264 / Error setting KB status while trying to restore the previously-saved state.

I left four_zone_kb enabled anyway because the writes work — users get RGB control even with that broken read. If you'd rather mask the broken read entirely, dropping .four_zone_kb = 1 from the quirk is a one-line revert; let me know if you'd prefer that.

Test plan

• Build with LLVM=1 against linux-cachyos 7.0.8 (clang 22.1.5) — clean compile, 2 pre-existing -Wbitwise-instead-of-logical warnings unrelated to this patch.
• Boot/runtime: module auto-detects via DMI, no module params needed, predator_sense/ and four_zoned_kb/ populated.
• All 8 predator_sense attrs readable.
• per_zone_mode write accepted (verified with ff0000,00ff00,0000ff,ffffff,80 — RGB visibly changed; readback shows the firmware-side zone4 get-method bug noted above).
• DAMX-Daemon (downstream consumer) now reports Detected laptop type: PREDATOR with Base path: …/predator_sense, Four-zone keyboard: Yes, and 10/10 features detected.

DMI strings for reference

DMI_SYS_VENDOR     = Acer
DMI_PRODUCT_NAME   = Predator PT316-51s
DMI_PRODUCT_FAMILY = Predator Triton 300 SE
DMI_BOARD_NAME     = Roadster_ADH