Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
evdevtouchhandler and hy46xx_ts
mjhammel last edited by
Is anyone else using the HyCon hy46xx_ts driver with Qt 5.12.3? I'm having problems with the touch handler and the HyCon hy46xx_ts driver on a new board we're building. evtest shows events flowing from the device. But qevdevtouchhandler (part of the evdevtouch plugin) seems to get locked up when inside assignIds(). What appears to happen is that the loop that iterates the pending hash calls findClosestContact() but that returns an -1 id and so bestDist is not set. This means the candidates hash is never drained and we stay stuck in the while() loop inside assignIds().
I believe this may be related to why events an not propogating up to the application layer too. You can touch the screen and see debug output that events are being seen (for awhile, at least) by the qevdevtouchhandler but those presses don't get propagated to the signals that call the slot functions. SOMETIMEs they do immediately after a restart, but mostly they don't after that.
Also, after this loop there is a test for candidates.isEmpty(). The only way you break out of that loop was to have that be true, which seems like a redundant check.
At one point I hacked my way past this by counting the number of times we looped with no change there and forced a break after 100 loops. Since I'm breaking out and now have !candidates.isEmpty() I added an else that clears candidates.isEmpty() which I thought would effectively drop the touch event but allow things to keep moving. With these changes the plugin doesn't lock up anymore but we still don't get events propagating up the stack.
This is Qt 5.12.3 and I'm talking about qtbase/src/platformsupport/input/evdevtouch/qevdevtouchhandler.cpp.
Any pointers would be appreciated.
Hi and welcome to devnet,
Before digging further, did you check whether more recent versions of Qt work better with this device ?
mjhammel last edited by mjhammel
@SGaist Thanks for the tip, but that's not really an option for us (it's kind of a pain to do the cross compile and reload on the target) so I didn't go there. Since we have other boards with different touch sensors working with 5.12.3 it seemed likely the problem was a compatibility with the driver. Fortunately, we found the problem this afternoon.
They hy46xx_ts driver reports additional events that Qt is not happy with. Removing the input_mt_sync(data->input_dev); call (which, interestingly, is wrapped in an #ifdef LINUX_OS) from the hy46xx_report_value() function in the driver seems to fix the problem. At least our app is now working as expected.
Followup: looks like we also have to remove the input_report_key(data->input_dev, BTN_TOUCH, 0); and
input_report_key(data->input_dev, BTN_TOUCH, 1); calls at the end of that function or the app dies. But I think that's the gist of it now.
Testing with a more recent version is essentially to check if the issue still happens and if not there might be something you can back port to the version you are locked with.
In any case, even if locked to 5.12, there have been several releases in that series that you might want to take a look at.
Since the events look like they could be valid but are not handled, I would say that this is something that should also be brought to the bug tracker with your additional findings.