From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.tuxedocomputers.com (mail.tuxedocomputers.com [157.90.84.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E61712E46; Fri, 29 Dec 2023 19:22:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=tuxedocomputers.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=tuxedocomputers.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=tuxedocomputers.com header.i=@tuxedocomputers.com header.b="Ud/KVEaL" Received: from [192.168.42.20] (p5de453e7.dip0.t-ipconnect.de [93.228.83.231]) (Authenticated sender: wse@tuxedocomputers.com) by mail.tuxedocomputers.com (Postfix) with ESMTPSA id 1DA392FC006B; Fri, 29 Dec 2023 20:13:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxedocomputers.com; s=default; t=1703877226; 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=SLTb8MHngpCr9Ay6alL/D0Bkd3X169eJXti2fNSNyUU=; b=Ud/KVEaLvSu5mZr8YUyKpZxPaKTMiVlzkT7gRzRovNYW5O6jE76s0nHvX3sKKkiqpQ4aT+ g4FVQEN+xtw5YnRmzO2e8ZpaoD5WznFS69Z9PTGoEwWlaBAp0BBwGevuglfcPbg+8T7vN1 xP2xSqZwiIfMaoLCgHz9FoImfR4yKeQ= Authentication-Results: mail.tuxedocomputers.com; auth=pass smtp.auth=wse@tuxedocomputers.com smtp.mailfrom=wse@tuxedocomputers.com Message-ID: <49f12cc1-2dce-43b3-addf-b0fdb7df8fdb@tuxedocomputers.com> Date: Fri, 29 Dec 2023 20:13:44 +0100 Precedence: bulk X-Mailing-List: linux-input@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Implement per-key keyboard backlight as auxdisplay? From: Werner Sembach To: Hans de Goede , Pavel Machek , Jani Nikula , jikos@kernel.org, Jelle van der Waa Cc: Lee Jones , linux-kernel@vger.kernel.org, "dri-devel@lists.freedesktop.org" , Miguel Ojeda , linux-input@vger.kernel.org, ojeda@kernel.org, linux-leds@vger.kernel.org References: <20231011190017.1230898-1-wse@tuxedocomputers.com> <0440ed38-c53b-4aa1-8899-969e5193cfef@tuxedocomputers.com> <87sf61bm8t.fsf@intel.com> <8096a042-83bd-4b9f-b633-79e86995c9b8@redhat.com> <4222268b-ff44-4b7d-bf11-e350594bbe24@redhat.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Hans & the others, [snip] > I also stumbled across a new Problem: > > We have an upcoming device that has a per-key keyboard backlight, but does the > control completely via a wmi/acpi interface. So no usable hidraw here for a > potential userspace driver implementation ... > > So a quick summary for the ideas floating in this thread so far: > > 1. Expand leds interface allowing arbitrary modes with semi arbitrary optional > attributes: > >     - Pro: > >         - Still offers all default attributes for use with UPower > >         - Fairly simple to implement from the preexisting codebase > >         - Could be implemented for all (to me) known internal keyboard backlights > >     - Con: > >         - Violates the simplicity paradigm of the leds interface (e.g. with > this one leds entry controls possible multiple leds) > > 2. Implement per-key keyboards as auxdisplay > >     - Pro: > >         - Already has a concept for led positions > >         - Is conceptually closer to "multiple leds forming a singular entity" > >     - Con: > >         - No preexisting UPower support > >         - No concept for special hardware lighting modes > >         - No support for arbitrary led outlines yet (e.g. ISO style enter-key) > > 3. Implement in input subsystem > >     - Pro: > >         - Preexisting concept for keys and key purpose > >     - Con: > >         - Not in scope for subsystem > >         - No other preexisting light infrastructure > > 4. Implement a simple leds driver only supporting a small subset of the > capabilities and make it disable-able for a userspace driver to take over > >     - Pro: > >         - Most simple to implement basic support > >         - In scope for led subsystem simplicity paradigm > >     - Con: > >         - Not all built in keyboard backlights can be implemented in a > userspace only driver > > Kind Regards, > > Werner Just a gentle bump and request for comments again. 4. would be better then nothing but it is not a universal future proof solution so I'm hesitant to put work into it even though it would be the simplest driver. I still tend towards 1. as the leds interface already got expanded once with the multicolor stuff. The only other way I see would be to implement a platform driver with no standardized api or implement a complete new api/subsystem from the ground up. Kind Regards, Werner