Bug 82181

What are the applications that fail here?

Most devices don't report all values within the same frame and I haven't seen any issues for a while. If this is really an issue with some applications, it should likely be fixed in the server anyway. Client's don't ever see evdev events directly, they see core, XI1 or XI2 events.

I see it with okular.

I tried to play with evemu and record the problem but, even though I see the bug while recording, it doesn't show while playing !

Here is what I did: I launched okular on some file (evdev.h), I typed F6 so that the annotation tools appear, I selected the "Freehand line", then launched the recording on my pen an draw a more or less straight horizontal line.


I am attaching a record of the event, and

Created attachment 104315 [details]
screenshot of okular

Created attachment 104316 [details]
output of evemu-record

(Sorry, my earlier comment was not complete. I am starting again)

I see it with okular.

I tried to play with evemu and record the problem but, even though I see the bug while recording, it doesn't show while playing !

Here is what I did: I launched okular on some file (evdev.h), I typed F6 so that the annotation tools appear, I selected the "Freehand line", then launched the recording on my pen an draw a more or less straight horizontal line.

I am attaching a record of the event, and a screenshot of okular. The problem is: if I try to replay the events, I get a nice straight line. How is that possible ?

I have similar problems with evemu on the other bug [82250]. I'll make an update tomorrow.

Thank-you for your work!

I just found a report of someone with (probably) the same problem that I observe:

https://forum.kde.org/viewtopic.php?f=251&t=118624

This is probably a bug with okular's handling of tablets (or pens), but still, it is weird that the problem does not happen with the emulated device and the recording of events.

Ok, I think I understand (more or less) what is going on.

Okular differentiates events from mouses and from tablets. It knows which is which through Qt, and Qt seems to have a strange heuristics to determine if a device is a mouse or a tablet (see: http://qt-project.org/doc/qt-4.8/qtabletevent.html, Notes for X11 Users: Qt uses the following hard-coded names to identify tablet devices from the xorg.conf file on X11 (apart from IRIX): 'stylus', 'pen', and 'eraser'. If the devices have other names, they will not be picked up Qt.)

For some reason, the pen is recognized as a tablet while the emulation device is recognized as a mouse, which explains why the behaviours are different.

Looking at Okular's source, I added some fprintf-debugging:
--- ui_orig/annotationtools.cpp 2014-07-10 23:36:03.000000000 +0200
+++ ui/annotationtools.cpp      2014-08-14 21:57:00.210847260 +0200
@@ -33,6 +33,7 @@
 
 void AnnotatorEngine::decodeEvent( const QMouseEvent * mouseEvent, EventType * eventType, Button * button )
 {
+       fprintf(stderr, "Mouse: %d,%d   %d,%d\n",mouseEvent->x(),mouseEvent->y(), mouseEvent->globalX(), mouseEvent->globalY() );
     *eventType = AnnotatorEngine::Press;

     if ( mouseEvent->type() == QEvent::MouseMove )
         *eventType = AnnotatorEngine::Move;
@@ -49,6 +50,11 @@
 
 void AnnotatorEngine::decodeEvent( const QTabletEvent * tabletEvent, EventType * eventType, Button * button )
 {
+       fprintf(stderr, "Tablet: %d,%d   %d[%g];%d[%g]\n",
+               tabletEvent->x(),tabletEvent->y(), 
+               tabletEvent->globalX(), tabletEvent->hiResGlobalX(),
+               tabletEvent->globalY(), tabletEvent->hiResGlobalY()
+                );
     switch ( tabletEvent->type() )
     {
         case QEvent::TabletPress:

and, sure enough, when the device is recognized as a tablet, the hiResGlobal[XY] methods sometimes return 0:
Tablet: 207,425   850[847,621];497[497,371]
Tablet: 204,425   847[844,952];497[497,371]
Tablet: 201,425   844[842,617];497[0]
Tablet: 199,425   842[840,615];497[0]
Tablet: 197,425   840[838,947];497[0]
Tablet: 195,425   838[837,28];497[0]
Tablet: 194,425   837[835,612];497[0]
Tablet: 192,425   835[834,277];497[497,559]
Tablet: 191,425   834[833,277];497[497,747]

I suspect that Qt, in order to compute an hi-res position, looks directly at the values of the valuators in the X event instead of looking at the position returned by X. When the device and evdev return only one valuator, Xcore keeps track and sends a correct position, but still only one valuator and Qt fails.
With the patch I proposed when I opened this bug,  both valuators are always sent and Qt works fine.

Sure enough, if I apply the following patch to okular, everything works fine.
--- ui_orig/pageviewannotator.cpp       2014-07-10 23:36:03.000000000 +0200
+++ ui/pageviewannotator.cpp    2014-08-14 21:57:23.966971270 +0200
@@ -904,7 +904,7 @@
     // figure out the event type and button
     AnnotatorEngine::decodeEvent( e, &eventType, &button );
 
-    const QPointF globalPosF = e->hiResGlobalPos();
+    const QPointF globalPosF = e->globalPos();
     const QPointF localPosF = globalPosF - localOriginInGlobal;
     return performRouteMouseOrTabletEvent( eventType, button, localPosF, item );
 }

So, for this one, a bug in Qt. Still, it seems that most tablets will always send both coordinates, and that some programs depend on it. Maybe it would help a bit if X would always send all the valuators to the programs...("Be conservative in what you send")

In the other bug I opened (82250), I suspect that a similar problem occurs: the program determine that my pen is a tablet and expect some specific type of behaviour. As my pen is not a tablet but, really, just a pen, it doesn't have the expected behaviour and the programs are confused. I'd like to be able to disguise my pen into an ordinary mouse, just to see.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-evdev/issues/3.