On Mon, Jun 26, 2017 at 09:16:40AM -0500, Rob Herring wrote:
> On Mon, Jun 26, 2017 at 8:22 AM, Wang Yafei <wangyafei@xxxxxxxxxx> wrote:
> > Hi Rob,
> >
> > Thank you for the review.
> >
> > On Fri, Jun 23, 2017 at 03:37:06PM -0500, Rob Herring wrote:
> >> On Mon, Jun 19, 2017 at 06:40:32PM +0800, Wang Yafei wrote:
> >> > Signed-off-by: Wang Yafei <wangyafei@xxxxxxxxxx>
> >> > ---
> >> > .../bindings/input/touchscreen/goodix-gtx5.txt | 75 ++++++++++++++++++++++
> >> > 1 file changed, 75 insertions(+)
> >> > create mode 100755 Documentation/devicetree/bindings/input/touchscreen/goodix-gtx5.txt
>
> [...]
>
> >> > +- touchscreen-key-map: keycode value map /*KEY_HOMEPAGE, KEY_BACK*/
> >>
> >> This hardly seems sufficient to map screen areas to keys. There's been
> >> some discussion about doing that in the past.
> >
> > Sorry haven't notice that before, I will change it to the flowing
> > property format:
> > linux,keycodes = <KEY_HOMEPAGE>, <KEY_MENU>, <KEY_BACK>;
>
> That's better, but not really what I meant. There's still some
> assumption about what region each key is located in. Is every design 3
> keys? How do you know what region of the touchscreen is a given key?
> iOW, what are the valid ranges of coordinates for each key?
I'm afraid it hard to show each key located in. The location of touch
key is determined by touch panel hardware design and the touchscreen
controller configuration data. In general, there are two different
implementations of touch key, one is specified some area on the top of
LCD, another is on the out side of LCD and will print some pattern to
indicate the key info. No matter what kind kind of implementation, the
touch controller will report a specialized key event to driver different
from coordinate events, and the driver no need to care about the rages of
coordinates. When receive a key event the only thing that driver need to
do is map it to a certain linux keycode and report to OS. The
corresponding linux keycodes of each key is determined by this device
property. The key number in not immutable, for example on some x86 tablets
there only have one home button with windows logo on the front. The key
number is determined by touch controller firmware usually no more than
5.
>
> >> > + compatible = "goodix,gtx5";
> >> > + reg = <0x14>;
> >> > + interrupt-parent = <&msm_gpio>;
> >> > + interrupts = <13 0x2800>;
> >> > + vtouch-supply = <&pm8916_l15>;
> >> > + reset-gpios = <&msm_gpio 12 0x0>;
> >> > + irq-gpios = <&msm_gpio 13 0x2800>;
> >> > + irq-flags = <1>; /* 1:trigger rising, 2:trigger falling;*/
> >> > + touchscreen-max-id = <10>;
> >> > + touchscreen-size-x = <400>;
> >> > + touchscreen-size-y = <400>;
> >> > + touchscreen-max-w = <400>;
> >> > + touchscreen-max-pressure = <255>;
> >> > + touchscreen-swapped-x-y;
> >> > + touchscreen-key-map = <172 158>; /*KEY_HOMEPAGE, KEY_BACK*/
> >> > + sensor0 {
> >>
> >> How many sensors can there be? That needs to be documented.
> >>
> >> Why do you need a sub-node?
> >
> > sensor is an internal call, we use senesorX to represent the touchpanel
> > is produced by which factory. A panel factory will have it corresponding
> > config data to get the best touch results. It will delete the sub-node
> > and change to the following format:
> > panel0,normal-cfg = [...] /* panelX,cfg : X is no more than 10*/
>
> panel0 is not a vendor and normal doesn't tell us anything. How about
> just "goodix,panel-cfg-X"?
Okay, goodix,panel-cfg-X, seems more reasonable, I will use this.
Sincerely.
> Rob
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
