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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 03AE5C77B7C for ; Fri, 12 May 2023 07:21:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240327AbjELHVE (ORCPT ); Fri, 12 May 2023 03:21:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240225AbjELHUJ (ORCPT ); Fri, 12 May 2023 03:20:09 -0400 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D262A1AC for ; Fri, 12 May 2023 00:20:06 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-9660af2499dso1478467066b.0 for ; Fri, 12 May 2023 00:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1683876005; x=1686468005; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WlguJbcdCNMathxuQaT8K1ShmJFBrwncaunh1gm2DMA=; b=zjZZlcSx9bRLm7NbRTThmkTzkg6bZAe2fzIMzQG7yK9ZQxEGgMdJ8YRXv/ExXqGGy8 53J76c6RZ01PDztd4+wRS0qnQSuOAU4EuKqJXt7v7XxfFaW+rKLUMg4AQKIYwxzeo3yf 87d0MBoshdRtjOD17HdXHQyXlDgAfPceSbwvKHR6ObXMAuwkpXdQ8E9ktapySertXzwO 3m8tZUo6x+WYJNmmUet/uYBaikJHufa3SwQpXD4fxDJJlaYSzvlupAKQsgjUs7hxK3ZW rPR4Knx4coKMiNgrZM6ex39R8Ka2NvwFNjQNYHniVJRt5zP5Nj+om9GAh9I6DS7787HX 1d2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683876005; x=1686468005; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WlguJbcdCNMathxuQaT8K1ShmJFBrwncaunh1gm2DMA=; b=ESBJTDaAvuZl9qm+/5DDnMFwlyszqBfK1OWpXA4TN1rilb7mrPqFAN32ANi9TzRAhU tOQz5khmQdTLOuo+95vRQcfe+grT59cba/ur/yqTNeoyzcK6BeHsdcpfnmP7OXc6yJJ4 /UU4ZMXyO23TZePYNxYorDjTDstnH0d7QlS+tKH5CfGR6SkceR04XeeCMv+1iq/byT/c mltUxVkFDsL6FwUI0Do+jUn/k6039aGt097TeJx7svmJcgHu5siKBl0O0uBNOcxYg+/D qSrhG74RjxmV1/OU5gCOtGpQ1g+Ta4qkvgr57gwq7gRlqFZsmYAQxJVQYjDkYChFttqO UbaQ== X-Gm-Message-State: AC+VfDyAoeFFDml8FM/9SM6p/7nBb5hE+ttz2xMNlENoUhKSqq+CYDos gAgkZES5SMZqWEA5OVXS7NtXIQ== X-Google-Smtp-Source: ACHHUZ6kHpYm/ztsDr4Tt/aKxMxZJ/ipvJtZl7+U0eec21VCikd5eB6PtaLIK6EKdEJz94Ji8ssSxA== X-Received: by 2002:a17:907:94d3:b0:96a:58a:6cd8 with SMTP id dn19-20020a17090794d300b0096a058a6cd8mr11609156ejc.9.1683876005348; Fri, 12 May 2023 00:20:05 -0700 (PDT) Received: from ?IPV6:2a02:810d:15c0:828:7ede:fc7b:2328:3883? ([2a02:810d:15c0:828:7ede:fc7b:2328:3883]) by smtp.gmail.com with ESMTPSA id r16-20020a170906c29000b0094f3e169ca5sm4998094ejz.158.2023.05.12.00.20.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 00:20:04 -0700 (PDT) Message-ID: Date: Fri, 12 May 2023 09:20:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH 2/4] dt-bindings: touchscreen: add virtual-touchscreen and virtual-buttons properties Content-Language: en-US To: Michael Riesch , Javier Carrasco , Dmitry Torokhov , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Henrik Rydberg , Bastian Hecht Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, devicetree@vger.kernel.org References: <20230510-feature-ts_virtobj_patch-v1-0-5ae5e81bc264@wolfvision.net> <20230510-feature-ts_virtobj_patch-v1-2-5ae5e81bc264@wolfvision.net> <280ab18d-bbfa-9920-5f1b-d069fd866e1f@linaro.org> <18526d2a-ac5f-2b26-9ed3-5a82f20cac86@wolfvision.net> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org On 12/05/2023 09:08, Michael Riesch wrote: > Hi Krzysztof, > >>> These buttons are actually physical i.e. printed and with a given >>> functionality, but still part of the touchscreen as the physical device >>> is not aware of them. Therefore they only make sense in the touchscreen >>> context. >> >> So basically you still have the same touchscreen under the buttons and >> these are not separate devices. Whether someone put a sticker on >> touchscreen, does not really change hardware behavior and it's up to >> system to handle this. What you are trying to do here is to create >> virtual buttons through Devicetree and DT is not for that. > > I have already addressed a similar statement here: > https://lore.kernel.org/lkml/20230504042927.GA1129520@quokka/t/#m1a93595c36535312df0061459a1da5e062de6c44 > but let me extend this comment a bit. > > The notion of "someone putting a sticker on touchscreen" does not really > reflect the use case we have in mind. We are talking about devices that > are shipped from the factory in a particular configuration, e.g., > > +-----------------------+---------+ > | | power | > | | button | > | touchscreen +---------+ > | (behind: display) | return | > | | button | > +-----------------------+---------+ > > Here, the real touchscreen is larger than the display. The display is > behind the "touchscreen" part. Behind the buttons there are symbols > engraved in metal or printed foils or what not. I just would like to > make it clear that these symbols are not going to change. > > We believe that the engraved or printed symbols actually define the > (expected) hardware behavior. Of course there is a virtual notion to > that, and of course it would be possible to let the power button work as > return button and vice versa in software. However, the user sees the > engraved or printed symbols (which are not going to change) and expects > the device to react appropriately. OK, I actually missed the concept that display is not equal to the touchscreen ("screen" actually suggests display :) ). In your case here it sounds good, but please put some parts of this description into this common binding. The sketch above is nice, especially if you can point where the virtual origin x/y are. Picture is thousands words. > > Now if you suggest that the system (that is user space, right?) should > handle this, then the question would be which component is supposed to > handle the touchscreen events and react accordingly. I don't have an > answer to that and hope I don't need to find one. But independent of > that, a configuration file is required that defines the area of the > virtual buttons etc. Wouldn't this be similar to the (mostly) beloved > xorg.conf containing the definitions of input devices? If the case was a bit different - e.g. display is everywhere - I could easily imagine that on the device rotation you want to move (re-position) the buttons. Or if user has some accessibility option enabled, you want bigger buttons. Then it would be a prove that it must be configured and managed from user-space. How, I don't know. Best regards, Krzysztof