Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#5960 closed bug (fixed)

Wacom Intuos3 9x12 has wrong resolution

Reported by: bobrost Owned by: stippi
Priority: normal Milestone: R1
Component: Drivers/Mouse/USB Version: R1/alpha2
Keywords: wacom input Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

My Wacom PTZ-930 (device 0xB2?) has the wrong mapping size. Upper left of the tablet correctly maps the pen to the upper left of the screen, but lower-right of the tablet only goes to the center of the screen. There is no way for the pen tool to access any of the screen outside of the upper-left quadrant. This is consistent across all screen resolutions I tried, and it did not happen with a Wacom Graphire 2.

Possibly fixed by updating TabletDevice.cpp with
case 0xB2:
SetDevice(30480.0, 22860.0, DEVICE_INTUOS3);

Running official R1/Alpha 2 on Apple iMac hardware.

Attachments (2)

wacom.zip (14.2 KB ) - added by stippi 9 years ago.
GCC2 build of the Wacom driver with the fix included.
wacom2.zip (14.3 KB ) - added by idefix 9 years ago.
GCC2 build of the Wacom driver with RDY-bit checking disabled.

Download all attachments as: .zip

Change History (18)

comment:1 by anevilyak, 9 years ago

Owner: changed from mmlr to stippi
Status: newassigned

Reassigning to stippi since he wrote the Wacom driver.

comment:2 by korli, 9 years ago

The listusb output would be helpful to identify the device. Thanks!

comment:3 by bobrost, 9 years ago

From listusb:

056a:00b2 /dev/bus/usb/1/0 "Tablet" "PTZ-930" ver. 0102

I just checked the OSX Wacom preference panel. It shows the device coordinate size as 60960x45720, which matches the Haiku driver source. While my suggested fix (halving the device coordinate range) may end up working, it appears that might just be a hack around a different problem.

comment:4 by idefix, 9 years ago

The Linux driver also uses 60960 and 45720 so these values are the correct ones.

But device 0xB1 has got the same hack as you proposed, so I think it wouldn't hurt to apply it for 0xB2 also. Did you test your hack?

comment:5 by bobrost, 9 years ago

I have not tested the hack, since I do not currently have a build environment set up.

Based on the numbers and my assumptions about the products, it appears that device 0xB0 still has the full range (incorrect for Haiku) and will display the same behavior as 0xB2. I am guessing that the application of this hack would need to be consistent for all Intuos 3 tablets (devices 0xB0, 0xB1, and 0xB2). Alternately, perhaps DEVICE_INTUOS3 should double the position around line 300 of that file? If this same issue shows up for Intuos 4 or Bamboo tablets, it might make sense to instead have a position scale factor (1.0 for most tablets, 2.0 for Intuos 3, etc.).

comment:6 by idefix, 9 years ago

Well, it look likes the Linux driver uses a different method for the Intuos3 and Cintiq to calculate the absolute coordinates:

input_report_abs(input, ABS_X, (data[2] << 9) | (data[3] << 1) | ((data[9] >> 1) & 1));
input_report_abs(input, ABS_Y, (data[4] << 9) | (data[5] << 1) | (data[9] & 1));

While Haiku uses:

xPos = data[2] << 8 | data[3];
yPos = data[4] << 8 | data[5];

Which would explain the halving of the position in Haiku.

comment:7 by stippi, 9 years ago

I just went to post a comment with the same suspicion. So we are missing one bit of precision on these devices. Makes for a good explanation. :-)

comment:8 by stippi, 9 years ago

Resolution: fixed
Status: assignedclosed

I've commited the probable fix in hrev36791. Thanks idefix! bobrost, please confirm if the problem is fixed, otherwise just reopen the ticket if not, I have no way to test this.

comment:9 by idefix, 9 years ago

Dang! I was just about to post (almost) the same patch. ;)

comment:10 by idefix, 9 years ago

Oh, I see a bug in your patch: Cintiq also needs the different calculation method.

My patch used:

                if (fDeviceMode == DEVICE_INTUOS) {
                    xPos = data[2] << 8 | data[3];
                    yPos = data[4] << 8 | data[5];
                } else {
                    xPos = data[2] << 9 | data[3] << 1 | data[9] >> 1 & 1;
                    yPos = data[4] << 9 | data[5] << 1 | data[9] & 1;
                }

comment:11 by stippi, 9 years ago

Cintique was around before Intuos3. So either there are different Cintique models, and we should differentiate between those, or it was indeed wrong in the first place. Can you find that out from the Linux driver? Or confirm either way if you already did? Thanks!

in reply to:  8 comment:12 by bobrost, 9 years ago

Replying to stippi:

I've commited the probable fix in hrev36791. Thanks idefix! bobrost, please confirm if the problem is fixed, otherwise just reopen the ticket if not, I have no way to test this.

If you can provide a binary of the driver, then I can test it today or tomorrow morning. Otherwise, I will be available to test it again in about two weeks, and will try one of the nightly releases then.

in reply to:  11 comment:13 by idefix, 9 years ago

Replying to stippi:

Cintique was around before Intuos3. So either there are different Cintique models, and we should differentiate between those, or it was indeed wrong in the first place. Can you find that out from the Linux driver? Or confirm either way if you already did? Thanks!

The Linux driver uses the following if-statement:

if (features->type >= INTUOS3S) {
    input_report_abs(input, ABS_X, (data[2] << 9) | (data[3] << 1) | ((data[9] >> 1) & 1));
    input_report_abs(input, ABS_Y, (data[4] << 9) | (data[5] << 1) | (data[9] & 1));

And CINTIQ is greater than INTUOS3S:

enum {
    PENPARTNER = 0,
    GRAPHIRE,
    WACOM_G4,
    PTU,
    PL,
    BAMBOO_PT,
    INTUOS,
    INTUOS3S,
    INTUOS3,
    INTUOS3L,
    INTUOS4S,
    INTUOS4,
    INTUOS4L,
    CINTIQ,
    WACOM_BEE,
    WACOM_MO,
    TABLETPC,
    TABLETPC2FG,
    MAX_TYPE
};

So I came to the conclusion that Cintiq also needs the different calculation method.

by stippi, 9 years ago

Attachment: wacom.zip added

GCC2 build of the Wacom driver with the fix included.

comment:14 by stippi, 9 years ago

bobrost, I've attached a pre-built binary. Hopefully it was still in time. :-) Otherwise no worries.

comment:15 by bobrost, 9 years ago

Confirmed that PTZ-930 now has correct bounds with the updated driver. Also confirmed that drivers take effect almost immediately when you put them in the add-ons folder. Wow!

There is a usability issue at the edges of the screen. The OSX (and presumably Windows) driver provides about a half inch of buffer zone outside of the primary sensing area, but Haiku simply stops the cursor, instead of following the pen along the outer edge. Slate that for its own lower priority enhancement request ticket?

in reply to:  15 comment:16 by idefix, 9 years ago

Replying to bobrost:

There is a usability issue at the edges of the screen. The OSX (and presumably Windows) driver provides about a half inch of buffer zone outside of the primary sensing area, but Haiku simply stops the cursor, instead of following the pen along the outer edge. Slate that for its own lower priority enhancement request ticket?

No, that is a bug. But I think I know what's causing it. (It always checks the RDY-bit that Cintiq tablets set.)

Could you test if it is fixed with the attached driver?

by idefix, 9 years ago

Attachment: wacom2.zip added

GCC2 build of the Wacom driver with RDY-bit checking disabled.

Note: See TracTickets for help on using tickets.