Details
-
Bug
-
Resolution: Out of scope
-
P4: Low
-
None
-
4.7.3
-
None
-
Linux 2.6.39.4 on iMX357
Qt everywhere opensource 4.7.3
Description
in src/gui/embedded/qmousepc_qws.cpp in method int tryData() of class QWSPcMouseSubHandler_intellimouse there seems to be the following issue:
if mousedata seems to be invalid the method returns 1 instead of the packetsize.
as result the following calls to tryData are also invalid - in my case the mousepointer was moved to an invalid point because of missinterpreted data.
debug output:
QWSPcMouseSubHandler tryData read 4 bytes: 08 00 01 00 virtual void Dial::mouseMoveEvent(QMouseEvent*) 92 Intellimouse: motion 0,0, state 0, raw wheel 1, wheel 120 QWSPcMouseSubHandler tryData read 4 bytes: 08 00 00 ff Intellimouse: motion 0,0, state 0, raw wheel 5, wheel 0 QWSPcMouseSubHandler tryData read 1 bytes: 08 Intellimouse: skipping (overflow) QWSPcMouseSubHandler tryData read 1 bytes: 00 Intellimouse: skipping (overflow) QWSPcMouseSubHandler tryData read 1 bytes: 00 Intellimouse: motion -248,256, state 3, raw wheel 0, wheel 0 QWSPcMouseSubHandler tryData read 4 bytes: fb 08 00 00 Intellimouse: skipping (overflow)
I did not see this on my PC, this issue was only on my embedded system - maybe because of this (slower cpu, etc) the wheelcount is bigger than 2 so data is marked as invalid...
the following patch resolves this problem for IntelliMouse (I think it should be solved also for the rest of the handlers but I cannot test this):
--- a/src/gui/embedded/qmousepc_qws.cpp
+++ b/src/gui/embedded/qmousepc_qws.cpp
@@ -233,7 +233,6 @@ public:
goodness++;
} else {
badness++;
- return 1;
}
}
return packetsize;
Also a suggestion: why is wheel in line 225 limited to -2..+2 ? on slower systems and systems with progressive wheelfunction this could be a real problem. The main problem is that wheel is not just limited to -2..+2 but set to 0.