Hi,
I’ve recently bought a graphic tablet, Gaomon S620. It is a Chinese tablet and it has native Linux software but it isn’t very good. I think it’s quite heavy for only a driver and depends heavily on X, while Fedora uses Wayland.
Now, there’s a project called Open Tablet Driver. It is available for Linux too, but there’s no Fedora packaged driver.
Could someone explain step-by-step how to install it?
I use the latest Fedora 38 with Gnome.
The link you provided shows how to install it under the part for Arch Linux – the second section there. One seems to need to install only directly by downloading from github and compiling.
The makepkg command seems to be available by installing pacman on fedora
# dnf provides /usr/bin/makepkg
Last metadata expiration check: 0:51:07 ago on Mon 12 Jun 2023 06:54:29 PM CDT.
pacman-6.0.1-6.fc38.x86_64 : Package manager for the Arch distribution
Repo : fedora
Matched from:
Filename : /usr/bin/makepkg
pacman-6.0.2-2.fc38.x86_64 : Package manager for the Arch distribution
Repo : updates
Matched from:
Filename : /usr/bin/makepkg
There is an alternative package mentioned here: RPM package still not working on Fedora 35 · Issue #1986 · OpenTabletDriver/OpenTabletDriver · GitHub
The last comment says it works on F38 with more details.
You can install downloaded rpms by path:
sudo dnf install /path/to/rpm
To inspect the contents before installing:
rpm -qplv /path/to/rpm
Please don’t suggest installing other package managers, to then install packages for other distros on Fedora. The PKGBUILD for the AUR opentabletdriver package would have Arch/AUR dependencies. You will lead people into dependency hell.
Many thanks, Justin!
i’ve managed to install the driver, now trying to figure out why it isn’t detecting the (pretty popular) tablet.
Also, I wonder if this amount of dependencies that came along the driver is okay?
Package Arch Version Repository Size
Installing:
opentabletdriver x86_64 0.6.0.4-1 @commandline 25.2 MiB
Installing dependencies:
dotnet-host x86_64 7.0.5-1.fc38 updates 296.2 KiB
dotnet-hostfxr-6.0 x86_64 6.0.16-1.fc38 updates 381.7 KiB
dotnet-runtime-6.0 x86_64 6.0.16-1.fc38 updates 65.0 MiB
libXau-devel x86_64 1.0.11-2.fc38 fedora 6.4 KiB
libXext-devel x86_64 1.3.5-2.fc38 fedora 98.8 KiB
libXrender-devel x86_64 0.9.11-2.fc38 fedora 50.1 KiB
libevdev-devel x86_64 1.13.1-1.fc38 updates 95.6 KiB
libxcb-devel x86_64 1.13.1-11.fc38 fedora 2.6 MiB
xorg-x11-proto-devel noarch 2022.2-3.fc38 fedora 1.7 MiB
Installing weak dependencies:
libX11-devel x86_64 1.8.4-1.fc38 fedora 1.0 MiB
libXrandr-devel x86_64 1.5.2-10.fc38 fedora 21.9 KiB
Looks like there’re some issues related to Gaomon S620. I didn’t check them all, but #2768 might have the solution.
I don’t use this software, so I can only guess. The dotnet dependencies look correct. The *-devel packages are typically build deps (used to compile software), but some software might use them at runtime. Regardless, they’re harmless to install and negligible in size.
The upstream packaging situation seems quite troublesome[1], so I don’t want to get involved. You could ask upstream (or the person that made the alternative package) if you have concerns about the deps.
Aside from the organisational issues, their build system is backwards: using custom build scripts to compile the software first then run the spec file, instead of using the spec file to run their build scripts. ↩︎
Thanks.
I’ve seen the Github thread and reported my issue there but the driver still doesn’t work.
That’s just my amateur presumption but maybe it’s Wayland that isn’t compatible.
Regarding dependencies, I had to install additional Microsoft package of a specific version to run a script and it brought along another 10 or so dependencies. The total number must be is around 30 for a small driver.
The original Chinese driver looks humble in comparison.
Not sure why you care about the number of dependencies. There are 100s, if not 1000s of packages on your system you’re not aware of, that are dependencies (of dependencies (of dependencies…)).
Asking “is this dependency correct” is valid, which I’ve already said, you’ll have to ask upstream or the person who made the package. But the number of dependencies is completely irrelevant.
Don’t dependencies make the system work slower?
Don’t dependencies make the system work slower?
Yes, in the same way that wings make an airplane heavier.
I am not sure but the multiple dependencies are likely being addressed by the system, which makes it slower. Further to your analogy, these are wings made of lead, kind of.
The question is: could these be avoided? I have no expertise to answer because I don’t quite understand how these things work. What I wrote is just my common sense.
Think of dependencies this way.
Your car needs to be driveable.
It needs wheels which need tires, which need wheel bearings, which needs drive axles, which needs a transmission, which needs an engine, which needs a fuel system, etc. When it is all put together we see a car. Each piece is only a part of the whole.
Each dependency is a piece in the chain which allows the app to perform its job.
The alternative would be one massive program to do the same job and would be impossible (or almost so) to build and maintain. Each dependency is a single small block in the entire structure and each dependency has a specific task. Any one missing would mean something else would need to be created to perform that same exact task.
Many small blocks that already fit together are easier to use (by many different apps) than having each app completely reinvent something new to do the same task. It saves space, maintenance time, development time, and all fits the basic adage of “each piece should do one task and do it well”.
There likely are many different dependencies already installed on the system that one does not even see listed since they are already in place.