I'm having an issue where the full size of my tablet isn't being utilized; I'm only able to draw on about 60% of it in 'show canvas only' mode, and when in normal view, the cursor and brush are out of alignment. If I use the 'brush outline' cursor, then the alignment is fine, though not with the selector cursor (for selecting tools and colors and such); that is actually using the full size of the tablet.

Here, let me see if an example of what I'm talking about will help. If I am drawing on the canvas in normal view (with all the toolbars and dockers and whatnot), with a canvas size of 1920X1080, I can use about 4.5" (w) X 5.5" (h) out of the 10" X 6" active area this thing has. BUT, if I want to use the stylus to select anything off the toolbars, on the left side of the screen, the pointer/selector cursor will show up before the brush outline cursor goes off the side of the canvas. And on the right side, there's a huge dead zone on the table where the brush outline cursor is off the page, but the pointer cursor is still invisible, somewhere in the middle of the thing. Eventually, when my stylus gets all the way over towards the right side of the tablet, the pointer shows up, and I can select things. A similar, but smaller, effect is present on the top and bottom margins. This doesn't seem to change with the size of the canvas, nor the zoom. And lastly, when in 'view canvas only' mode, it's still only using about 60% of the tablet's real estate.

The specs of the system are as follows:

*Ugee M708 tablet
* Asus m5a97r2.0 mobo
* Nvidia geforce gtx 650 ti
* AMD FX6300 cpu
* Acer x213h monitor, 1920X1080
* Windows 7 ult, 64 bit
* Krita v 2.5.3

Thanks for any help. I searched before posting this and couldn't find anything, but that doesn't mean it's not already been asked and answered. If so, just point me in that direction. And, if you need any clarification, I'll do what I can to explain what's happening.

Edit: Added to specs list.

Hm... well, for one, we're on krita 2.8.6 now, 2.5.3 was quite a while(several years) ago?

The Ugee is not supported offcially. We had someone else report that the pressure curve is strange, but until we can get a tablet log, or the device itself, there's no way we can figure out why it doesn't work correctly.

Either way, 2.8.6 will probably solve the offset issue, but I am not sure if the pressure will work properly.

TheraHedwig wrote:Hm... well, for one, we're on krita 2.8.6 now, 2.5.3 was quite a while(several years) ago?

The Ugee is not supported offcially. We had someone else report that the pressure curve is strange, but until we can get a tablet log, or the device itself, there's no way we can figure out why it doesn't work correctly.

Either way, 2.8.6 will probably solve the offset issue, but I am not sure if the pressure will work properly.

Whoops. My bad. 2.8.3 is the version I have. I'll look into getting it updated, and post any changes here.

..................................................................

OK. According to krita.org, the latest version in 64 bit is 2.8.3, which I have.

Also, the pressure sensitivity hasn't been an issue.

You can get the latest 2.9 betas at files.kde.org/krita/windows -- the second beta will be announced tomorrow.

boudewijn wrote:You can get the latest 2.9 betas at files.kde.org/krita/windows -- the second beta will be announced tomorrow.

Is that likely to fix my problem? I feel like there's a setting somewhere that I have wrong, or something like that.

The 'mouse pointer' cursor utilizes the entire tablet, but the area allocated to working on the canvas is about half of what it should be, shoved over towards the buttons - left as I use it.

But, if I select a different brush, and as soon as I cross over to the canvas (which, when coming from the right, it's a smooth transition with no gaps) I start a line, I can use the entire area I should be able to use. So long as I don't lift the stylus. If I do, then the cursor will jump to the right a significant amount, and I will be again stuck in my little portrait-oriented 4X5 area.

The tablet doesn't do this in any other programs that I've tried, including browsing both the file system of my computer and the internet, lightroom 5.3, and a few others. I have not tried it in any other art program than Krita and MSPaint.

Update:

It would seem that this has something to do with the fact that I'm running two monitors. When I re-installed the tablet's driver, I forgot to go in and change it to main monitor only, so it was going across both. I decided to try Krita set up like that, and all of a sudden, there was no problem! No gaps between brush and pointer, nor between any canvas boundaries and the toolbars/menus.

Of course, the active size for use on the canvas was still tiny, compared to the whole tablet. So, I changed it back to main monitor only, and the problem reappeared.

Anything special I should know about Krita's multi-monitor support?

No... Basically, multi-monitor setups are really tricky, no matter what. I've had different problems with Wacom, Yiynova and Huion tablets. They all provide their own wintab driver software, and most of it is completely broken. The only 'spec' is to be found on Wacom's website, and it only really works for Wacom. And don't get me started on what Windows' desktop scaling does to wintab drivers... Or that special n-trig driver which reports 256 levels of pressure, but in the actual tablet events reports a 0..1024 range of values.

Right now, I'd say that with their current drivers, Yiynova and Wacom tablets work best, then Huion, then n-trig -- the rest, ugee, uc-logic, genius, that brand that start with a 'b' but where I've forgotten the name, we don't have the hardware to test, and, honestly, with one full-time developer on Krita, not the time to support all hardware and drivers out in the world.

boudewijn wrote:No... Basically, multi-monitor setups are really tricky, no matter what. I've had different problems with Wacom, Yiynova and Huion tablets. They all provide their own wintab driver software, and most of it is completely broken. The only 'spec' is to be found on Wacom's website, and it only really works for Wacom. And don't get me started on what Windows' desktop scaling does to wintab drivers... Or that special n-trig driver which reports 256 levels of pressure, but in the actual tablet events reports a 0..1024 range of values.

Right now, I'd say that with their current drivers, Yiynova and Wacom tablets work best, then Huion, then n-trig -- the rest, ugee, uc-logic, genius, that brand that start with a 'b' but where I've forgotten the name, we don't have the hardware to test, and, honestly, with one full-time developer on Krita, not the time to support all hardware and drivers out in the world.

Oh well, I figured it was as much.

Thank you for the answer, and I totally understand your point about not being able to predict all the problems that all the different cheap tablet manufacturers' sub-par drivers will have, much less develop workarounds/support for them.

That said, I spent a lot of time yesterday playing around with a lot of different digital art programs, and I understand why Krita is so popular, especially for a free program. I won't be using anything else.

And, I did find a workaround. It's not the most elegant solution, but it works. I use DisplayFusion for managing both the monitors, and if I go into the settings and deactivate the 2nd monitor, everything's hunky-dory. So, until something else comes along, that's what I'll do.

Thanks, again, for all the work you put in, not just developing this wonderful program, but getting down here to help me (and many others) out.

Btw, I saw the same problem with Intuos5 yesterday on Windows 8 if connected to an external monitor.

QDesktopWidget returns correct value, but Wintab not. I'm going to add a manual switch soon, so that the user could workaround such problems in drivers