linux-kernel - Re: [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <39f84cfe-bb89-4194-81a9-e178c93e5309@tuxedocomputers.com>
Date: Mon, 7 Oct 2024 19:57:05 +0200
From: Werner Sembach <wse@...edocomputers.com>
To: Benjamin Tissoires <bentiss@...nel.org>
Cc: Armin Wolf <W_Armin@....de>, Pavel Machek <pavel@....cz>,
 Hans de Goede <hdegoede@...hat.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 dri-devel@...ts.freedesktop.org, jelle@...aa.nl, jikos@...nel.org,
 lee@...nel.org, linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-leds@...r.kernel.org, miguel.ojeda.sandonis@...il.com,
 ojeda@...nel.org, onitake@...il.com, platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO
 NB04 devices

Hi,

Am 02.10.24 um 10:31 schrieb Benjamin Tissoires:
> On Oct 01 2024, Werner Sembach wrote:
>> Hi Benjamin,
>>
>> Am 01.10.24 um 15:41 schrieb Benjamin Tissoires:
>>> [...]
>>> PPS: sorry for pushing that hard on HID-BPF, but I can see that it fits
>>> all of the requirements here:
>>> - need to be dynamic
>>> - still unsure of the userspace implementation, meaning that userspace
>>>     might do something wrong, which might require kernel changes
>> Well the reference implementetion for the arduiono macropad from microsoft
>> ignores the intensity (brightness) channel on rgb leds contrary to the HID
>> spec, soo yeah you have a point here ...
> Heh :)
>
>>> - possibility to extend later the kernel API
>>> - lots of fun :)
>> You advertise it good ;). More work for me now but maybe less work for me
>> later, I will look into it.
> Again, I'm pushing this because I see the benefits and because I can
> probably reuse the same code on my Corsair and Logitech keyboards. But
> also, keep in mind that it's not mandatory because you can actually
> attach the BPF code on top of your existing driver to change the way it
> behaves. It'll be slightly more complex if you don't let a couple of
> vendor passthrough reports that we can use to directly talk to the
> device without any tampering, but that's doable. But if you want to keep
> the current implementation and have a different layout, this can easily
> be done in BPF on top.
>
> Cheers,
> Benjamin
>
>
> [0] https://lore.kernel.org/linux-input/20241001-hid-bpf-hid-generic-v3-0-2ef1019468df@kernel.org/T/#t

Thinking about the minimal WMI to HID today, but found a problem: a HID feature 
report is either strictly input or output afaik, but the WMI interface has both 
in some functions.

How would I map that?

If I split everything in input and output the new interface wouldn't actually be 
much smaller.

Also what would I write for the usage for the reserved padding in the report 
descriptor. Usage: 0x00?

best regards,

Werner