kurikaesu / userspace-tablet-driver-daemon

Linux device drivers for non-wacom (XP-Pen, Huion, Gaomon) graphics tablets and pen displays
GNU General Public License v3.0
65 stars 16 forks source link

Report #1

Closed kanashimia closed 3 years ago

kanashimia commented 3 years ago

First - XP-Pen Deco Pro M works with this driver, no problema were found after you fixed hotplug issue.

Second - this driver seems to require uinput module to be loaded manually, otherwise you need to start driver as root. Other than modalias i think one can load modules through udev and kmod builtin.

X.Org conf files seems to have wrong pids for all models - why?

Why does xev report codes that are 8 higher than what config of this driver uses?

Also can you please rename MD to M and SM to S both in this userspace driver, and digimend PR, that is the model name, it was confusing why S was SM, as if it was for both S and M, also there are new SW and MW models, if one adds support for them - would be even more confusing.

There also were problems with config util, i use dvorak layout, and it doesn't follow it, and i wasn't being able to package that stuff for nixos, albeit was being able to run it, seems that setuptools config was wrong? I'm not that familiar with python to tell why. And there are alot of code duplication there. I will try to write my own config util, pretty trivial it seems.

There are two problems with CMakeLists:

  1. cmake requirement is TOO new
  2. It should have ${CMAKE_CURRENT_SOURCE_DIR}/LICENCE instead of LICENCE otherwise won't build

Finally i would personally prefer if wheel in digimend with wacom driver worked, instead of using this, so i only have to touch xsetwacom.

kurikaesu commented 3 years ago

Thanks for the report.

Did you restart your computer after installing? The package should add a udev config that changes the permissions of uinput to allow users in the "plugdev" group access without being root. Not sure if the first user of the system is automatically given that group access so let me know if that is not the case.

X.Org config contains modified pids because the driver will alias the original pids. I don't know what users have done to try and get their tablets working with xorg so I use unique product ids to reduce the amount of weird reports I may get.

Definitely can rename the models.

There is a lot of code duplication in both packages because I don't write super optimized code on the first few iterations where I don't know exactly how future modules will inherit things. Once a few tablet models are written (even with duplicate code) and I can get confirmed responses that they work then I can abstract things away afterwards. Remember, perfect is the enemy of done.

I'll look at the CMakelists

As for the last thing regarding the wheel in digimend or my driver, that's a problem with the wacom driver itself, see: https://github.com/DIGImend/digimend-kernel-drivers/issues/275#issuecomment-691860908

kanashimia commented 3 years ago

Did you restart your computer after installing? The package should add a udev config that changes the permissions of uinput to allow users in the "plugdev" group access without being root.

Yeah but only if the module is already loaded, anyways i figured it out, here are correct rules:

KERNEL=="uinput", MODE="0660", GROUP="plugdev", OPTIONS+="static_node=uinput"
SUBSYSTEM=="usb", ATTR{idVendor}=="28bd", GROUP="users", TAG+="uaccess"

Where as rules from the official proprietary driver for linux are:

KERNEL=="uinput",MODE:="0666",OPTIONS+="static_node=uinput"
SUBSYSTEMS=="usb",ATTRS{idVendor}=="28bd",MODE:="0666"

Looking at the man udev that option seems correct.

BTW it is very strange that /dev/uinput is there even when module isn't loaded, just seems weird.

kurikaesu commented 3 years ago

That's because /dev/uinput is part of the Linux Kernel and not something that I load: https://www.kernel.org/doc/html/v4.12/input/uinput.html

It is usually present without having to modprobe or install anything.

With the rules you've set, basically every user on the system whether it is you or anybody that has access to your computer (be it authorized or unauthorized) can create a virtual keyboard (or mouse) and control your computer. There is a reason why /dev/uinput by default requires super-user access so be careful.

kanashimia commented 3 years ago

With the rules you've set

My rules are:

KERNEL=="uinput", MODE="0660", GROUP="plugdev", OPTIONS+="static_node=uinput"
SUBSYSTEM=="usb", ATTR{idVendor}=="28bd", GROUP="users", TAG+="uaccess"

The only diff with your rules is: OPTIONS+="static_node=uinput"

It is usually present without having to modprobe or install anything.

Yeah, if it is there it doesn't mean that it is loaded, but your udev rule requires the kernel module to be loaded.

Basically see this comment and whole issue: https://github.com/ValveSoftware/steam-for-linux/issues/4794#issuecomment-327006061

kurikaesu commented 3 years ago

Got it, let me fix up the rules on my side. Alternatively you can send me a PR with the fix

kurikaesu commented 3 years ago

Updated the rules