Created attachment 104059 [details] Try hard to report all the valuators at the same time I have a HP ElitBook Revolve 810 with an HP executive (actually registrering as an Atmel maXTouch Digitizer Pen). I am running an up-to-date Fedora 20 on this box. My pen has numerous problems making it unusable, and I am trying to make it work. One of these problems is that the device sometimes only report ABS_X or ABS_Y without the other coordinate before a SYNC event. Some application try to cope with it, and some fail miserably. Even the applications that try to compensate by remembering the other coordinate may fail, and it would be much better if all the coordinates were sent to the applications. Arguably, this could be fixed in the kernel, but it seems very easy to fix in the evdev driver. I have attached a patch which works for me. It works by using the values in the old_vals valuators if some values are missing in the current valuators. Nota: this patch alone is not enough to make my pen work. There is a patch on the kernel-input mailing list to fix another problem in the kernel, and with these two pathes it is nearly usable, but only nearly: there is a third problem for which I'll open another bug report.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.