feat: add graphics tablet support and fix Nix development shell

[dominicegginton]

Implement graphics tablet (digitizer) support via the wp_tablet_manager_v2 Wayland protocol, enabling high-definition pen input and stylus hover tracking on the infinite canvas.

• Initialize TabletManagerState on the compositor state and delegate the protocol.
• Track physical graphics tablet devices and register tools on hotplug.
• Project absolute tablet hardware coordinates to screen coordinates and convert them to absolute world space using the infinite canvas coordinate transforms.
• Forward high-definition stylus inputs (tilt, pressure, distance, rotation) to native tablet-aware clients like Krita or GIMP.
• Emulate standard pointer buttons and motion for non-tablet-aware legacy apps and server-side window title/border decorations.
• Correctly route stylus hover proximity enter/exit states.
• Clean up Nix devShell definition in flake.nix by inheriting inputs from the default package using inputsFrom = [...] to guarantee all dev-tools build correctly.
• Update user-facing and developer documentation with tablet configuration details.
• user configuration for mapping a graphics tablet input to output

see also: #118

[malbiruk]

@dominicegginton is this still on your radar? No pressure, tablet support is very much wanted (#118) and this draft is the closest thing to it, but it's been idle a few weeks and now conflicts with main. If you've run out of time, just say so and I'll close the draft while keeping #118 open for whoever picks it up -- the branch stays linked there either way.

[Shlubka]

Hi @malbiruk,

I saw your comment. I have a Wacom tablet built into my ThinkPad X1 Yoga and I'm very interested in getting this feature working (as I mentioned in #118).

If @dominicegginton is currently unavailable, I would be happy to help out. I have some Rust experience (junior level) and can offer my real hardware for testing.

I can pull this branch, resolve the merge conflicts with main, fix the cargo fmt and clippy CI issues, and test it thoroughly on my machine. If needed, I can open a new PR based on this work.

Let me know if you are open to this approach!

[malbiruk]

Thanks for the offer, @Shlubka

Dom's still on this: he confirmed in #118 he's cleaning the branch up this weekend, so I don't want to reassign it while he's active. The most useful thing right now is what he already invited: pull the pen branch, run it on your Wacom, and report back how pen/pressure/proximity behave on real hardware. That's gold regardless of who lands the code.

If it stalls after the weekend, let's revisit ✌️

[Shlubka]

@dominicegginton @malbiruk

I tested the pen branch on my laptop with Krita 5.2, Rnote (Flatpak), and wlr-randr. The tablet works impressively well overall! Pressure, distance, eraser, and side buttons are all functional. Thank you for this great work!

Here are the issues I noticed during ~30 min of testing:

1. Cursor offset: The pointer seems offset by a few pixels relative to the actual pen position. It's minor but noticeable. I can try to measure the offset precisely if needed. Possibly a coordinate transformation bug.

2. Click-through on window borders: When clicking on the window decoration (e.g., the close button), the click is passed to the window content instead of the decoration. This breaks window control via title bar/buttons.

3. Rotation not mapped: After rotating the display with wlr-randr --output eDP-1 --transform 90, the tablet input doesn't follow the rotation. The pen still moves in the original orientation.

4. Flatpak app issue: In Rnote (Flatpak), drawing produces a line made of small arrow shapes instead of a smooth stroke. This might be a protocol mismatch or flatpak-specific permissions issue.

5. Stylus button drag behaviour: The side buttons work (one toggles eraser in Krita, the other pans the canvas). However, if I drag to pan, lift the pen, move it quickly, and press again elsewhere, the canvas jumps instantly to the new location as if the button was held continuously. Possibly the button state is not cleared on proximity leave, or the buffer for events is too large.

6. Everything else (distance, pressure, hover) works perfectly.

I can provide RUST_LOG=debug logs for any of these issues if needed. Let me know what would help most.

Do you want me to run more extensive tests (e.g., multi-monitor, different apps, specific transforms)? I'm happy to help.

[dominicegginton]

@Shlubka thank you so much for the feedback. I'll take a look at ensuing I iron out bugs before also getting this into a reviewable state this weekend.

[malbiruk]

@Shlubka take this if you're still up for it -- it's still at its June 27 commit. Easiest path is a fresh PR from your fork with Dom's three commits rebased onto main; a rebase keeps his authorship as long as you don't squash them. @dominicegginton if you'd rather add Shlubka to your fork so this PR updates in place, even better -- say the word and we'll do that instead. Either way the commits stay yours and you're welcome back anytime.

Shlubka, after the rebase: regenerate docs/config.md (UPDATE_CONFIG_DOCS=1 cargo test docs_config_md_is_up_to_date), cargo fmt, and split out the unrelated flake.nix change. Then your five bugs, cursor offset and stuck stylus drag matter most.

[Shlubka]

@malbiruk @dominicegginton

I'm still here and very interested in taking this forward. I'll start working on the rebase and fixes this week and will open a fresh PR once it's ready.

Thanks for trusting me with this!