Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CA+cxXhm45emyg-9j99U=UWY8QuhzWifh+VvsFBaTOTWs81tvUQ@mail.gmail.com>
References: <20210107154200.v4.1.I025fb861cd5fa0ef5286b7dce514728e9df7ae74@changeid> <20210107154200.v4.2.Ibe7d7d53c5b4fe72c60de90111ff763b53f38dbb@changeid> <161041827643.3661239.17919996906733477213@swboyd.mtv.corp.google.com> <CA+cxXhm45emyg-9j99U=UWY8QuhzWifh+VvsFBaTOTWs81tvUQ@mail.gmail.com>
Subject: Re: [PATCH v4 2/2] Input: cros-ec-keyb - Expose function row physical map to userspace
From:   Stephen Boyd <swboyd@chromium.org>
Cc:     LKML <linux-kernel@vger.kernel.org>,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Douglas Anderson <dianders@chromium.org>,
        Benson Leung <bleung@chromium.org>,
        Enric Balletbo i Serra <enric.balletbo@collabora.com>,
        Guenter Roeck <groeck@chromium.org>,
        Lee Jones <lee.jones@linaro.org>, linux-input@vger.kernel.org
To:     Philip Chen <philipchen@chromium.org>
Date:   Tue, 12 Jan 2021 22:49:45 -0800
Message-ID: <161052058590.3661239.5654596152411573148@swboyd.mtv.corp.google.com>
User-Agent: alot/0.9.1
Precedence: bulk

Quoting Philip Chen (2021-01-12 15:55:28)
> On Mon, Jan 11, 2021 at 6:24 PM Stephen Boyd <swboyd@chromium.org> wrote:
> >
> > Quoting Philip Chen (2021-01-07 15:42:09)
> > > The top-row keys in a keyboard usually have dual functionalities.
> > > E.g. A function key "F1" is also an action key "Browser back".
> > >
> > > Therefore, when an application receives an action key code from
> > > a top-row key press, the application needs to know how to correlate
> > > the action key code with the function key code and do the conversion
> > > whenever necessary.
> > >
> > > Since the userpace already knows the key scanlines (row/column)
> > > associated with a received key code. Essentially, the userspace only
> > > needs a mapping between the key row/column and the matching physical
> > > location in the top row.
> > >
> > > This patch enhances the cros-ec-keyb driver to create such a mapping
> > > and expose it to userspace in the form of a function-row-physmap
> > > attribute. The attribute would be a space separated ordered list of
> > > row/column codes, for the keys in the function row, in a left-to-right
> > > order.
> > >
> > > The attribute will only be present when the device has a custom design
> > > for the top-row keys.
> >
> > Is it documented in Documentation/ABI/?
> Not yet.
> Is it proper to add the documentation to `testing/sysfs-driver-input-keyb=
oard`?

Somewhere in testing is fine. I'm not sure if it is a generic proprty
for all keyboards though? What's the path in sysfs?

> >
> > >
> > >  /**
> > >   * struct cros_ec_keyb - Structure representing EC keyboard device
> > >   *
> > > @@ -42,6 +44,9 @@
> > >   * @idev: The input device for the matrix keys.
> > >   * @bs_idev: The input device for non-matrix buttons and switches (o=
r NULL).
> > >   * @notifier: interrupt event notifier for transport devices
> > > + * @function_row_physmap: An array of the encoded rows/columns for t=
he top
> > > + *                        row function keys, in an order from left t=
o right
> > > + * @num_function_row_keys: The number of top row keys in a custom ke=
yboard
> > >   */
> > >  struct cros_ec_keyb {
> > >         unsigned int rows;
> > > @@ -58,6 +63,9 @@ struct cros_ec_keyb {
> > >         struct input_dev *idev;
> > >         struct input_dev *bs_idev;
> > >         struct notifier_block notifier;
> > > +
> > > +       u16 function_row_physmap[MAX_NUM_TOP_ROW_KEYS];
> > > +       u8 num_function_row_keys;
> >
> > Why not size_t?
> I usually try to use the minimal required bytes for variables, even
> for local ones.
> In this case, we only need one byte for num_function_row_keys.
> Are there any reasons why size_t is better?

I suppose to indicate that it's an array size. It's not a super strong
argument but the usage of u8 looks like we're trying to save space in a
single structure instance (or maybe a couple if there are a few
keyboards), when for all I know it actually generates worse code because
it has to do some masking operation on the load from memory when it
could just load the value directly into a register.

> >
> > >  };
> > >
> > >  /**
> > > @@ -587,6 +613,52 @@ static int cros_ec_keyb_register_matrix(struct c=
ros_ec_keyb *ckdev)
> > >         return 0;
> > >  }
> > >
> > > +static ssize_t function_row_physmap_show(struct device *dev,
> > > +                                        struct device_attribute *att=
r,
> > > +                                        char *buf)
> > > +{
> > > +       ssize_t size =3D 0;
> > > +       u8 i;
> >
> > int i? Why u8? Surely the size of a local variable isn't important.
> The same reason as "u8 num_function_row_keys".
> Is int better in this case?

Yeah int is better because it's a local variable and nobody cares about
those extra few bytes.

> >
> > > +       struct cros_ec_keyb *ckdev =3D dev_get_drvdata(dev);
> > > +
> > > +       if (!ckdev->num_function_row_keys)
> > > +               return 0;
> > > +
> > > +       for (i =3D 0; i < ckdev->num_function_row_keys; i++)
> > > +               size +=3D scnprintf(buf + size, PAGE_SIZE - size, "%0=
2X ",
> > > +                                 ckdev->function_row_physmap[i]);
> > > +       size +=3D scnprintf(buf + size, PAGE_SIZE - size, "\n");
> > > +
> > > +       return size;
> >
> > I'd rather see
> >
> >         ssize_t size =3D 0;
> >         int i;
> >         struct cros_ec_keyb *ckdev =3D dev_get_drvdata(dev);
> >         u16 *physmap =3D ckdev->function_row_physmap;
> >
> >         for (i =3D 0; i < ckdev->num_function_row_keys; i++)
> >                 size +=3D scnprintf(buf + size, PAGE_SIZE - size,
> >                                   "%s%02X", size ? " " : "", physmap[i]=
);
> >
> >         if (size)
> >                 size +=3D scnprintf(buf + size, PAGE_SIZE - size, "\n");
> >
> >         return size;
> >
> > And I wonder if hex_dump_to_buffer() works for this?
> It seems to work? I'll give it a try.
> If hex_dump_to_buffer() doesn't work, I'll fall back to the
> implementation you suggested above.

Ok sounds good.