xp-pen-artist-pro-14-gen-2-driver: init at 4.0.4-240815

[gepbird]

Fixes #347116

@HangedFool please test how it works, I saw the GUI open but don't have a tablet for it. You can run this and the GUI should open: NIXPKGS_ALLOW_UNFREE=1 nix run github:gepbird/nixpkgs/xp-pen-init#xp-pen-artist-pro-14-gen-2-driver --impure

Postponed to an upcoming follow up PR: If the latest xp-pen driver is backwards compatible with all the previously released tablets, we could merge all the 2 old (xp-pen-deco-01-v2-driver and xp-pen-g430-driver) and this (xp-pen-artist-pro-14-gen-2-driver) package into a single one called xp-pen-driver. What do you think about it @virchau13 ?

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[HangedFool]

I am currently using a virtual machine to utilize NixOS because I don't have time to distro hop, I plan to switch in a couple weeks. That being said my VM is acting very funky with the package but I am unsure if that is because of an issue with the package or the VM, I am getting

[demo@nixos:~]$ NIXPKGS_ALLOW_UNFREE=1 nix run github:gepbird/nixpkgs/xp-pen-init#xp-pen-artist-pro-14-gen-2-driver --impure --extra-experimental-features nix-command --extra-experimental-features flakes
MESA: error: ZINK: failed to choose pdev
glx: failed to create drisw screen
Qt: Session management error: None of the authentication protocols specified are supported
QtLockedFile::lock(): file is not opened
QtLockedFile::lock(): file is not opened

Can I setup Nix on my current machine (Arch) to test it?

[HangedFool]

Upon trying to run

sudo NIXPKGS_ALLOW_UNFREE=1 nix run github:gepbird/nixpkgs/xp-pen-init#xp-pen-artist-pro-14-gen-2-driver --impure --extra-experimental-features nix-command --extra-experimental-features flakes

on my Arch system with nix I got this,

Authorization required, but no authorization protocol specified

qt.qpa.xcb: could not connect to display :1
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

[1]    5439 IOT instruction  sudo NIXPKGS_ALLOW_UNFREE=1 nix run  --impure --extra-experimental-features  

Am I missing something obvious?

[HangedFool]

I can confirm, I was missing something obvious. Upon uninstalling my already existing drivers and then running the command the gui did appear... I feel very silly now

That being said, I think there does seem to be a problem with this

"Please connect device."

Here is the terminal

sudo NIXPKGS_ALLOW_UNFREE=1 nix run github:gepbird/nixpkgs/xp-pen-init#xp-pen-artist-pro-14-gen-2-driver --impure --extra-experimental-features nix-command --extra-experimental-features flakes
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QLocale::English
QObject::connect: Incompatible sender/receiver arguments
        QDesktopWidget::primaryScreenChanged() --> MainWindow::onDeskScreenChanged(int)
Function  EnumDisplay nScreenCount: 2
Device.AllScreen "(0,0,3840,1200)"
Device.Screen 1 : "1(0,0,1920,1080)"
Device.Screen 2 : "2(1920,0,1920,1200)"
qt.glx: qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize 0, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile)
-------type: 4
manufacturer:Hanvon Ugee product:Shortcut Remote Get Max X:0xd8cc64 Y:0x1373a0  Press:0x1fff

Function  LoadConfig Error: open file "/usr/lib/pentablet/conf/xppen/config.xml" failed, error: "No such file or directory"
ReadXml Failed!
------------------load xml failed: ACK05
-------type: 2
manufacturer:UGTABLET product:Artist Pro 14 (Gen2) Get Max X:0xeba0 Y:0x9342  Press:0x3fff

Function  LoadConfig Error: open file "/usr/lib/pentablet/conf/xppen/config.xml" failed, error: "No such file or directory"
ReadXml Failed!
------------------load xml failed: LPH1416F-A
DeviceListLabel: ""
open uinput ok 

open uinput ok 

open uinput ok 

[gepbird]

@HangedFool thanks for the quick reply! I'll be more active today as I went to sleep soon after I opened the PR.

The last issue where it doesn't find the config.xml should be fixed now, please try again.

Nix might not pull the latest commit using the previous test command, adding --refresh fixes it: sudo NIXPKGS_ALLOW_UNFREE=1 nix run github:gepbird/nixpkgs/xp-pen-init#xp-pen-artist-pro-14-gen-2-driver --impure --extra-experimental-features nix-command --extra-experimental-features flakes --refresh

Edit: oops, looks like it segfaults, give me a few minutes

[gepbird]

Segfault is fixed, you can try it now.

[HangedFool]

The GUI Successfully connects
    In Tablet Settings
        In Device Settings
            Calibration works
                But can be difficult to utilize if the calibration is already far off as you cannot click the calibrators
                But you can export config file then edit it then import if it is too far off to fix with the app
            The work area setter has functionality (it is hard to test extensively with my setup but it looks good)
            In display setting
                Brightness works
                Contrast works
                All Prebuilt Color profiles work
                User Color Profiles work
                    Color temperature adjustment works
                    RGB adjustments work
                    Reset to Default Works
        In Pen Settings
            Pressure works
                Pressure Adjustment works
                Pressure indicator works
                Pressure test zone does not work (This is very minor, I just tested with Krita)
            Tilt works
            Mouse Mode has functionality (It is hard for me to tell)
            Pen Buttons work
            Pen Eraser works
            Shortcut Rebindings Seems to work (I didn't test extensively but all the tests I did do succeeded)
            Reset to Default works
        In Settings
            Common
                Export config works
                Import config works
    Shortcut Remote
        Battery Indicator works
        Rotation works
        Wheel
            Wheel Setter works
            Wheel works
        Keys work
        Key rebinds work
        Key group switching works
    Current Device
        Diagnostic Tool works
        Feedback Works
        Default Works
        Prompt Toggle Works
        Shortcut Keys Toggle does not work
            That being said you can manually disable all of them or import a config where they are all disabled so whatever

These tests were done on an Artist Pro 14 (Gen 2) on Arch Linux

All in all fantastic job, this works nearly perfectly and the bugs I did find are incredibly minor. In fact, I would say it has a fraction of as many bugs as the AUR version had, how much of that is due to it being an updated version compared to the AUR version and how much is packaging I am unsure, but the end all be all is that I am very happy with this. The only thing I think it is missing is that it isn't in the application launcher, but I assume that that will be in the final package.

[gepbird]

@HangedFool Great to hear it works, and thanks for your detailed testing!

I used most of the dependencies from one of the older xp-pen drivers, but I don't think they are being used.

I just removed those, the GUI opens up the same for me, would you mind testing the basics? (checking whether it detects your tablet, and some basic features work is enough, no need to go through that long list)

The bugs are most likely fixed by the newer version and not by packaging, but I'm curious what issues you had with the AUR package.

[HangedFool]

Should I just rerun the command to test this?

[gepbird]

Should I just rerun the command to test this?

Yes, rerun the last test command (that has --refresh at the end)

[HangedFool]

I believe all functionalities are intact

Also, the "Shortcut Keys Toggle" actually does work, I miss-tested that

And the problems with the original AUR package I felt were just quality of life stuff that I had to manually fix. Their was a problem with launching it through an application launcher, I had problems with prompts, and some other stuff
(it has been awhile since I resolved most of the problems so I can't super well remember)

[HangedFool]

I am unsure if this is just because it isn't a full package yet or if you even have control over this but I have noticed that when closing the gui the process doesn't end (it shouldn't so that is good) but it doesn't go into the application tray, which it should.
Also I made brief mention of this in my last post but a concern I have is that in the AUR package it had a bug wherein the application path it would create would launch a script that would launch the program, but that script wouldn't launch properly so application launchers like rofi would just not launch it. In the original AUR package my solution to this was just making the application path point directly to the application instead of the weird script.

[gepbird]

I decided instead of adding this driver in a single PR and doing some refactors, I will do the refactors in a seperate PR.
This way the package could get merged faster as reviewers have to look at less code.

Also I have some other ideas regarding to all xp-pen drivers in nixpkgs. First of all with this we'd have 3 xp-pen device names: artist-pro-14-gen-2, g430 and deco-01-v2. But similar to the AUR, we could have a v3 (for g430, deco-01-v2 and many others) and a v4 (for artist-pro-14-gen-2 and many other) drivers. Currently for example if someone wants to to use an Innovator 16 device, he'd need to install deco-01-v2 because that has the same major version 3, which is quite confusing.

Another idea: to improve security, instead of giving sudo to a proprietary driver (needed because of udev rules), we could make a NixOS module that loads the udev rule (just like with the OpenTabletDriver module. This would also make it possible to add a desktop entry, so people who prefer to start it from a GUI application launcher rather than CLI can. However only people on NixOS would benefit from that.

With these future refactors, this would change from a user's perspective. Rather than

environment.systemPackages = [ pkgs.xp-pen-artist-pro-14-gen-2-driver ];

you'd do

services.xp-pen = {
  enable = true;
  package = xp-pen-v3; # this is optional, omitting it would use the latest v4 driver
};

Everything should work as before since I just deleted the refactor commits, but just to be sure, a final short and quick test wouldn't hurt.
@HangedFool I'd love to see you test the upcoming follow PR :)

[gepbird]

I have noticed that when closing the gui the process doesn't end (it shouldn't so that is good) but it doesn't go into the application tray, which it should.

I noticed that too, I usually xkill-ed it or Ctrl+C-d it from the terminal, actually I'm not sure how the application tray works since I haven't been using it on my WM, but I might look into it later.

Also I made brief mention of this in my last post but a concern I have is that in the AUR package it had a bug wherein the application path it would create would launch a script that would launch the program, but that script wouldn't launch properly so application launchers like rofi would just not launch it.

Yes, I noticed that too, it will be fixed it in the follow up PR.

[HangedFool]

In regard to closing it the expected behavior is that you right click it in the application tray and hit quit, so you would not be able to close it without the tray unless you manually kill it.

That is also typically how you would access it when it is already open, with the current system I think that relaunching the gui would make you have two instances of it open, the one you just launched and the one in the background, but you should be able to just click it in the application tray to recall it.

So not having access to it in the tray makes it somewhat awkward to work with.

[HangedFool]

Everything should work as before since I just deleted the refactor commits, but just to be sure, a final short and quick test wouldn't hurt. @HangedFool I'd love to see you test the upcoming follow PR :)

Just tell me when <3

[gepbird]

I just found out about #285660 which packages the v3 driver with a NixOS module, solving the issues I planned to fix (only running under root, no desktop file). Adding a v4 driver to that PR would be the best IMO, this PR can be closed then.

[HangedFool]

Sorry if I'm being stupid, but I wanted to clarify the status of the package request. Is the plan to integrate the driver into the existing module? Also, regarding my next steps, you mentioned that the package request can be closed, but should I take any action beyond that? And finally, I was just a bit concerned that development might have stalled given the lack of comments over the last couple days. I don’t want to seem bothersome, but I’d appreciate any information you can share, this software is pretty important to me.

Also, I just wanted to say thank you for taking the time to assist me.

[gepbird]

Sorry if I'm being stupid, but I wanted to clarify the status of the package request. Is the plan to integrate the driver into the existing module? Also, regarding my next steps, you mentioned that the package request can be closed, but should I take any action beyond that? And finally, I was just a bit concerned that development might have stalled given the lack of comments over the last couple days. I don’t want to seem bothersome, but I’d appreciate any information you can share, this software is pretty important to me.

Also, I just wanted to say thank you for taking the time to assist me.

If you want to use the v4 driver for yourself, you can with the previous test command (I don't plan on deleting this branch yet, but you can make a copy of it in your own nixpkgs fork if you wish).

My plan is to get the more polished #285660 PR merged first (that has a proper NixOS module and better driver names that are device independent), preferably with the v4 driver, but it likely won't happen as the author doesn't have much time to work on it. If that won't include the v4 driver, I'll make a PR for it.
If that PR won't get much attention I'll consider taking it over.
This will take time, but I want to avoid making a bunch of aliases because as a user I'd be annoyed (eg. xp-pen-artist-pro-14-gen-2-driver package getting into nixpkgs, then getting renamed to xppen_4 in a few days).

[gepbird]

Just tell me when <3

Hi @HangedFool, can you check if the v4 driver works for you and whether your previously mentioned issues are fixed in #351647? Thanks for taking your time to test it in advance.

[HangedFool]

Correct me if I'm wrong but I don't think I am able to test it because it is a module. I am currently still using Arch, I plan to make the switch to NixOS when I have more time; which at this point is looking like it'll be at least a couple months down the line. I did think about setting up a virtual machine to test it but vbox doesn't want to accept my tablet (this may be vbox issue or it might be specific to me).

But I digress, if their is a way for me to test it I would love to help, it's just that things are just really busy for me right now.

[gepbird]

Correct me if I'm wrong but I don't think I am able to test it because it is a module.

You're right, you can't use NixOS modules on non-NixOS systems. The programs.xppen module installs some config files to /var/lib/pentablet/conf/xppen/, if you can do that step manually on Arch then running the xppen_4 package should have a similar result to running it on NixOS, but doing a more "end-to-end" test with the NixOS module would be preferred.

I did think about setting up a virtual machine to test it but vbox doesn't want to accept my tablet (this may be vbox issue or it might be specific to me).

I'm not too familiar with VirtualBox (or virtualisation in general), but once I passed through an FPGA board using VMWare Workstation without any extra config, just clicking on the board in Devices worked well. If you want to continue your VM attempt, can you see the tablet with sudo hwinfo or in the kernel logs with sudo dmesg?

I am currently still using Arch, I plan to make the switch to NixOS when I have more time; which at this point is looking like it'll be at least a couple months down the line.
But I digress, if their is a way for me to test it I would love to help, it's just that things are just really busy for me right now.

I assume many technicalities in the v3 and v4 drivers are similar, so testing both is not that mandatory but would be very good. One of the v3 driver testers is giving us great feedback and we can probably find and tackle the issues with them. Thanks for your previous testing and for still being interested, feel free to focus on other things if you are busy. You can always report issues when you'll actually use the driver on NixOS in the future.