Auto-connect request of `hardware-observe` and `raw-input` for `fingerpaint`

Hello :slight_smile:

I recently published Fingerpaint on Snapcraft, and I would like that the app to work out of the box (without manual connections).

The app allows you to draw using your touchpad, using it as a canvas (that means getting raw/absolute touch data from the sensor).

In order to do that I need:

  • The raw-input plug (for access to /dev/input/eventX)
  • The hardware-observe plug (for navigating /sys to know which device is the touchpad)

In addition, I add a udev rule (ENV{ID_INPUT_TOUCHPAD}=="1", MODE="0664") that allows non-root users to access this device (I consider this ok privacy-wise since it’s just a touchpad, not a keyboard, and since getting this data is rather trivial anyway when not running in a confined snap).

Adding the udev rule is handled by prompting the user to run a setup script as root (outside the sandbox) if the device is inaccessible.

Thanks :slight_smile:

From what I can tell from the snap’s description:

Your touchpad will not control the cursor while drawing, though external mice should still work

I assume that this snap takes the raw-input from the device rather than using the higher-level input interfaces provided by wayland / X etc? And so that is why it needs this low-level access?

Can you also explain more about the udev rule? What exactly do you prompt the user to do in this case? How does the snap handle removing this udev rule when it is uninstalled? Would it be better to instead ask the user to say add themselves to the input group? Or to split your snap into a privileged daemon that can run as root and access the device file directly and then have the frontend user-facing part communicate with the daemon to get the input events through it? Then a user should not have to do anything.

@Wazzaps ping, can you please provide the requested information?

Hi,

The udev rule grants raw access to the touchpad (bypassing any window server), and does not get removed on uninstall at the moment.

I prompt them to run a shell script outside the sandbox as root, since snap has no api for pkexec.

The input group idea hurts privacy (allows keylogging (not that it matters, breaking out of the snap sandbox is pretty trivial for on a desktop environment with gsettings)), and requires a logout (terrible UX).

The daemon idea seems overcomplicated (socket activation + fd over Unix socket) or slow/bloated (always running, sending events over socket) and introduces unnecessary attack surface for the root user.

I gave up on packaging this as a snap once I rewrote the app in GTK4 and encountered multiple bugs, a huge 50MiB+ (compressed, 150MiB+ uncompressed) package, and 10 second startup times on my top of the line Ryzen FROM RAM (liveusb with no persistent partition).

I refuse to ship an app under my name that takes more than a second to display a sign of life.

For comparison, the flatpak is 1MiB and works on Ubuntu 18.04 (unlike the snap, I ain’t debugging that).

So basically I won’t release a new update for this snap as long as the GTK4 experience wont improve

Thanks for your work and attention, and I hope for the sake of the Linux ecosystem y’all improve on these points.

@kenvandine just wondering if you or anyone else on the desktop team may be able to provide some guidance on snapping GTK4 based applications?

@Wazzaps FWIW there has been a number of gtk4 based snaps published recently by both @SamAlex and @soumyaDghosh who also may be able to help advise.

looking at @Wazzaps snap (https://github.com/Wazzaps/fingerpaint/blob/feature/snap/snap/snapcraft.yaml) it seems to use a lot of external helper scripts pulled in via various stage-snap entries (tcltk-launch, debian-multiarch-triplet-provider-launch)… i wonder if all use the same base snap here, else you might indeed see a lot of harmful issues …

it also does not use the gnome extension so there will be a good bunch of duplicated (gtk) libs pulled in and such which will indeed result in a rather large size … i guess with a bit of clean up of the packaging to use the correct bits and pieces the snap won’t be (and behave) much different to the flatpak in the end.

The gnome extension would be the best way to package a gtk4 app. There are quite a few gtk4 apps in the store without these performance/size issues.

@ogra @kenvandine The linked snapcraft is the tkinter-based version, this is the gtk4-based version. I haven’t pushed it to the repo yet. It does use the gnome extension.

@Wazzaps I submitted a PR which seems to improve things quite a bit. https://github.com/Wazzaps/fingerpaint/pull/31

1 Like

(Note: I had to restart in the middle of this process since I noticed the build process is not hermetic and showed build files from previous tries which made it work)

Cannot pack snap file: Command '['snap', 'pack', '--filename', 'fingerpaint_1.4.0_amd64.snap', '--compression', 'xz', PosixPath('/root/prime'), PosixPath('/root/project')]' returned non-zero exit status 1. (2023/06/15 19:44:37.899502 container.go:215: in snap "fingerpaint": path "bin/fingerpaint" does not exist   
error: cannot pack "/root/prime": snap is unusable due to missing files)

(This is solved by the override-prime part)

Log: https://gist.github.com/Wazzaps/16f0f50c4f71deac36dd4a8c158926e5

You shouldn’t need all the override stuff, the plugin should just process setup.py, but kens Patch removed the source: entry in line 39… that might have some impact…

EDIT: oops, sorry I’m obviously blind, it is there lower down…

It does process the setup.py, it just installs it to the wrong directory (in ~/.local/lib/python3.10/site-packages, not under the build dir).

EDIT: I’ll clarify, I mean the ~/.local inside the lxd container

It would be better to do a “snapcraft clean” in cases like that rather than using override-prime. Generally you shouldn’t end up in that state, but it’s always useful to do a clean to ensure your build is sane.

This is after a snapcraft clean, i reproduced it just now

FWIW I just checked out @kenvandine’s branch locally and was able to build it successfully with just snapcraft. What version of snapcraft are you using?

@Wazzaps ping, can you please provide the requested information?

Hi @Wazzaps - ping, this request cannot proceed without the requested information. Thanks.

Hey hey @Wazzaps, ping again. Can you please provide the requested information? thanks

Ok, finally got the time to look at this, sorry for the delay. Re-installing snapd and snapcraft fixed the issue, I’m in the process of building it for ARM64 as well and then i’ll publish the new GTK-based version. Thanks for the help!

OK, now both revisions (amd64 & arm64) are waiting for review.