Hi!

I am one of the authors of a Linux driver for the Bosto Kingtee 14wa(2) tablet.
The driver source is here: https://github.com/lesliev/bosto_14wa

This driver works fairly well with Krita, but there's been a recent commit that adds support for the eraser device at the back of the stylus. This works in Gimp but not in Krita - which seems to hardcode device information. If that's true, can you add the eraser device? Currently Krita treats the eraser like a pen.

This post shows how the devices look in Gimp, which hopefully gives you enough information to do this:
http://forum.bosto.co/viewtopic.php?f=9 ... 3058#p2659

I believe the *name* of the device is used to determine its function. Amazingly.
Otherwise, can you let me know what else is needed to get the eraser working right in Krita?

Thanks!

Krita checks the QTabletEvent::Eraser flag to determine whether by default to use an eraser preset or not. If that's set correctly, absent the user having selected a non-eraser preset with the eraser end, Krita would select an eraser preset.

Ok, thanks for that. I took a look at http://doc.qt.io/qt-4.8/qtabletevent.html, which has this interesting note:

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.

So I attempted to mess around with xorg.conf like so:

Section "InputDevice"
Driver "bosto14_wa"
Identifier "eraser"
EndSection

Following recipe's mentioned here: https://wiki.archlinux.org/index.php/Wacom_Tablet
But that seemed to have no effect - Krita thought the eraser was a pen as before.

So I thought that perhaps I could change the names reported to the system to "eraser" and "stylus", which I did in the driver:

$ xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=11 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=12 [slave pointer (2)]
⎜ ↳ Logitech USB Optical Mouse id=14 [slave pointer (2)]
⎜ ↳ stylus id=17 [slave pointer (2)]
⎜ ↳ eraser id=18 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Integrated Camera id=9 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]
↳ ThinkPad Extra Buttons id=13 [slave keyboard (3)]
↳ SONiX Key Roll id=15 [slave keyboard (3)]
↳ SONiX Key Roll id=16 [slave keyboard (3)]

Unfortunately that also seemed to have no effect.

The eraser and stylus end also need to have a different unique id. I'm not sure whether that's the case for Bosto. The Bosto people did reach out to us to get us test hardware, but their proposal was a bit odd: they offered to give us the change to buy the test hardware, and I'm afraid that we don't have the budget for that, especially when Huion, Yiynova and Wacom made test and development hardware available for free to the Krita project.

The stylus and eraser do have different id's. Hacking around with MyPaint made me realise they need to be two different devices.
Maybe I can get hold of the QT people to explain the problem, or look at QT's source.

"the change to buy the test hardware"? Not sure what you mean. Chance?
Bosto did provide me a tablet, under the condition that I get a Linux driver working for it within a certain amount of time, or else send it back at my own expense. This I was able to do, though I would love to get the driver into the kernel and the tablet working well with all the major programs.

Well, the Bosto people contacted me, and offered to provide a tablet to make krita work with it, if I paid for it... The actual tablet handling code for Krita 2.9 is in krita/ui/input/wintab: Krita 2.9 doesn't use the Qt tablet support. Krita 3.0 will be using Qt 5's tablet support though.

Hehe, yes, that's not very much of an incentive, if that's what they had in mind

I'll try to take a look at krita's code.

I looked around to try and find a Qt tablet program and the first I found was Drawpile (http://www.ubuntuupdates.org/package/ge ... b/drawpile). Unfortunately this hardly works at all with the tablet. The pressure detection seems to cut out all the time. It's getting to be quite frustrating - every single program I try reacts differently to the same tablet and driver.

It's still not as bad as the SP3 problem that I am trying to solve, where Krita will only work with the n-trig wintab drivers _if_ I install the Photoshop trial!

Probably true!

How long do you think 2.9 will be around? Is it worth me try to get a build environment up to hack on 2.9 or should I focus on getting QT5 to work in time for Krita 3?

My guess is until the end of the year, and then I expect people to keep using it for a bit longer. It sounds long, but it's probably better to start looking into the Qt5 version of Krita!

I was accidentally building the test program with qt4 - when I switched to qt5, it did indeed detect the eraser device properly. Yahoo! Now I can't wait for Krita 3!

Actually since Qt5 will probably be ok, I might apt-get source the current krita and hack it a bit to try and figure out what the problem is. If I can check a few more things off the list I may be able to finally get this driver into the kernel.

Oh, that would be cool!

Moin,

I am using a Bosto 22HD pen display - unfortunately I can not use Linux, because none of the Linux distributions I tried recently would run smoothly with my hardware (the Bosto display only being one of the impossible to configure devices), so I am stuck with Windows 10.

So far I can use Krita 3.0 RC 1 (64Bit) on Windows 10 with the Bosto 22HD. Unfortunately, and that is the reason for me posting here, the "right mouse button" on the pen does not work reliably in Krita. Interestingly it works, if I set the focus out of Krita, like clicking on the desktop once and then right-clicking (with the stylus) in the Krita window. But having the focus in Krita will 98% not trigger a right mouse button function (bring up the pie menu) with the stylus. It works perfectly with the mouse, though.

Is there some advice you could give at what to try out to make it work? I would be willing to dig into patching the code, but unfortunately my spare time is too limited to start development participation in another project (I am "backing" Krita on Kickstarter, of course, and I will try to find other ways of supporting the project as well).

Thanks,
Marc

Hi Malbrecht,

I'm already amazed you can paint with it... Bugs like this are _really_ difficult to fix without hardware: I actually think that something like this was reported for some other tablet, too, but I cannot find the bug right now.

It might, depending on how **** the drivers are (and usually the **** is incredible) be impossible. And unfortunately, unlike Huion, Yiynova and Wacom, Bosto hasn't donated hardware to the Krita project. That's to say, they contacted me and graciously offered to send me hardware if I paid the full price for it! I didn't take them up on the offer.

Bosto is just one of the brands for which we don't have hardware: Genius, Trust and Peritab are others -- with those, Krita crashes. Or the wintab driver crashes, I don't know. Ugee seems to work, but we don't have the hardware either... And if we had the hardware, we'd be facing another problem: you cannot install two wintab drivers in Windows at the same time. That means that a given Windows box can only work with one make of tablet, or even one model of one brand. Since the drivers are worse than you probably want to believe, often uninstalling a driver and then installing a driver for another model will either do nothing, won't make the second tablet work or will just screw up the Windows installation...

(And !@#$% the forum software for taking the **** out of c_r_a_p)