Kivy touch events not working on Raspberry PI with Adafruit PiTFT #2656
Comments
|
Update: I fetched the lastest from github, updated my local master with origin/master, and ran make to rebuild local kivy (I have PYTHONPATH set to this path in ~/.profile). Touch events still error as noted above. |
|
To confirm: The touchscreen works with X, it sees input as expected, it is only when using the touchscreen with kivy that I see problems. |
|
Please let me know if there is anything I can do to investigate/debug/etc. I'm not familiar enough with what is different on RPi, is there a sensible place in the code I can start digging? |
|
Tito's observations regarding this bug: tito: 0x14a (330) is not in the keyboard_keys |
|
I've tested by adding an entry for key 330 like so: Kivy does not crash, but the hidinput provider is not doing anything else with the events, and Kivy does not register button presses. I'm still not fully groking hidinput.py and event processing, so guidance on how to help Kivy pick up on these events is appreciated. Another note: Further down, I added a crude print on infos to confirm Kivy is seeing/processing the touch data: This works, and I see the infos struct when I touch the screen. Looks like: ...so Kivy is at least processing the touch data. |
|
@kived, @tshirtman, @tito, @dessant, I have been reading through hidinput.py to better understand what is missing, but I have not been able to identify what this module needs to properly register the HIDMotionEvents for this touchscreen on the RaspberryPi. I appreciate any insights, pointers, and debugging help - I am willing to code, but also having a difficult time understanding all of Kivy that is relevant here. |
|
I have the exact same problem with this touchscreen: http://www.chalk-elec.com/?p=1712 Here is the output of evtest: According to this, the keycodes 320 and 330 are simple touch events. |
|
@sonovice did you use just a touch, or a pen to touch the screen? Cause here we are seeing 2 different keycode as you said. If we dispatch both directly, you might have issues with it, like constently trigger a double tap. For now, i'll add 330, and ignore 320. |
|
@sonovice i think morefix is needed for you no? Did you try to add only --- a/kivy/input/providers/hidinput.py
+++ b/kivy/input/providers/hidinput.py
@@ -446,7 +446,9 @@ else:
276: 'extra',
277: 'forward',
278: 'back',
- 279: 'task'}
+ 279: 'task',
+ 330: 'touch',
+ 320: 'pen'}
if ev_code in buttons.keys():
if ev_value:? |
|
@tito I tried that already with no effect (except from avoiding the error). A pen is not used, only a single finger. |
|
@tito, I've tested with both pen and finger and get similar results. I should also clarify that simply adding in these magic numbers is not enough for kivy to respond correctly - with the magic we wipe away the error, but kivy is not yet setting up button presses and similar types of events. When I last dug into this, I was unable to traverse enough of the code to understand why that was not happening. My apologies if this is not clear enough. |
|
What I have tried is to define 330 as 'left' and 320 to be ignored... Didn't work out either. |
|
Yep, that's what i see from the evdev trace. For non-multitouch devices, we don't handle EV_ABS, only EV_REL (ie, a mouse). It need more work to get it right. Because @sonovice already give a output example of evtest, @illumin-us-r3v0lution, could you do the same please? This will ensure me the similarities of a Rpi touchscreen, and try to do the work based on thoses output. What i need (separated evtest):
Thanks! |
|
@tito Here we go. Your second scenario is already covered with my posted evtest output. Single touch: "Multitouch": Although the touchscreen should support multitouch it doesn't look like it... too bad, but I don't really need that for my application. Thank you for taking care of the problem, tito! Hope these outputs are valuable for you. |
tito
added
Component: core-providers
|
@sonovice @illumin-us-r3v0lution Could you try the branch named |
|
Here are the evtest logs for you: Start up: Single tap, my nail more than my finger (this is a resistive touch): Down, move, up: |
|
Cool, you have the pressure support, which @sonovice don't have :) The fix include supports for it too. Could you try it? |
|
@tito, testing |
|
@tito, button presses are being recognized now, though it is not perfect. I did not see an event on the log, though kivy would sometimes fire button presses (I would see blue and/or have a new view). I think the primary problem with the patch as it is: the x/y position max in your patch is limited to 255 where the device (at least mine) notes a max resolution of 4095. Kivy was able to see the button press, but I didn't feel like the placement was correct |
|
I set |
|
@illumin-us-r3v0lution the 255 is default value, superseeded with the configuration reported by the device itself (see lines 593/606). But i made one mistake here, fixing it. |
|
@illumin-us-r3v0lution reset your changes, pull, and retry |
|
Here is evtest with the latest commits: |
|
@sonovice It works for @illumin-us-r3v0lution (debugged on IRC.) He got a Y axis invertion that Kivy cannot detect. @sonovice More work might needed for you, i think there is an issue with touch and pen button state. Try the latest branch and tell me your thoughs. If you have Y axis inversion too, you can either change in your
Enjoy! |
|
@tito Thanks for your lightning fast support. Unfortunately I am at a congress right now and can test your fix not until monday. I will get back to you as soon as I have access to the hardware. |
|
I don't really have the ability to create a video right now, but I will take the time to more clearly describe what I see with the PiTFT. For reference, I'm talking about this device [0], install info [1] and script [2]. By default, the PiTFT setup modifies X config for the input device: This snippet differs for the other PiTFT models. There are 3: 2 resistive (sm/lg) and 1 capacitive. There is also this file: Ok, on to what happens. We've talked about x/y inversion, I will start with this disabled. To test, I run Let's break up the screen into quadrants: Let's now touch each quadrant (t) and see what value (v) results. The first quadrant: Second: Fourth: Third: Here is another in the third quadrant to show the inversion more clearly: If you start in q1 and move clockwise through q2, q4, and q3, the touch value will show up in the 'previous' quadrant. Eg, pressing q2 value is q1, press q4, value is q2, press q1, value is q3. Let's change the x/y inversion, setting the following in Now X is inverted, let's test each quadrant. Here is the first: Second: Fourth: Third: So q2 and q3, which are diagonal to each other, are correct in real/perceived touch/value, while q1 and q4 are incorrect with the touch/value in the opposite (diagonal) quadrant. If we update to only invert y (no x), we will find these correct: And these incorrect: This is the same pattern as when we inverted x, but which quadrants are good/bad is flipped. Inverting both x and y together does not work, and is even more confusing to use. [0] http://www.adafruit.com/product/1601 |
|
@illumin-us-r3v0lution , I just tried the sample "gestures" minute ago and got the same result as yours. |
|
I saw on your configuration file something about 90 degrees rotation. That's exactly what we see here. So it's something new for us :/ |
|
The above from @tshirtman adds a new option (rotate) to hidinput provider, but tests are the same as before. |
|
It's normal, the patch is half done :) |
|
Pull the latest branch:support-rpi-touchscreen and add the |
|
It finally works for @illumin-us-r3v0lution. As he said on irc: param=rotation=270,param=invert_y=1 Both works. Let's merge into master! |
|
Thanks to @tito and others who helped to get this resolved! |
|
@tito I updated everything to the latest version. Still no working touch function. 😢 |
|
@sonovice, does X work with the touchscreen? When kivy starts, do you see the touchscreen and related features/config picked up in the log? |
|
@iluminite X is working without problems. Now that you've mentioned it: There is indeed nothing about a HID device in the startup log. Before the update to the latest kivy version there was definitely something about a HID input provider. |
|
@sonovice, can you include some of that log info? do you have an |
|
We don't use X, or anything related to X. That's mean if you used X for calibration or device detection, it's just no help. Best is to give us the evtest output, device path, and your ~/.kivy/config.ini Please don't answer on a closed thread except if you known for a fact that the bug is not resolved. I can ensure it's it :) If you don't have anything related to hid, maybe you messed your config file. Better to use the mailing list for now! |
|
Sorry, I know this thread is closed. @tito, would you make tutorial-like post for other who began work with PiTFT + Kivy + Raspberry, because for example I can't fully understand what you've done to work this touchscreen. It would be good because all who have issues will be clarified by your post and will not disturb you. Thanks |
|
@tito I am facing issue even displaying anything on the touchscreen. The screen is calibrated (I don't use X either). Event test works (ts_test & evtest). Please let me know how to display the UI on touch display instead of HDMI. (I have tried the usual methods FRAMEBUFFER variable & DISPLAY variable) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi!
I have an Adafruit 2.8in LCD with a resistive touchscreen [1], connected to a Raspberry Pi and working with Kivy. I have had to use fbcp [2] to get this setup to work with Kivy, but that is fine. While I have seen issues with idle apps using 30-40% CPU (as per htop), the primary blocker in my setup is that the touchscreen errors out with Kivy.
I can create a Button in a Kivy App and press it, Kivy does see the touch, but errors out:
Here are a few additional notes:
[1] https://www.adafruit.com/prohttps://www.adafruit.com/product/1601duct/1601
[2] https://github.com/tasanakorn/rpi-fbcp
The text was updated successfully, but these errors were encountered: