Touchscreen event trouble

[mangodan2003]

Any body else noticed the touchscreen doesn't work quite right?

I've always found it to be a bit finicky but am currently working on a touchscreen friendly mpd client based on pyqt/QML. I noticed the flickable behaviour doesn't always work - in fact hardly ever works.
I found this is because the "pressed" event usually doesn't happen until you release!

you can see this behaviour simply with

xev | grep ButtonPress

Edit : disabling 3rd button emulation resolved the weird buttonpress behaviour button didn't resolve the original problem with my app :/ - it works fine with my laptops touchscreen.

[Juggler]

I don't use the joggler touchscreen at all, but have played a bit. I don't think the Jogglers touch screen is that great, and I get miffed at putting grease marks all over the screen. I use the keyboard most of the time.

Anyway, some of these may shed some light :

Not ubuntu, but talks about calibration
https://wiki.archlinux.org/index.php/Touchscreen

I played with evtest, as I has a small project in mind, and it gives a lot of detail :
https://wiki.ubuntu.com/DebuggingTouchp ... ion/evtest
http://manpages.ubuntu.com/manpages/pre ... est.1.html

May be some items of interest here :
http://superuser.com/questions/248517/s ... d-in-linux

AFAIAA, linux manages any human interface device through an events based interface. So apps for keyboard or mouse may also work for a touchscreen.

Be interesting to hear how your project goes and maybe you could share some more detail on it.

Cheers

J

PS maybe evtest would confirm what you suspect - "the "pressed" event usually doesn't happen until you release"

[mangodan2003]

Hi,

Thanks for the feedback , however already covered those. I had done a screen calibration as it was slightly out by default.

evtest is what lead me to find the mouse3 emulation behaviour in xorg config - as it runs at a lower level on the device node - /dev/input/event0 for the jogglers TS and indeed there the events look normal, whereas xev was showing the delayed press event reported in first post.

I had also read the problem may be due to timestamps being missing on the events - or even too course, making press and release appear to coincide and thus prevent calculation of a valid "flick velocity" - but confirmed this is not the case too.