[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZwlDpCPhieF3tezX@duo.ucw.cz>
Date: Fri, 11 Oct 2024 17:26:28 +0200
From: Pavel Machek <pavel@....cz>
To: Armin Wolf <W_Armin@....de>
Cc: Werner Sembach <wse@...edocomputers.com>,
Benjamin Tissoires <bentiss@...nel.org>,
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!
> > 1.
> > https://lore.kernel.org/all/6b32fb73-0544-4a68-95ba-e82406a4b188@gmx.de/
> > -> Should be no problem? Because this is not generally exposing wmi
> > calls, just mapping two explicitly with sanitized input (whitelisting
> > basically).
>
> It would be OK to expose a selected set of WMI calls to userspace and sanitizing the input of protect potentially buggy firmware from userspace.
>
I don't believe this is good idea. Passthrough interfaces where
userland talks directly to hardware are very tricky.
>
> Regarding the basic idea of having a virtual HID interface: i would prefer to create a illumination subsystem instead, but i have to agree that we should be doing this
> only after enough drivers are inside the kernel, so we can design a
> suitable interface for them. For now, creating a virtual HID
> interface seems to be good enough.
I have an RGB keyboard, and would like to get it supported. I already
have kernel driver for LEDs (which breaks input functionality). I'd
like to cooperate on "illumination" subsystem.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists