Step to reproduce: 1) Install ArchlinuxARM on RaspberryPi 3 (installing official RPI Touchscreen 7inch) 2) startx => Cannot touch on the top area Found that kernel resolve it as 800x600 (not 800x480). Followed the guide and with "touchpad-edge-detector 800x480 /dev/input/event0" added this on /etc/udev/hwdb.d/61-evdev-local.hwdb evdev:name:* EVDEV_ABS_00=2:800:1 EVDEV_ABS_01=2:480:1 EVDEV_ABS_35=2:800:1 EVDEV_ABS_36=2:480:1 It was working without udev patch in previous version.. Unfortunately touchpad-edge-detector cannot give me an identifier string so I override all the evdev device (the only one connected is this touchscreen)
what's the kernel driver running this thing? it's connected via GIO, right? What does evemu-describe say about the device, name-wise and pid/vid wise? We obviously can't ship a generic override like this, people may get upset ;)
The kernel i'm running is 4.14.18-1-ARCH #1 SMP Sun Feb 11 20:39:08 UTC 2018 armv7l GNU/Linux (the one available on ArchlinuxARM official repository) The display use the DISPLAY port on RPI and 4 pins on the GPIO (2 are for DATa) This is the output of evemu-describe EVEMU 1.3 # Kernel: 4.14.18-1-ARCH # Input device name: "FT5406 memory based driver" # Input device ID: bus 0000 vendor 0000 product 0000 version 0000 # Size in mm: 798x478 # Supported events: # Event type 0 (EV_SYN) # Event code 0 (SYN_REPORT) # Event code 1 (SYN_CONFIG) # Event code 2 (SYN_MT_REPORT) # Event code 3 (SYN_DROPPED) # Event code 4 ((null)) # Event code 5 ((null)) # Event code 6 ((null)) # Event code 7 ((null)) # Event code 8 ((null)) # Event code 9 ((null)) # Event code 10 ((null)) # Event code 11 ((null)) # Event code 12 ((null)) # Event code 13 ((null)) # Event code 14 ((null)) # Event code 15 (SYN_MAX) # Event type 1 (EV_KEY) # Event code 330 (BTN_TOUCH) # Event type 3 (EV_ABS) # Event code 0 (ABS_X) # Value 268 # Min 2 # Max 800 # Fuzz 0 # Flat 0 # Resolution 1 # Event code 1 (ABS_Y) # Value 324 # Min 2 # Max 480 # Fuzz 0 # Flat 0 # Resolution 1 # Event code 47 (ABS_MT_SLOT) # Value 0 # Min 0 # Max 9 # Fuzz 0 # Flat 0 # Resolution 0 # Event code 53 (ABS_MT_POSITION_X) # Value 0 # Min 2 # Max 800 # Fuzz 0 # Flat 0 # Resolution 1 # Event code 54 (ABS_MT_POSITION_Y) # Value 0 # Min 2 # Max 480 # Fuzz 0 # Flat 0 # Resolution 1 # Event code 57 (ABS_MT_TRACKING_ID) # Value 0 # Min 0 # Max 65535 # Fuzz 0 # Flat 0 # Resolution 0 # Properties: # Property type 1 (INPUT_PROP_DIRECT) N: FT5406 memory based driver I: 0000 0000 0000 0000 P: 02 00 00 00 00 00 00 00 B: 00 0b 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 04 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 01 00 00 00 00 00 00 00 00 B: 02 00 00 00 00 00 00 00 00 B: 03 03 00 00 00 00 80 60 02 B: 04 00 00 00 00 00 00 00 00 B: 05 00 00 00 00 00 00 00 00 B: 11 00 00 00 00 00 00 00 00 B: 12 00 00 00 00 00 00 00 00 B: 14 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 B: 15 00 00 00 00 00 00 00 00 A: 00 2 800 0 0 1 A: 01 2 480 0 0 1 A: 2f 0 9 0 0 0 A: 35 2 800 0 0 1 A: 36 2 480 0 0 1 A: 39 0 65535 0 0 0
Reopen after debug info added
ok, we (and by "we" I mean you :) should open a PR with systemd to add the evdev override into the 60-evdev.hwdb, with a match on the FT5406 name. what version did you say this was working with? because whatever changed, I doubt libinput was it since it just uses the coordinates the kernel gives it.
Can you provide me a Bugzilla link where to post the issue?
https://github.com/systemd/systemd/pull/8226 is one example for such a PR. Make sure you cc @whot on it so I see it
I opened an issue. Unfortunately I never push a PB for systemd right now and it seems to be a long work (have I to sync all the systemd github repository to do that?) Hoping someone will look at it (otherwise I ask you some help merging it) Regards
(In reply to MadPapo from comment #7) > I opened an issue. > > Unfortunately I never push a PB for systemd right now and it seems to be a > long work (have I to sync all the systemd github repository to do that?) > > Hoping someone will look at it (otherwise I ask you some help merging it) > Regards https://github.com/systemd/systemd/issues/8272
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.