linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Javier Carrasco <javier.carrasco@wolfvision.net>,
	202305140640.VLcvhR5G-lkp@intel.com,
	kernel test robot <lkp@intel.com>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	Rob Herring <robh+dt@kernel.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,
	oe-kbuild-all@lists.linux.dev
Subject: Re: [PATCH 3/4] Input: st1232 - add virtual touchscreen and buttons handling
Date: Mon, 15 May 2023 10:41:26 +0200	[thread overview]
Message-ID: <e1b34042-9de3-92cb-c04d-ba19e3e87f0f@kernel.org> (raw)
In-Reply-To: <e458d47e-e0da-c6a4-f91a-c44b3a66531b@wolfvision.net>

On 15/05/2023 10:33, Javier Carrasco wrote:
>>> All these functions are declared in the linux/input/ts-virtobj.h header
>>> and also inline-defined there if ts-virtobj is not selected. If it is
>>> selected (either y or M), the functions are exported from
>>> driver/input/touchscreen/ts-virtobj.c. According to the error report,
>>> ts-virtobj was selected as a module.
>>>
>>> I could build the kernel with the three possible configurations
>>> (ts-virtobj y/n/M) for x86_64 as well as for arm64 with no errors or
>>> warnings repeatedly, so I am a bit confused now. I am probably
>>> missing something, but I do not know what.
>>>
>>> I wonder if the new file where the functions are defined (ts-virtobj.c)
>>> could not be found by some reason or if the test build does not like the
>>> way I handled the function declaration/definition. Any hint or advice
>>> would be more than welcome.
>>
>> The report is correct. Build driver builtin and your virtual as module.
> 
> You are right, that was the configuration I was missing, which I
> honestly did not even consider when I tested this feature.
> 
> The problem seems to be that I am using the IS_ENABLED macro which
> returns true if selected as a module, but the define is in that case
> CONFIG_TOUCHSCREEN_TS_VIRTOBJ_MODULE instead of
> CONFIG_TOUCHSCREEN_TS_VIRTOBJ. As I am using the latter define in the
> Makefile, it does not get compiled.

This could be proper solution for build failure but does not look like
the proper solution for entire choice/design. The questions are: why
TOUCHSCREEN_TS_VIRTOBJ should be selectable by user? How can user know
that he needs a driver with VIRTOBJ?

I think he cannot and your config help option suggests that:
"you are using a touchscreen driver that supports printed overlays".
What driver supports or not, is a job for kernel developers. Not for
kernel configurators or distros. User should never investigate whether
his touchscreen driver support printed overlays. Why would user like to
dig into kernel to know that? Thus either your driver should select
VIRTOBJ or depend on it.

Best regards,
Krzysztof


  reply	other threads:[~2023-05-15  8:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-10 13:50 [PATCH 0/4] Input: support virtual objects on touchscreens Javier Carrasco
2023-05-10 13:50 ` [PATCH 1/4] Input: ts-virtobj - Add touchsreen virtual object handling Javier Carrasco
2023-05-10 13:50 ` [PATCH 2/4] dt-bindings: touchscreen: add virtual-touchscreen and virtual-buttons properties Javier Carrasco
2023-05-11  9:45   ` Krzysztof Kozlowski
2023-05-11 10:28     ` Javier Carrasco
2023-05-12  6:25       ` Krzysztof Kozlowski
2023-05-12  7:08         ` Michael Riesch
2023-05-12  7:20           ` Krzysztof Kozlowski
2023-05-12  8:13             ` Michael Riesch
2023-05-10 13:50 ` [PATCH 3/4] Input: st1232 - add virtual touchscreen and buttons handling Javier Carrasco
2023-05-13 22:38   ` kernel test robot
2023-05-15  4:34     ` Javier Carrasco
2023-05-15  6:43       ` Krzysztof Kozlowski
2023-05-15  8:33         ` Javier Carrasco
2023-05-15  8:41           ` Krzysztof Kozlowski [this message]
2023-05-15  9:08             ` Javier Carrasco
2023-05-10 13:50 ` [PATCH 4/4] dt-bindings: input: touchscreen: st1232: add example with ts-virtobj Javier Carrasco
2023-05-10 14:59   ` Krzysztof Kozlowski
2023-05-11  6:26     ` Javier Carrasco

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e1b34042-9de3-92cb-c04d-ba19e3e87f0f@kernel.org \
    --to=krzk@kernel.org \
    --cc=202305140640.VLcvhR5G-lkp@intel.com \
    --cc=conor+dt@kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=hechtb@gmail.com \
    --cc=javier.carrasco@wolfvision.net \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=michael.riesch@wolfvision.net \
    --cc=oe-kbuild-all@lists.linux.dev \
    --cc=robh+dt@kernel.org \
    --cc=rydberg@bitmath.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).