v3-alpha mailing list #40
Comments
|
I just received the default keycodes for all of the devices from VEIKK, and I'll try to implement them over the next day or so. When this is done, the first button should report Ctrl+Alt+Shift+Keypad 0, the second should report Ctrl+Alt+Shift+Keypad 1, etc. I detailed why I ended up using these long keycodes in the blog post about button mapping, but I'd like any feedback on that as a design decision. Current devices with button mapping working: A50, VK1560 Current devices with button mapping not working: A30, A15, A15Pro, VK1560Pro, VK2200 (will try to get these working over the next day or two and let you know) In the meantime you can let me know if the pointer events are working properly with v3-alpha, and (when I've added the mappings for all of the devices) if the buttons are correctly reporting the aforementioned key combinations. (E.g., post the output of |
|
Now that I've looked at the button codes, the only one that I notice might cause problems is the A15 Pro. The 5th key (third row, first button) is mapped to Ctrl, and some other buttons are mapped to Ctrl+ other buttons, which might hide the Ctrl key. @sparshjain265 (Or anyone else with the A15 Pro) Can you try this:
Thanks. |
|
@sparshjain265 Still GIMP pressure not working with 'Edit/Input Devices/VEIKK A30 Pen' enabled in screen mode, but fine in Krita. xev doesn't report any keycodes for the buttons. |
|
Thanks @RaSTuS26. Almost everything you said is expected, and I might not have been entirely clear. (Also, I wrote For the buttons, there should be (a lot of) debugging output right now in The only thing that's unexpected is still the GIMP pressure..... Maybe some debugging with |
|
Cheers jlam55555, I didn't really expect the buttons to work from reading your notes, but thought I'd try, then report back anyway. Here is the output from xinput: The output from evtest: 'dmesg -w' only showed output for pen events, not buttons, as expected. A shortened dmesg output: |
|
@RaSTuS26 Try again with the newest commit. A new "VEIKK A30 Keyboard" input should show up in evtest and xinput, and hopefully things will just work. I'm reluctant to implement the A15 and A15Pro buttons before getting more feedback on the Control button, but the A30 was straightforward to implement with the current system. (Same thing, |
|
Here we go jlam55555 'xinput list' output: Tried all 3 id's, same output as previous (no event registered...) 'evtest' devices: Again, tried all 3 inputs, no live output given. 'dmesg -w' output for button presses: EDIT: I did make sure the old driver was unloaded with 'rmmod veikk' before trying new versions of driver. |
|
@RaSTuS26 I believe you've compiled and loaded the version from the master branch -- this is the behavior of the V2 driver (and what the V3 driver is intended to fix). |
|
@jlam55555 No, definitely from the alpha3 branch, the latest commit was only 10mins old when I downloaded it. It did make a difference, I now had 3 hid-inputs instead of 1, so something did register. As mentioned I also made sure to unload previous driver with 'rmmod' before activating (replugging A30). This is the branch link I'm using: |
|
@RaSTuS26 I understand that it made a difference, but it's not the latest update. See this line: the format is different from what you're showing. Sorry if this is a stupid question, but how did you download it? Did you make sure to run |
|
@jlam55555 I'm an idiot, I compiled from the old v2 directory. Now installed latest v3alpha, will report shortly. I don't use git, just download the zip. |
|
@jlam55555 ok, testing now. 'xinput list' 'xinput test 21' output: 'evtest' output: 'dmesg -w' output: Yay, it's working Jonathan, great work mate. |
|
@RaSTuS26 Cheers! Now go have some fun with xbindkeys. Keyboard shortcuts like (I also realized I made a mistake with the mapping: the fourth button should map to Keypad 3 but I accidentally wrote Keypad 4. Will fix this in the next commit.) In the meantime I'll be waiting on input from @sparshjain265 for the A15 Pro. |
|
@jlam55555 Have GIMP working now, didn't notice the 'Dynamics' (brush/pencil) options, my tool dock was too small to see them. Will play with that for a bit now. |
|
On a side note, will experiment a little today with a USB sniffer on Windows with the Windows driver to see if I can reverse engineer the USB packets. I really wonder if VEIKK performs the key mappings in hardware after sending some command to it since mapping like I'm currently attempting in this driver feels a little too abstruse, but I have no idea about the internals of the driver in Mac or Windows. I've asked VEIKK about it but no clear answer yet. If there is some command to send to the tablet to remap keys that would be a godsend. Never tried USB sniffing so most likely nothing will come out of this and this will be a spectacular fail, but who knows? |
|
Have fun, good luck. |
|
Ubuntu 20.04.1 LTS, kernel 5.4.0-42-generic, device A15 Pro, using the latest commits on alpha3. To compile, I had to add Outputs: xinput list sudo xinput test 20 dmesg -w # on key presses, nothing gets printed dmesg -w # on pen input evtest devices evtest #after selecting device in evtest evtest # on key presses, nothing gets printed evtest # on pen input @jlam55555 this looks like the undesired output (I double-checked if I have the latest commit and working in branch v3-alpha) |
|
@sparshjain265 No, this is the desired output, thank you for showing me this. I may not have been clear about this, but since I hadn't mapped the keyboard buttons yet for the A15 Pro (or the A15, VK1560 Pro, and VK2200), no events should show up in I see that dmesg shows events for pen events, but does it also show button events? If it does, please annotate the dmesg output like I mentioned here. |
|
@jlam55555 no, dmesg doesn't show button events, only pen events |
|
Hi all! Regarding the SSL errors, I do not have Secure Boot enabled, if that is relevant. In spite of the errors, it appears to be doing something as evidenced by- (1) a leftover mouse pointer stuck on the screen in some position, with a new pointer existing and being in use. (2)
I gather that's not what we're looking for, as I see the output of other users has an actuall veikk entry. For reference, the only other device connected to my machine is an apple bluetooth keyboard. Any suggestions of what to test next? My ultimate goal is to be able to (1) configure one of the stylus buttons to switch to a scroll mode where swiping up and down is the equivalent of a scroll wheel, and (2) Same thing but a zoom in/out mode, with the 1 being the most necessary of the two. What is the prognosis to being able to do something like this using this driver; is this a pipedream? Thanks! |
|
|
Yep, so, after switching to x11, the output of xinput is: After installing using I notice the key mapping on the pen changed from the default already. After unplugging/replugging I'm getting the same results as @RaSTuS26 xinput test of the Keyboard. xinput test 8 gives no events registered. xinput test 11 give all three buttons, motion, and pressure. |
|
Holy crap, starting to get something to work with the third, VEIKK proprietary interface after playing around with USB sniffers (wasn't expecting to get anything out of it). Didn't get very far but this looks very promising. This should eliminate a lot of the weird mapping issues with overlapping keycodes (e.g., on the A50, A15, and A15 Pro). For reference, was sniffing using USBlyzer on Windows (trialware) and Wireshark + usbmon on Linux. The basic premise is that I noticed that when the Windows VEIKK driver was installed, the device reported different input reports from the proprietary device, which should be easier to work with. This confirms some of the suspicions I've been holding for a long time (and seems to correspond with the vague information I've been told about the third device from VEIKK). I also noticed that there was a certain set of commands (output reports) sent from the computer to the VEIKK device which seems to toggle this. I'm playing around with the exact nature of the output reports now. At least, all I've gotten to work with the new system is the A50 Pro keyboard (not the pen yet). Will test on the other devices soon and report back. |
|
@meelash Your output from |
|
Update on the proprietary driver: a lot of success! The changes are now on the v3-alpha-ff0a branch (ff0a is the usage code of the proprietary HID interface). I'm lucky that between the S640, A50, and VK1560 there's a lot of variability, so I get to test out most of the features (e.g., gesture pad, rotating buttons, regular buttons, etc.). It'd be great if we could have people test this, and show the output of What was achieved/decided:
Brief overview of changes in v3-alpha-ff0aYou don't have to read this, but here's a brief overview of what was accomplished so far (I'll probably write another blog post on this when things get a little more stable):
I know I was messing around a while with the idea of "pseudo-usages" to make the interface consistent across VEIKK devices, and I know some (e.g., @sparshjain265) were playing around with the pseudousages table. This update abolishes that darned complicated mess. Sorry if anyone spent any time messing around with those, but this should make things much easier going forward. |
|
@jlam55555 Testing alpha3-ff0a evtest devices: buttons test 1 to 4 in order (event24): Gesture Pad test (event25): If you require any other output let me know Jonathon. |
|
@jlam55555 Playing with the Touchpad, all directions work except "right" xbindkeys --key for "left": ... for "right": ... for "up": ... for "down": Mapped them in GIMP to scroll-[direction], but I have no scroll-right. Also was able to map buttons 1-4 to certain tool selections in GIMP no problems. |
|
@RaSTuS26 I'm confused, by the looks of your numbers it sounds like your situation is very similar to @sparshjain265's and the (If it's 50800x31750, then it's an 8/5 aspect ratio, which is strange because it doesn't match the drawing area physical aspect ratio.) |
|
@jlam55555, Still didn't reach right side properly. I'm now using "x_max = 50600, .y_max = 31750" and it covers the whole perfectly. |
|
Another thing I'm starting to notice: when remapping keys on the buttons, the modifiers are great, but on the gesture pad, it doesn't work so well with Autokey. My guess is that it's because the gesture pad events are hardrepeated, which causes all of the modifiers to be rapidly switched on and off, which probably creates problems for autokey. Either I have to find out how to debounce the four gestures or switch them to key that wouldn't require modifiers. More on that later. |
|
@jlam55555 I think the 50800x31750 (8/5 aspect ratio) is when we include the inputs received from outside the designated drawing area, and if we tried to note the min/max values of both x and y, we should get a proper 5/3 aspect ratio. About that buttons_state, I think making it 32 bit is a better option considering new devices in the future may have more buttons. |
|
@RaSTuS26 if you can't reach the right side properly, can you set 'x_max' to something lower and try? I have a hunch that a number lower than 50600 will help you more than a number higher than this. |
|
@sparshjain265, 50600 works fine, when it's 50800 it doesn't reach. My current working figures are 50600x31750. |
|
@RaSTuS26 oh alright, I'm sorry. Yes, I meant to say less than 50800 (which 50600 is, so yay, my hunch was right). |
|
@sparshjain265, How does 50600x31750 work for you? |
|
@RaSTuS26 well, I reach the right end of my screen slightly before I reach the right end of the drawing area in my tab. With 50800, it's seemingly exact. |
|
@sparshjain265, Very strange, even when using unaltered ff0a version my max x was 50576 on same 10x6 surface. Probably different manufacturing tolerances, wouldn't surprise me if even two of the same model gave slightly different results. |
|
@RaSTuS26 100% agreed |
|
I did kind of get the gesture pad repeating to work with autokey by manually doing some throttling, which is okay but not great... I'm really tempted to write my own little input mapping tool daemon to integrate with the configuration tool. Also, Going to experiment with it tomorrow. If I think I can reasonably write a mapping script within a few hundred lines (maybe <500), then I'll probably try it. |
OverviewI've decided to attempt it, and hopefully this architecture will grow out into the new configuration tool. Here's the basic overview:
The basic commands for veikkctl [start] # start veikkctl daemon
veikkctl reload # call this when configuration files change or a new device is attached/detached
veikkctl stop # stop veikkctl daemon
veikkctl config # CLI configuration tool
veikkctl gui # GUI configuration tool
veikkctl help
veikkctl versionAnd it will also take a configuration file that I'm imagining will look something like the PurposeThe point of this configuration tool is to provide a somewhat-low-level (i.e., lower in the stack than X.org and tools like Autokey, but still in userspace) tools to effectively remap keys. This will keep the driver code simple, and allows a fast, intermediate-level customization. The problem I had with Autokey and xbindkeys is that while they seem pretty well-suited for running shell commands or doing more advanced things like abbreviation expansion, it's hard for them to (efficiently) emit native events (e.g., key presses, mouse clicks, scroll buttons, etc.) because they are already higher in the stack than X. (So there is no reason why this The main frustration I had was that if I wanted to do something like make the gesture pad work like mouse scroll directions, there was no easy way to do it. I could fudge it around with The goal is to be able to do this much more simply in a configuration file like the one above, which can send arbitrary keys, (mouse) buttons (which includes scrolling), and shell commands. Then they will be emitted by a uinput virtual device as ordinary evdev events, and hopefully will be much more responsive than autokey. For now, I'm going to leave the driver as-is, but I'm going to start developing this in the configuration tool in the GUI repo (even though this will not be a GUI at first). If I do go through with this and everything works out well, then I'll probably change the keycodes emitted by the driver to something Of course, let me know if you have feedback on this decision. It took a lot of thought and internal argument (I've stated exactly why I didn't want to do this) but I'm always open to ideas. |
|
@jlam55555, Using 3-alpha-ff0a_2020-08-20 and changing x/y to 50600x31750, works much the same as 2020-08-19 version. Gesture right still doesn't seem to work in GIMP, but does work on evtest. evtest output for up, down, left, right gestures: EDIT: |
My main concern with button mapping is I only have four, so prefer to map them on a per appliction basis. If I had more to contemplate I may use some for shell commands, like launching an application etc, but for now not important for me. I would like to see some way of editing/setting the pen/tablet spatial mapping so not having to hack the source with my 50600x31750 parameters each time. |
The goal is not to stop this from happening. The
Working on that, will be part of the configuration tool after I get the new skeleton set up with the changes mentioned in my last post. Do (As for the 50600x31750, I'll push a commit soon with the corrected |
|
@jlam55555, thanks Jonathan. Just FYI, xinput --list-props 23 output: That's with the modified sources, I'll try with the original sources soon, a little busy at present. |
|
@jlam55555, OK got my info from here: https://wiki.archlinux.org/index.php/Calibrating_Touchscreen My calculation was: X 32768/50600=0.647588932, Y 32768/31750=1.032062992 So to set my xinput --set-prop "Coordinate Transformation Matrix" I used: This worked wonderfully. So I added a 'udev rule' to load those settings automatically, it's also working. As mentioned in a previous post, I do have to plug the usb in twice to get results, doesn't work on first go. EDIT: probably wouldn't worry about modifying the source with these figures Jonathan, could be different for each device even of the same model, I'm quite happy to use 'udev' (or even xinput) to set the parameters. |
|
@RaSTuS26 I'm glad you got the screen mapping to work (also really cool that you can set the calibration matrix directly via a udev environment variable). And the values for the device really should be hardcoded in -- maybe we just have to confer with other A30 users (or I can ask VEIKK) to see what the true |
|
@jlam55555, I don't mean they use different specs, but the manufacturing tolerances might not be consistant over time, or even between the ppl assembling them. One thing I really don't understand is in version2 driver the Xmax and Ymax used 32768 also, but there was no problem with screen mapping, the pen would cover the screen area perfectly without any need to change/configure that. Here is an excerpt for the A30 from 'veikk_vdev.c' version2 sources: Why doesn't it work the same in alpha-3 ? |
|
@RaSTuS26 in v1-v2 use the generic devices, which mostly seem to output a maximum of 32768, but switching to use the proprietary devices seem to report a different maximum. As for why, I don't know. And since it's proprietary, I don't think there's likely any documentation on it. |
@jlam55555, I'm still a little concerned about this. Why is GIMP not getting the correct kbd mapping as shown in evtest? It's like it interprets those shortcuts totally differently to the system. |
|
@RaSTuS26 F13-F24 are not common keys (at least nowadays, not sure in the past), so it looks like people didn't care to be consistent between the naming of the input codes (defined in |
|
@jlam55555, much thanks for the explanation Jonathan. Can't wait to see what the configuration tool offers, it certainly sounds like it'll be a welcome addition. |
|
@jlam55555, I hope you're ok, haven't heard from you here or on twitter for a while. |
|
@RaSTuS26 Thanks for the concern, got hit hard with school. I really do want to get the configuration tool done so I can finally mark this project complete with all the originally intended features, but I don't know when I have any reasonable amount of time to finish this. |
|
@jlam55555, good to hear you're OK, School is most important of course, best of luck with that, hope you go well. |
|
With a free weekend and some extra knowledge over the last year, I think I am going to split off the v3 project into a new repo, and continue support for the v2 driver here. I've been very busy with studies/school projects/Master's thesis, but I've dedicated this weekend to a 48-hour hackathon-style to work on this driver and this driver only. I've already written about what the v3 driver brings and how we can get which buttons are pressed, but there were still a number of difficulties:
In the v3 driver, I took out most of the "policy" out of the driver (in preparation for the move to userspace configuration), and in the v3-ff0a branch, I figured out how to get usable values for the button mappings. The code for the v3-ff0a branch is basically finished, but I never figured out a clean userspace/config solution. But I now have a plan in mind for a system:
I thought the above would all be too complicated and involve complicated systemd, evdev, udev, dbus, and other configs/bindings. Luckily, it seems that Python makes it easy to deal with the latter three, and then I just need to figure out how to package a Python project for distribution. I usually don't like Python because it always seems to have versioning issues, but the C/C++ APIs involve too much boilerplate code and these Python packages are very mature. There will be one python script (veikk) for the daemon, and another (veikkctl) that will be a CLI to access the daemon. I will only be writing a CLI for this (I suck at writing GUI applications, as you can tell with the config application for the v2 driver), but anyone is free to adapt a GUI for it. You might also ask, why a new repo? Is that just abandoning all the existing issues with the current repo and config tool? Kind of? I don't want to confuse users with different versions of the same software in the same repo, especially when the current one has been in use for a little while. It's best to distinguish the versions explicitly here. I will also update the README with the current status of the project -- it is NOT being actively maintained right now because of lack of time, but v3 is still in the works. If and when the v3 version becomes stable in the near future, I will update the README again to reflect that again. Basic support will continue for this version (v2), like fixing the current issues with 64-bit division on 32-bit machines, and spamming the kernel logs. But that may not happen until after this weekend. I will also add a proper license to this repo and the config repo. Apologies for the lack of support in the last year. The new repos are: |
This thread will be for open discussion (e.g., questions, suggestions, answers, what-have-you's) for those testing v3 of the driver. Please post all questions related to v3-alpha here before it becomes a release.
The relevant blog posts related to this driver:
When you first post, please list your Linux distribution, kernel version, and devices, and please try to list relevant output (e.g., with
xinput test).Anyone is welcome and encouraged to comment. Some people who have reached out already:
@meelash @sparshjain265 @RaSTuS26
The text was updated successfully, but these errors were encountered: