linux-kernel - Re: [RFC] chromeos_laptop: Make touchscreen work on C720

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAD_xR9dfgVeBkm9PZ5gk1fB37vEj+__5O6HUoK6SW3zoOwhDiw@mail.gmail.com>
Date:   Wed, 4 Dec 2019 10:55:42 -0500
From:   Stephen Oberholtzer <stevie@...ff.net>
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     Benson Leung <bleung@...omium.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] chromeos_laptop: Make touchscreen work on C720

On Tue, Dec 3, 2019 at 2:36 PM Dmitry Torokhov
<dmitry.torokhov@...il.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