[v5,2/4] dt-bindings: touchscreen: add overlay-touchscreen and overlay-buttons properties
Message ID | 20230510-feature-ts_virtobj_patch-v5-2-ff6b5c4db693@wolfvision.net |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp4049002vqb; Tue, 17 Oct 2023 04:00:59 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHmrB/kh8z0aQPChlVlWRwPt8kjD/q26TpOhbO7nFm0RPFgkC9MgfjcHYtlXkHuodfFR3ny X-Received: by 2002:a05:6871:468d:b0:1d5:1a99:537f with SMTP id ni13-20020a056871468d00b001d51a99537fmr1962283oab.2.1697540459124; Tue, 17 Oct 2023 04:00:59 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1697540459; cv=pass; d=google.com; s=arc-20160816; b=cf8KFJf3dy/rfQWuav9Eo5OvaOm/B+4G7RrImdyl1l2WqvMPN9r81geG3aa48fjta7 gbwDN29NNBEKkwVz+XTL3qynxXFm8WOkpuLtC9Lxi5n+87AtCYBqnZbTsgA9OI7Y1iMf UGC/kZKjJq5x/oSfq94J3myjKhoT7aVrjKeBRCAet1Q1eR2KPjeuhMefkOasjcZSIVtA FWfJGJZbJLY4cg+XR9DAsiKWyiGJROTp4R7PIZNMMqr/D6Bn+9PSge47FRYTVa8kmERN 5ChqEzyZS0lXW9oFDthDHELQRbiB0H1e14bQKoYWwfPUAVw3yVRb1XK4jKRJb+nbeYL/ jucg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:cc:to:in-reply-to:references :message-id:content-transfer-encoding:subject:date:from :dkim-signature; bh=q2PhTsUJcMQ4SW1OvpZNerNhpFQAX2maswC0f+vfs70=; fh=Q2yKSKQ8R8KEx8rDZBLMysofwwLup8S/+bsFQ+KI0PY=; b=klgL4Ka4OOgE+3jFPh05FOosu0EWpckPDRUHX0mixiXrYTbOAa/eoEo7YVWpYBWWA7 Eq/SbmW0YR27rfAX/JukVWc0TZh2DV2iWiexOI7ppR3FiH2KFx+opcK6o7XgOMTYIpGR g6NMVk6buN4QW93sUR1hQrf9pgiB24GdKev7uTIiNCtNogjcunRZISBw3XWiJzGYCTqs LckPISKwluH/+2YVtuSA2BjihlZrVcnRARqxcgNuevXi5vKycxlUo070q4C0IOCX0bCj lvIhrGFdvykPNSkm+5vCXNuS/8QSLME6gjErpzZ1HxgCDPRpO08cqQPHGDu5sVpDN4qq JkDg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@wolfvision.net header.s=selector2 header.b=1vComKO4; arc=pass (i=1 spf=pass spfdomain=wolfvision.net dkim=pass dkdomain=wolfvision.net dmarc=pass fromdomain=wolfvision.net); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=wolfvision.net Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id c37-20020a631c25000000b00578c64433d5si1485633pgc.877.2023.10.17.04.00.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Oct 2023 04:00:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@wolfvision.net header.s=selector2 header.b=1vComKO4; arc=pass (i=1 spf=pass spfdomain=wolfvision.net dkim=pass dkdomain=wolfvision.net dmarc=pass fromdomain=wolfvision.net); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=wolfvision.net Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 3CEAA80BB3C4; Tue, 17 Oct 2023 04:00:56 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343758AbjJQLA1 (ORCPT <rfc822;hjfbswb@gmail.com> + 19 others); Tue, 17 Oct 2023 07:00:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234809AbjJQLAW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 17 Oct 2023 07:00:22 -0400 Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2047.outbound.protection.outlook.com [40.107.249.47]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5986B0; Tue, 17 Oct 2023 04:00:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZWmMSVixzF/PIR+tC6JHTsenD9P88P5os/AY41O12ayCN3Blu/EOn1FVsr+HhpwkAo9JaUG+gqItRwcxHu19WmFsU9SX5hqaACr3PcPclreIFUVvIN+1SazdPKaoQVQkey/9ajwTEonZz7ZQFoc68uxRVdhCODx86NWtg5IibO77CdcSDRhBgV6eCVnXGkisPkLeGe0eWOqRy9awtjHYF/jbfv5twa/3CUPEn/LUyYtyoh+6VhNLD93075I7KC1Jre+UX+DYHKUJYwIlM1DVbg+iD1vXBIy4asewZugbyWA2hBdNqH5QMeH/I35r1WEHj1c2GLA7DeuDrlbO6zoREg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=q2PhTsUJcMQ4SW1OvpZNerNhpFQAX2maswC0f+vfs70=; b=cKBZ91FIEF0bChbpdwrIiTA+rxIGHVTz3IRkpS82ZweVm6vNL4A311zVFBi6z/YQIvz2GCvQLUKrR32NXO4MpY4TOcuHG2q5Zi1BvOz0IPNMjmWO4ybPdVOMoiMFrllDxWbB2sDkg2pUJdr4sqzNIGHQmeLf1DvgV8PW3VQ1TCaNBnHNGJEoHYKzYSCtEQpaojcDU/KULPMuU+f42yxGdiIo19XNX1mnUK5/oUsChneffMxmGXGpW3LPC5MMPaiHilGl5xCh4ceBg5vWyX8qat5bpnH8QT9vbEclFJBUQV+VE7+JYaZkhz4Lw9BVyO59ACjiEyghRXnAd+Cl4Z1FWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wolfvision.net; dmarc=pass action=none header.from=wolfvision.net; dkim=pass header.d=wolfvision.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wolfvision.net; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q2PhTsUJcMQ4SW1OvpZNerNhpFQAX2maswC0f+vfs70=; b=1vComKO4VFSPizXJeM3owWTxtyT+y/5eTj0xYPQ0emlhBG9ZA0tKahN+D/INpShv6syk2HcJNdoqntW6n5zWfxBrXsqiQtazuVBhKeGxXVo6YVkoICPTN/DyEq4tHdEfqwPH3ymj5f731ebnZnIUnRuxF+usode5teDJfgZSOUc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=wolfvision.net; Received: from VE1PR08MB4974.eurprd08.prod.outlook.com (2603:10a6:803:111::15) by AS8PR08MB6295.eurprd08.prod.outlook.com (2603:10a6:20b:295::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6886.36; Tue, 17 Oct 2023 11:00:15 +0000 Received: from VE1PR08MB4974.eurprd08.prod.outlook.com ([fe80::bc92:216b:11ed:db63]) by VE1PR08MB4974.eurprd08.prod.outlook.com ([fe80::bc92:216b:11ed:db63%6]) with mapi id 15.20.6886.034; Tue, 17 Oct 2023 11:00:15 +0000 From: Javier Carrasco <javier.carrasco@wolfvision.net> Date: Tue, 17 Oct 2023 13:00:08 +0200 Subject: [PATCH v5 2/4] dt-bindings: touchscreen: add overlay-touchscreen and overlay-buttons properties Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <20230510-feature-ts_virtobj_patch-v5-2-ff6b5c4db693@wolfvision.net> References: <20230510-feature-ts_virtobj_patch-v5-0-ff6b5c4db693@wolfvision.net> In-Reply-To: <20230510-feature-ts_virtobj_patch-v5-0-ff6b5c4db693@wolfvision.net> To: Dmitry Torokhov <dmitry.torokhov@gmail.com>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, Henrik Rydberg <rydberg@bitmath.org>, Bastian Hecht <hechtb@gmail.com>, Michael Riesch <michael.riesch@wolfvision.net> Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, devicetree@vger.kernel.org, Javier Carrasco <javier.carrasco@wolfvision.net> X-Mailer: b4 0.12.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1697540413; l=8076; i=javier.carrasco@wolfvision.net; s=20230509; h=from:subject:message-id; bh=wU9mLFkAGHcvGbxx9FJKDONfjfWjyoVrkM1llQopSTA=; b=XLIuisbolFeig/Z3ayKvnMqCF4whG3kIp9PhOPP9aY9r/G3u7sNSg5rUUSnyIOJXPEb1bWunM CZSxQ/s9Jm0DHjoSEwuA7wCAD/V5FTX7vqM8eOFcgBlF2ECszSHL0gC X-Developer-Key: i=javier.carrasco@wolfvision.net; a=ed25519; pk=tIGJV7M+tCizagNijF0eGMBGcOsPD+0cWGfKjl4h6K8= X-ClientProxiedBy: VI1PR07CA0250.eurprd07.prod.outlook.com (2603:10a6:803:b4::17) To VE1PR08MB4974.eurprd08.prod.outlook.com (2603:10a6:803:111::15) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VE1PR08MB4974:EE_|AS8PR08MB6295:EE_ X-MS-Office365-Filtering-Correlation-Id: 6075dda0-d713-4eb3-df1d-08dbcf003e1c X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: f9arAlYJR5derrwSuzQAjKxdKsntFwhMekMcG+y78MaXQmpGlU3oFhwjHCQ1pIctcUN3JMI56pl15nuBVQ2m+igStkQ6G18xI060b70pIAz2xr+9bXG7EUj1tCIA/KWWrFMkl+MOK2gVh+GJCO6x75U+qD8nRBD2AV9aDZZETjRexl8syum/73EZ5WGO+u6npV4TCNc/AwpZX5vgNMUVGswmrrm1aodlTiYMoChvbxkQOLjAXGlAqgBNGXVlqu2e6uDEA0DN4yOLvLRzK/RyiO6evHl5KbuuKutnc51f7Vc92COGTwjQ4ssPufDi7PSVh0RI5TGTaejoMKQ58MU93D9Mz8F1JOftuB/ttMoM7joTpSDQSsOxk/xTkkngh9OHGG+EUYGyMA5KMTPIC1Yl2GvRCHeEv74SNxpYpdbWAAuf10T0yiR7sM3GBgjNwTMHOdxy3iWpTeGrrYDCEcdrwUgvmWcCuvijOYjUA3UT9TI/4dTeGSgZpNRPSzfKr/UvX6VWhSrLARIEaK3XMERkKuk8SEQhegMyd0rusk+30EGItFtWFj9FhnUbTLR6rODzav+9u2+oiaVuAqeGGdcquz/ty6cw99SvKnpmzESM9iDntWM3yrgT1+Mo+dyLQKKz X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VE1PR08MB4974.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(346002)(376002)(39840400004)(396003)(366004)(230922051799003)(451199024)(64100799003)(186009)(1800799009)(107886003)(478600001)(38100700002)(52116002)(6506007)(2616005)(6486002)(38350700005)(26005)(6512007)(6666004)(41300700001)(44832011)(5660300002)(4326008)(8936002)(8676002)(316002)(66946007)(86362001)(110136005)(2906002)(66556008)(66476007)(6636002)(36756003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?q?GjGb6IJm93TKRDL0QvzraKzfNiD2?= =?utf-8?q?X/nRWD3Wx2lua1OnSgkZb7o4r+E4BJAX70gAMz3yNc5hQTDLGJqv44U5hFCkxZZbA?= =?utf-8?q?ERxdKdrizeDTDz+q1RfeHKkmZj9xf1XjNZj/UGAopk7XQerN1HFqfCy+QWRQu7Mv7?= =?utf-8?q?2VHRL3feRV62KPCUkvOSJpxVgTwa1tG/n6lyEKN5n46Tw8hcT4BFolW6myYxj5aQg?= =?utf-8?q?+fVlvJeF+zKpA9GkAWNgz+pQBpVq/GBwpJjJ0J+WNRV+LQm7QcPeXEu9dYrYs9IhG?= =?utf-8?q?JDHn9vSSlXNCoSqAfy2dsE4JW5en5tCRifdzdDBehU/lAzepO39qSdHeBTfq+tr2g?= =?utf-8?q?Kgqb1asRSPKasymuCDRCIkk/k6L6m5yEY7/xN1nS52uPkt8V2X2mxuGMhYVMJei9F?= =?utf-8?q?wxN1WQxY8lypSKzdaqLmYHQbBaJMJUsR3mwq83VjgMtvx8P9SQijX8334TAK6dPpV?= =?utf-8?q?s+TLnT7RZ3x6BAxSJWVnhTWcPato7RjsHNQAXZOOQVruj7lFWGOQ0Q3b0hcI3JXD1?= =?utf-8?q?I9n4/hcaf+p0W5okcwV4BkyYQqd+Sn1IxSUNTTBerIpnVTQA1JpPBBo7lY1bZSbso?= =?utf-8?q?YVyRo7708nCqrTbpXKNEO2fy4hPNRc+fzRuKLO3v/suPllc/ET6PkqonxywGQn7Q/?= =?utf-8?q?Z3W4ffa7FOL4q0ZLHHrrgHkyTJLwF7P07qgDKSmV84FOdlsN1DlmK0q58IBW9CU0R?= =?utf-8?q?iGeZ5bTy3gwCkNV0u5fN1Y05Tw96vo9JoWaJ3x0eN1UwpJvkhkQPFLICB5zuOPjsX?= =?utf-8?q?F+uDaS+qDKol7xFOC9YYQxER8YIC1cMQQZ/l76Xoc5M68JT4SppjUAzG1D9qzZT1S?= =?utf-8?q?5cwQ02DHhhO4oeg6Wjb/jXmn55MdgQ6iP2n7mCphprffByl22E5b2x2hPoTB4VSrm?= =?utf-8?q?KHQ6I6YD/0jm/IqjDPMgz7ZK++piX74Wq9eukDbenouaonKKF1DI1XiHzZ0PiVxm3?= =?utf-8?q?tX5j31artSccmo6h8F9X+WnqQ/DOnfbSpBtt2IgI9dnEDlylxnzp3lEp/6Zy/j2A+?= =?utf-8?q?4y89LaPyIdcfFrAQXvyyID1AwSvl0YA5fJL47Kq/DtQoZP1ZtB5t9VXSmAuB7shsh?= =?utf-8?q?XGImm29LzpUxWXCEdNtSlgrHK0vyjCXwehFgbkWWRAWUwd8KIqPZHqmMaihoacCXm?= =?utf-8?q?5dg30sRlsqofgRUmdIYp/EELNpGaVp3nJxbllv8EU6Nw0i/LYWBG00JVo8+keuMOX?= =?utf-8?q?usvDciksAp4ZWB5qGUF1Sw3uUOXPltOObxm1Dz5OVHrA76es8h3iZBe60EgSAOsMq?= =?utf-8?q?1QSJ62Tig7NbzizPDzqQyxwmTPoOr2574YTNvwNFIqw/nJxBgJYDnXqPwIfIbAzSp?= =?utf-8?q?uKLIlAjqqjH6IgrtwVOr927CVB4fm/A0bgVGcI7PDP09Vhi0w/jKW3Bi7SHe0Og2z?= =?utf-8?q?lfROUx2r6b0kCdiCMxKJgFsJ3gNDY/4RcvzEbi+bkGd4erVykW79jH3No0+kyQQje?= =?utf-8?q?9qctFs26h4TRZFpTDOwnMxWURfcFKkJAJLLimKfuxBxc3QAUP8EwaQPxQ2anbNsNb?= =?utf-8?q?tEsf7xT3X6aLEKXJOPNzPCbfcqqJpDkFeReM03teisEmgydnrTF98xw=3D?= X-OriginatorOrg: wolfvision.net X-MS-Exchange-CrossTenant-Network-Message-Id: 6075dda0-d713-4eb3-df1d-08dbcf003e1c X-MS-Exchange-CrossTenant-AuthSource: VE1PR08MB4974.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Oct 2023 11:00:15.3057 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e94ec9da-9183-471e-83b3-51baa8eb804f X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: uK4O51GRrmrmeatfZl7n6nWs5hmKHWp0ZXXDF0VNvzLt38JcoKzPWhDF/coMiUoChqG0p0GHIlEONsc+0URNaUECnSymM8yqi3deiDbgNFQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6295 X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 17 Oct 2023 04:00:56 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780000184763038434 X-GMAIL-MSGID: 1780000184763038434 |
Series |
Input: support overlay objects on touchscreens
|
|
Commit Message
Javier Carrasco
Oct. 17, 2023, 11 a.m. UTC
The overlay-touchscreen object defines an area within the touchscreen
where touch events are reported and their coordinates get converted to
the overlay origin. This object avoids getting events from areas that
are physically hidden by overlay frames.
For touchscreens where overlay buttons on the touchscreen surface are
provided, the overlay-buttons object contains a node for every button
and the key event that should be reported when pressed.
Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net>
---
.../bindings/input/touchscreen/touchscreen.yaml | 143 +++++++++++++++++++++
1 file changed, 143 insertions(+)
Comments
Hi Javier, Thank you for continuing to drive this high-quality work. On Tue, Oct 17, 2023 at 01:00:08PM +0200, Javier Carrasco wrote: > The overlay-touchscreen object defines an area within the touchscreen > where touch events are reported and their coordinates get converted to > the overlay origin. This object avoids getting events from areas that > are physically hidden by overlay frames. > > For touchscreens where overlay buttons on the touchscreen surface are > provided, the overlay-buttons object contains a node for every button > and the key event that should be reported when pressed. > > Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> > --- > .../bindings/input/touchscreen/touchscreen.yaml | 143 +++++++++++++++++++++ > 1 file changed, 143 insertions(+) > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml > index 431c13335c40..5c58eb79ee9a 100644 > --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml > +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml > @@ -87,6 +87,129 @@ properties: > touchscreen-y-plate-ohms: > description: Resistance of the Y-plate in Ohms > > + overlay-touchscreen: > + description: Clipped touchscreen area > + > + This object can be used to describe a frame that restricts the area > + within touch events are reported, ignoring the events that occur outside > + this area. This is of special interest if the touchscreen is shipped > + with a physical overlay on top of it with a frame that hides some part > + of the original touchscreen area. > + > + The x-origin and y-origin properties of this object define the offset of > + a new origin from where the touchscreen events are referenced. > + This offset is applied to the events accordingly. The x-size and y-size > + properties define the size of the overlay-touchscreen (effective area). > + > + The following example shows the new touchscreen area and the new origin > + (0',0') for the touch events generated by the device. > + > + Touchscreen (full area) > + ┌────────────────────────────────────────┐ > + │ ┌───────────────────────────────┐ │ > + │ │ │ │ > + │ ├ y-size │ │ > + │ │ │ │ > + │ │ overlay-touchscreen │ │ > + │ │ │ │ > + │ │ │ │ > + │ │ x-size │ │ > + │ ┌└──────────────┴────────────────┘ │ > + │(0',0') │ > + ┌└────────────────────────────────────────┘ > + (0,0) > + > + where (0',0') = (0+x-origin,0+y-origin) > + > + type: object > + $ref: '#/$defs/overlay-node' > + unevaluatedProperties: false > + > + required: > + - x-origin > + - y-origin > + - x-size > + - y-size > + > + overlay-buttons: > + description: list of nodes defining the buttons on the touchscreen > + > + This object can be used to describe buttons on the touchscreen area, > + reporting the touch events on their surface as key events instead of > + the original touch events. > + > + This is of special interest if the touchscreen is shipped with a > + physical overlay on top of it where a number of buttons with some > + predefined functionality are printed. In that case a specific behavior > + is expected from those buttons instead of raw touch events. > + > + The overlay-buttons properties define a per-button area as well as an > + origin relative to the real touchscreen origin. Touch events within the > + button area are reported as the key event defined in the linux,code > + property. Given that the key events do not provide coordinates, the > + button origin is only used to place the button area on the touchscreen > + surface. Any event outside the overlay-buttons object is reported as a > + touch event with no coordinate transformation. > + > + The following example shows a touchscreen with a single button on it > + > + Touchscreen (full area) > + ┌───────────────────────────────────┐ > + │ │ > + │ │ > + │ ┌─────────┐ │ > + │ │button 0 │ │ > + │ │KEY_POWER│ │ > + │ └─────────┘ │ > + │ │ > + │ │ > + ┌└───────────────────────────────────┘ > + (0,0) > + > + The overlay-buttons object can be combined with the overlay-touchscreen > + object as shown in the following example. In that case only the events > + within the overlay-touchscreen object are reported as touch events. > + > + Touchscreen (full area) > + ┌─────────┬──────────────────────────────┐ > + │ │ │ > + │ │ ┌───────────────────────┐ │ > + │ button 0│ │ │ │ > + │KEY_POWER│ │ │ │ > + │ │ │ │ │ > + ├─────────┤ │ overlay-touchscreen │ │ > + │ │ │ │ │ > + │ │ │ │ │ > + │ button 1│ │ │ │ > + │ KEY_INFO│ ┌└───────────────────────┘ │ > + │ │(0',0') │ > + ┌└─────────┴──────────────────────────────┘ > + (0,0) > + > + type: object I am still confused why the buttons need to live under an 'overlay-buttons' parent node, which seems like an imaginary boundary. In my view, the touch surface comprises the following types of rectangular areas: 1. A touchscreen, wherein granular coordinates and pressure are reported. 2. A momentary button, wherein pressure is quantized into a binary value (press or release), and coordinates are ignored. Any contact that falls outside of (1) and (2) is presumed to be part of a border or matting, and is hence ignored. Areas (1) and (2) exist in the same "plane", so why can they not reside under the same parent node? The following seems much more representative of the actual hardware we intend to describe in the device tree: touchscreen { compatible = "..."; reg = <...>; /* raw coordinates reported here */ touch-area-1 { x-origin = <...>; y-origin = <...>; x-size = <...>; y-size = <...>; }; /* a button */ touch-area-2a { x-origin = <...>; y-origin = <...>; x-size = <...>; y-size = <...>; linux,code = <KEY_POWER>; }; /* another button */ touch-area-2b { x-origin = <...>; y-origin = <...>; x-size = <...>; y-size = <...>; linux,code = <KEY_INFO>; }; }; With this method, the driver merely stores a list head. The parsing code then walks the client device node; for each touch* child encountered, it allocates memory for a structure of five members, and adds it to the list. The event handling code then simply iterates through the list and checks if the coordinates reported by the hardware fall within each rectangle. If so, and the keycode in the list element is equal to KEY_RESERVED (zero), we assume the rectangle is of type (1); the coordinates are passed to touchscreen_report_pos() and the pressure is reported as well. If the keycode is not equal to KEY_RESERVED (e.g. KEY_POWER), we assume the rectangle is of type (2); input_report_key() is called instead and the coordinates are ignored altogether. Instead, the existing implementation has two separate structures, one of which inherits the other. Its corresponding properties are then parsed in a separate function to account for the fact that the two structures exist at different layers in the heirarchy. My argument is that all nodes can be parsed in the same way, without having to understand whether they represent case (1) or (2). The existing method also has to count the nodes; this would not be necessary with a linked list. Can you help me understand why the buttons must be "wrapped" in their own node? As I mention in v2, this isn't a deal breaker necessarily, but I'd like to understand the reasoning behind what I interpret as additional complexity, and a degree of separation from a natural description of the touch surface. The only reason I can think to insert the 'overlay-buttons' parent is in case we want to specify a property within this node that applies to all buttons, but this does not exist in the current implementation, nor do I see a compelling reason to do so in the future. > + > + patternProperties: > + '^button-': > + type: object > + description: > + Each button (key) is represented as a sub-node. > + $ref: '#/$defs/overlay-node' > + unevaluatedProperties: false > + > + properties: > + label: > + $ref: /schemas/types.yaml#/definitions/string > + description: descriptive name of the button > + > + linux,code: true > + > + required: > + - linux,code > + - x-origin > + - y-origin > + - x-size > + - y-size > + > dependencies: > touchscreen-size-x: [ touchscreen-size-y ] > touchscreen-size-y: [ touchscreen-size-x ] > @@ -94,3 +217,23 @@ dependencies: > touchscreen-y-mm: [ touchscreen-x-mm ] > > additionalProperties: true > + > +$defs: > + overlay-node: > + type: object > + properties: > + x-origin: > + description: horizontal origin of the node area > + $ref: /schemas/types.yaml#/definitions/uint32 > + > + y-origin: > + description: vertical origin of the node area > + $ref: /schemas/types.yaml#/definitions/uint32 > + > + x-size: > + description: horizontal resolution of the node area > + $ref: /schemas/types.yaml#/definitions/uint32 > + > + y-size: > + description: vertical resolution of the node area > + $ref: /schemas/types.yaml#/definitions/uint32 > > -- > 2.39.2 > Kind regards, Jeff LaBundy
Hi Jeff, On 26.10.23 16:46, Jeff LaBundy wrote: > I am still confused why the buttons need to live under an 'overlay-buttons' > parent node, which seems like an imaginary boundary. In my view, the touch > surface comprises the following types of rectangular areas: > > 1. A touchscreen, wherein granular coordinates and pressure are reported. > 2. A momentary button, wherein pressure is quantized into a binary value > (press or release), and coordinates are ignored. > > Any contact that falls outside of (1) and (2) is presumed to be part of a > border or matting, and is hence ignored. > > Areas (1) and (2) exist in the same "plane", so why can they not reside > under the same parent node? The following seems much more representative > of the actual hardware we intend to describe in the device tree: > > touchscreen { > compatible = "..."; > reg = <...>; > > /* raw coordinates reported here */ > touch-area-1 { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > }; > > /* a button */ > touch-area-2a { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > linux,code = <KEY_POWER>; > }; > > /* another button */ > touch-area-2b { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > linux,code = <KEY_INFO>; > }; > }; > > With this method, the driver merely stores a list head. The parsing code > then walks the client device node; for each touch* child encountered, it > allocates memory for a structure of five members, and adds it to the list. > > The event handling code then simply iterates through the list and checks > if the coordinates reported by the hardware fall within each rectangle. If > so, and the keycode in the list element is equal to KEY_RESERVED (zero), > we assume the rectangle is of type (1); the coordinates are passed to > touchscreen_report_pos() and the pressure is reported as well. > > If the keycode is not equal to KEY_RESERVED (e.g. KEY_POWER), we assume > the rectangle is of type (2); input_report_key() is called instead and > the coordinates are ignored altogether. > > Instead, the existing implementation has two separate structures, one of > which inherits the other. Its corresponding properties are then parsed in > a separate function to account for the fact that the two structures exist > at different layers in the heirarchy. > > My argument is that all nodes can be parsed in the same way, without having > to understand whether they represent case (1) or (2). The existing method > also has to count the nodes; this would not be necessary with a linked list. > > Can you help me understand why the buttons must be "wrapped" in their own > node? As I mention in v2, this isn't a deal breaker necessarily, but I'd > like to understand the reasoning behind what I interpret as additional > complexity, and a degree of separation from a natural description of the > touch surface. > > The only reason I can think to insert the 'overlay-buttons' parent is in > case we want to specify a property within this node that applies to all > buttons, but this does not exist in the current implementation, nor do I > see a compelling reason to do so in the future. > > Kind regards, > Jeff LaBundy I was about to send a gentle ping when I saw that you have reviewed the last version almost a month ago. Somehow I overlooked your emails, sorry for the late reply. As I said in a previous discussion, there is no unavoidable reason why the buttons should have their own node. I just wanted to make clear that there are different objects with different properties and in case of some new appear, there is no need to check several properties to build a decision tree. Moreover, the device tree is self-documented and even if you never saw this feature before, there is no need to explain anything: every object type has its node and the boundary I would be drawing would be logical, not physical. On the other hand, with the current implementation a single keycode property is enough to tell what object is being handled as there are only two types of objects. If some new objects appear and the decision tree ends up getting too complex, some other solution might be more suitable. But until that happens (if ever), I can give up on the button nodes and simplify the code with a list head. I will work on that approach for v7. This will require some major modifications in the code and the bindings, so it will take some time until the next version is ready and gets proper testing. Your comments on 1/4 do not require further discussion and will be applied as well. Thanks again for your thorough review and enriching feedback. Best regards, Javier Carrasco
Hi Jeff, On 26.10.23 16:46, Jeff LaBundy wrote: > Hi Javier, > > Thank you for continuing to drive this high-quality work. > > On Tue, Oct 17, 2023 at 01:00:08PM +0200, Javier Carrasco wrote: >> The overlay-touchscreen object defines an area within the touchscreen >> where touch events are reported and their coordinates get converted to >> the overlay origin. This object avoids getting events from areas that >> are physically hidden by overlay frames. >> >> For touchscreens where overlay buttons on the touchscreen surface are >> provided, the overlay-buttons object contains a node for every button >> and the key event that should be reported when pressed. >> >> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> >> --- >> .../bindings/input/touchscreen/touchscreen.yaml | 143 +++++++++++++++++++++ >> 1 file changed, 143 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml >> index 431c13335c40..5c58eb79ee9a 100644 >> --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml >> +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml >> @@ -87,6 +87,129 @@ properties: >> touchscreen-y-plate-ohms: >> description: Resistance of the Y-plate in Ohms >> >> + overlay-touchscreen: >> + description: Clipped touchscreen area >> + >> + This object can be used to describe a frame that restricts the area >> + within touch events are reported, ignoring the events that occur outside >> + this area. This is of special interest if the touchscreen is shipped >> + with a physical overlay on top of it with a frame that hides some part >> + of the original touchscreen area. >> + >> + The x-origin and y-origin properties of this object define the offset of >> + a new origin from where the touchscreen events are referenced. >> + This offset is applied to the events accordingly. The x-size and y-size >> + properties define the size of the overlay-touchscreen (effective area). >> + >> + The following example shows the new touchscreen area and the new origin >> + (0',0') for the touch events generated by the device. >> + >> + Touchscreen (full area) >> + ┌────────────────────────────────────────┐ >> + │ ┌───────────────────────────────┐ │ >> + │ │ │ │ >> + │ ├ y-size │ │ >> + │ │ │ │ >> + │ │ overlay-touchscreen │ │ >> + │ │ │ │ >> + │ │ │ │ >> + │ │ x-size │ │ >> + │ ┌└──────────────┴────────────────┘ │ >> + │(0',0') │ >> + ┌└────────────────────────────────────────┘ >> + (0,0) >> + >> + where (0',0') = (0+x-origin,0+y-origin) >> + >> + type: object >> + $ref: '#/$defs/overlay-node' >> + unevaluatedProperties: false >> + >> + required: >> + - x-origin >> + - y-origin >> + - x-size >> + - y-size >> + >> + overlay-buttons: >> + description: list of nodes defining the buttons on the touchscreen >> + >> + This object can be used to describe buttons on the touchscreen area, >> + reporting the touch events on their surface as key events instead of >> + the original touch events. >> + >> + This is of special interest if the touchscreen is shipped with a >> + physical overlay on top of it where a number of buttons with some >> + predefined functionality are printed. In that case a specific behavior >> + is expected from those buttons instead of raw touch events. >> + >> + The overlay-buttons properties define a per-button area as well as an >> + origin relative to the real touchscreen origin. Touch events within the >> + button area are reported as the key event defined in the linux,code >> + property. Given that the key events do not provide coordinates, the >> + button origin is only used to place the button area on the touchscreen >> + surface. Any event outside the overlay-buttons object is reported as a >> + touch event with no coordinate transformation. >> + >> + The following example shows a touchscreen with a single button on it >> + >> + Touchscreen (full area) >> + ┌───────────────────────────────────┐ >> + │ │ >> + │ │ >> + │ ┌─────────┐ │ >> + │ │button 0 │ │ >> + │ │KEY_POWER│ │ >> + │ └─────────┘ │ >> + │ │ >> + │ │ >> + ┌└───────────────────────────────────┘ >> + (0,0) >> + >> + The overlay-buttons object can be combined with the overlay-touchscreen >> + object as shown in the following example. In that case only the events >> + within the overlay-touchscreen object are reported as touch events. >> + >> + Touchscreen (full area) >> + ┌─────────┬──────────────────────────────┐ >> + │ │ │ >> + │ │ ┌───────────────────────┐ │ >> + │ button 0│ │ │ │ >> + │KEY_POWER│ │ │ │ >> + │ │ │ │ │ >> + ├─────────┤ │ overlay-touchscreen │ │ >> + │ │ │ │ │ >> + │ │ │ │ │ >> + │ button 1│ │ │ │ >> + │ KEY_INFO│ ┌└───────────────────────┘ │ >> + │ │(0',0') │ >> + ┌└─────────┴──────────────────────────────┘ >> + (0,0) >> + >> + type: object > > I am still confused why the buttons need to live under an 'overlay-buttons' > parent node, which seems like an imaginary boundary. In my view, the touch > surface comprises the following types of rectangular areas: > > 1. A touchscreen, wherein granular coordinates and pressure are reported. > 2. A momentary button, wherein pressure is quantized into a binary value > (press or release), and coordinates are ignored. > > Any contact that falls outside of (1) and (2) is presumed to be part of a > border or matting, and is hence ignored. > > Areas (1) and (2) exist in the same "plane", so why can they not reside > under the same parent node? The following seems much more representative > of the actual hardware we intend to describe in the device tree: > > touchscreen { > compatible = "..."; > reg = <...>; > > /* raw coordinates reported here */ > touch-area-1 { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > }; > > /* a button */ > touch-area-2a { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > linux,code = <KEY_POWER>; > }; > > /* another button */ > touch-area-2b { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > linux,code = <KEY_INFO>; > }; > }; > Now that I am working on the approach you suggested, I see that some things can get slightly more complicated. I still think that it is worth a try, but I would like to discuss a couple of points. The node parsing is not that simple anymore because the touch-area nodes are only surrounded by the touchscreen node. Theoretically they could be even be defined with other properties in between. The current approach only needs to find the overlay-buttons parent and iterate over all the inner nodes(simply by calling device_get_named_child_node() and fwnode_for_each_child_node() the parsing is achieved in two lines + error checking). So maybe even if we opt for the single-object approach, an overlay node to group all the touch-areas could simplify the parsing. Or did you have a different approach in mind? Your example would turn into this one: touchscreen { compatible = "..."; reg = <...>; touch-overlay { /* raw coordinates reported here */ touch-area-1 { x-origin = <...>; y-origin = <...>; x-size = <...>; y-size = <...>; }; /* a button */ touch-area-2a { x-origin = <...>; y-origin = <...>; x-size = <...>; y-size = <...>; linux,code = <KEY_POWER>; }; /* another button */ touch-area-2b { x-origin = <...>; y-origin = <...>; x-size = <...>; y-size = <...>; linux,code = <KEY_INFO>; }; }; }; In my opinion it looks cleaner as well because you are defining a physical object: the overlay. > With this method, the driver merely stores a list head. The parsing code > then walks the client device node; for each touch* child encountered, it > allocates memory for a structure of five members, and adds it to the list. > The button objects do not only store the keycode, but also the slot and if they are pressed or not. I could allocate memory for these members as well, but maybe an additional struct with the button-specific members set to NULL for the touch areas with keycode = KEY_RESERVED would make sense. I don't know if that's adding too much overhead for two members though. > The event handling code then simply iterates through the list and checks > if the coordinates reported by the hardware fall within each rectangle. If > so, and the keycode in the list element is equal to KEY_RESERVED (zero), > we assume the rectangle is of type (1); the coordinates are passed to > touchscreen_report_pos() and the pressure is reported as well. There is another case to consider that might make the iteration less optimal, but I don't think it will be critical. A button could be defined inside an overlay-touchscreen (no keycode) area. Given that the other way round (a touchscreen inside a button) does not make much sense, the buttons have a higher priority. Let's take your example: imagine that your third area is a button inside the first one. We have to iterate through the whole list until we are sure we checked if there are buttons in the given position, but keeping in mind that the first object already has the right coordinates to handle the touch event. Your approach even allows for multiple no-key areas and we do not know if there are buttons when we iterate (there could be none). Therefore some iterations could be unnecessary, but this is probably an edge case that would cost at most a couple of extra iterations compared to a two-list approach. I will keep on working on the next version with a single list while we clarify these points, so maybe we can save an iteration. > Kind regards, > Jeff LaBundy Best regards, Javier Carrasco
Hi Javier, I am so sorry for the delayed response. On Thu, Nov 23, 2023 at 08:48:56PM +0100, Javier Carrasco wrote: > Hi Jeff, > > On 26.10.23 16:46, Jeff LaBundy wrote: > > Hi Javier, > > > > Thank you for continuing to drive this high-quality work. > > > > On Tue, Oct 17, 2023 at 01:00:08PM +0200, Javier Carrasco wrote: > >> The overlay-touchscreen object defines an area within the touchscreen > >> where touch events are reported and their coordinates get converted to > >> the overlay origin. This object avoids getting events from areas that > >> are physically hidden by overlay frames. > >> > >> For touchscreens where overlay buttons on the touchscreen surface are > >> provided, the overlay-buttons object contains a node for every button > >> and the key event that should be reported when pressed. > >> > >> Signed-off-by: Javier Carrasco <javier.carrasco@wolfvision.net> > >> --- > >> .../bindings/input/touchscreen/touchscreen.yaml | 143 +++++++++++++++++++++ > >> 1 file changed, 143 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml > >> index 431c13335c40..5c58eb79ee9a 100644 > >> --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml > >> +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml > >> @@ -87,6 +87,129 @@ properties: > >> touchscreen-y-plate-ohms: > >> description: Resistance of the Y-plate in Ohms > >> > >> + overlay-touchscreen: > >> + description: Clipped touchscreen area > >> + > >> + This object can be used to describe a frame that restricts the area > >> + within touch events are reported, ignoring the events that occur outside > >> + this area. This is of special interest if the touchscreen is shipped > >> + with a physical overlay on top of it with a frame that hides some part > >> + of the original touchscreen area. > >> + > >> + The x-origin and y-origin properties of this object define the offset of > >> + a new origin from where the touchscreen events are referenced. > >> + This offset is applied to the events accordingly. The x-size and y-size > >> + properties define the size of the overlay-touchscreen (effective area). > >> + > >> + The following example shows the new touchscreen area and the new origin > >> + (0',0') for the touch events generated by the device. > >> + > >> + Touchscreen (full area) > >> + ┌────────────────────────────────────────┐ > >> + │ ┌───────────────────────────────┐ │ > >> + │ │ │ │ > >> + │ ├ y-size │ │ > >> + │ │ │ │ > >> + │ │ overlay-touchscreen │ │ > >> + │ │ │ │ > >> + │ │ │ │ > >> + │ │ x-size │ │ > >> + │ ┌└──────────────┴────────────────┘ │ > >> + │(0',0') │ > >> + ┌└────────────────────────────────────────┘ > >> + (0,0) > >> + > >> + where (0',0') = (0+x-origin,0+y-origin) > >> + > >> + type: object > >> + $ref: '#/$defs/overlay-node' > >> + unevaluatedProperties: false > >> + > >> + required: > >> + - x-origin > >> + - y-origin > >> + - x-size > >> + - y-size > >> + > >> + overlay-buttons: > >> + description: list of nodes defining the buttons on the touchscreen > >> + > >> + This object can be used to describe buttons on the touchscreen area, > >> + reporting the touch events on their surface as key events instead of > >> + the original touch events. > >> + > >> + This is of special interest if the touchscreen is shipped with a > >> + physical overlay on top of it where a number of buttons with some > >> + predefined functionality are printed. In that case a specific behavior > >> + is expected from those buttons instead of raw touch events. > >> + > >> + The overlay-buttons properties define a per-button area as well as an > >> + origin relative to the real touchscreen origin. Touch events within the > >> + button area are reported as the key event defined in the linux,code > >> + property. Given that the key events do not provide coordinates, the > >> + button origin is only used to place the button area on the touchscreen > >> + surface. Any event outside the overlay-buttons object is reported as a > >> + touch event with no coordinate transformation. > >> + > >> + The following example shows a touchscreen with a single button on it > >> + > >> + Touchscreen (full area) > >> + ┌───────────────────────────────────┐ > >> + │ │ > >> + │ │ > >> + │ ┌─────────┐ │ > >> + │ │button 0 │ │ > >> + │ │KEY_POWER│ │ > >> + │ └─────────┘ │ > >> + │ │ > >> + │ │ > >> + ┌└───────────────────────────────────┘ > >> + (0,0) > >> + > >> + The overlay-buttons object can be combined with the overlay-touchscreen > >> + object as shown in the following example. In that case only the events > >> + within the overlay-touchscreen object are reported as touch events. > >> + > >> + Touchscreen (full area) > >> + ┌─────────┬──────────────────────────────┐ > >> + │ │ │ > >> + │ │ ┌───────────────────────┐ │ > >> + │ button 0│ │ │ │ > >> + │KEY_POWER│ │ │ │ > >> + │ │ │ │ │ > >> + ├─────────┤ │ overlay-touchscreen │ │ > >> + │ │ │ │ │ > >> + │ │ │ │ │ > >> + │ button 1│ │ │ │ > >> + │ KEY_INFO│ ┌└───────────────────────┘ │ > >> + │ │(0',0') │ > >> + ┌└─────────┴──────────────────────────────┘ > >> + (0,0) > >> + > >> + type: object > > > > I am still confused why the buttons need to live under an 'overlay-buttons' > > parent node, which seems like an imaginary boundary. In my view, the touch > > surface comprises the following types of rectangular areas: > > > > 1. A touchscreen, wherein granular coordinates and pressure are reported. > > 2. A momentary button, wherein pressure is quantized into a binary value > > (press or release), and coordinates are ignored. > > > > Any contact that falls outside of (1) and (2) is presumed to be part of a > > border or matting, and is hence ignored. > > > > Areas (1) and (2) exist in the same "plane", so why can they not reside > > under the same parent node? The following seems much more representative > > of the actual hardware we intend to describe in the device tree: > > > > touchscreen { > > compatible = "..."; > > reg = <...>; > > > > /* raw coordinates reported here */ > > touch-area-1 { > > x-origin = <...>; > > y-origin = <...>; > > x-size = <...>; > > y-size = <...>; > > }; > > > > /* a button */ > > touch-area-2a { > > x-origin = <...>; > > y-origin = <...>; > > x-size = <...>; > > y-size = <...>; > > linux,code = <KEY_POWER>; > > }; > > > > /* another button */ > > touch-area-2b { > > x-origin = <...>; > > y-origin = <...>; > > x-size = <...>; > > y-size = <...>; > > linux,code = <KEY_INFO>; > > }; > > }; > > > Now that I am working on the approach you suggested, I see that some > things can get slightly more complicated. I still think that it is worth > a try, but I would like to discuss a couple of points. > > The node parsing is not that simple anymore because the touch-area nodes > are only surrounded by the touchscreen node. Theoretically they could be > even be defined with other properties in between. The current approach > only needs to find the overlay-buttons parent and iterate over all the > inner nodes(simply by calling device_get_named_child_node() and > fwnode_for_each_child_node() the parsing is achieved in two lines + > error checking). So maybe even if we opt for the single-object approach, > an overlay node to group all the touch-areas could simplify the parsing. > Or did you have a different approach in mind? Your example would turn > into this one: > > touchscreen { > compatible = "..."; > reg = <...>; > > touch-overlay { > /* raw coordinates reported here */ > touch-area-1 { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > }; > > /* a button */ > touch-area-2a { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > linux,code = <KEY_POWER>; > }; > > /* another button */ > touch-area-2b { > x-origin = <...>; > y-origin = <...>; > x-size = <...>; > y-size = <...>; > linux,code = <KEY_INFO>; > }; > }; > }; > In my opinion it looks cleaner as well because you are defining a > physical object: the overlay. I like this idea. My original example assumes one would include any node that contains some magic substring (e.g. "touch") in the node name, but thinking about this more, that may be a bit presumptive. It seems safer to wrap all of the children in one newly introduced node as you have done here. > > > With this method, the driver merely stores a list head. The parsing code > > then walks the client device node; for each touch* child encountered, it > > allocates memory for a structure of five members, and adds it to the list. > > > The button objects do not only store the keycode, but also the slot and > if they are pressed or not. I could allocate memory for these members as > well, but maybe an additional struct with the button-specific members > set to NULL for the touch areas with keycode = KEY_RESERVED would make > sense. I don't know if that's adding too much overhead for two members > though. It's still not clear to me why your code is responsible for storing button state; that's the job of the input subsystem. Your code is only responsible for reporting instantaneous state after you are told something interesting happened (e.g. interrupt). The input core is responsible for determining whether the most recently reported state is different than the last. > > > The event handling code then simply iterates through the list and checks > > if the coordinates reported by the hardware fall within each rectangle. If > > so, and the keycode in the list element is equal to KEY_RESERVED (zero), > > we assume the rectangle is of type (1); the coordinates are passed to > > touchscreen_report_pos() and the pressure is reported as well. > > There is another case to consider that might make the iteration less > optimal, but I don't think it will be critical. > > A button could be defined inside an overlay-touchscreen (no keycode) > area. Given that the other way round (a touchscreen inside a button) > does not make much sense, the buttons have a higher priority. > > Let's take your example: imagine that your third area > is a button inside the first one. We have to iterate through the whole > list until we are sure we checked if there are buttons in the given > position, but keeping in mind that the first object already has the > right coordinates to handle the touch event. Your approach even allows > for multiple no-key areas and we do not know if there are buttons when > we iterate (there could be none). > Therefore some iterations could be unnecessary, but this is probably an > edge case that would cost at most a couple of extra iterations compared > to a two-list approach. I think we need to model the overlay as having only two dimensions, with nothing "on top of" or "inside" anything else. For this case of a button inside a touch surface, with the latter making a square doughnut shape of sorts, the 'touch-overlay' node would have five children: two tall rectangles (left and right), two shorter rectanges (above and below the button), and then finally a button in the center. Stated another way, the 'touch-overlay' node shall support an infinite number of infinitesimally small rectangles which comprise the entire touch surface. It shall be possible for a contact to be in zero rectangles, but impossible for any contact to be in more than one rectangle. I appreciate that the devil is in the details, but here we are defining the interface, independent of the implementation. > > I will keep on working on the next version with a single list while we > clarify these points, so maybe we can save an iteration. I see there is a v6 now; I'll take a look at that next. Thanks again for the productive discussion! > > Kind regards, > > Jeff LaBundy > > Best regards, > Javier Carrasco Kind regards, Jeff LaBundy
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml index 431c13335c40..5c58eb79ee9a 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml @@ -87,6 +87,129 @@ properties: touchscreen-y-plate-ohms: description: Resistance of the Y-plate in Ohms + overlay-touchscreen: + description: Clipped touchscreen area + + This object can be used to describe a frame that restricts the area + within touch events are reported, ignoring the events that occur outside + this area. This is of special interest if the touchscreen is shipped + with a physical overlay on top of it with a frame that hides some part + of the original touchscreen area. + + The x-origin and y-origin properties of this object define the offset of + a new origin from where the touchscreen events are referenced. + This offset is applied to the events accordingly. The x-size and y-size + properties define the size of the overlay-touchscreen (effective area). + + The following example shows the new touchscreen area and the new origin + (0',0') for the touch events generated by the device. + + Touchscreen (full area) + ┌────────────────────────────────────────┐ + │ ┌───────────────────────────────┐ │ + │ │ │ │ + │ ├ y-size │ │ + │ │ │ │ + │ │ overlay-touchscreen │ │ + │ │ │ │ + │ │ │ │ + │ │ x-size │ │ + │ ┌└──────────────┴────────────────┘ │ + │(0',0') │ + ┌└────────────────────────────────────────┘ + (0,0) + + where (0',0') = (0+x-origin,0+y-origin) + + type: object + $ref: '#/$defs/overlay-node' + unevaluatedProperties: false + + required: + - x-origin + - y-origin + - x-size + - y-size + + overlay-buttons: + description: list of nodes defining the buttons on the touchscreen + + This object can be used to describe buttons on the touchscreen area, + reporting the touch events on their surface as key events instead of + the original touch events. + + This is of special interest if the touchscreen is shipped with a + physical overlay on top of it where a number of buttons with some + predefined functionality are printed. In that case a specific behavior + is expected from those buttons instead of raw touch events. + + The overlay-buttons properties define a per-button area as well as an + origin relative to the real touchscreen origin. Touch events within the + button area are reported as the key event defined in the linux,code + property. Given that the key events do not provide coordinates, the + button origin is only used to place the button area on the touchscreen + surface. Any event outside the overlay-buttons object is reported as a + touch event with no coordinate transformation. + + The following example shows a touchscreen with a single button on it + + Touchscreen (full area) + ┌───────────────────────────────────┐ + │ │ + │ │ + │ ┌─────────┐ │ + │ │button 0 │ │ + │ │KEY_POWER│ │ + │ └─────────┘ │ + │ │ + │ │ + ┌└───────────────────────────────────┘ + (0,0) + + The overlay-buttons object can be combined with the overlay-touchscreen + object as shown in the following example. In that case only the events + within the overlay-touchscreen object are reported as touch events. + + Touchscreen (full area) + ┌─────────┬──────────────────────────────┐ + │ │ │ + │ │ ┌───────────────────────┐ │ + │ button 0│ │ │ │ + │KEY_POWER│ │ │ │ + │ │ │ │ │ + ├─────────┤ │ overlay-touchscreen │ │ + │ │ │ │ │ + │ │ │ │ │ + │ button 1│ │ │ │ + │ KEY_INFO│ ┌└───────────────────────┘ │ + │ │(0',0') │ + ┌└─────────┴──────────────────────────────┘ + (0,0) + + type: object + + patternProperties: + '^button-': + type: object + description: + Each button (key) is represented as a sub-node. + $ref: '#/$defs/overlay-node' + unevaluatedProperties: false + + properties: + label: + $ref: /schemas/types.yaml#/definitions/string + description: descriptive name of the button + + linux,code: true + + required: + - linux,code + - x-origin + - y-origin + - x-size + - y-size + dependencies: touchscreen-size-x: [ touchscreen-size-y ] touchscreen-size-y: [ touchscreen-size-x ] @@ -94,3 +217,23 @@ dependencies: touchscreen-y-mm: [ touchscreen-x-mm ] additionalProperties: true + +$defs: + overlay-node: + type: object + properties: + x-origin: + description: horizontal origin of the node area + $ref: /schemas/types.yaml#/definitions/uint32 + + y-origin: + description: vertical origin of the node area + $ref: /schemas/types.yaml#/definitions/uint32 + + x-size: + description: horizontal resolution of the node area + $ref: /schemas/types.yaml#/definitions/uint32 + + y-size: + description: vertical resolution of the node area + $ref: /schemas/types.yaml#/definitions/uint32