Summary: | Feature to set raw sample rate and raw suppress rate for graphic tablets | ||
---|---|---|---|
Product: | [Applications] systemsettings | Reporter: | Raghavendra kamath <raghu> |
Component: | kcm_tablet | Assignee: | Plasma Bugs List <plasma-bugs-null> |
Status: | RESOLVED UPSTREAM | ||
Severity: | wishlist | CC: | aleixpol, info, josh, natalie_clarius, nate, nicolas.fella |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
URL: | https://gitlab.freedesktop.org/libinput/libinput/-/issues/225 | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Raghavendra kamath
2023-11-30 05:38:16 UTC
It is a wishlist item since it's a new requested feature in the Drawing Tablet KCM. The Wacomtablet KCM may already have the feature, but it needs to be written for the Drawing Tablet KCM too. If I may ask what is the difference between "normal" and "wishlist"? I already explained it in another bug report where you asked similar things today, and also in the comment above. If it's still not clear, see https://community.kde.org/index.php?title=Guidelines_and_HOWTOs/Bug_triaging#Set_the_Severity_field. Unlike on X11 there is no suppression of events by default on Wayland, the application always receives all incoming events. What's the use case for artificially suppressing events? Hi, As for the use case, consider a device like a Ms Surface Pro 3, or an old Tablet PC. Sometimes these types of devices have a fairly high resolution digitiser, but a slow way of processing all the events of the tablet (could be the input connection in the device, or a slow CPU, not sure). In any case, the result is a visible lag, which can be seen in the distance between the moving cursor and the actual pen tip. This sometimes happens when all the events are sent to the screen for rendering, and it feels like a "hardware event bottleneck". Some paint programs can also be slow to render brush strokes. In this case, event suppression (trimming or filtering/removing duplicates) may be useful to improve performance. Personally, I always keep them to a minimum with xsetwacom because I have good hardware on my main workstation and I prefer to get the most coordinate/event out of my digitizers: xsetwacom --set "$tabletstylus" Suppress 0 # data pt.s filtered, default is 2, 0-100 (old 4) xsetwacom --set "$tabletstylus" RawSample 1 # data pt.s trimmed, default is 4, 1-20 (old 1) I only increased these values a little on my old laptop or my Surface Pro 3. The gain is not dramatic as far as I can tell; and if you set a higher value than the default of X11 (4 Rawsample and 2 Suppress), I remember that you quickly damage the quality of the brush stroke (visible segment between coordinates when drawing fast large spirals on the canvas). Here is a personal opinion about terms like "Suppress" and "RawSample": I found them hard to understand. Just an idea, but in case of a GUI I would prefer something simpler like a single slider with 5 positions (or 3?) from Quality (=no even suppression) to Performance (=many). Eg: Performance Quality |------|------|------|------[] Suppress and sample can be used to reduce too much sensitivity for some people this helps in reducing small the wiggle in line. It averages the data to give a smoother points. This is decided upstream (see https://gitlab.freedesktop.org/libinput/libinput/-/issues/225) and there's nothing we can do until the libinput maintainers accept having an option to disable smoothing explicitly. To break down the situation: libinput performs *some* smoothing depending on the pen type. For AES pens they disable smoothing automatically for example (https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/512) and they are adding devices explicitly to the no-smoothing list as users report them. In the future if Peter decides maybe that's too much, and adds an API for it we can re-open this. But currently there's nothing we can do. |