Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report #1

Closed
kanashimia opened this issue Sep 13, 2021 · 6 comments · Fixed by #3
Closed

Report #1

kanashimia opened this issue Sep 13, 2021 · 6 comments · Fixed by #3

Comments

@kanashimia
Copy link
Contributor

kanashimia commented Sep 13, 2021

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
Copy link
Owner

kurikaesu commented Sep 13, 2021

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: DIGImend/digimend-kernel-drivers#275 (comment)

@kanashimia
Copy link
Contributor Author

kanashimia commented Sep 13, 2021

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
Copy link
Owner

kurikaesu commented Sep 13, 2021

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
Copy link
Contributor Author

kanashimia commented Sep 13, 2021

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:
ValveSoftware/steam-for-linux#4794 (comment)

@kurikaesu kurikaesu reopened this Sep 13, 2021
@kurikaesu
Copy link
Owner

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

@kurikaesu
Copy link
Owner

Updated the rules

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants