A50 not working at all after installing the driver

[KibaGasteiz]

I tried with the 1.0 from the AUR and compiling 2.0 myself, but the thing doesn't work. What info should i give as feedback?

lsusb gives me this: Bus 001 Device 002: ID 2feb:0003 VEIKK.INC A50

Is the GUI tool needed or something?

Off-Topic: @artixnous Are you planning an update on your AUR version? That would be great :')

[jlam55555]

@KibaGasteiz I just posted an update to your other issue just a minute ago. Please check that out. Are you using the old configuration tool?

Also, I was playing around with dkms earlier today and realized I had a fundamental misunderstanding. The package on dkms is up-to-date (it upstreams from this repo).

Maybe a silly question, but did you insert the module with sudo modprobe veikk? dkms doesn't do that for you automatically. (Let me know if lsmod|grep veikk shows anything.)

[KibaGasteiz]

Didn't inserted it, but now i did and still nothing. [arch@arch-pc ~]$ lsmod|grep veikk [arch@arch-pc ~]$ sudo modprobe veikk [arch@arch-pc ~]$ lsmod|grep veikk veikk 16384 0 hid 143360 5 usbhid,hid_generic,hid_logitech_dj,hid_logitech_hidpp,veikk The first time lsmod|grep veikk gave me nothing, very strange. But when i used the second command that's what it says.

[jlam55555]

It's expected that it shows up after the modprobe command, based on my earlier comment. So now it's loaded. That's good. Have you tried unplugging and replugging in your A50 after loading the module? Seems to be an issue right now for some reason.

[KibaGasteiz]

Yes, tried that but is not working, also restarted and nothing.

[jlam55555]

Do you have any errors in dmesg? And do you see it being probed in the dmesg log?

On Sat, Jan 18, 2020 at 9:22 PM KibaGasteiz notifications@github.com wrote:

Yes, tried that but is not working, also restarted and nothing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jlam55555/veikk-linux-driver/issues/17?email_source=notifications&email_token=ACDPJJY6VWRIGFB3UONN323Q6O2NBA5CNFSM4KIWM3DKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJKG66Y#issuecomment-575958907, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDPJJ3KMW7QI6D6ULRTGCTQ6O2NBANCNFSM4KIWM3DA .

[KibaGasteiz]

It seems like isn't the case, but here you got the full log: https://gist.github.com/KibaGasteiz/b2d62eceb3e1718d6bb8dd650684b03a

[jlam55555]

So the device is being probed successfully and registered with the input subsystem, that's good. I don't have a good prediction for what the problem may be. What do you mean the driver is not working? Is the cursor not moving at all?

Maybe you can see if Xorg is registering any events? E.g., use one (or both) of the following:

xinput    # find VEIKK device id
xinput test [device id]

or

sudo evtest
# [choose device id when prompted]

You should be able to see x, y, pressure, and buttons events.

Also, just to cover more bases: did you just download the newest version just now? As of these past few days, there have been many major updates. The driver should have been operational since the 2.0 update, but some things may have updated since then. I'm pretty sure the current version should work fairly well, but I can't say that about the past few.

[KibaGasteiz]

Yes, the cursor isn't moving, the LED light in the tablet flashes like it is working well when i put the pen on it just like on Windows, but nothing happens on screen. xinput gives me this list:

⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Logitech G502 HERO Gaming Mouse id=9 [slave pointer (2)] ⎜ ↳ Logitech G502 HERO Gaming Mouse Consumer Control id=11 [slave pointer (2)] ⎜ ↳ Logitech K400 Plus id=13 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Power Button id=7 [slave keyboard (3)] ↳ Sleep Button id=8 [slave keyboard (3)] ↳ Logitech G502 HERO Gaming Mouse Keyboard id=10 [slave keyboard (3)] ↳ Logitech G502 HERO Gaming Mouse System Control id=12 [slave keyboard (3)] ↳ Logitech Gaming Keyboard G105 id=14 [slave keyboard (3)] ↳ Logitech Gaming Keyboard G105 Consumer Control id=15 [slave keyboard (3)] ↳ Eee PC WMI hotkeys id=16 [slave keyboard (3)] ↳ Logitech G502 HERO Gaming Mouse Consumer Control id=17 [slave keyboard (3)] ↳ Logitech K400 Plus id=18 [slave keyboard (3)] ↳ VEIKK A50 Pen id=19 [slave keyboard (3)] ↳ VEIKK A50 Pen id=20 [slave keyboard (3)] ↳ VEIKK A50 Pen id=21 [slave keyboard (3)]

It is normal to have 3 "A50 Pen" but nothing about "A50 Tablet"??

When using xinput test 19 it says no event registered..., same for 20 and 21.

sudo evtest gives me this:

/dev/input/event0: Sleep Button /dev/input/event1: Power Button /dev/input/event2: Power Button /dev/input/event3: HDA Digital PCBeep /dev/input/event4: VEIKK A50 Pen /dev/input/event5: Logitech K400 Plus /dev/input/event6: HDA NVidia HDMI/DP,pcm=3 /dev/input/event7: Logitech Gaming Keyboard G105 /dev/input/event8: Logitech Gaming Keyboard G105 Consumer Control /dev/input/event9: Logitech G502 HERO Gaming Mouse /dev/input/event10: Logitech G502 HERO Gaming Mouse Keyboard /dev/input/event11: Logitech G502 HERO Gaming Mouse Consumer Control /dev/input/event12: Logitech G502 HERO Gaming Mouse System Control /dev/input/event13: PC Speaker /dev/input/event14: Eee PC WMI hotkeys /dev/input/event15: HDA Intel PCH Front Mic /dev/input/event16: HDA Intel PCH Rear Mic /dev/input/event17: HDA Intel PCH Line /dev/input/event18: HDA Intel PCH Line Out Front /dev/input/event19: HDA Intel PCH Line Out Surround /dev/input/event20: HDA Intel PCH Line Out CLFE /dev/input/event21: HDA Intel PCH Front Headphone /dev/input/event22: HDA NVidia HDMI/DP,pcm=7 /dev/input/event23: HDA NVidia HDMI/DP,pcm=8 /dev/input/event24: HDA NVidia HDMI/DP,pcm=9 /dev/input/event25: VEIKK A50 Pen /dev/input/event26: VEIKK A50 Pen

But selecting any of the three "A50 Pen" isn't registering any events, while it registers when selecting the mouse for example. Tried pressing the tablet buttons, moving the pen on the tablet and touching the touchpad, but nothing.

I've installed the 2.0 version from yesterday, now i'm using the AUR one, and the Qt GUI utility from yesterday won't show any event neither. This is the output when i build the AUR today again:

Construyendo input-veikk-dkms... ==> Creando el paquete: input-veikk-dkms r59.28eabab-1 (dom 19 ene 2020 13:49:15 CET) ==> Comprobando dependencias mientras se ejecuta... ==> Comprobando dependencias mientras se compila... ==> Recibiendo las fuentes... -> Actualizando input-veikk del repositorio git... Extrayendo origin Desde https://github.com/jlam55555/veikk-s640-driver 350b94d..414cda2 master -> master -> veikk.conf ha sido encontrado -> dkms.conf ha sido encontrado ==> Validando los archivos source con sha1sums... input-veikk ... Omitido veikk.conf ... Aprobado dkms.conf ... Aprobado ==> Eliminando el directorio $srcdir/... ==> Extrayendo las fuentes... -> Creando copia de trabajo de input-veikk del repositorio git... Clonando en 'input-veikk'... hecho. ==> Iniciando pkgver()... ==> Entrando en entorno fakeroot... ==> Iniciando package()... ==> Depurando la instalación... -> Quitando los archivos libtool... -> Purgando los archivos innecesarios... -> Quitando los archivos de las bibliotecas estáticas... -> Despojando los símbolos innecesarios de los binarios y de las bibliotecas... -> Comprimiendo las páginas del manual y de información... ==> Buscando problemas de empaquetado... ==> Creando el paquete «input-veikk-dkms»... -> Generando el archivo .PKGINFO... -> Generando el archivo .BUILDINFO... -> Generando el archivo .MTREE... -> Comprimiendo el paquete... ==> Abandonando el entorno fakeroot. ==> Compilación terminada: input-veikk-dkms r59.28eabab-1 (dom 19 ene 2020 13:49:18 CET) ==> Limpiando...

Preparando... Resolviendo dependencias... Comprobando conflictos entre paquetes... Ejecutando hooks de post-transacción... Comprobando llavero... Comprobando integridad... Cargando archivos de los paquetes... Comprobando conflictos entre archivos... ==> dkms remove input-veikk/r59.28eabab -k 5.4.12-arch1-1 Reinstalando input-veikk-dkms (r59.28eabab-1)... Ejecutando hooks de post-transacción... Arming ConditionNeedsUpdate... Install DKMS modules ==> dkms install input-veikk/r59.28eabab -k 5.4.12-arch1-1 Transacción terminada con éxito.

[jlam55555]

Hmm, everything looks correct except for not having the events registered.

The S640 also has three USB interfaces, and I've registered Pen devices with each of them (as per the above link, I'm not entirely sure what the purpose of the three devices are, but this has worked fine so far), but only one should emit the tablet events. Also, it seems like I have no control over the LEDs atm, so them blinking doesn't tell much.

You should see something like this for evtest:

$ sudo evtest ... /dev/input/event23: VEIKK S640 Pen /dev/input/event24: VEIKK S640 Pen /dev/input/event25: VEIKK S640 Pen Select the device event number [0-25]: 23 Input driver version is 1.0.1 Input device ID: bus 0x3 vendor 0x2feb product 0x1 version 0x100 Input device name: "VEIKK S640 Pen" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 330 (BTN_TOUCH) Event code 331 (BTN_STYLUS) Event code 332 (BTN_STYLUS2) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 7810 Min 0 Max 32768 Resolution 1 Event code 1 (ABS_Y) Value 13566 Min 0 Max 32768 Resolution 1 Event code 24 (ABS_PRESSURE) Value 0 Min 0 Max 8192 Properties: Property type 0 (INPUT_PROP_POINTER) Property type 1 (INPUT_PROP_DIRECT) Testing ... (interrupt to exit) Event: time 1579449068.841045, type 3 (EV_ABS), code 0 (ABS_X), value 19676 Event: time 1579449068.841045, type 3 (EV_ABS), code 1 (ABS_Y), value 16734 Event: time 1579449068.841045, -------------- SYN_REPORT ------------ Event: time 1579449068.858931, type 3 (EV_ABS), code 1 (ABS_Y), value 16691 Event: time 1579449068.858931, -------------- SYN_REPORT ------------ Event: time 1579449068.866946, type 3 (EV_ABS), code 1 (ABS_Y), value 16648 Event: time 1579449068.866946, -------------- SYN_REPORT ------------ Event: time 1579449068.870955, type 3 (EV_ABS), code 0 (ABS_X), value 19658 Event: time 1579449068.870955, type 3 (EV_ABS), code 1 (ABS_Y), value 16601 ...

Unfortunately, now that I'm going back to school I won't have physical access to the tablet (which is my sister's, at home) for a while, so I might be blindly trying to get the event registration to work. I'll poke around for now, but not sure what I can find.

[KibaGasteiz]

Ok, don't worry you're doing a great job, i will use the tablet on Windows this days. Isn't possible to ask Veikk for help? They have a Mac driver so they could give us support trough github somehow?

[KibaGasteiz]

May i need an additional package maybe? Something like wacom driver or anything like that?

[jlam55555]

Not exactly and probably no -- Mac is fairly different from Linux, and this package should be fairly standalone (except for the build tools).

I do plan to ask VEIKK engineers for help at some point, but the real question is whether I'll have any time during the school year. Sorry it isn't working for you.

My last suspicion is that it might have something to do with Wayland (I noticed you're using GNOME, which is Wayland by default) or the A50 PR that @grumgull made on the 1.0 driver. I just tried installing GNOME w/ Wayland and didn't have problems (but that would explain why it wouldn't show/work on xinput, but evtest did seem to work for me). If you're willing to experiment, here are some things I'd suggest:

• Roll back to the 1.0 or 1.1 release and install that. (2.0 really isn't that different, so probably not the case.)
• Log into GNOME for Xorg or install an Xorg-based DE (most are, except KDE & GNOME)
• Try @gromgull's PR (1.1 release, support for extra buttons for A50 -- maybe it'll only work with that?)

Sorry if this is a lot, but it is hard without having an A50 to say anything definitively.

[KibaGasteiz]

echo $XDG_SESSION_TYPE x11

Don't worry, i'll keep doing testing, maybe i'll try other distros or Wayland on this one, if i got any new info i'll tell you ;)

[artixnous]

Off-Topic: @artixnous Are you planning an update on your AUR version? That would be great :')

As @jlam55555 already noted, the AUR package pulls the latest git. :-)

[jlam55555]

Sorry, tagged this issue from a duplicate issue by accident. Meant to tag the Debian bug. Ignore that ^

[lenonk]

Let me see if I can give you a little additional information on this, because I'm having exactly the same problem. Dmesg says:

[  978.609561] usb 1-2: new full-speed USB device number 5 using xhci_hcd
[  978.768977] usb 1-2: New USB device found, idVendor=2feb, idProduct=0003, bcdDevice= 0.00
[  978.768980] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  978.768983] usb 1-2: Product: A50
[  978.768984] usb 1-2: Manufacturer: VEIKK.INC
[  978.768986] usb 1-2: SerialNumber: 0000001
[  978.814241] input: VEIKK A50 Pen as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-2/1-2:1.0/0003:2FEB:0003.000F/input/input63
[  978.814363] veikk 0003:2FEB:0003.000F: hidraw1: USB HID v1.00 Mouse [VEIKK.INC A50] on usb-0000:2a:00.1-2/input0
[  978.814365] veikk 0003:2FEB:0003.000F: VEIKK A50 Pen probed successfully.
[  978.822306] input: VEIKK A50 Pen as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-2/1-2:1.1/0003:2FEB:0003.0010/input/input64
[  978.822418] veikk 0003:2FEB:0003.0010: hidraw3: USB HID v1.00 Keyboard [VEIKK.INC A50] on usb-0000:2a:00.1-2/input1
[  978.822420] veikk 0003:2FEB:0003.0010: VEIKK A50 Pen probed successfully.
[  978.830126] input: VEIKK A50 Pen as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-2/1-2:1.2/0003:2FEB:0003.0011/input/input65
[  978.830240] veikk 0003:2FEB:0003.0011: hidraw4: USB HID v1.00 Device [VEIKK.INC A50] on usb-0000:2a:00.1-2/input2
[  978.830242] veikk 0003:2FEB:0003.0011: VEIKK A50 Pen probed successfully.
[  986.001016] veikk 0003:2FEB:0003.0010: Unknown input report with id 2
[  986.021005] veikk 0003:2FEB:0003.0010: Unknown input report with id 2
[  986.065007] veikk 0003:2FEB:0003.0010: Unknown input report with id 2
< ... >

The unknown input report happens whenever the pen moves over the tablet. If there's any other way I can help you, please let me know.

[jlam55555]

@lenonk That looks like what @gromgull mentioned in this PR. I'm not exactly sure how to fix this at the moment, but you can see his workaround in the PR. It might be that you have to switch from the libinput to evdev driver for X11 (but I'm not exactly sure -- his post isn't too clear).

I might have gotten in touch with VEIKK and be able to test an A50 soon, but not too sure yet.

[lenonk]

Unfortunately, after commenting out the keyboard and touchpad sections of /usr/share/X11/xorg.conf.d/40-libinput.conf, there is no change.

I didn't patch any code, I'm not sure if I was intended to. I'd like this to work, but I'm not too stressed about it. However, I am a developer, and if there's anything I can do to help you, I'd be more than happy to.

[lenonk]

Actually, yeah, it looks like the code patch would be required. I'll work on that

[jlam55555]

So, new update: VEIKK sent an A50 sample for testing! Yay! Unfortunately still busy with school, but I was excited today and spent a few hours.

@lenonk It's interesting that you're receiving "Unknown input report with id 2". For me, the A50 works OOTB, because the pen input is sending input reports with report ID = 1. The keyboard should be report ID = 3. (I am, however, getting that error for report ID = 3, as expected.) Link1J notes the same thing in the other issue where we're analyzing the report descriptors:

Also the buttons report as a keyboard, because they act as such. Report number 3 on the buttons should be handled in the same way a keyboard is.

Originally posted by @Link1J in https://github.com/jlam55555/veikk-linux-driver/issues/14#issuecomment-580425312

If you use the report descriptor decrypting tool linked in that issue, you can see that report ID 2 is used for the "Stylus" usage, and report ID 1 is used for "Pointer" usage. I'm not sure why it acts differently on our systems.

// this is consistent on the S640, the A15 (from Link1J), and the A50:

0x85, 0x01,        //   Report ID (1)
0x09, 0x01,        //   Usage (Pointer)
....
0x85, 0x02,        //   Report ID (2)
0x09, 0x20,        //   Usage (Stylus)

I'm not really sure why this is the case. (Is your kernel version up to date? Not sure if this has any relevance.)

I also just realized that "Unknown input report with id 2" comes from my own code, not the hid core. Therefore, try adding the line:

switch(report_id) {
    case VEIKK_PEN_REPORT:
    case 2:    // this line

in veikk_vdev.c on line 100, and let me know what happens. The input format should be exactly the same for usages 1 and 2 (different only in name afaik), so hopefully this should work.

[lenonk]

~/dev/veikk-linux-driver (master ✘)✹✭ ᐅ uname -a Linux Minerva 5.5.0-1-MANJARO #1 SMP PREEMPT Mon Jan 27 09:39:12 UTC 2020 x86_64 GNU/Linux

I pretty much already tried your suggestion in adding case 2, though I did it by adding static int veikk_a50_handle_raw_data(...) in veikk_vdev.c. The result was that the error went away, but the pen still doesn't work.

Are you using libinput or evdev?

[lenonk]

Update: After reconnecting it, the pointer now moves with the above fix.

[lenonk]

I'm unsure whether pen pressure is working or not though..

[lenonk]

I don't know enough about usb devices to have any idea what this actually means, but here's the data from my system:

~/dev/myrina (master ✘)✹✭ ᐅ sudo usbhid-dump -d 2feb
[sudo] password for lenon:
001:005:002:DESCRIPTOR         1580881904.948538
06 0A FF 09 01 A1 01 85 09 09 02 75 08 95 08 15
00 26 FF 00 81 02 09 03 75 08 95 08 15 00 26 FF
00 91 02 C0

001:005:001:DESCRIPTOR         1580881904.951525
05 0D 09 01 A1 01 85 02 09 20 A1 00 09 42 09 44
09 45 09 3C 15 00 25 01 75 01 95 04 81 02 75 01
95 02 81 01 09 32 75 01 95 01 81 02 81 01 75 10
95 01 35 00 A4 05 01 09 30 65 13 55 0D 46 34 03
27 38 63 00 00 81 02 09 31 46 4D 04 27 88 3B 00
00 81 02 B4 09 30 45 00 26 FF 1F 81 02 C0 C0 05
01 09 06 A1 01 85 03 05 07 19 E0 29 E7 15 00 25
01 75 01 95 08 81 02 05 07 19 00 29 FF 26 FF 00
75 08 95 06 81 00 C0

001:005:000:DESCRIPTOR         1580881904.954532
05 01 09 02 A1 01 85 01 09 01 A1 00 05 09 19 01
29 03 15 00 25 01 95 03 75 01 81 02 95 05 81 01
05 01 09 30 09 31 26 FF 7F 95 02 75 10 81 02 05
0D 09 30 26 FF 1F 95 01 75 10 81 02 C0 C0

[28171.848986] input: VEIKK A50 Pen as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-2/1-2:1.2/0003:2FEB:0003.0012/input/input61
[28171.849113] veikk 0003:2FEB:0003.0012: hidraw1: USB HID v1.00 Device [VEIKK.INC A50] on usb-0000:2a:00.1-2/input2
[28171.849115] veikk 0003:2FEB:0003.0012: VEIKK A50 Pen probed successfully.
[28171.857108] input: VEIKK A50 Pen as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-2/1-2:1.1/0003:2FEB:0003.0013/input/input62
[28171.857222] veikk 0003:2FEB:0003.0013: hidraw2: USB HID v1.00 Keyboard [VEIKK.INC A50] on usb-0000:2a:00.1-2/input1
[28171.857224] veikk 0003:2FEB:0003.0013: VEIKK A50 Pen probed successfully.
[28171.865016] input: VEIKK A50 Pen as /devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:08.0/0000:2a:00.1/usb1/1-2/1-2:1.0/0003:2FEB:0003.0014/input/input63
[28171.865141] veikk 0003:2FEB:0003.0014: hidraw3: USB HID v1.00 Mouse [VEIKK.INC A50] on usb-0000:2a:00.1-2/input0
[28171.865143] veikk 0003:2FEB:0003.0014: VEIKK A50 Pen probed successfully.

[jlam55555]

Thanks for the input. Having to disconnect and reconnect the VEIKK tablet after reinstall seems to be a problem (see this issue). You can test pressure sensitivity using xinput; xinput test [DEVICE ID] or sudo evtest. Either that, or try a drawing program like Krita designed to handle pressure sensitivity. I should probably make a quick supplemental wiki on this, seems to be pretty useful for debugging problems with the driver in general.

If pressure sensitivity works, that's very encouraging. @KibaGasteiz should try this fix as well. Your symptoms don't exactly match (Kiba is not getting any error in dmesg and no inputs registered), however, so no guarantees.

_{Also, a suggestion -- to avoid spamming watchers' emails, you can edit your post if you have multiple things to say in quick succession. I don't mind, but I've seen people who do.}

[lenonk]

Seems to be working:

Event: time 1580887067.601442, -------------- SYN_REPORT ------------
Event: time 1580887067.667445, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 8186
Event: time 1580887067.667445, -------------- SYN_REPORT ------------
Event: time 1580887067.673440, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 8001
Event: time 1580887067.673440, -------------- SYN_REPORT ------------
Event: time 1580887067.679434, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 7629
Event: time 1580887067.679434, -------------- SYN_REPORT ------------
Event: time 1580887067.685420, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 7052
Event: time 1580887067.685420, -------------- SYN_REPORT ------------
Event: time 1580887067.691434, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 6191
Event: time 1580887067.691434, -------------- SYN_REPORT ------------
Event: time 1580887067.697434, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 5216
Event: time 1580887067.697434, -------------- SYN_REPORT ------------
Event: time 1580887067.703435, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 4026
Event: time 1580887067.703435, -------------- SYN_REPORT ------------
Event: time 1580887067.709435, type 3 (EV_ABS), code 24 (ABS_PRESSURE), value 2731

[jlam55555]

@lenonk @KibaGasteiz See: https://github.com/jlam55555/veikk-linux-driver/commit/7ccdfb127f3082034e95da778f22b0ec65d8e7fc

Added the stylus HID usage to the event handler. I just received a VK1560 for testing, and it seems that it does indeed send the stylus usage report and not the pointer. Kiba let me know if this fixes your issue.

[lenonk]

@jlam55555 Looks pretty good from basic perspective. The pointer is moving around, and I can see pressure values popping up in dmesg. The only real problem I see now is the screen mapping is way off. I have two monitors, one is 1080p and the other is 1440p. The 1080p is to the left of the 1440p, and with the default mapping, the pointer will go all the way to the left and the bottom of the 1080p, but will not reach the right side, or the bottom, of the 1440p. Ideally, I'd like the pointer to be constrained to the 1440p monitor.

I've tried playing with the screen mapping in the GUI, but it seems broken by my dual monitor setup, and I can't really make sense of what's supposed to be happening. I haven't yet tried unplugging one of my monitors, but I will and I'll get back to you on the results.

Anyway, good progress so far. As I get time I'll contribute where and how I can. Thanks!

[jlam55555]

Oops, I forgot to clear the debugging line in dmesg...

I realized the issue with dual monitors today with the VK1560, and luckily bc my screen and the tablet are both at 1080p, it was easy to set a screen mapping manually in the config GUI by mapping the right half of the screen to the tablet. You can mess around with it — it’s all about the ratio of drawing area to the screen area. I believe you should be able to get any desired screen mapping if you set the parameters manually — it’s a little strange that the default mapping doesn’t go to the ends of both screens, but maybe that is the case if the default screen is smaller than the secondary screen.

I’ll probably (try to) address it this weekend, once I figure out how screens/monitors/displays work in X11 and Qt.

You should probably open a new issue (on the GUI repo) for this to keep this issue on task about the A50.

On Thu, Feb 6, 2020 at 11:42 PM lenonk notifications@github.com wrote:

@jlam55555 https://github.com/jlam55555 Looks pretty good from basic perspective. The pointer is moving around, and I can see pressure values popping up in dmesg. The only real problem I see now is the screen mapping is way off. I have two monitors, one is 1080p and the other is 1440p. The 1080p is to the left of the 1440p, and with the default mapping, the pointer will go all the way to the left and the bottom of the 1080p, but will not reach the right side, or the bottom, of the 1440p. Ideally, I'd like the pointer to be constrained to the 1440p monitor.

I've tried playing with the screen mapping in the GUI, but it seems broken by my dual monitor setup, and I can't really make sense of what's supposed to be happening. I haven't yet tried unplugging one of my monitors, but I will and I'll get back to you on the results.

Anyway, good progress so far. As I get time I'll contribute where and how I can. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jlam55555/veikk-linux-driver/issues/17?email_source=notifications&email_token=ACDPJJ4A5N4SR7Z64GKGWT3RBTRCDA5CNFSM4KIWM3DKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELBWOJA#issuecomment-583231268, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACDPJJ4PRS3VOMZEQ5BDYF3RBTRCDANCNFSM4KIWM3DA .

[KibaGasteiz]

Trying the last version but still not working. dmesg gives me this: https://gist.github.com/KibaGasteiz/b030ad0d14c946ae97821a3a632cc584

[KibaGasteiz]

Okay, just restarted the PC and now it's working but with the same issue as lenonk said. I only have one monitor connected right now and i can move the pointer and pressure is working on kirta, but only works at the top left part of the screen like i had a lower screen resolution or something.

[lenonk]

Yeah, same issue, even with one monitor plugged in. On a 1440p screen I had to almost double the "Map Width" and "Map Height" to get it to go all the way to the right and bottom of the screen.

[jlam55555]

@KibaGasteiz @lenonk Closing this issue now that the original problem was solved with adding report ID 2. I spoke to VEIKK, they said that the distinction between the two reports is just that different systems will accept different reports, but their function is identical.

For the mapping issue, please open a new issue. I'm not sure why it's not taking up the entire screen on a single-monitor layout, but two-monitor layout is something I need to work on.