Arch Linux

Baplar

Member

Registered: 2018-03-27

Posts: 5

Wacom - Cursor offset in a few programs only

Update: The problem is caused by a regression introduced in Qt 5.12.4.
As a temporary workaround, the legacy behavior can be forced by setting the environment variable QT_XCB_TABLET_LEGACY_COORDINATES to any value before launching the affected application, which makes the problem disappear.

This can be done manually when launching an affected application:

QT_XCB_TABLET_LEGACY_COORDINATES=1 application

Or by setting it automatically when X.org starts, as described on the Arch Wiki.

This topic sparked the creation of a Qt bug report. Further conversation should be deferred there until the resolution of the issue upstream.

——

I have recently acquired a new Wacom One M for my laptop, and it works very well out of the box without any specific configuration or tweak.
However, in some specific programs, the cursor seems to be “offset”  with regards to the GUI.

What I mean by this is that the cursor still appears on the monitor where it is supposed to be, but when trying to interact with the buttons, the clicks seem to be applied at a different position.
Re-using the touchpad of my laptop at the exact same cursor position correctly clicks the targeted button.
This made me think that the problem came from the absolute positioning used by the tablet; however, switching to relative positioning did not fix the problem.

After a few tests, it appears to me that the guilty programs behave as if the "working area" (the widget, maybe?) were positioned at the very top-left of the screen.
When putting the window there, minus KDE’s taskbar and the program’s titlebar, it seems to click directly below the cursor’s position.
Speaking of the titlebar, it still behaves correctly even if its "contained" program is bugged: the window can be dragged, minimized, closed, etc. without issue.

I had initially discovered this bug with LibreOffice, and thought it was a Gtk bug due to my KDE setup. However, I later discovered that it also affected the "Connections" KDE settings module.
There is an even more interesting behavior that I noticed with this module: the KDE System Settings program usually works perfectly with the pen tablet, but as soon as the "Connections" module is loaded, it makes the entire settings program bug, even after the module is switched back to a "working" one.
This makes me think that this might be due to the module loading such or such library, or setting such or such parameter or environment variable, which makes the entire program behave differently.

Here are a few annotated screenshots illustrating the problem.

I am pretty sure that this is not the correct place to post this, but to be honest, this bug involves so many moving parts that I have no idea where to post it.
If you have any guess as to what might cause this, or need any system info on my part to help diagnose it, please let me know!

I am using an Optimus laptop, and set it up with PRIME to only use the Nvidia GPU. Do you think it might have a role in this issue?

Last edited by Baplar (2019-08-27 16:31:44)

d_fajardo

Member

Registered: 2017-07-28

Posts: 1,652

Re: Wacom - Cursor offset in a few programs only

First question, is this a bluetooth device or wired? Bluetooth in Wacom tends to be unreliable. Have you checked the Wacom Wiki for specific configurations?
From experience, I find the KDE Wacom kcm unreliable and have totally abandoned it. Your bug might actually come from that and it's worth a test not using it and just setting things up with xsetwacom.
Another question is what other programs have you tried to use the device?
I wouldn't think your GPU has anything to do with the issue.

Baplar

Member

Registered: 2018-03-27

Posts: 5

Re: Wacom - Cursor offset in a few programs only

This is a wired tablet, not likely to be a problem.
I have indeed read through the Wacom Wiki, as well as scouring the forum for similar issues, but I didn’t find anything similar to my program-specific problem.
I mentioned the GPU because I read in a post that multi-monitor setups could require a specific config, although I only have my laptop screen.

What really bothers me is that everything works smoothly in almost every other program I use: the vast majority of the KDE desktop and utilities, Firefox, VS Code, Cantata, Dolphin, Gimp, Konsole, VLC, Steam, the list goes on…
I actually checked again, and out of all the GUI programs I have installed, only the LibreOffice suite and a few KCM widgets (Network > Connections and Workspace > Desktop Behavior > Activities) exhibit that weird behavior.
I don’t see any immediate connection between these programs, so I’m really in the dark about this problem.

I have indeed used the Wacom KCM to experiment with the tablet, but I did so after noticing the issue.
For a long time, because it just worked out of the box, I didn’t mess with xsetwacom or the KCM at all.
I do not really know how to completely reset my current settings, but I will try doing so and see how it goes.
As for using a specific hand-made configuration for my case, I have no clue where to begin.

EDIT: When putting LibreOffice in fullscreen mode, the cursor is correctly aligned with the GUI.
This leads me to believe that the program uses the absolute position of the pen on the screen, and interprets it as the absolute position of the pen on the active program.
When trying the same thing with the System Settings and a guilty module, the vertical offset on the module list disappears, but a horizontal offset on the active widget remains, which reinforces this hypothesis.

Last edited by Baplar (2019-08-18 18:16:37)

d_fajardo

Member

Registered: 2017-07-28

Posts: 1,652

Re: Wacom - Cursor offset in a few programs only

It's looking like a LibreOffice issue - that's why I asked how tablet behaves with other program. I haven't tried using Wacom with LibreOffice but I will experiment with it and see if I can replicate the problem on my side.

Baplar

Member

Registered: 2018-03-27

Posts: 5

Re: Wacom - Cursor offset in a few programs only

After fiddling a little, I managed to isolate the potential root of the problem: this appears to be a Qt problem!

By default, LibreOffice runs the backend that corresponds to the current desktop environment (e.g. Qt for KDE and GTK for Gnome).
Forcing LibreOffice to use GTK solves the issue (and the problem remains when forcing the Qt backend):

SAL_USE_VCLPLUGIN=gtk3 libreoffice

If you want to try and reproduce my issue, and you are not using a Qt-based DE, I think you should set the variable to qt5.

I suspect that the guilty programs (LibreOffice and the aforementioned KCMs) use some deprecated feature of Qt which makes this behavior appear.
But what exactly triggers it is anyone’s guess at this point.

When running the KDE system settings in console, the logs do not indicate any particular warning or error when the problem is triggered.
However, once the issue appears, when highlighting the left menu entries to make their contextual info appear, this message is logged:

QWidgetWindow(0x<address>, name="FocusHackWidgetClassWindow") must be a top level window.

This is the case for both the Activities module and the Connections module.

A quick Google search indicates that this message is produced by the "QWindow::setTransientParent" method, but I don’t really know what to make of it…

Last edited by Baplar (2019-08-19 10:50:16)

d_fajardo

Member

Registered: 2017-07-28

Posts: 1,652

Re: Wacom - Cursor offset in a few programs only

Well done! I will definitely have a look. I'm not even sure what backend LibreOffice uses in my system. I assume it would be Qt as I'm on KDE.

A quick Google search indicates that this message is produced by the "QWindow::setTransientParent" method, but I don’t really know what to make of it…

Me neither...

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

Hi, I have the same problem using a Wacom Intuos4 (8x13) (PTK-840) tablet.
It is connected with a USB cable.
I see the problem in the following appliactions:
* digiKam
* showFoto
* Gwenview
* systemsettings5 (the KDE System settings application), but only after activating "Workspace > Desktop Behaviour > Activities" or "Network > Connections".
* LibreOffice

@Baplar, Would you be willing to test if you see the problem in digiKam, showFoto and Gwenview?
digiKam and showFoto are both in package digikam.
Gwenview is in package gwenview.

I know I used digiKam to find some photos on 2019-06-19, so the tablet worked back then.

I can add the following info to the problem:

When I log in to an Icewm session (no KDE stuff), the problem is _not_ there in LibreOffice, but it is still there in the other applications.
I can confirm that when LibreOffice is run in a Plasma session using "SAL_USE_VCLPLUGIN=gtk3 libreoffice", the problem is _not_ there in LibreOffice.
This seems to confirm that the problem has something to do with the KDE/Qt Plasma session environment.

I have downloaded the distro independent appimage of digiKam from digikam.org
Both the Arch repo digiKam and the non-Arch digikam.appimage are version 6.2.0.
The problem is _not_ there in digikam.appimage.

Given that the tablet works in digikam.appimage, and this appimage doesn't contain neither the linux kernel, nor the Wacom kernel driver, it must be using the Arch kernel and the Arch Wacom driver.
Thus it doesn't seem to be an issue with the kernel or the kernel driver.
Downgrading xf86-input-wacom to a version prior to 2019-06-19 does not solve the problem.
Thus it doesn't seem to be an issue with the X.Org Wacom tablet driver.

I have tried resetting my tablet settings to the Arch defaults. The problem is still there.

I have tried finding the common set of files in the digikam.appimage and in the normal file system, then temporarily replacing file system files with the appimage files. That did not help pinpoint a possible single file which might contain the problem.

I have tried using lsof to see what files the different applications open, to see if the applications having the problem use some different files than the ones not having the problem.
They all use the same files, as far as I can see.

I have tried using lsof to see what files LibreOffice opens when running in an Icewm session compared to when running in a Plasma session.
There are about 100 files in difference under Plasma, most of which relate to KDE Framework 5 (KF5) and Qt.
This seems again to point to a problem with something in KDE/Qt.

Any additional ideas on how to proceed to try to pinpoint where the problem is?

Best regards

Johnny

d_fajardo

Member

Registered: 2017-07-28

Posts: 1,652

Re: Wacom - Cursor offset in a few programs only

I can see what you both are pointing at. I've not really used Wacom besides drawing so I haven't discovered this issue. In my system Gwenview and KDE System Settings work fine but LibreOffice and Digikam are not. Digikam particularly has a terrible offset.
I don't have the answers but it does point to KDE and Qt.

Baplar

Member

Registered: 2018-03-27

Posts: 5

Re: Wacom - Cursor offset in a few programs only

As far as I can tell, Gwenview and Digikam work fine on my system. Did you have to perform a specific task for the problem to manifest?
ShowFoto does indeed exhibit the issue on my laptop too, however. Weird, considering Digikam is from the same suite and seems to work fine for me.

Now that you mention a change in behavior over time, I think I do remember Gwenview having the same problem before, but I can not reproduce it anymore. Is your version of Gwenview up-to-date?

I think there’s not much we can do on our own here. The problem is mostly a corner case of some obscure part of the Qt library.
I guess once we gather all evidence we have, our best hope would be to report it to the Qt team.
I wouldn’t expect much from it, though. This issue only affects a tiny portion of the user base, and is easy to work around by using another pointing device. This would probably not rank very high on the Qt dev team’s priority list.

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

So, the problem shows up in different KDE applications for all of us.
The only application where we all see the problem is LibreOffice.
By the way, I use the libreoffice-still package. Which LibreOffice package do you use?

I also tried making a new test user on the system. Same problem there, so it doesn't seem to be user specific settings that make the problem show up.

@Baplar, I do not have to perform a specific task for the problem to manifest. It is there as soon as the application window shows, except in KDE System Settings, where it starts as soon as one of the mentioned modules are activated.
@Baplar, my version of Gwenview is up-to-date. I upgraded this morning.

@Baplar and @d_fajardo, are both of your systems up to date?
Mine was upgraded this morning.
Can you remember when you initially installed Arch? And how often do you upgrade?
Mine seems to have been installed 2017-10-16.
Perhaps some disruptive cruft can accumulate over time, if one upgrades often?
I usually upgrade daily. Sometimes several times a day.

These root commands show when the file system was created, which may be an indication of when the system was installed:

# fs=$(df / | tail -1 | cut -f1 -d' ') && tune2fs -l $fs | grep created

Or,

# dumpe2fs /dev/sda1 | grep 'Filesystem created:'

Or,

# tune2fs -l /dev/sda1 | grep 'Filesystem created:'

@Baplar, I think it could also be a KDE KF5 library issue. All the mentioned applications open the same bunch of files from KDE Framework 5 (KF5) when run under Plasma, as far as I have been able to tell using the lsof command. And they all open the same handful of Qt files. So it could be either.

Perhaps I should try to install a new clean Arch on an old hard drive I have lying around, and see if the problem shows up there too.
If the problem is there in a new installation, I could try installing a different distro to see if it is a problem specific to Arch.
OpenSuse Tumbleweed seems to be a rolling release bleeding edge distro too.

Best regards

Johnny

d_fajardo

Member

Registered: 2017-07-28

Posts: 1,652

Re: Wacom - Cursor offset in a few programs only

My system is up-to-date.
I don't think there's much one can do. I mainly use Wacom for drawing and Blender, GIMP, Inkscape, Krita all works fine with it. I guess it's not really designed to be another mouse.
Note also the differences in our outcome might have to do with the differences in our devices.

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

I hadn't thought of device differences, but you are right. That may be a factor.
I use my tablet as the pointing device almost exclusively, so this is a big deal to me.

Anyway, I may have found the date where the problem was introduced.

I installed the latest Arch on a spare hard drive.
On 2019-08-21 on my system I see the problem in digiKam, showFoto, LibreOffice (still) and KDE System settings. Gwenview however doesn't show the problem on this test install. That's odd, because on my production system Gwenview still show the problem, and this system has been upgraded even later today than the test system. Weird.

Using the Arch Linux Archive to restore all packages to specific dates, and then downgrading/upgrading, at least on my system I found that my tablet worked in all applications on 2019-06-16, but upgrading to the next day (2019-06-17) my tablet didn't work in digiKam, showFoto and KDE System Settings. However LibreOffice (still) and Gwenview do not have the problem.

The packages upgraded from 2019-06-16 to 2019-06-17 are:

appstream (0.12.6-1 -> 0.12.7-1)
qt5-base (5.12.3-2 -> 5.12.4-1)
appstream-qt (0.12.6-1 -> 0.12.7-1)
btrfs-progs (5.1-1 -> 5.1.1-1)
less (550-1 -> 551-1)
qt5-script (5.12.3-1 -> 5.12.4-1)
qt5-x11extras (5.12.3-1 -> 5.12.4-1)
qt5-multimedia (5.12.3-1 -> 5.12.4-1)
qt5-speech (5.12.3-1 -> 5.12.4-1)
qt5-svg (5.12.3-1 -> 5.12.4-1)
qt5-declarative (5.12.3-2 -> 5.12.4-1)
libakonadi (19.04.2-1 -> 19.04.2-2)
qt5-graphicaleffects (5.12.3-1 -> 5.12.4-1)
qt5-location (5.12.3-1 -> 5.12.4-1)
qt5-quickcontrols (5.12.3-1 -> 5.12.4-1)
qt5-quickcontrols2 (5.12.3-1 -> 5.12.4-1)
qt5-sensors (5.12.3-1 -> 5.12.4-1)
qt5-tools (5.12.3-1 -> 5.12.4-1)
qt5-webchannel (5.12.3-1 -> 5.12.4-1)
qt5-webengine (5.12.3-2 -> 5.12.4-1)
qt5-xmlpatterns (5.12.3-1 -> 5.12.4-1)

That seems to strongly confirm what has been suspected previously: It's likely a Qt bug.

I need sleep now, but tomorrow I will try to downgrade individual packages to see if a single package introduces the problem.
If anyone has any suggestions as to a particular package you think could be the one, please let me know, so I may avoid spending time trying all the packages.

Best regards

Johnny

huyizheng

Member

Registered: 2018-05-15

Posts: 21

Re: Wacom - Cursor offset in a few programs only

Same here, it seems a problem related to qt version 5.12.4 and later.
I found this problem after one system update, during that update nothing other than qt5-* is updated.

huyizheng

Member

Registered: 2018-05-15

Posts: 21

Re: Wacom - Cursor offset in a few programs only

For libreoffice this problem can be solved by using "SAL_USE_VCLPLUGIN=gtk3 libreoffice". But for other apps like smplayer, gwenview, texmaker I cannot find out any solution except to downgrade qt to 5.12.3

d_fajardo

Member

Registered: 2017-07-28

Posts: 1,652

Re: Wacom - Cursor offset in a few programs only

Thanks for the info huyizheng. I guess it's a matter of downgrading qt or waiting for the next upgrade with a fix. This might be a good bug report upstream. Does anyone know how to do it?

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

Update:

At least on my test system I have narrowed it down to these packages in an Icewm session:

qt5-base
qt5-declarative
qt5-quickcontrols
qt5-quickcontrols2
qt5-svg

When downgrading these from 5.12.4 to 5.12.3 the problem stops in the two problematic modules in KDE System settings.
The other qt5-* packages can be left at 5.12.4 without the problem.
So it seems the problem was introduced in one of those packages.

digiKam and showFoto won't start with just those five packages downgraded.
qt5-webchannel must be downgraded also to 5.12.3 for them to start.
But the error message without downgrading qt5-webchannel seems unrelated to the pointer problem:

relocation error: /usr/lib/libQt5WebChannel.so.5: symbol _ZN5QtQml29qmlAttachedPropertiesFunctionEP7QObjectPK11QMetaObject version Qt_5 not defined in file libQt5Qml.so.5 with link time

Given that the problem can be removed in KDE System Settings without downgrading that package, I don't think the problem is in there.

Far from me to tell other people if they should make upstream bug reports, but before making a bug report upstream, I think it would be wise first to find out if this is a problem specific to Arch, which, as I understand it, patches some of the packages from upstream.
Tomorrow I will try to install openSuse Tumbleweed, which, as I understand it, is also a bleeding edge rolling release distro.
If the problem is there too, it is more likely to be an upstream problem.
If the problem is not there, it is more likely to be an Arch specific problem.

Best regards

Johnny

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

Update:

OpenSuse has the same problem.

I tested both the latest ordinary release (named Leap) and the much more up-to-date rolling release (named Tumbleweed).
The ordinary release use qt5 5.9.7 and does _not_ have the problem.
The rolling release use qt5 5.13.0 and _does_ have the problem.

I would say that points to an upstream bug.

Best regards

Johnny

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

Update:

Searching through the qt5 source code for files that have changed between the commits tagged 5.12.3 and 5.12.4, one particular file stands out as having had added code that looks like it is calculating pointer coordinates in relation to screen size.

qt5 source code, module qtbase

diff --git a/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp b/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp
index 04ddd3c98c..450706fc53 100644
--- a/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp
+++ b/src/plugins/platforms/xcb/qxcbconnection_xi2.cpp
@@ -240,6 +240,10 @@ void QXcbConnection::xi2SetupDevice(void *info, bool removeExisting)
     } else if (name.contains("uc-logic") && isTablet) {
         tabletData.pointerType = QTabletEvent::Pen;
         dbgType = QLatin1String("pen");
+    } else if (name.contains("ugee")) {
+        isTablet = true;
+        tabletData.pointerType = QTabletEvent::Pen;
+        dbgType = QLatin1String("pen");
     } else {
         isTablet = false;
     }
@@ -1208,6 +1212,11 @@ bool QXcbConnection::xi2HandleTabletEvent(const void *event, TabletData *tabletD
     return handled;
 }
 
+inline qreal scaleOneValuator(qreal normValue, qreal screenMin, qreal screenSize)
+{
+    return screenMin + normValue * screenSize;
+}
+
 void QXcbConnection::xi2ReportTabletEvent(const void *event, TabletData *tabletData)
 {
     auto *ev = reinterpret_cast<const qt_xcb_input_device_event_t *>(event);
@@ -1220,6 +1229,17 @@ void QXcbConnection::xi2ReportTabletEvent(const void *event, TabletData *tabletD
     QPointF global(fixed1616ToReal(ev->root_x), fixed1616ToReal(ev->root_y));
     double pressure = 0, rotation = 0, tangentialPressure = 0;
     int xTilt = 0, yTilt = 0;
+    static const bool useValuators = !qEnvironmentVariableIsSet("QT_XCB_TABLET_LEGACY_COORDINATES");
+
+    // Valuators' values are relative to the physical size of the current virtual
+    // screen. Therefore we cannot use QScreen/QWindow geometry and should use
+    // QPlatformWindow/QPlatformScreen instead.
+    QRect physicalScreenArea;
+    if (Q_LIKELY(useValuators)) {
+        const QList<QPlatformScreen *> siblings = window->screen()->handle()->virtualSiblings();
+        for (const QPlatformScreen *screen : siblings)
+            physicalScreenArea |= screen->geometry();
+    }
 
     for (QHash<int, TabletData::ValuatorClassInfo>::iterator it = tabletData->valuatorInfo.begin(),
             ite = tabletData->valuatorInfo.end(); it != ite; ++it) {
@@ -1228,6 +1248,20 @@ void QXcbConnection::xi2ReportTabletEvent(const void *event, TabletData *tabletD
         xi2GetValuatorValueIfSet(event, classInfo.number, &classInfo.curVal);
         double normalizedValue = (classInfo.curVal - classInfo.minVal) / (classInfo.maxVal - classInfo.minVal);
         switch (valuator) {
+        case QXcbAtom::AbsX:
+            if (Q_LIKELY(useValuators)) {
+                const qreal value = scaleOneValuator(normalizedValue, physicalScreenArea.x(), physicalScreenArea.width());
+                global.setX(value);
+                local.setX(value - window->handle()->geometry().x());
+            }
+            break;
+        case QXcbAtom::AbsY:
+            if (Q_LIKELY(useValuators)) {
+                qreal value = scaleOneValuator(normalizedValue, physicalScreenArea.y(), physicalScreenArea.height());
+                global.setY(value);
+                local.setY(value - window->handle()->geometry().y());
+            }
+            break;
         case QXcbAtom::AbsPressure:
             pressure = normalizedValue;
             break;

I searched for files where the strings "wacom" or "tablet" (case insensitive) was part of the file name, or part of the text content, and which seemed to be part of the modules I have identified as introducing the bug. So I can't rule out that the bug is in some other file that just doesn't happen to contain those strings.

Tomorrow I will try to make a nice structured bug report with the information in this thread.
I believe others have to confirm the bug, before anyone wants to spend time working on it, so I will make a post here when I have done that.
Please be careful to tell the qt people these things:

* Exactly what tablet you are using, and how it is connected to your computer (wireless, wired).
* What linux distribution you are using.
* In what applications you experience the problem.
* With what qt5 version you are experiencing the problem.
* If you have downgraded qt5: What version you have downgraded to, to get rid of the problem.

Best regards

Johnny

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

Bug reported in the qt bugtracker.

https://bugreports.qt.io/browse/QTBUG-77826 (Wacom tablet: Cursor input offset from cursor position)

Please go there and add:
* a vote on/confirmation of the bug.
* exactly what tablet you are using, and how it is connected to your computer (wireless, wired).
* What linux distribution you are using.
* In what applications you experience the problem.
* With what qt5 version you are experiencing the problem.
* If you have downgraded qt5: What version you have downgraded to, to get rid of the problem.

The more people vote on the bug, and the more information the qt developers have, the more likely it is that someone starts working on the bug.

Best regards

Johnny

Last edited by johnnyn (2019-08-26 11:19:50)

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

Workaround:

Start the afflicted application like this:

QT_XCB_TABLET_LEGACY_COORDINATES="" digikam

This seems to work for all the afflicted applications on my system.
Please try on your systems.

The content of the environment variable doesn't matter. It just has to be set, according to this commit message:

Commit SHA: e4532224145a0a72cde9b40cb7fd39011624d1c1
Commit time: 2019-04-01 16:36:47

Fix tablet jitter on X11

We should get the correct stylus position from the valuators,
not from the X11-provided global position. Global position is rounded
to the nearest FP16 values, which is not enough for smooth painting.

[ChangeLog][Platform Specific Changes][X11 / XCB] QTabletEvent
coordinates now come from AbsX/AbsY valuators in the X11 event, in
more precise 32.32 fixed-point format, scaled to fit the virtual
desktop.  It's possible to revert to using the legacy 16.16-format
event_x/event_y coordinates as in previous releases by setting the
QT_XCB_TABLET_LEGACY_COORDINATES environment variable.

Task-number: QTBUG-45375
Fixes: QTBUG-48151

This commit is exactly the one adding the new coordinate calculations shown in the git diff in post #18.

I will add information in the qt bug report.

Best regards

Johnny

Baplar

Member

Registered: 2018-03-27

Posts: 5

Re: Wacom - Cursor offset in a few programs only

Wow, incredible job investigating this issue, Johnny!
The QT_XCB_TABLET_LEGACY_COORDINATES workaround you proposed worked like a charm on my end as well. I have set it up to be exported when the X server starts up, and it solved the problem for all the programs that encountered it on my rig. Nice catch!

I have gone ahead and voted your Qt bug report.
I guess this topic is now redundant, but we can’t really mark it as [SOLVED] just yet, can we?
I think we should defer further discussion to the Qt bug report and lock this one down as soon as it is taken care of upstream.

d_fajardo

Member

Registered: 2017-07-28

Posts: 1,652

Re: Wacom - Cursor offset in a few programs only

Yes, Great! It does work for me too!

johnnyn

Member

Registered: 2015-10-26

Posts: 26

Re: Wacom - Cursor offset in a few programs only

I guess this topic is now redundant, but we can’t really mark it as [SOLVED] just yet, can we?

I aggree. No fix has been found, just a workaround, so the problem isn't really resolved
Thank you for putting a link to the qt bug report at the top of your initial post.
Could you also put the environment variable workaround up there, so people don't have to dig through 19 posts to find it?
Best regards
Johnny

GRem

Member

From: Asunción

Registered: 2010-08-20

Posts: 32

Re: Wacom - Cursor offset in a few programs only

I originally had this happen only with Virtualbox and the issue was a bit different - inside the VM, the cursor was effectively offset, and in the VM manager interface no tablet clicks would register at all. Touchpad or mouse would register normally, however. I thought it was just something with VBox since no other program had something like that.

Then after a system update this also started affecting Libreoffice as well, but now that's no longer an issue. Currently using the aforementioned solution works, thanks!