Hi, I was recently tasked with getting one of these going on RPI: http://www.chalk-elec.com/?page_id=1280#!/~/product/category=3094861&id=14647624
It *almost* worked ok :) There was a problem where evdevtouch would never detect a touch release, and thereby never deliver a Qt::TouchPointReleased event to the rest of qt. This caused a variety of subtle issues with various Qt programs. The TL;DR version: I have a change request available that I'd like reviewed/approved. I am not sure who to add as reviewers: https://codereview.qt-project.org/#change,38795 It solves the problem with this panel. I also cross tested with a panel that already worked fine (Dell ST2220T) and see no regressions. Longer version: evdevtouch seems to assume that when a ABS_MT_TOUCH_MAJOR with value == 0 is emmitted, then a Qt::TouchPointReleased should be queued. The trouble is that this particular panel and driver (hid_ntrig) never emits this condition, and I can find nowhere in the spec[0] were this behavior is specified on a touch release. As a result, a Qt::TouchPointReleased is never emitted, which causes things to go downhill from there. Now I check for an EV_KEY, code BTN_TOUCH, with value == 0 to emit Qt::TouchPointReleased. This seems to work fine on this panel. [0] https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt Thanks! -- Jon Trulson "Oh the land of the free, and the home of the brave. Are you heaven on Earth, or the gloom of the grave." -- Iron Sky _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
