STEPS TO REPRODUCE Hold S Pen's eraser side button while selecting tools or drawing. OBSERVED RESULT Still drawing while eraser button is pressed. EXPECTED RESULT Always changes to eraser. SOFTWARE/OS VERSIONS Krita Version: 4.1.7 Qt Version (compiled): 5.9.3 Version (loaded): 5.9.3 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.17763 Pretty Productname: Windows 10 (10.0) ADDITIONAL INFORMATION Samsung's PenS2Helper is based on WinTab, and is similar to this bug report: https://bugs.kde.org/show_bug.cgi?id=341899 Besides, according to Samsung's PenS2Helper.inf inside the driver for Samsung Notebook 9 Pen, it affects the following devices: ``` HID\VEN_WCOM&DEV_0032&Col02 HID\VEN_WCOM&DEV_0033&Col02 HID\VEN_WCOM&DEV_006C&Col01 HID\VEN_WCOM&DEV_006D&Col01 HID\VEN_WCOM&DEV_006E&Col01 ```
Hi, Can I tempt you to create a tablet log? You can go to settings->configure Krita->tablet settings and open the tablet tester. There, draw a bit on the window that shows up. There should be debug output on the righthand part of the window. If you could make some strokes and try to enable the eraser sidebutton while doing so, and then copy-paste the output, we can see what kind of events Krita is receiving for the eraser side button if any at all.
OK the following are the logs: WHEN I PRESS THE SIDE BUTTON IN PROXYMITY: Pen tip brought near Stylus press X=158.93 Y=223.88 B=1 P=7.1% [Omitted] Stylus release X=182.11 Y=270.60 B=0 P=0.0% Pen tip taken away WHEN I PRESS THE SIDE BUTTON BEFORE MY NOTEBOOK DETECTS S PEN: Eraser brought near Stylus press X=171.24 Y=122.88 B=1 P=0.0% Stylus move X=171.82 Y=126.87 B=1 P=3.0% (DRAW) [Omitted] Stylus release X=188.53 Y=198.39 B=0 P=0.0% Eraser taken away To sum up, Krita could read the eraser event, but when I draw several lines and I pressed the side button, it doesn't get the eraser event.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
Could you please test with the latest nightly build? We've swapped out our own tablet support code for Qt's (heavily patched to make things work...) https://binary-factory.kde.org/job/Krita_Nightly_Windows_Build/
It is worse now, without pressure and eraser support... So shall we send a bug report to Qt? Tablet Tester Output: Mouse press X=39 Y=67 B=1 Mouse move X=19 Y=77 B=1
We're actually trying really hard to fix the tablet support issues inside Qt... I'll ping Dmitry, who is working on that.
Hi, Aster! Could you please clarify three questions: 1) You use WinTab protocol in Krita, right? (Preferences->Tablet->WinTab checkbox) 2) When you press the "eraser" button outside the proximity distance and then go into proximity, does Krita recognize the eraser correctly? 3) The problem happens only when you press eraser button while being in proximity area?
(In reply to Dmitry Kazakov from comment #7) > Hi, Aster! > > Could you please clarify three questions: > > 1) You use WinTab protocol in Krita, right? (Preferences->Tablet->WinTab > checkbox) > > 2) When you press the "eraser" button outside the proximity distance and > then go into proximity, does Krita recognize the eraser correctly? > > 3) The problem happens only when you press eraser button while being in > proximity area? Oh my bad, I didn't explain my problem explicitly enough. Yup I use WinTab in Krita. Samsung's S Pen is based on Wacom EMR, so the digitizer knows the pen is still there from a short distance from screen. Krita could get the eraser event when pressing the eraser button before S Pen is near enough for the screen to "know" its existance. But if I press the eraser button after detection (The pen cursor shows up), it works as stylus instead of a eraser as it should be.
Okay, got it, thanks! :) I'll make a testing patch and push it to the nightly builds. I will need your help with testing it tomorrow, since I don't have a device with such stylus switch.
Git commit 714c9aaed2fee3a28dac9f317c013a605ea00a17 by Dmitry Kazakov. Committed on 17/04/2019 at 17:30. Pushed by dkazakov into branch 'master'. Switch stylus pointer type when the tablet is in the tablet proximity Some convertible tablet devices have a special stylus button that converts the stylus into an eraser. Such button can be pressed right when the stylus is in tablet surface proximity, so we should check that not only during proximity event handling, but also while parsing normal wintab packets. A +61 -0 3rdparty/ext_qt/0027-Switch-stylus-pointer-type-when-the-tablet-is-in-the.patch M +1 -0 3rdparty/ext_qt/CMakeLists.txt https://commits.kde.org/krita/714c9aaed2fee3a28dac9f317c013a605ea00a17
Hi, Aster! Could you please test if this package fixes the problem for you? I have added a fix. https://yadi.sk/d/db3yUdmPLm8wAg
Marking as waitingforinfo
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
The reported wrote that his device got broken and he cannot test the build right now. We should remind about this bug in the end of May.
Sorry that I didn't reply to this bug submit for a month. Currently my laptop works but somehow I cannot configure Krita to use WinTab for Tablet input. Under Windows Ink it doesn't work too, and outputs of stylus tester is the same as before.
Have you checked with the 4.2.0 beta we released last week? See https://krita.org/en/item/krita-4-2-0-beta-released/
(In reply to Boudewijn Rempt from comment #17) > Have you checked with the 4.2.0 beta we released last week? See > https://krita.org/en/item/krita-4-2-0-beta-released/ Yup I have tried it, but still the same.
Git commit f0d23431d760a2bb7a3c9cc37fd61698a70ba429 by Dmitry Kazakov. Committed on 19/06/2019 at 11:29. Pushed by dkazakov into branch 'master'. Fix switching of pointer type by the stylus tip We should check if any button is pressed by the already mapped value, but not raw value of the buttons. Wintab will always report the button to be pressed, although it is unmapped by CSR_SYSBTNMAP Related: bug 408454 M +27 -25 3rdparty/ext_qt/0024-Fetch-stylus-button-remapping-from-WinTab-driver.patch M +9 -7 3rdparty/ext_qt/0026-Fetch-mapped-screen-size-from-the-Wintab-driver.patch M +28 -10 3rdparty/ext_qt/0027-Switch-stylus-pointer-type-when-the-tablet-is-in-the.patch M +6 -4 3rdparty/ext_qt/0028-Fix-updating-tablet-pressure-resolution-on-every-pro.patch https://invent.kde.org/kde/krita/commit/f0d23431d760a2bb7a3c9cc37fd61698a70ba429
Git commit a9870aa6e2c90ce2cc8cc1066f2dddc7719ae1cc by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 20/06/2019 at 10:33. Pushed by rempt into branch 'krita/4.2'. Fix switching of pointer type by the stylus tip We should check if any button is pressed by the already mapped value, but not raw value of the buttons. Wintab will always report the button to be pressed, although it is unmapped by CSR_SYSBTNMAP Related: bug 408454 M +27 -25 3rdparty/ext_qt/0024-Fetch-stylus-button-remapping-from-WinTab-driver.patch M +9 -7 3rdparty/ext_qt/0026-Fetch-mapped-screen-size-from-the-Wintab-driver.patch M +28 -10 3rdparty/ext_qt/0027-Switch-stylus-pointer-type-when-the-tablet-is-in-the.patch M +6 -4 3rdparty/ext_qt/0028-Fix-updating-tablet-pressure-resolution-on-every-pro.patch https://invent.kde.org/kde/krita/commit/a9870aa6e2c90ce2cc8cc1066f2dddc7719ae1cc