Krita: new extended tablet support!

Traditionally Krita supported various types of tablets on Linux, but this support was limited to the tablets handled by wacom driver. The list of the supported hardware included (obviously) all the Wacom-branded tablets and some rare species that were trying to resemble the branded devices. It was the best that one could get form the Qt's tablet code. From now on Krita can also work with all the devices which are handled by the evdev X11 driver!

The list of the devices supported by evdev is really vast. It includes such not-very-expensive brands like Monoprice, Bosto, Huion and Genius. By the moment we tested Krita on two devices: Bosto 19MA [0] and Genius G-Pen 560. Both work fine with Krita and have really nice pressure support! Right now we are also working on support for the Huion tablet supplied by huiontablet.com to the Krita project as well!

Bosto kingtee 19MA now works with Krita!

So if you have a tablet device which used to refuse to work with Krita on Linux, test it now!

I also did a small cross-test of my old Wacom Graphire2 device and Genius G-Pen 560. What I noticed is that the lines generated by the Wacom tablet are more stable and smooth, whereas the lines by the Genius tablet are a bit dizzy. I don't know what is the exact reason for it, but I have a feeling that Wacom does some internal filtering of the coordinates generated by the hardware, which gives us better lines. Anyway, even if you own this Genius device, Krita allows you to workaround the issue. Just enable Weighted Smoothing painting algorithm and it will produce the results just like Wacom does!

And if you would like to know the technical details about why Qt's tablet code supports wacom-driver-based tablets only...

Qt's code doesn't fully support the interface of the XDeviceMotionEvent. Qt expects that the values of all six axes of the tablet will be sent to the client in each event. This is true for wacom driver, but it is not guaranteed to be true for other XInput devices. The motion event can also send the values that changed since the last event only. It even has special fields for that:

typedef struct
    {
    /* ... skipped ... */
    unsigned char axes_count;
    unsigned char first_axis;
    int           axis_data[6];
    } XDeviceMotionEvent;

axes_count field tells us how many axes are really delivered to the client and first_axis tells to what absolute axis the first element of axis_data corresponds to.

Now Krita can handle that effectively, as well as recognize to what sensor each axis is assigned to! [1]

[0] - https://groups.google.com/forum/#!topic/bosto-user-group/sL_O4VoopVk
[1] - unlike Gimp's way, where the user must manually investigate to which sensor each axis is connected to ;P