The drawing tablet is the following:

https://www.banggood.com/VSON-WP9620N-New-Passive-Electromagnetic-Technology-Design-Drawing-Graphic-Tablet-with-Battery-free-Stylus-8192Levels-5080LPI-230PPS-p-1824456.html?cur_warehouse=CN&ID=229

And playing with the following command seems to have absolutely no effect:

xinput set-prop 12 --type=float "Coordinate Transformation Matrix" 2 0 0 0 1 0 0 0 0

Thank you for your bug report, the problem is the devices HID descriptors:

    Logical maximum (32767)

Which should correspond to the value the tablet sends when the styles is at the right edge, but you report that this is the value in the middle, likely making the value at the end 65535.

So it seems that the HID descriptors of the device are broken and we need to patch them up.

Can you run:

ls -l /sys/bus/hid/devices/*/driver

And copy and paste the output here.

Also please as root run:

ls /sys/kernel/debug/hid/

And then for the entry matching the tablet do:

cat /sys/kernel/debug/hid/<device>/rdesc > rdesc

And attach the generated rdesc file here.

Thanks, Hans. Below, you can find what you had asked for:

# ls -l /sys/bus/hid/devices/*/driver
lrwxrwxrwx. 1 root root 0 Sep 20 10:31 /sys/bus/hid/devices/0003:03F0:2A41.0002/driver -> ../../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx. 1 root root 0 Sep 20 10:31 /sys/bus/hid/devices/0003:04CA:707A.0003/driver -> ../../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx. 1 root root 0 Sep 20 10:31 /sys/bus/hid/devices/0003:413C:2107.0001/driver -> ../../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx. 1 root root 0 Sep 20 11:42 /sys/bus/hid/devices/0003:6161:4D15.0008/driver -> ../../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx. 1 root root 0 Sep 20 11:42 /sys/bus/hid/devices/0003:6161:4D15.0009/driver -> ../../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx. 1 root root 0 Sep 20 11:42 /sys/bus/hid/devices/0003:6161:4D15.000A/driver -> ../../../../../../../../bus/hid/drivers/hid-generic
lrwxrwxrwx. 1 root root 0 Sep 20 11:42 /sys/bus/hid/devices/0003:6161:4D15.000B/driver -> ../../../../../../../../bus/hid/drivers/hid-generic
#


# ls /sys/kernel/debug/hid/
0003:03F0:2A41.0002  0003:6161:4D15.0008  0003:6161:4D15.000B
0003:04CA:707A.0003  0003:6161:4D15.0009
0003:413C:2107.0001  0003:6161:4D15.000A
#

Created attachment 1824582 [details]
The requested rdesc file

Thanks, what is the USB vendor-id:product-id of your tablet ?

I will try to prepare a kernel patch to work around this, but it may be a while before I can make some time for this. I have my Mondays reserved to work on "small" hw-enablement issues like this one, but my list which such issues contains a couple other issues to, so it may be a couple of Mondays until I get around to this...

If I provide a patch, can you build your own kernel to test this then ?

Thanks, Hans.

The vendor-id:product-id of my tablet are: 

VSON WP9620N 

Please, consult

https://www.banggood.com/VSON-WP9620N-New-Passive-Electromagnetic-Technology-Design-Drawing-Graphic-Tablet-with-Battery-free-Stylus-8192Levels-5080LPI-230PPS-p-1824456.html?cur_warehouse=CN&ID=229

for more details.

Yes, I can to test the patch, as long as you give me the directions about how to do that, as I have never built a kernel!

Meanwhile, while waiting for your pacth, is there any workaround to make usable the whole active area of my tablet?

I meant the 16 bit hexadecimal product:vendor id as shown in e.g. lsusb, so one of:

03F0:2A41
04CA:707A
413C:2107
6161:4D15

Which of those is from your tablet ?

> Yes, I can to test the patch, as long as you give me the directions about how to do that, as I have never built a kernel!

In that case it is probably easier if I just prepare a test kernel rpm for you.

> Meanwhile, while waiting for your pacth, is there any workaround to make usable the whole active area of my tablet?

No I'm afraid not.

Thanks, Hans.

> I meant the 16 bit hexadecimal product:vendor id as shown in e.g. lsusb, so one of:
> 
> 03F0:2A41
> 04CA:707A
> 413C:2107
> 6161:4D15
> 
> Which of those is from your tablet ?

I guess is the last one, as, to obtain the rdesc file, I used the following command:

cat /sys/kernel/debug/hid/0003:6161:4D15.0009/rdesc > rdesc.txt


> In that case it is probably easier if I just prepare a test kernel rpm for you.
That would be perfect, Hans!

>> Meanwhile, while waiting for your pacth, is there any workaround to make usable the whole active area of my tablet?
> 
> No I'm afraid not.

No problem, I will wait.

Hi,

I was discussing this with a colleague, especially about how to avoid the following:

1. Me writing a kernel patch which turns out to not be entirely correct
2. Me providing you with a test kernel
3. Wait for you to get around to testing.
4. You testing, providing feedback patch version does not help / does not fully solve the issue.
5. Waiting for me to find/make time to work on this again goto 1.

Which sometimes can be a pretty drawn-out process because of 3. and 5.

There is a tool which allows recording of traffic at the HID level and then I can replay that on my machine and I should then instantly see the problem (and I can even test a kernel fix for it this way).

Please install hid-replay by running:

sudo dnf install hid-replay

And then use hid-recorder to make 2 recordings of the tablet:

1. One recording where the pen starts at the center of the left edge of the tablet and then is moved all the way to the right edge of the tablet in a straight line.

2. Another recording where the pen starts at the center of the top edge of the tablet and then is moved all the way to the bottom edge in a straight line.

If you can make these 2 recordings and attach them here, then that would be great. Once I've those I'll try to work on this soon.

Thanks, Hans. The recordings are attached.

Created attachment 1828612 [details]
Horizontal stylus movement

Created attachment 1828613 [details]
Vertical stylus movement

Thanks.

So I've been looking into this and I'm afraid that your tablet simply is broken ?   (does it work in say Windows?).

If you look at an event line in horizontal.txt :

E: 0.095808 8 0a c0 00 00 e8 38 00 00

Then the "00 00" between the "c0" and "e8" here are the x coordinates of the pen, which in the beginning is 0, so far so good.

Now lets just sample a couple of further lines, I have added ** around the 2 bytes we care about:

E: 0.101951 8 0a c0 ** 08 00 ** ec 38 00 00
E: 0.108202 8 0a c0 ** 1a 00 ** ef 38 00 00
E: 0.115989 8 0a c0 ** 37 00 ** f0 38 00 00
E: 0.121956 8 0a c0 ** 5e 00 ** f1 38 00 00
E: 0.127810 8 0a c0 ** 8e 00 ** f2 38 00 00
E: 0.135956 8 0a c0 ** c8 00 ** f3 38 00 00
E: 0.141815 8 0a c0 ** 0c 01 ** f4 38 00 00
...
E: 0.169957 8 0a c0 ** 79 02 ** f4 38 00 00
...
E: 0.337978 8 0a c0 ** 80 10 ** d0 38 00 00


So here we first see the first byte going from 00 - ff, and then te second byte goes from 0 -> 1 with the first byte going from ff -> 0 (not literary ff and 0, but close to ff / 255 and then close to 0. So everything here is working as expected the first byte are the low 8 bits of the x coordinate and the second byte are the high 8 bits of the 16 bit coordinate.

But now look at these:

E: 1.809984 8 0a c0 ** ff 7f ** 99 36 00 00
E: 1.815985 8 0a c0 ** ff 7f ** 99 36 00 00
E: 1.821981 8 0a c0 ** ff 7f ** 99 36 00 00
E: 1.829983 8 0a c0 ** ff 7f ** 99 36 00 00
E: 1.835981 8 0a c0 ** ff 7f ** 85 36 00 00
E: 1.841987 8 0a c0 ** ff 7f ** 85 36 00 00
E: 1.849985 8 0a c0 ** ff 7f ** 85 36 00 00
E: 1.855983 8 0a c0 ** ff 7f ** 85 36 00 00
...
E: 4.952334 8 0a c0 ** ff 7f ** 0d 32 00 00
E: 4.960322 8 0a c0 ** ff 7f ** 14 32 00 00
E: 4.966341 8 0a c0 ** ff 7f ** 1b 32 00 00
E: 5.708461 8 0a c0 ** ff 7f ** 1b 32 00 00

So after 1.8 seconds into the recording we hit a maximum X coordinate value of 32767, matching your earlier evtest recording and I assume this is again halfway through the tablet since the recording goes on for 4 more seconds.

32767 matches the advertised maximum value for the X axis, so this is not a descriptor issue as I thought earlier, but the tablet is actually sending 32767 as X coordinate for the entire right half of the tablet.

The Y axis in vertical.txt looks good, but notice that the X axis there is always 0x7fff / 32767 so if you did that recording moving the pen from top to bottom aprox. halfway through the tablet, that again indicates the X axis is simply broken somehow.

The best thing to do next would be to test this under say Windows and then we can see from there.

Thanks, Hans. It is hard to believe that the tablet is broken, as it is brand new.

I do not currently have access to a MS Windows machine, but I do have a MS Windows machine running as a virtual machine (VirtualBox). I could test the tablet on this virtual machine, but I suspect it will not be reliable, since behind the scene it is Linux. What do you think?

If you attach the tablet to the VM with USB pass-through then Linux does not really touch it anymore, so testing with a VM should be fine.

Thanks, Hans. I have been able to attach the tablet to the VM with USB pass-through. However, the mouse cursor does not simply move as I slide the stylus on the tablet. Maybe I am missing somethings in the VirtualBox configuration.

It is working now (it was necessary to add mouse trails inside MS Windows).

In MS Windows, the stylus and tablet work very well: It is when the stylus reaches the right edge of the tablet that the cursor reaches the monitor right edge -- and not when the stylus reaches the horizontal middle of the tablet. Therefore, the table is not broken!

Ok, interesting, so Windows like is changing some settings inside the tablet which make it work. I guess we need to make a capture of the USB traffic under Windows to figure out what is going on here.

Please install USBPcap inside the Windows VM:

https://desowin.org/usbpcap/

And then follow the instructions from here to make an USB capture:
https://desowin.org/usbpcap/tour.html

Please start the recording before redirecting the tablet to the VM, then move the pen from the left edge to the right edge and then stop the capture. After that attach the created .pcap file here, thanks.

Also please attach the rdesc files from all 0003:6161:4D15.* directories under /sys/kernel/debug/hid/  (when not redirected to the Windows VM).

Created attachment 1829072 [details]
Files with the requested tests.

Thanks, Hans. Please, see the attached ZIP file, which contains the files you asked for.

Thanks, that was fast :)   It looks like the device was already redirected to the VM when you started the USBPCAP capture inside the vm though. Can you try again, this time redirecting the device to the VM after you've started the capture?

Created attachment 1829116 [details]
The new .pcap file

Thanks! Done, Hans!

Ok, this is weird. Can you do:

sudo lsusb -v -d 6161:4d15 > lsusb.log

And attach lsusb.log here, as well as the output of the dmesg command ?

Ok, I just found another bug-report about this:
https://github.com/DIGImend/digimend-kernel-drivers/issues/528

Apparently the tablet has some sort of OS detection going on and works differently dependent on the OS it iis talking too.

I wonder if just having it redirected to Windows and then unredirecting it is enough to get it going?

Otherwise according to the bug I found, this helps:

"My problem of half screen got solved by simultaneously pressing buttons which are adjacent to the middle one for approximately 6 seconds till green light turned red. After that, it did not go again in Android mode even after disconnecting and reconnecting or restarting the computer, not even after pressing those 2 buttons again."

Thanks, Hans, but no progress:

> Ok, I just found another bug-report about this: 
> https://github.com/DIGImend/digimend-kernel-drivers/issues/528
> 
> Apparently the tablet has some sort of OS detection going on and
> works differently dependent on the OS it iis talking too.
> 
> I wonder if just having it redirected to Windows and then
> unredirecting it is enough to get it going?

Tried that, but no success.

> Otherwise according to the bug I found, this helps:
> 
> "My problem of half screen got solved by simultaneously pressing
> buttons which are adjacent to the middle one for approximately 6
> seconds till green light turned red. After that, it did not go again
> in Android mode even after disconnecting and reconnecting or
> restarting the computer, not even after pressing those 2 buttons
> again."

Doing as suggested, the green light never turns red -- and the half tablet problem persists. I do not know whether is just a mistake (of the original author), but your quotation mentions "half screen", while the problem is "half tablet"!

Ok, so after looking at the second USB capture under Windows I've written down the following notes for myself:

Interface 0 EP 0x81 bootclass mouse, rdesc len 18, report id 0x08, Application(ff00.0001)
Interface 1 EP 0x82 bootclass mouse, rdesc len 83, report id 0x0a, Tablet
Interface 2 EP 0x83 bootclass keybd, rdesc len 64, report id none, Std Kbd
Interface 3 EP 0x84 bootclass mouse, rdesc len 75, report id 0x01, Std Mouse

Linux uses Interface 1, EP 0x82, report id 0x0a, there the X axis is wrong and reaches its max coordinates halfway through the tablet.

Windows uses Interface 0, EP 0x81, report id 0x08. Also Windows never requests the HID descriptors for Interface 0
(which are meaningless) instead it seems to use a special driver for Interface 0 which simply knows how to interpret the EP 0x81, report id 0x08 reports.

So my conclusion is that Windows is using a special driver which uses custom HID reports on interface 0, rather then the standard tablet HID reports on interface 1 which Linux uses.

This has made me curious enough to spend 30 EUR on this and order one of these tablets from banggood myself. It will be approx. 3 weeks when my tablet arrives. I will look further into this once I have my own tablet.

Thanks, Hans. Let me add something that may be relevant: The maker of the tablet supplies a MS Windows device driver, which I have installed and is available at:

http://download.myvsoncloud.com/

All tests that I did on MS Windows were done with that device driver on.

And since the tablet is announced to work on Android and the maker does not supply a device driver for Android (there is only device drivers for MS Windows and Mac), I guess that the tablet is, by default, configured to work with no more ado on Android -- this is maybe the cause of the issue.

So I just got my own WP9620N tablet.

I've been playing around with it a bit and looking a the pictures in the Chinese manual.

The pictures are helpful. You can set an aspect ratio for the device you want to use it with and depend on the aspect ratio only a part of the tablet is used in the Android interface.

And it defaults to a portrait aspect-ratio of 9:16, if you still have the little leaflet with came with it it has a picture showing how only the left side of the tablet is used in this case.

To program a 16:9 aspect ratio do the following:

1. Orient the tablet with the USB-connector and the buttons on the left side of the tablet (which is its normal orientation AFAICT).
2. Press the buttons which are closest to the bottom together and keep them pressed. The status LED will now turn off and after approx. 3 seconds turn on again.
3. Release the buttons.

Now you can use the entire width of the tablet, but you are missing an edge at the top and bottom of the active area. To make the missing edge smaller set the tablet to a 16:10 aspect ratio:

1. Orient the tablet with the USB-connector and the buttons on the left side of the tablet (which is its normal orientation AFAICT).
2. Press the buttons which are closest to the bottom together and keep them pressed. The status LED will now turn off and after approx. 3 seconds turn on again.
3. Keep the buttons pressed, the LED will turn off again and after again approx. 3 seconds (so approx 7 seconds in total) it will turn on a second time.
4. Release the buttons.

Note you will now still miss a small part of the active area at the top and bottom. Fixing this, as well as fixing the buttons on the tablet and the stylus buttons will require writing a driver to use the custom Windows protocol.

I'm a bit busy atm, so I'm not sure when I will get around to writing a driver to use the custom Windows protocol, but just fixing the aspect ratio should make the tablet a lot more usable for you.

I just realized my instructions are not entirely clear. "Press the buttons which are closest to the bottom" should be "Press the 2 buttons which are closest to the bottom".

Thank very much indeed, Hans. By following your instructions, the situation improved a lot! I will wait for your drive. Thanks again!

The driver that you will write will offer the possibility of configuring the tablet buttons to run user-written scripts when pressed, Hans?

Good news I've finished writing the kernel driver for this and submitted it upstream:
https://lore.kernel.org/linux-input/20211212212333.239644-1-hdegoede@redhat.com/

I still need to add a tablet profile to libwacom for this tablet, but the GNOME UI to assign actions to the 5 buttons on the pad of the tablet does not work, which seems to be a GNOME bug:
https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1321

Once I can test that my libwacom profile is correct I will also submit that upstream.

That is really great news, Hans! Thank you very much indeed!

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07.

Fedora Linux 34 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release.

Thank you for reporting this bug and we are sorry it could not be fixed.