Wintab broken with multiple monitors (huion Kamvas 13) #84179

Closed
opened 2020-12-27 17:29:33 +01:00 by Diogo Valadares Reis dos Santos · 29 comments

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: AMD Radeon RX 5700 XT ATI Technologies Inc. 4.5.14736 Core Profile Context 20.11.1 27.20.12033.2007

Blender Version
Broken: 2.92.0 Alpha, branch: wintab-coalesced-logging

Whenever using multiple monitors, the cursor is with an offset from the pen

2020-12-21 18-41-42.mp4

a problem that can be seen in other softwares like gimp (https://youtu.be/OoPiBoD23dw)

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: AMD Radeon RX 5700 XT ATI Technologies Inc. 4.5.14736 Core Profile Context 20.11.1 27.20.12033.2007 **Blender Version** Broken: 2.92.0 Alpha, branch: wintab-coalesced-logging Whenever using multiple monitors, the cursor is with an offset from the pen [2020-12-21 18-41-42.mp4](https://archive.blender.org/developer/F9522845/2020-12-21_18-41-42.mp4) a problem that can be seen in other softwares like gimp (https://youtu.be/OoPiBoD23dw)

Added subscriber: @Diogo_Valadares

Added subscriber: @Diogo_Valadares

Added subscriber: @PrototypeNM1

Added subscriber: @PrototypeNM1
Nicholas Rishel self-assigned this 2020-12-27 19:51:49 +01:00

@Diogo_Valadares could you run this build, copy the system console here, and link the paste in a reply to this report?

@Diogo_Valadares could you run [this build](https:*blender.community/c/graphicall/Wlbbbc/), copy the system console [here](https:*developer.blender.org/paste/edit/form/default/), and link the paste in a reply to this report?

here it goes P1862

here it goes [P1862](https://archive.blender.org/developer/P1862.txt)
  • Do the monitors have different scaling?
  • Are the monitors mapped to anything except full screen in the tablet preferences program?

Given there's nothing obvious in the log and that GIMP seems to have the same problem, and Huion drivers are known to be spotty, I'm guessing this is a driver bug. If we can't find a solution you may have better luck with Windows Ink.

- Do the monitors have different scaling? - Are the monitors mapped to anything except full screen in the tablet preferences program? Given there's nothing obvious in the log and that GIMP seems to have the same problem, and Huion drivers are known to be spotty, I'm guessing this is a driver bug. If we can't find a solution you may have better luck with Windows Ink.

1- yes, and also, changing the scaling has no effect.

2- no, its only mapped to the display itself as seen below
image.png

I don't think its a driver issue since this problem isn't present in blender 2.91.

If it is not something easy to fix, at least when set to automatic mode I think it should use windows ink when a huion tablet is being used if possible.

1- yes, and also, changing the scaling has no effect. 2- no, its only mapped to the display itself as seen below ![image.png](https://archive.blender.org/developer/F9538810/image.png) I don't think its a driver issue since this problem isn't present in blender 2.91. If it is not something easy to fix, at least when set to automatic mode I think it should use windows ink when a huion tablet is being used if possible.

In #84179#1084735, @Diogo_Valadares wrote:
I don't think its a driver issue since this problem isn't present in blender 2.91.

The reason a driver issue would not be present in 2.91 but is now is because 2.92 is more dependent on Wintab reported information. This dependency is necessary to enable high frequency tablet input for Wintab.

That said, could you check if there's a similar problem in GIMP? Blender's use of Wintab now more closely resembles GTK, and their code is filled with hard earned lessons.

If it is not something easy to fix, at least when set to automatic mode I think it should use windows ink when a huion tablet is being used if possible.

IMO this should be the default. I'm assuming you tried Windows Ink and it worked for you?

> In #84179#1084735, @Diogo_Valadares wrote: > I don't think its a driver issue since this problem isn't present in blender 2.91. The reason a driver issue would not be present in 2.91 but is now is because 2.92 is more dependent on Wintab reported information. This dependency is necessary to enable high frequency tablet input for Wintab. That said, could you check if there's a similar problem in GIMP? Blender's use of Wintab now more closely resembles GTK, and their code is filled with hard earned lessons. > If it is not something easy to fix, at least when set to automatic mode I think it should use windows ink when a huion tablet is being used if possible. IMO this should be the default. I'm assuming you tried Windows Ink and it worked for you?

I'm assuming you tried Windows Ink and it worked for you?

yep it worked perfectly fine with windows ink.

That said, could you check if there's a similar problem in GIMP?

yes, it has the same issue

> I'm assuming you tried Windows Ink and it worked for you? yep it worked perfectly fine with windows ink. > That said, could you check if there's a similar problem in GIMP? yes, it has the same issue

Thank you for the follow up. I'll investigate defaulting to Windows Ink when available.

If you want to continue investigating check Krita too (make sure their tablet API is set to Wintab, requires restart); it uses Qt instead of GTK (GIMP). If they have the same problem this is almost certainly a driver issue that surfaced because Blender was updated to handle tablet input in a way similar to those applications.

Thank you for the follow up. I'll investigate defaulting to Windows Ink when available. If you want to continue investigating check Krita too (make sure their tablet API is set to Wintab, requires restart); it uses Qt instead of GTK (GIMP). If they have the same problem this is almost certainly a driver issue that surfaced because Blender was updated to handle tablet input in a way similar to those applications.

krita is working perfectly right out of the box. I even checked if it wasn't using windows ink and no, it was with wintab.

krita is working perfectly right out of the box. I even checked if it wasn't using windows ink and no, it was with wintab.

Thanks, I'll keep it in mind while reviewing their source code.

Thanks, I'll keep it in mind while reviewing their source code.

@Diogo_Valadares could you open Krita and screencap the advanced tablet settings window (Settings > Configure Krita > Tablet Settings > Advanced)?
image.png

@Diogo_Valadares could you open Krita and screencap the advanced tablet settings window (Settings > Configure Krita > Tablet Settings > Advanced)? ![image.png](https://archive.blender.org/developer/F9595948/image.png)

Changed status from 'Needs Triage' to: 'Needs User Info'

Changed status from 'Needs Triage' to: 'Needs User Info'

In addition to the above, another build, and paste link. I noticed some of the logging information last time wasn't quite correct.

In addition to the above, [another build](https:*blender.community/c/graphicall/Wlbbbc/), and [paste link](https:*developer.blender.org/paste/edit/form/default/). I noticed some of the logging information last time wasn't quite correct.

image.png
krita is like this ^^

and the paste link: P1912

I'll leave a note that for some reason I was not able to not reproduce the bug now, for some weird reason its not happening neither in the new build you made or the older one, I even checked if I was using wintab and if the bug was still happening in gimp, and yes, it was both in wintab and happening in gimp.
I'm not sure if I forgot something here or if windows just went crazy,

![image.png](https://archive.blender.org/developer/F9597797/image.png) krita is like this ^^ and the paste link: [P1912](https://archive.blender.org/developer/P1912.txt) I'll leave a note that for some reason I was not able to not reproduce the bug now, for some weird reason its not happening neither in the new build you made or the older one, I even checked if I was using wintab and if the bug was still happening in gimp, and yes, it was both in wintab and happening in gimp. I'm not sure if I forgot something here or if windows just went crazy,

The only difference I see is that in the earlier build Windows and Wintab reported the window coordinate range as...

left: -480, top: -85, width: 2400, height: 1165

... and the most recent build as...

left: -640, top: 0, width: 2560, height: 1080

So it looks like you moved the monitors around in some way. It looks like one of the monitors used to be a bit higher than the main monitor previously, but then I can't understand the change in width.

What tablet do you have and does it have an in-built screen? What's your monitor layout, could you screencap your display layout settings (see image below)?

image.png

The only difference I see is that in the earlier build Windows and Wintab reported the window coordinate range as... > left: -480, top: -85, width: 2400, height: 1165 ... and the most recent build as... > left: -640, top: 0, width: 2560, height: 1080 So it looks like you moved the monitors around in some way. It looks like one of the monitors used to be a bit higher than the main monitor previously, but then I can't understand the change in width. What tablet do you have and does it have an in-built screen? What's your monitor layout, could you screencap your display layout settings (see image below)? ![image.png](https://archive.blender.org/developer/F9597877/image.png)

What tablet do you have and does it have an in-built screen?

the huion kamvas 13 has a 1080x1920 screen built in.

so, the difference is that the second monitor resolution I was using was higher, windows is glitching on me and is not letting the second monitor work properly anymore, so I'm leaving it deactivated most of the time.
When I reactivated it to test the bug, I can only get 640x480(I was using 1280x800 before), its enough to get the bug in gimp, but for some reason blender isn't catching it anymore. I may test it later if I manage to change the monitor resolution to what it was before.

(red outline was roughly what I had before)
image.png

image.png

> What tablet do you have and does it have an in-built screen? the huion kamvas 13 has a 1080x1920 screen built in. so, the difference is that the second monitor resolution I was using was higher, windows is glitching on me and is not letting the second monitor work properly anymore, so I'm leaving it deactivated most of the time. When I reactivated it to test the bug, I can only get 640x480(I was using 1280x800 before), its enough to get the bug in gimp, but for some reason blender isn't catching it anymore. I may test it later if I manage to change the monitor resolution to what it was before. (red outline was roughly what I had before) ![image.png](https://archive.blender.org/developer/F9597881/image.png) ![image.png](https://archive.blender.org/developer/F9597884/image.png)

Changed status from 'Needs User Info' to: 'Archived'

Changed status from 'Needs User Info' to: 'Archived'

Thanks. I think given this context it's safe to say this is a driver issue, either in your monitor or in Huion's driver. Given your issues with the monitor I'd say it's a likely candidate, but some tablet drivers have been known to misbehave when displays change resolution.

Feel free to add additional information, but for now I'm going to assume the issue is outside of Blender.

Thanks. I think given this context it's safe to say this is a driver issue, either in your monitor or in Huion's driver. Given your issues with the monitor I'd say it's a likely candidate, but some tablet drivers have been known to misbehave when displays change resolution. Feel free to add additional information, but for now I'm going to assume the issue is outside of Blender.

well, weirdly the bug came back after I deactivated the second monitor(not unplugging it)

also I don't know if you also take care of the windows ink part, but if so I found a bug on it, while drawing in a part of an image, blender draw a straight line up:

2021-01-26 11-11-38.mp4

as you can see, Gimp is fine, blender now has the offset and windows ink is a bit broken

edit: after reactivating the second monitor, gimp is offseted again, blender wintab AND windows ink are working fine, so multiple monitors seems to break both apis

well, weirdly the bug came back after I deactivated the second monitor(not unplugging it) also I don't know if you also take care of the windows ink part, but if so I found a bug on it, while drawing in a part of an image, blender draw a straight line up: [2021-01-26 11-11-38.mp4](https://archive.blender.org/developer/F9598749/2021-01-26_11-11-38.mp4) as you can see, Gimp is fine, blender now has the offset and windows ink is a bit broken edit: after reactivating the second monitor, gimp is offseted again, blender wintab AND windows ink are working fine, so multiple monitors seems to break both apis

Could you run [this build ]], and [ https:*developer.blender.org/paste/edit/form/default/ | upload the log again? I realized some of the logging wasn't set up correctly since your last upload (not that I have high hopes given the other weird system behavior).

Could you run [this build ]], and [[ https:*developer.blender.org/paste/edit/form/default/ | upload the log](https:*blender.community/c/graphicall/Wlbbbc/) again? I realized some of the logging wasn't set up correctly since your last upload (not that I have high hopes given the other weird system behavior).

the position seems correct, but now wintab sometimes is glitching like windows ink, and sometimes its glitching in another way
P1948

image.png

also the pressure seems to get messed up sometimes or just not work at all.
and both wintab and windows ink aren't working at all at any dual/single monitor setup I select, Maybe they only update when blender Restart, so I'm not sure,

here's a video showing it.

2021-02-05 12-33-18.mp4

the position seems correct, but now wintab sometimes is glitching like windows ink, and sometimes its glitching in another way [P1948](https://archive.blender.org/developer/P1948.txt) ![image.png](https://archive.blender.org/developer/F9654457/image.png) also the pressure seems to get messed up sometimes or just not work at all. and both wintab and windows ink aren't working at all at any dual/single monitor setup I select, Maybe they only update when blender Restart, so I'm not sure, here's a video showing it. [2021-02-05 12-33-18.mp4](https://archive.blender.org/developer/F9654470/2021-02-05_12-33-18.mp4)

Changed status from 'Archived' to: 'Confirmed'

Changed status from 'Archived' to: 'Confirmed'

Going to reopen for now so that I remember to review it later. In the meantime you might check if Windows Ink is better behaved in the this build (note: Wintab is disabled but you may still have to change the Tablet API).

Going to reopen for now so that I remember to review it later. In the meantime you might check if Windows Ink is better behaved in the [this build](https://blender.community/c/graphicall/xrbbbc/) (note: Wintab is disabled but you may still have to change the Tablet API).

yep. windows ink works flawlessly in this build, even changing the monitor setup it still works fine

yep. windows ink works flawlessly in this build, even changing the monitor setup it still works fine

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'

This should be resolved by 2e81f2c01a, if the issue is still present after tonight's daily build please let me know and I'll reopen the issue. If the daily build is earlier than Feb 17, the above change has not yet taken effect.

This should be resolved by 2e81f2c01a, if the issue is still present after tonight's daily build please let me know and I'll reopen the issue. If the daily build is earlier than Feb 17, the above change has not yet taken effect.

so, there is still a problem in the sculpt, the first dot of a stroke has maximum pressure, both in wintab and windows ink, besides it, windows ink pressure doesn't work at all

2021-02-18 13-24-06.mp4

in the video you can also see the bug where the stroke glitches when reaching a certain part of the screen, tho it only happened because I changed from 2 display to one display while blender was open so I don't think this is one should be critical.

EDIT: I tried to switch to windows ink and restart blender and it worked well, then I switched to wintab(wihich also was working fine) and then back to windows ink and it with a weird laggy behavior where it only updates what you did when you finish making the stroke

EDIT2: I now tried to start blender with wintab first bug is back again.. so I'm guessing all the glitches I got have to do with switching the api from Wintab to windows ink or starting blender with Wintab.

so, there is still a problem in the sculpt, the first dot of a stroke has maximum pressure, both in wintab and windows ink, besides it, windows ink pressure doesn't work at all [2021-02-18 13-24-06.mp4](https://archive.blender.org/developer/F9815035/2021-02-18_13-24-06.mp4) in the video you can also see the bug where the stroke glitches when reaching a certain part of the screen, tho it only happened because I changed from 2 display to one display while blender was open so I don't think this is one should be critical. EDIT: I tried to switch to windows ink and restart blender and it worked well, then I switched to wintab(wihich also was working fine) and then back to windows ink and it with a weird laggy behavior where it only updates what you did when you finish making the stroke EDIT2: I now tried to start blender with wintab first bug is back again.. so I'm guessing all the glitches I got have to do with switching the api from Wintab to windows ink or starting blender with Wintab.

I think all the issues you mention are expected from reverting the changes to Wintab. Fixing Wintab when the displays change and switching between Wintab and WinInk without restarting Blender were all in one package with high frequency Wintab.

I think all the issues you mention are expected from reverting the changes to Wintab. Fixing Wintab when the displays change and switching between Wintab and WinInk without restarting Blender were all in one package with high frequency Wintab.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#84179
No description provided.