From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 2BBFCC48BF8 for ; Thu, 22 Feb 2024 17:42:39 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8020010E069; Thu, 22 Feb 2024 17:42:38 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=ucw.cz header.i=@ucw.cz header.b="lM3hEXNV"; dkim-atps=neutral Received: from jabberwock.ucw.cz (jabberwock.ucw.cz [46.255.230.98]) by gabe.freedesktop.org (Postfix) with ESMTPS id 59AA310E069 for ; Thu, 22 Feb 2024 17:42:37 +0000 (UTC) Received: by jabberwock.ucw.cz (Postfix, from userid 1017) id 2B21C1C0080; Thu, 22 Feb 2024 18:42:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ucw.cz; s=gen1; t=1708623756; 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: in-reply-to:in-reply-to:references:references; bh=7+iTr5gsQUOr/RFi5kEyD7spJTWKMjOx6qK/fQXts4o=; b=lM3hEXNVlZoJUF4FIW1VT4TSTf+3jXX1RhHjbz0USgfJbo7J8viUGgfh+SMVmSqY6JxwdS P5S0KNyxLRZKKCe/H+r+1mi/5AHFJeecO8TKJwT3GHwIuzXpG8VX0bmcXERaUOQjzDeabh DNOZaxt24SrzeEnuibgTBoDSjjVBQrc= Date: Thu, 22 Feb 2024 18:42:35 +0100 From: Pavel Machek To: Hans de Goede Cc: Gregor Riepl , Werner Sembach , Lee Jones , jikos@kernel.org, linux-kernel@vger.kernel.org, Jelle van der Waa , Miguel Ojeda , "dri-devel@lists.freedesktop.org" , linux-input@vger.kernel.org, ojeda@kernel.org, linux-leds@vger.kernel.org Subject: Re: Future handling of complex RGB devices on Linux v2 Message-ID: References: <9851a06d-956e-4b57-be63-e10ff1fce8b4@tuxedocomputers.com> <1bc6d6f0-a13d-4148-80cb-9c13dec7ed32@redhat.com> <477d30ee-247e-47e6-bc74-515fd87fdc13@redhat.com> <247b5dcd-fda8-45a7-9896-eabc46568281@tuxedocomputers.com> <825129ea-d389-4c6c-8a23-39f05572e4b4@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M3rPF2twcL7SMY4r" Content-Disposition: inline In-Reply-To: <825129ea-d389-4c6c-8a23-39f05572e4b4@redhat.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --M3rPF2twcL7SMY4r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > > To be honest, I think the kernel shouldn't include too much high-level = complexity. If there is a desire to implement a generic display device on t= op of the RGB device, this should be a configurable service running in user= space. The kernel should provide an interface to expose this emulated disp= lay as a "real" display to applications - unless this can also be done enti= rely in user space in a generic way. >=20 > We really need to stop seeing per key addressable RGB keyboards as displa= ys: >=20 > 1. Some "pixels" are non square > 2. Not all "pixels" have the same width-height ratio They are quite close to square usually. > 3. Not all rows have the same amount of pixels True for cellphone displays, too. Rounded corners. > 4. There are holes in the rows like between the enter key and then numpad True for cellphone displays, too. Hole for camera. > 5. Some "pixels" have multiple LEDs beneath them. These might be addressa= ble > per LEDs are the sub-pixels ? What about a 2 key wide backspace key vs > the 1 key wide + another key (some non US layouts) in place of the bac= kspace? > This will be "2 pixels" in some layout and 1 pixel with maybe / maybe-= not > 2 subpixels where the sub-pixels may/may not be individually addressab= le ? Treat those "sub pixels" as pixels. They will be in same matrix as the rest. > For all these reasons the display analogy really is a bit fit for these k= eyboards > we tried to come up with a universal coordinate system for these at the b= eginning > of the thread and we failed ... I'd suggest trying harder this time :-). Best regards, Pavel --=20 People of Russia, stop Putin before his war on Ukraine escalates. --M3rPF2twcL7SMY4r Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCZdeHiwAKCRAw5/Bqldv6 8mBLAKC9+qlX2QD/GG3KxUQ6OdUQowvJqgCZAXRtFZkC9ADxIgsvu06fsWM2LoE= =hnzz -----END PGP SIGNATURE----- --M3rPF2twcL7SMY4r--