Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
From:   Stephen Oberholtzer <stevie@qrpff.net>
Date:   Wed, 4 Dec 2019 10:55:42 -0500
Message-ID: <CAD_xR9dfgVeBkm9PZ5gk1fB37vEj+__5O6HUoK6SW3zoOwhDiw@mail.gmail.com>
Subject: Re: [RFC] chromeos_laptop: Make touchscreen work on C720
To:     Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc:     Benson Leung <bleung@chromium.org>, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, Dec 3, 2019 at 2:36 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Stephen,
>
> Does the new kernel work with the original firmware (it should as that's
> what it's been tested with)?

It took some finagling -- MrChromebox is UEFI, but the stock firmware
boots with SeaBIOS -- but I was able to confirm that yes, the
touchscreen works in 4.19 when booting from stock firmware.

> Acer C720 did not use ACPI to describe its devices, it relied on static
> board support to instantiate touchscreen and trackpad and other devices.

> I see that MrChromebox BIOS declares the peripherals on Peppy via ACPI.
> I'd recommend reaching out and ask to update the binding (maybe switch
> from ATML0001 to PRP0001 and full OF-style binding to avoid confusion).

(This is my first-ever foray into anything involving Linux and I2C,
ACPI, _or_ multi-module cooperation, and lucky me, I get all three!
Good thing it's easy to verify that a touchscreen is working.  I also
have no idea what "OF-style binding" is.)

Approaching from the perspective of "I'm designing a brand new kind of
machine that runs Linux, uses ACPI tables, and has one or more Atmel
MXT chips", several things become apparent:

* The driver expects a strange "compatible" property that communicates
no useful information.  The property's value is not read, only its
existence, which is one bit of information. '1' is interpreted as
'this is a supported device', while '0' is interpreted as 'this is not
a supported device'.  But if it's not a supported device, why was the
driver loaded in the first place?

* If it's a touchpad, the driver needs to know what buttons the
various GPIOs are mapped to.
  (Conceivably, it doesn't need to be a touchpad; in my hypothetical
machine, it could also be a touchscreen that also has some input
buttons wired up through the MXT chip, because that saved a nickel per
unit. To support that, however, we would also need an indicator
specifying whether it's a touchscreen or a touchpad, as the driver
interprets 'has buttons' as 'is touchpad'.)

This leads to my first question: With this in mind, couldn't simply
removing the "compatible" check work?
On any existing machine where this driver is loaded and working, the
chromeos_laptop driver has already run and set up the appropriate
device properties first.

--
Stephen