From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 77753155333 for ; Tue, 22 Oct 2024 07:58:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729583937; cv=none; b=gXTKhDlh1FyGssCrV8iUv+DC24+ujGjmMDWIMv/GZrtAH5FhDUr3lq3lVNaFlcwc4W431jAtU6Mbj9PnDSynghFxtaPz0X47i0x8XN9JDKopg9Q4iFzYmi/9ZOH+6VwaD2/iGPhr6fEG1tKelj+qTzTSWebqmh4UYx+IxzMk9Kw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729583937; c=relaxed/simple; bh=lASjZqRy8DWUdG/x3b3JyJoeoS2+o+iWUvtizrQ9F9A=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rRijzWmmbUcmNK2SC3XZgJg93g5ag1qCxWHC7477aSUaD2kqzuNA3WeUnJtI+x0HjKgdox54/kD0Jn3MMUiqMEDGCPQ8NYrhUSO7LU+3tE5s9/yz4x5YsYWMGCZ/5VK/Z10cyOQYXOVH5IzqOVZ4wQ7wr1U6wzu9zChl+x/fTGU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=GweyATkd; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="GweyATkd" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1729583934; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/toOIhDFxtm2KiH53yytgdrHcc4/hOCbQgrRu1IsbBM=; b=GweyATkdPlz0anyMzAz6zXPcWMA27iYEuO3M3LQ6iQb/kjW6uw99NsXwpEZMhqsDCBItwW A8vjzzuLMXG0Fgahfefy2hD9sCOtugivyRKBCVH4FLc8A4HJRgC7KweOah9jIZAdgFOFLb pBihlF67nq8Dy/vnrzV7TzqDvOEKbCA= Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-138-gZ39yAP-Nu2SZgBT83pT5w-1; Tue, 22 Oct 2024 03:58:53 -0400 X-MC-Unique: gZ39yAP-Nu2SZgBT83pT5w-1 Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-53a0b48e8d4so4950981e87.3 for ; Tue, 22 Oct 2024 00:58:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729583932; x=1730188732; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/toOIhDFxtm2KiH53yytgdrHcc4/hOCbQgrRu1IsbBM=; b=W3E2IkCVGmIaBlKZF5SJdj5v0ASs3WUlHUgS7ciUtca2z5In51KoTtUGQxtQIIkWJ6 Badjos3JeVpD8bg/eBAMzZpE4b15gMseIZm21c5zSQHsqC5taL2jMHCYAx5/I2jDGQEX okS5K7AVYngC/qnKqs74TJ2h5jL0D6kI8tOX85kAQmVgr6s045mosWtHb9Ptt4v0Y65F Dv1R241Spl9O3HSmjhthbqDQND119AaZbCQrLghrtBgfDRBrnsVv9/+rkjdwACh1EV6h XZNY9ZKui46KBSr63UbEXv/rwIctbxxsTC1sH6greyv1Ui/qtlPVql1j5jCnbWm9Ci0s Ye4w== X-Forwarded-Encrypted: i=1; AJvYcCXLpi42dxfNIivfjLhNMnsw1834xufh3ovyF5iQkXc3koUyiC+ttK7FfgLB1xuo0oVkxdHObTzKlPJsoos=@vger.kernel.org X-Gm-Message-State: AOJu0YzMGNPM9Vf5XMa908Z6Q58d64hvsKcF3QlT1LII6Qe86Qy+STTg K+Jw0JBSJ2UtOAeCMGR5pyTLg7tjBxv2x7qVaxq3WoiWkVLN3QOjdt6GNUMkUF7EEbdYE4swJ+9 4TvW1trLQESUgnPCWGJVfB2O6GgH6VNpGA2wrHj1lEk9mSzxdERCa4mUTP7G9BA== X-Received: by 2002:a05:6512:1396:b0:539:e873:6e6 with SMTP id 2adb3069b0e04-53a15445fbbmr6176905e87.43.1729583931491; Tue, 22 Oct 2024 00:58:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFHZkuY2o29BsH2nW9fSeox5DGzjxId3xF7ANCRMftKPLZng9BBjKBjW/HI8QrQjL7hrhqDkQ== X-Received: by 2002:a05:6512:1396:b0:539:e873:6e6 with SMTP id 2adb3069b0e04-53a15445fbbmr6176880e87.43.1729583930939; Tue, 22 Oct 2024 00:58:50 -0700 (PDT) Received: from ?IPV6:2001:1c00:c32:7800:5bfa:a036:83f0:f9ec? (2001-1c00-0c32-7800-5bfa-a036-83f0-f9ec.cable.dynamic.v6.ziggo.nl. [2001:1c00:c32:7800:5bfa:a036:83f0:f9ec]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5cb66a6a729sm2841670a12.54.2024.10.22.00.58.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Oct 2024 00:58:50 -0700 (PDT) Message-ID: Date: Tue, 22 Oct 2024 09:58:48 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] platform/x86/tuxedo: Add virtual LampArray for TUXEDO NB04 devices To: Armin Wolf , Pavel Machek Cc: Werner Sembach , Benjamin Tissoires , =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= , dri-devel@lists.freedesktop.org, jelle@vdwaa.nl, jikos@kernel.org, lee@kernel.org, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org, miguel.ojeda.sandonis@gmail.com, ojeda@kernel.org, onitake@gmail.com, platform-driver-x86@vger.kernel.org References: <7ce4470c-a502-416a-8472-a5b606bb8fd4@tuxedocomputers.com> <39f84cfe-bb89-4194-81a9-e178c93e5309@tuxedocomputers.com> <82a6eca1-728c-436f-8c4d-073d8a43ee27@tuxedocomputers.com> <5crqia4gecxg62n2m2lf6haiifue4wlxrr3g35dyoaa3svjyuj@cd5bhouz5rlh> <4a761cd0-611a-4245-8353-5c66ba133715@tuxedocomputers.com> <06c58141-4aa9-4b54-8ae4-e27069561ac9@tuxedocomputers.com> <48a8d62f-ea3f-4f17-b917-ff3aaa83e89c@gmx.de> Content-Language: en-US, nl From: Hans de Goede In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Armin, On 21-Oct-24 10:26 PM, Armin Wolf wrote: > Am 11.10.24 um 17:26 schrieb Pavel Machek: > >> 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 > > Sorry for taking a bit long to respond. > > This "illumination" subsystem would (from my perspective) act like some sort of LED subsystem > for devices with a high count of LEDs, like some RGB keyboards. > > This would allow us too: > - provide an abstract interface for userspace applications like OpenRGB > - provide an generic LED subsystem emulation on top of the illumination device (optional) > - support future RGB controllers in a generic way > > Advanced features like RGB effects, etc can be added later should the need arise. > > I would suggest that we model it after the HID LampArray interface: > > - interface for querying: >  - number of LEDs >  - supported colors, etc of those LEDs >  - position of those LEDs if available >  - kind (keyboard, ...) >  - latency, etc > - interface for setting multiple LEDs at once > - interface for setting a range of LEDs at once > - interface for getting the current LED colors > > Since sysfs has a "one value per file" rule, i suggest that we use a chardev interface > for querying per-LED data and for setting/getting LED colors. > > I do not know if mixing sysfs (for controller attributes like number of LEDs, etc) and IOCTL > (for setting/getting LED colors) is a good idea, any thoughts? I wonder what the advantage of this approach is over simply using HID LampArray (emulation), openRGB is already going to support HID LampArray and since Microsoft is pushing this we will likely see it getting used more and more. Using HID LampArray also has the advantage that work has landed and is landing to allow safely handing over raw HID access to userspace programs or even individual graphical apps with the option to revoke that access when it is no longer desired for the app to have access. HID LampArray gives us a well designed API + a safe way to give direct access to e.g. games to control the lighting. I really don't see the advantage of inventing our own API here only to then also have to design + code some way to safely give access to sandboxed apps. Note that giving access to sandboxed apps is a lot of work, it is not just kernel API it also requires designing a portal interface + implementing that portal for at least GNOME, KDE and wlroots. Personally I really like the idea to just emulate a HID LampArray device for this instead or rolling our own API. I believe there need to be strong arguments to go with some alternative NIH API and I have not heard such arguments yet. Regards, Hans