Feature request/brainstorming: Drawing tablet support

[leviport]

This was mentioned in https://github.com/pop-os/cosmic-settings/issues/8, but I wanted to break this out specifically so as to not overwhelm that design thread with something that's not planned for the alpha.

I figured that since I had my arm tied to one of these things for a decade while working my way through college in graphic design, I could share my thoughts about configurable features, current Gnome support, and what support in COSMIC DE might look like. There are many brands of tablets, but Wacom is definitely the big dog, so starting with Wacom support seems sensible to me.

Features:

(Listed, in my estimation, from most important to least important.)

• Mapping tablet to displays: Need to be able to map the tablet to a specific display. In my experience, it's not typical for multi-display setups to have the tablet mapped to the whole array of displays.

• Letterboxing / force aspect ratio mapping to display(s): The aspect ratio of a display (or group of displays) rarely matches the aspect ratio of a tablet. An ultrawide, for example, would have much faster cursor movement from side to side, than it would top to bottom. If I force letterbox with this display, a region of the tablet will be unmapped, and only a region with an aspect ratio that matches that of the display will be used. * Note: For some reason, letterboxing is not allowed in Gnome unless the tablet is mapped to one specific display. Mapping to a single display is the most common use case anyway, so this limitation probably doesn't affect very many users.

• Left handed mode: Many tablets have their buttons on one side of the drawing area. For lefties, that means their hand would rest on them while they draw. Left handed mode rotates the tablet's mapping by 180° so that the physical tablet can be rotated, putting the buttons on the right side instead of on the left.

• Pen pressure feel: Usually a slider from "soft" to "firm". Pens with "erasers" on the back usually have a second slide for the eraser as well.

• Stylus button mapping: Most styli have 2 buttons on them. Since left click is done by touching the stylus to the tablet, usually one of these is right click by default, and the second is frequently customized based off the user's workflow. 3D workflows often change it to middle click, and a digital painter may want it bound to Ctrl + Z, or a hotkey that summons a quick access menu for a particular application. As a stretch component to this item, some configurators support multiple profiles for individual applications. So if I want certain bindings in Blender and completely different bindings in Krita, the application I currently have focused is detected, and the bindings are adjusted accordingly.

• Tablet button mapping: These tablets usually have buttons, sliders, or dials, which the user can remap to send certain commands or key combos. The dial either repeats a key combo, or is bound to a scroll, zoom, or rotate action. When properly set up, the user won't have to reach for their keyboard, which is otherwise competing with the tablet for desk space.

• Tracking mode: There are two different tracking modes. Absolute/tablet tracking makes the position of the cursor on the screen correspond with the position of the pen on the tablet. If the pen is picked up and moved to a different location, the cursor snaps to that location. Relative/mouse tracking does not snap the cursor to a new position if the pen is picked up and moved, but movements do move the cursor, much like how picking up up an optical mouse off the desk and setting it in a different location on the desk should not change the cursor's position. In my opinion, relative tracking is simply and objectively the wrong way to use a tablet, but some people probably prefer it for some reason.

• Test your settings: Most of the configuration tools I've seen have a small rectangular area that the user can draw black lines so they can test their pressure settings.

• Move and resize the mapped region on the tablet: This is one that Gnome Control Center does not have, but one I remember from Wacom's customizer from Windows. The active region on a tablet should be resizeable and moved to any position on the drawing area of the tablet. This somewhat ties into letterboxing, but it's much less important, so I made it into its own item down here.

• LED settings: These tablets sometimes have customizable LEDs on them. The Intuos4 tablets even have little OLED displays next to the buttons. Being able to configure LEDs and mini OLED displays would be a very nice feature, but definitely a low priority.

[leviport]

A tour of the Wacom configuration utility in Gnome Control Center

The "Wacom Tablet" panel does not appear unless a Wacom tablet is detected. Once it is, it looks like this:

The "stylus" and "tablet" sections are separate from each other, but I'm not entirely sure they need to be.

The Stylus section is pretty simple. You can remap each button, and change the pressure of the nib and of the eraser (if present). It would be nice to be able to map custom key combos to the stylus buttons as well, but that functionality is not present:

The "Test Your Settings" button in the top bar shows this little drawing area that I can use to test my settings:

The Tablet section looks like this:

Tracking mode can be set to either "Tablet (absolute)" which is correct, or the inferior "Touchpad (relative)" mode.

Left handed mode is a simple toggle.

I had trouble screenshotting the Map Buttons... dialog, so here is a cell phone picture of my screen:

The layout corresponds to the physical layout of the tablet:

In this dialog, you press one of the buttons or spin the dial on your tablet, then it allows you to customize it:

And finally, the Map to Monitor dialog:

As mentioned before, the "Keep aspect ratio (letterbox)" switch becomes inactive if the tablet is not mapped to a single monitor.

[billksun]

In my opinion, relative tracking is simply and objectively the wrong way to use a tablet, but some people probably prefer it for some reason.

It's perhaps the wrong way to draw with a tablet, but relative tracking mode is definitely a requirement be able to use a tablet as a general purpose pointing device. I have been suffering from wrist pains for years now, and have just recently purchased Wacom Intuos Pro S as a replacement for my mouse that's causing much of the pain. So, please hear me out on this different use case.

I am software engineer and also a gamer, and while absolute mode is just fine for desktop usage, gaming is a no-go. There's no way around it. In my research for a mouse replacement for both gaming and coding, I found that a drawing tablet not only can alleviate wrist pain, but also has the potential to have even more precision than a gaming mouse. However, in games like FPS or any game that uses the pointing device to pan or turn the viewport, this can only be done in relative mode.

Relative mode might also work better with multi-display setups as a general mouse replacement. You can have displays of different sizes/resolutions/orientations and you don't have to worry about how that gets mapped to the tablet, possibly creating an awkwardly shaped active area, or if you have a smaller tablet, forced to use tablet in a higher sensitivity than desired.

Another configuration option that I feel should go with the relative mode implementation is the hover/proximity distance of the pen. You will be picking up the pen a lot when "mousing" around using relative mode, and being able to configure a comfortable lift height is absolutely crucial to long-term usage comfort.

A bonus option that would help with general desktop usage is having more options in the orientation of the tablet, similar to what OpenTabletDriver's "rotation" feature. Although I don't know how useful it is to have such fine grained rotation control, but I can definitely see the usefulness of having 90 degree increments, allowing you to place the tablet in landscape or portrait orientations. This gives users more options to optimally place their tablets amongst the other peripherals on their desktops.

[leviport]

I was being a bit cheeky with my remarks about relative mode. If I was seriously saying it shouldn't be included, I wouldn't have listed it in my feature list. Although I will say that I find the notion of gaming with a drawing tablet to be highly amusing. I might need to try it some time, just to see what it's like.

Another configuration option that I feel should go with the relative mode implementation is the hover/proximity distance of the pen.

I'm not sure this is something that is configurable in any tablet settings applications. I think EMR tablets can only sense whether the pen is present or not. If I'm wrong and it does receive information about the distance of the pen, I do think that would be a good setting to include.

[billksun]

In regards to hover height, according to this screen capture of the Wacom's settings software in Windows from a KDE Plasma PR comment, this is configurable (the "mouse height" setting, when "mouse mode" is selected):

From COSMIC's perspective, this will likely be configured through libinput's proximity events. OpenTabletDriver implements this via the Hover_Distance_Limiter plugin.

Sorry for over-reacting about relative mode. I guess it's just that important for me, because the alternative would be to give up some of my favorite game genres, which I really don't want to :sweat:.

I currently use OpenTabletDriver just for my gaming needs and switch back to KDE Plasma's default tablet support for regular desktop use. This is because OpenTabletDriver does not handle any touch events from tablets, but I use my Wacom tablet as a trackpad when not gaming (multi-touch gestures really does improve desktop productivity!). I'm hoping COSMIC's solution would make this back-and-forth switch obsolete!

That being said, OpenTabletDriver has an option that I find very useful for gaming that I neglected to mention in my previous comment. In OpenTabletDriver, you can set a "Tip Threshold" for the left mouse button activation: This allows my pen tip to be in contact with the pad while not triggering a click event until I press harder into the pad. I find this to improve my precision in shooting games because of the slight friction when I drag the pen across the pad, and it minimizes the "shake" when pressing down on the pad. Without this, I would have to be hovering before pressing down, and I find it hard to maintain the pointer position while doing that.

[kekkoudesu]

This is a great overview of desirable features for a Drawing Tablet settings panel! I would definitely be impressed by it.

Just for the sake of comparison, here's KDE Plasma's Graphics Tablet settings: https://www.davidrevoy.com/data/images/blog/2024/debian-kde/2024-05-30_02_Tablet-Wayland-versus-X11.jpg

(It's a part of this article)

[Karvie0]

I'm not a developer, but I can give my two cents as an artist. Both GNOME and Plasma have their shortcomings in this area, though GNOME is better than Plasma. Plasma's menu is too complicated, so people may be more inclined to ignore most of the settings, including ones they may have found useful if they were easier to understand. GNOME's settings are good, but they lean a bit too minimalistic IMO, and they don't need to be so separate.

I made a mockup of how the settings mentioned in the previous discussion could be presented nicely to the user. This isn't meant to be a suggestion for what the final menu should look like. This is just the clearest way to convey some ideas that I think are important to keep in mind.

There are a few main ideas here.

• It'd be nice to have the buttons laid out in the menu as they are on the physical tablet, so you can click on the button you want to change. Same Idea for the pen side buttons, and the eraser.
• It may also be nice to start editing a macro when you press the corresponding physical button on the tablet, so you don't have to click the menu.
• Selecting an app at the top would let you set custom macros for that app.
• The plus button to the right of the apps should show a list of open apps, or let you click on an open window to select an app.
• Having a curve adjustment for pen pressure is the best way to go (based on personal experience).
• The soft vs hard slider would be a faster way to adjust the pressure curve if you don't care about the detail so much.
• I've put the pen settings higher than the display settings because they would be adjusted more often.

I'd also like to point out that the mockup isn't complete. It's missing some things, like a "default" option in the app select, pen height adjustment for mouse mode, and calibration for screen tablets. It may also be good to replace the "tip threshold" idea with libinput's custom pressure range. This could be presented as a slider with two control points.

[abishekmuthian]

My Intuos CTH-480 tablet gets detected along with the pen but only tablet in touch mode works and not the pen. AFAIK wacom tablets work OOB in Fedora and Wayland with libinput, I'm not sure what needs to be done to make the pen work. Any advice would be appreciated.

-event18  DEVICE_ADDED            Wacom Intuos PT S Pen             seat0 default group5  cap:T  size 152x95mm
-event19  DEVICE_ADDED            Wacom Intuos PT S Finger          seat0 default group5  cap:pg  size 152x95mm tap(dl off) left scroll-nat scroll-2fg-edge
-event20  DEVICE_ADDED            Wacom Intuos PT S Pad             seat0 default group5  cap:P buttons:4 strips:0 rings:0 mode groups:1

P.S. I'm not sure whether this is the right place to ask about wacom pen but issue on wacom support in cosmic-epoch repo was closed - https://github.com/pop-os/cosmic-epoch/issues/591

[Karvie0]

AFAIK wacom tablets work OOB in Fedora and Wayland with libinput, I'm not sure what needs to be done to make the pen work. Any advice would be appreciated.

libinput is a library that lives inside the wayland compositor. Other areas of the compositor still have to handle all the information from libinput to send it to applications. There's also a lot of info from libinput that isn't meant to be sent to applications, but is instead meant to inform the compositor about how some things should be done (e.g., button mapping info), as well as some functions that allow the compositor to offload some transformations to libinput, such as for left-handed mode, or for custom pressure ranges.

TLDR; libinput provides hardware input info that the compositor still has to handle.

For now, it looks like you may be able to use OpenTabletDriver, as mentiond in https://github.com/pop-os/cosmic-comp/issues/313

[senntore]

Will this be implemented in Alpha 2?

[leviport]

No. New alphas are basically just spinning and releasing new ISOs. If you're on a 24.04 install (or 22.04 with COSMIC DE installed), the latest updates are released daily, and you will be receiving them as soon as they are released.

[SleepingCrows]

For now, it looks like you may be able to use OpenTabletDriver, as mentiond in

Unfortunately OTD isn't a silver bullet for all tablets, Huion tablet support has a lot of gaps and work to do, and the first party drivers already have spotty Wayland support as is.

[arkonbob]

For now, it looks like you may be able to use OpenTabletDriver, as mentiond in

Unfortunately OTD isn't a silver bullet for all tablets, Huion tablet support has a lot of gaps and work to do, and the first party drivers already have spotty Wayland support as is.

Yes - for myself (Wacom Intuos Pro M pth-651) the situation has improved since I last looked, touch is now supported although the wheel remains broken (tbh I never use the wheel anyway). For others however, there are still a lot of gaps in support:

https://opentabletdriver.net/Tablets

[billksun]

touch is now supported

@arkonbob, how did you get touch to work?

[arkonbob]

@billksun I mean that touch is now supported for my tablet in Open Tablet Driver. I haven't confirmed this myself, I'm just going by the information in the repo (see the link I posted). Previously touch support was listed as broken there for the Intuos Pro M.

[senntore]

I don't want to rely on opentabletdriver even for Wacom tablets, as it is very clunky to use. If I enable pen pressure using linux artist mode then certain buttons in the pen would not work like their default behavior. Which makes it unusable to me. I hope we can have something similar to gnome's implementation as it works great out of the box.

[senntore]

Since this issue is being used to track tablet support, I would like to mention the issues currently present in COSMIC for rudimentary support.

• [ ] When we click on a window with the pen, the focus(& active hint) does not switch to that window. Because of this we cannot use keyboard shortcuts of the application used by pen unless we manually switch the focus using keyboard, mouse or touchpad.

• [ ] Pen input does not work on any libcosmic related stuff like cosmic-panel, applibrary, launcher, dock & other cosmic applications. It works nicely on non-cosmic applications like Krita & Blender with pen pressure & everything.