I know Surface Pro 3 support is a huge pain for you guys. Thanks for making the program so usable already. The most recent update seems to have affected the support for the eraser side button in Krita. (The right click button seems to register properly.) I recall it worked in the last version I installed. I'm happy to run a debugger for you to collect output. Reproducible: Always Steps to Reproduce: 1. Press and hold eraser side button while selecting tools or drawing Actual Results: Change primary brush and stroke with primary brush Expected Results: Select alternate brush, stroke with alternate brush
Hm... Which was the last version you tried? Was that still a 2.8.3 stable?
Hi Boudewijn, The last version I used was 1710cf. I just tried re-installing it and the eraser works. Cheers, Michael
Rather, an 2.9 x64 pre-alpha version number 2.8.79.23
Okay, thanks for the info. I'll try to figure out how to configure my intel 2:1 with ntrig to support that button setup -- by default, on this system the buttons seem to be doing nothing.
Hi, I have had problems with n-trig getting to work on krita (I use a sony vaio fit flip, it often appears to share problems with surface machines) anyway, I installed a wintrab driver http://www.n-trig.com/wintab-2/ at some point (link now dead) and I think it messed with my wacom tablet ( I am not sure) because now I can't get pressure sensetivity on my wacom intuos 3 on krita, but it does work in photoshop. I don't know how to go about troubleshooting this. N-trig was bought by microsoft and their website and links seem to have vanished off the internet.
Hello, I think I found an issue in how Krita determines whether the wintab cursor is a cursor or an eraser, I'll write down how the issue occurs, as I am not quite sure about how to best fix it. I am, however, happy to test any changes (preferably as executable). - When a tablet pen is brought close enough to the digitizer as to be recognized, this gets parsed and sent to applications as WT_PROXIMITY messages. Depending on the exact type of device, either the pen has an eraser side (in which case it is immediately known if it is an eraser or not, and it won't switch, so this works perfectly), or an eraser button. In the latter case, erasing could switch at any moment (this is also why I am not certain about whether just updating the pen type on the fly would work). - Krita only checks if the device is a pen or eraser once, when it gets the WT_PROXIMITY message. This doesn't seem to be enough time between the pen being in proximity and the status being queried for the n-trig eraser button being recognized, thus having Krita recognize the device as a pen always, even when the eraser button is pressed. Basically, the best fix for this would be to have the pen status either be queried at mouse down, or have the pen status being read every packet and the internal state being updated too, to allow for dynamic switching between eraser and normal pen.
Please see https://git.reviewboard.kde.org/r/124278/ for a patch. The experience is not perfect because the actual packets where when the tool reports being an eraser are very short. For example, if you choose a different preset for the eraser it appears briefly on screen, but as soon as you lift the stylus up it disappears, even if you have held the eraser button down. It might be possible to write a more tailored solution but documentation for this thing is hard to come by. The best case would be detailed specs from Microsoft, but if someone wanted to reverse engineer the packet logic perhaps we could have a nicer solution. At the same time, this has the flavor of a bug and at the very least it is quite poor design, and I wouldn't be surprised if it's fixed in the future.
Hi, I have done some more information gathering on the N-trig pen, and these are my results: - When the eraser button is pressed/released while on the screen, there will be a few packets where the screen is not tapped. I think this is so they avoid problems where a pen suddenly transforms into an eraser, since the wintab spec doesn't specifically mentions the cursor number changing while in action. - Due to N-trig using an active pen, the pen always sends out a signal to indicate it exists, but it doesn't seem to send the data of the buttons until tapping the screen, to avoid massive battery usage (and, who has AAAA batteries? :P), this causes the effect as mentioned in my previous comment, and causes the issue in Krita. Some more information about the device: WTInfoA(WTI_DEVICES, DVC_NAME, name) returns "N-trig DuoSense device" WTInfoA(WTI_DEVICES, DVC_HARDWARE, &flags) just returns HWC_INTEGRATED which indicates it's integrated into a screen. However, it also indicates it cannot generate events when the cursor is entering and leaving the physical detection range. I hope this helps!
Hi Puck, The patch is coming along pretty well, and the information you supplied is definitely helpful. I plan to use the DVC_NAME string to make sure the workaround only applies to the Surface Pro 3. Thanks a lot! Michael
Git commit 8570f238078c4a14789edb64d3558f3253c27553 by Michael Abrahams. Committed on 30/07/2015 at 09:36. Pushed by abrahams into branch 'calligra/2.9'. Workaround for Surface Pro 3 Eraser This patch rewrites most of kis_tablet_support_win.cpp to support basic use of the eraser key on the Surface Pro 3. The keyissue is that the SP3 eraser button does not register being held until the stylus is touched to the screen. It generates a series of false stylus button presses. This patch attempts to handle those issues by watching for "inline" cursor changes. If a packet pops up with a different cursor ID, we will dispatch a release event and a tool switch signal. This breaks some layers of abstraction but it seems to work. Differential: https://phabricator.kde.org/D146 M +125 -54 krita/ui/input/wintab/kis_tablet_support_win.cpp M +6 -0 libs/flake/KoToolManager.cpp M +5 -0 libs/flake/KoToolManager.h http://commits.kde.org/calligra/8570f238078c4a14789edb64d3558f3253c27553