Works for me with Debian/Lenny (or almost lenny...) with an intuos3 tablet. And I can't reproduce the bug. It might not be a bug in Qt, but it might be a bug in the wacom driver. One way to check that would be to test with an application that doesn't use Qt for tablet events, or to check the values with xidump, and see if the X/Y values are ok.

I should've mentioned that the tablet works perfectly in GIMP. I'll have a look at xidump when I get a chance.

Interesting that it seems to work for you, because I'm using what could be described as "mostly Lenny", with bits pulled in from unstable and experimental as required for KDE 4.2 and KOffice betas.

I might also point out that since I'm using a 16:10 aspect display I've modified the parameters in xorg.conf to make the usable range of the tablet also 16:10, i.e. not use a small portion at the bottom. I had a go at removing those lines from xorg.conf but that didn't seem to make any difference.

Now that I think of this issue... It reminds me of a problem someone had in the past (he was also using a graphire), that I solved with a work around, but since he told me the problem was solved I removed the work around, I would suggest for the final release, to reinstantiate the work around, but I would also like the problem to be isolated between driver / Qt, and properly reported, so that it get properly fixed.

More info: I just tried xidump and all the values look reasonable. Min is zeros and max is (10208, 6380), and the position lies within that range as expected (though the mechanical resolution of the tablet isn't as high as the max numbers suggest, it's still greater than one pixel).

Interesting, I do get "Valuators: Absolute   ID: Unreported  Serial Number: Unreported". Perhaps Qt baulks at the "Unreported"s. If you know how I might test that theory, let me know and I'll try.

Hi,

I now suppose those "Unreported"s are expected since my tablet is only a Graphire, thus individual pens don't have their own identifiers.

I've spent a good while last night and today digging at how Qt works to interpret X events. I had a nice followup post typed up when, while trying to open a new X screen to further test a new debug logging level, X crashed and lost it. :( I won't be able to reproduce it all.

Suffice it to say, Qt grabs device data that appears to be coming to it untranslated from the X server, when that data should have been translated. The fault lies with X not calling the xf86WcmDevConvert function in xf86Wacom.c of the wacom driver, when it should. I don't know why. There is a work-around in the code when this occurs, but it should only be a problem for older versions of the X server, but it is certainly true that neither the work-around nor the function itself are being run.

Hopefully all that I've surmised is correct, as I'll shortly be submitting a bug report to the Debian wacom driver, with the hope that someone with better understanding of this stuff than I can investigate it further.

Peace,
Brendon

Oh Lord. Looks like I've stumbled into a whole can of worms with this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516537

The summary, as best I understand it, is that there are known problems with the way X does things at the moment, resulting in unscaled data being fed to applications.

But that might not actually be the problem after all. After some more poking this morning I've just found that Qt does attempt to perform its own scaling of the tablet-coord input to screen coords (line 4291 of qapplication_x11.cpp, see also qapplication_p.h line 135). This is based on maximum values that are set on line 2181.

Either the maximal values aren't being set correctly or the scaling isn't happening for some reason. I'll have to look into this further when I get time, since I really shouldn't be doing this at work. ;-)

Peace,
Brendon

I'll bring this bug to the attention of Thomas Zander, who works at Qt Software. It looks like something we, poor krita hackers, cannot really fix! Thanks for all the energy and inquistiveness you've put into this issue, much appreciated!

Hi! I think I've finally figured out exactly what the problem is. I've spotted that the hiRes values Qt gives are fine, scaled according to the screen. However, the "low-res" values are not. What is going on is that Qt calls the "scaleCoord" function to normalise the high-res data, but does nothing about the low-res data. It just assumes (See line 4171 of qapplication_x11.cpp and onwards) they're already scaled to screen coords, but the problems in X I linked to above make this a wrong assumption.

Qt could work around the X issue by deriving screen coords from the high res data, instead of using x/y and x_root/y_root from the X event.

Krita could work around the Qt issue similarly, by avoiding the use of low res data from Qt. I'll show you; take the code snippet I posted at the top of this bug report (found in kis_qpainter_canvas.cpp and kis_opengl_canvas2.cpp):
qreal subpixelX = e->hiResGlobalX();
subpixelX = subpixelX - ((int) subpixelX); // leave only part behind the dot
qreal subpixelY = e->hiResGlobalY();
subpixelY = subpixelY - ((int) subpixelY); // leave only part behind the dot
QPointF pos(e->x() + subpixelX + m_d->documentOffset.x(), e->y() + subpixelY + m_d->documentOffset.y());

I think (but haven't tested) that this should work:
// Workaround bugs in X/Qt by not assuming coord pairs are pre-scaled by the same amount.
qreal x = e->hiResGlobalX();
qreal y = e->hiResGlobalY();
QPoint intpixel((int) x, (int) y); // take only the integer part
QPointF subpixel(x - intpixel.x(), y - intpixel.y()); // take only part after the dot
QPointF pos = QPointF(mapFromGlobal(intpixel) + m_d->documentOffset) + subpixel;

The idea is that this bypasses Qt's calculation, grabbing the global translation from the widget itself rather than relying on the precalculated translated x/y in the TabletEvent structure. This way, it's doing the mapFromGlobal on the high res data, which is scaled, instead of X's low res event data, which Qt uses to mapFromGlobal and is not scaled.

I just realised this might have an issue with your mouse event suppression logic. I'm not sure, you'd probably want to check that.

I hope that all made sense. Feel free to ask me to be more clear, and feel free to pass any of this on to Qt devs. :-)

Peace,
Brendon

Please try if upgrading to Qt4.5 helps you with this problem.

You might as well have asked me if I've tried turning my machine off and on again [http://en.wikipedia.org/wiki/The_IT_Crowd#Situation_and_plot]. No, it doesn't help. Aside from making some things crashy (plasma crashes on startup, krita doesn't stay up very long), my little tablet test PyQt program does run. But it's clear that the position (local and global) QPoints in the QTabletEvent are the same unscaled numbers as before.

I'm not surprised. I'm looking at a diff of qapplication_x11.cpp between 4.4.3 and 4.5 RC1. There's a small number of tablet-related changes, predominately refactoring, but clearly nothing that would address this problem. Qt continues to assume that X scales the "low-res" position to screen coords, but the assumption doesn't hold. Please see my previous post in this bug report.

I'll attach the python program I've been using, FWIW. I originally stole it from somewhere on the net, can't for the life of me remember where, but I had to port it from Qt3.

Peace,
Brendon

Created attachment 31674 [details]
PyQt program to show Qt tablet event data.

Fixed, as of today, we are now using hiResGlobalPos.