Qt and DirectFB - linux_input events handling

McLion

@SGaist
Hi Samuel,

Thanks for your response.
I don't have a qlinuxinput.cpp on my system.
As far as I could see the following is the event sequence (instance) of modules in Qt4.6.3 with DFB1.4.3:

Input Event (OS)
linux_input.c (DFB)
qdirectfbmouse.c (Qt)
qmouse_qws.cpp (Qt)
qwindowsystem_qws.c (Qt)
MyApplication (Qt)

If you feel that that this is wrong, please let me know.
For testing, I attached a different type of touch screen controller that generates the correct event sequence in the controller. With this touch, everything works OK without any code patch.
With the touch controller I need to have working, even with patched linux_input.c to have the same, corrected sequence, it does not work.
I must miss something in the event queue between the OS input event and the event being dispatched to MyApplication.
I currently don't have all the Qt sources on my Linux dev-VM - only compiled version/libraries needed fro the application development. Therefore, I cannot easily place debug output everywhere.

Many thanks for any hint how to track down this.
Franz

SGaist

No it doesn't look wrong, I was checking the 4.8.7 sources.

Might be a silly question but does the other touchscreen you the same kernel module ?

McLion

I definitely don't understand what is happening here.
They use the same kernel module.

Just for testing I connected the controller that usually works and was very amazed that it now showed the same behavior. To find out the cause - and to have a working base - I reverted my mods step by step. Even after I reverted all changes I made to the DFB code - it still did not work with the controller it usually does.
I ended up in making a make clear to have it build everything new, and that was when it was back working.
I have no clue what makes the difference - before and after the make clean all the sources are the same after I reverted my changes.

I currently have no clue how to solve this nor do I understand the behavior of my project/compiler.

There is something I completely did not get/understand in how the events are propagated in the combination linux_input / DFB / Qt.

SGaist

To sum up: same kernel driver, same input handler and different results ?

Do you see any difference if you e.g. hexdump the input device ?

McLion

The only difference between the 2 controllers is the firmware version - the sequence it outputs the events.
A typical click on a new location of the old one:
17:00:49.418029: EV_ABS ABS_X 5024
17:00:49.418063: EV_ABS ABS_Y 6560
17:00:49.418086: EV_SYN code=0 value=0
17:00:49.505969: EV_MSC MSC_SCAN 589825
17:00:49.505995: EV_KEY BTN_LEFT pressed
17:00:49.506045: EV_SYN code=0 value=0
17:00:49.513981: EV_MSC MSC_SCAN 589825
17:00:49.514008: EV_KEY BTN_LEFT released
17:00:49.514058: EV_SYN code=0 value=0
It first sends the new location, then the click and then the release.

Now the click on a new location with the new one:
17:01:27.386117: EV_MSC MSC_SCAN 589825
17:01:27.386144: EV_KEY BTN_LEFT pressed
17:01:27.386184: EV_ABS ABS_X 6336
17:01:27.386204: EV_ABS ABS_Y 7040
17:01:27.386227: EV_SYN code=0 value=0
17:01:27.514085: EV_MSC MSC_SCAN 589825
17:01:27.514112: EV_KEY BTN_LEFT released
17:01:27.514162: EV_SYN code=0 value=0
It sends the click first, then the new position and then the release. For every desktop linux, windows or whatever, this seems not to be an issue because they use the EV_SYN and are intelligent enough to proceed as follows on a EV_SYN and both controllers work perfect:
-- update XY position
-- Evaluate button/click event

If I use tslib with DFB instead of the linux_input with DFB, it works as well. However, tslib shows some other issues and first of all does not feature Hot-Plug which I need.
It is confirmed, that the linux_input module of DFB does not support the EV_SYN event to synchronize evaluation of input event packets. This is what I added to this module and the dfb_input_dispatch shows that the dispatch in DFB now is reordered.

This is where Qt comes in. Even though DFB now dispatches the events reordered, Qt still show the same, wrong sequence as shown in my first post in this thread.
Moreover - and I absolutely don't understand this - the old controller that has worked before now also shows the wrong sequence in Qt and as described before, it doesn't even recover when resetting changes, needing a clean before recovering.

It must be something with how Qt gets the XY event that it somehow gets before the click even if DFB dispatches the click first - but fro the life of me, I just don't find the cause/issue.

I am more than thankful for every tiny hint on this. I spent days now to fix this - to no avail.
Cheers, Franz (... all my best from central Switzerland id's Wallis)

SGaist

And I guess you are locked to that old version of Qt ?

McLion

Unfortunately, yes.
A later Version of Qt and/or DFB may run as well. However, this integration has been supplied by the SoC manufacturer "as is" and I somehow fear what it takes to have a later version run smoothly in this SDK.
DFB has been extended and uses custom-made drivers by the SoC supplier to use the SoC's Graphic device. There has been a a lot of modifications to Linux as well as DFB to support the Hardware.

I suspect that Qt (QWS) does not get the XY event and the click event from DFB over the exact same path. That may be the source of the effect I am seeing, a timing issue in the end.

McLion

bump ... bump

SGaist

Cross-compiling Qt 4 is really not hard especially if you have the toolchain ready to use. From your description it seems that there's two different behavior between two devices that uses two different firmware, so there might be a clue there.

McLion

That doesn't really help. I know the difference between the 2 devices.
The issue seems to be in the path and maybe the resulting timing Qt (QWS to be more precise) gets the XY position compared to the path over which it gets the click events. This seems not to travel the same way from DFB to QWS.
Still have no solution for this.