It’s of course true that it’s still not all ready yet though, and doesn’t always get the priority it should have. I too think that in a vacuum, Fedora’s move is too soon. Outside of that though, it does push people and projects to make things work much sooner than otherwise - even if it doesn’t come across as a very nice thing to do, this very thread is proof that it works
About making the transition smoother, proper display calibration (so not just applying the vcgt but the whole icc profile, and making it possible to just select that profile in system settings like you’d expect) is still something I should get done for Plasma 6.0. Actually creating the profiles is ofc the other half of the equation, getting more details on how that works or should work would be great.
I couldn’t ‘apply’ the profile, so I never knew if it was correctly generated. But I can test again if necessary: create a profile with DisplayCal on Wayland, then try to import it on the same machine to a X11 compositor able to apply the profile to check if the profile is correct.
I haven’t tried the dispcal command line (part of the argyllcms package), but I imagine it should work too: it just needs to communicate with the USB device, and display the area of colors.
Actually creating the profiles is ofc the other half of the equation, getting more details on how that works or should work would be great.
As a temporary solution, can’t “Plasma Color Management” page manages only the attribution/removal of profiles to connected devices, and when it comes to real calibration and generating new profiles it triggers an external tool like DisplayCAL, which seems to be under GPL license, and already provides those complex functionalities.
Screenshot of the Color settings on X11. Note: my settings are empty on this screenshot; I use the command line ‘dispwin’ part of argyllcms to apply my ICC profiles.
Yes, the existing tools can work - but they probably need some amount of integration, like for example ensuring that (at least for the part of the image that is used for calibration) the compositor doesn’t already use an existing icc profile or monitor EDID data to do color management (or have HDR enabled), which will invalidate the result.
I guess we could simply add a small explainer that you need to do that manually in the meantime though.
I guess we could simply add a small explainer that you need to do that manually in the meantime though.
It would be excellent to have a big button in toolbar at the same level of “Remove Profile” button, which has a clear text that means “Calibration via DisplayCAL”, and after clicking it will show a warning will those technical explanations to avoid any ambiguous result, then after accepting it launches DisplayCAL app.
The tablet config has gained some significant features since that screenshot, like area remapping and binding buttons to key combinations.
We’re not going to have 100% parity with the X11 in the near future, and not everything may even make sense to replicate. We appreciate input on what parts are important and should be prioritized
I want you all to understand something: I care about your needs. For the past several years, I have been primarily focusing on creative professional work in Fedora KDE. This has been primarily oriented around game development and A/V production, but I also care about regular digital artists too.
I want to address your concerns head-on, so here we go…
On color management: KDE Plasma Wayland contains basic color profile and color calibration support, based on the stuff that was available in X11. We have colord integration and some things work now. Much more advanced color management is coming once the new Wayland protocol is finalized and kwin has an implementation. If you want to know more about what’s going on here, there’s much more detail about it.
On configuring graphics tablets, I’m not sure what you mean. I own a Wacom Intuos M and it “just works” out of the box in Plasma Wayland. If there’s something you’re missing with the newer tablet configuration KCM, please file bugs about it. Nobody can do anything about it without more information.
On Krita, my admittedly very basic use as someone who dabbles in digital art seems work fine in Plasma Wayland using the version of Krita packaged in the Fedora repositories (5.1.5 on Fedora 39). My tablet works, including all the pressure levels and such. I didn’t even get any warning about running in Wayland like I’ve heard other people talk about. If there are in fact issues, please file bugs about it.
Please understand that none of us in the Fedora KDE SIG are trying to ignore artists. We, in fact, want artists to leverage the awesomeness of the Plasma Wayland experience to create even better artwork beyond the limits of what X11 allowed. We’re not fully there yet, but from what I have been able to tell, we’re mostly at parity with where things are with X11.
A big part of this Change discussion is shaking out the remaining issues to prioritize with the upstream KDE community. This has been a difficult discussion to have when people say “just switch back to X11”, and we need to be able to have a conversation about what we need to do to make that excuse go away.
I want to thank you for participating in this discussion and highlighting your concerns, and I hope I’m able to demonstrate that I’m not brushing them away and that I do want your needs to be addressed in the Plasma Wayland world.
Ok, here is a list of things I would need for a smooth transition from X11 to Wayland:
Button on the stylus, custom shortcuts. Being able to customise the keyboard shortcuts or actions on the buttons of the stylus. I use ‘Ctrl’ modifier to color-pick on the first button of the stylus, and often a right-click on the second button. (note: no idea if it is part of the recent GUI in the Settings, if it is included as part of ‘binding buttons’, cool!)
Keep proportions. Your tablet might be not the same ratio as the monitor or projector. (eg. a 4:3 tablet, but a 16:9 monitor). If some area remapping work is already done, this should be a low hanging fruit (the feature might be even already there). I assume because I read about the area mapping in your answer that applying the active area on a single monitor within a multi monitor setup is already done. No idea what happens on eg. a Ms Surface Pro 3 (2160 x 1440px , 3:2 ratio) when connected to clone an external projector for a demo (1080p 16:9 ratio) and the 1080p appear letterboxed on the device, but the full area of the tablet is still mapped to the full surface of the device. In this case, mapping is essential.
Set the Suppress and RawSample value of the device. Tablets are not delivering the same flow of datas as their output. Some are really spammy, while other already curate the chain of events at the hardware level. Some even have a built-in smoothing of events. On GNU/Linux, some arbitrary trimming/filtering of event is applied by default ( 2 Suppress; filtering ‘half’, and 4 RawSample, trimming a lot). The purpose of this setting was not weight on the CPU of older devices with a stylus and a display (eg. to sign document for buisnessmen). This way, the cursor on this hardware doesn’t lag. But with suppressed and trimmed event, it lowers the quality of lines by default for artists. And on device with already not a lot of events, it makes a huge difference to turn Suppress to 0 and RawSample to 1. The X11 GUI has two sliders for that.
Pressure curve for styluses. The spring built-in the tip of the stylus and the way it returns data is never linear. You’ll never get a proportional ratio between the pressure you put with your hand, and a 0% pressure and 100% pressure returned by the device. It also get mechanically used in time being less and less sensitive. That’s why being able to set a hard or soft curve here (and not a slider, please) with the entry point of pressure, and the maximum of pressure is necessary. Right now I manage that with a xsetwacom Bash script, using this to get the coordinates.
Digimend. I’m using right now a XPPen Artist Pro 24, to make it work, I need to install a kernel module named Digimend. Then I have to add a X11 rules so I can setup the tablet with the xsetwacom command line. I have no idea how the KDE Setting GUI and Wayland will handle this tablet. But if it can’t, you can imagine what type of regression I’ll face.
Calibrating/Parralax solving. Some display tablet have a big distance between the glass and the cursor under the stylus. It produce a parralax situation, especially when moving cursor on the edges. A classic GUI is a four point click on the monitor to auto-recalculate the deformation.
Things I don’t need (but other might):
The multiple Setting profiles: I usually keep a single layout and configuration for a tablet. So, I’m not into the creation of multiple profile for my device, and switching between them.
Stylus relative mode: Impossible to draw this way, it’s a stylus, not a mouse. I never used this mode, only absolute mode.
Action on button to switch monitors: In a multiple monitor setup, I usually map the tablet to a monitor (the built-in, or an external) and rarely expect to get a button on the tablet to switch between the mapping of my monitors.
My understanding is that this is actually a backport project from Linux mainline. Fedora already ships the latest upstream kernels, so this should not be needed.
Thanks for such a detailed list! I filed this away, as it’s really useful.
However, #1 is already done as of some recent Plasma versions. It however, depends on how the tablet driver is implemented.
Edit: I just remembered, but I think you can’t bind it to mouse buttons yet. I think that’s a more general KDE hotkey issue though
#2 I think is done as well, but I’m not too familiar with the current tablet KCM config. I also only have 16:9 monitors to test with.
#3, #4, #6 are essential though and still missing from the interface. For pressure curves: I wonder if artists can use the pressure curve config in their art program like Krita as a workaround. I barely touch my pressure curves, so I don’t know if there’s some disadvantage to doing it that way.
#5 I don’t know if you know this, but I run the 22" version of that tablet and actually worked on getting it upstreamed in Linux. It works with Wayland, the new tablet config (and can even configure it’s many buttons). I still need to pick back up that project
Yes, I’m on the list of participants and follow this carefully already even if this issue was created 3 years ago. Real question here: will it be ready on Fedora KDE 40 or will I have to move temporary of distro and comeback for 41 or 42?
Good, I made a list just before this comment. Should I copy/paste each item on https://bugs.kde.org ?
[edit: I read while typing this the answer of @redstrate thanks for filing it! I’ll answer your post more detailed after, thanks again].
Honnestly, I sort of feel the layer: stronger input lags (or display lag?) It is subjective (or nocebo effect) but maybe I can capture that with high camera speed? When you sketch gesture quickly, something is off, I can’t describe. ‘A layer’ In the past, I had a good nose at detecting this type of micro-lag on Krita. I can research about it, but tiiiiimmmme. Difficult to find a full afternoon to run this, even if it is very interesting.
I have also focus glitches, issue with all interaction with outside of the app like the global color pickers or drag and drops (but this was long ago, not on my May recent test, maybe it is solved by now). In overall, it’s not bad; the app runs, but we are in a Krita Alpha territory here. I wouldn’t trust for the full production of a Pepper&Carrot episode to be honest (again, subjective here).
If Krita teams agree to debug X11-on-Wayland specific bugs, I’m all for starting to investigate and report. If Krita team decides it will wait Krita Qt6; then it will be difficult to do progress here before April.
I believe you, your experience and your POV.
But I have another POV, where the distance between X11 and Wayland is still a giant gap for digital painting at a professional level. I think it depends of the point of view, and for a metric, I would advice feedback from digital artist in this thread like @anon88800485 and @redstrate , or on Krita community and devs, like Halla, Tyson Tan and Wolthera who can understand the requirement of professional digital painting at a deeper level.
I know that is what you are doing right now by listening to my feedback. Thank you about it.
I want to thank you too for creating a profile here only to reply to my message. I sincerly feel honored (this is not a sarcasm, I mean it). I’m sure you are not brushing the issue, I’m convinced by your sincerity.
Oh yes I know! I follow your work on Mastodon and I envy your ability to dev!
Skill like you have on both digital painting and code is a bless in this community.
I feel lucky that our hardware is in the same family of devices, and thank you for the good news about it!
When I switch from my workstation to my mobile Thinkpad 370 (or my Purism Librem 13 with a tablet attached to it), they all have styluses with very different built-in pressure curves. But I try to calibrate them so I have the same feeling for my hand in final.
Because I sync my Krita preferences before travel, it would sync the same brush curves on all of them if I setup their curve at a Krita setting level. That’s why I prefer to set them with their own pressure curve at a Operating System level. So I can avoid that, and also get my pressure sensitivity right when I use Blender Grease Pencil and Mypaint (even if I launch them rarely I admit ).
My understanding, based on reading some xf86-input-wacom code, is that this filtering is done by xf86-input-wacom, i.e. the X11-part of the driver. That would imply that as of right now on Wayland one always gets unfiltered/unsuppressed events. (as far as I understand, I haven’t tested/compared anything).
Would it still be interesting to add filtering to that?
In my opinion − and I’m very biased from my artist POV − I would say unfiltered and untrimed is superior. It is up to the (digital painting) software to filter event, smooth them, trim them, etc… (eg. with a stabilizer, or simply by curating the events).
But when I switch POV to someone with an old laptop with a built-in display and stylus, they might just want their cursor to not lag when they need to sign a document with the stylus. I feel trimming and filtering was added for their use case, you know, the type of administrative agents who use Linux in some institutions. But this is totally my imagination here. I’m not competent at all to take a responsability at a wide level on all user this way based on my feeling.
The tablet config is great but it is not fully featured and misses some important things.
What we have now is only half the funcitonality we can map a portion the area of the screen to all the area of the tablet and nice vice versa. This ignores some use cases and mainly @David_Revoy’s where he uses a large tablet and maps small portion of it to entire screen. When the first implementation was done by Apol for the tablet config I had already tested and reported this last year here is the bug report - 457703 – Feature to to map an area on the tablet surface to the entire screen
The main elephant in the room is generating colour profiles through calibration device. I use displaycal Is that possible in wayland? will the generated profile be correct? Since there is no protocol yet I think this will take time. I will test and report to displaycal there are already some reports like this
You are lucky to have a tablet that doesn’t need configuration. I have added my bug reports in this thread.
I will test this some more, since there is no colour management, prepress work or any work which requires colour acuracy goes out of the window. I do not know if xwayland apps are colour managed. I hang around krita IRC and I know that wayland will be tackled and I have hopes for it to get good support on wayland.
And thanks for responding and also sorry if you found my reaction rude or abrupt or shocking it is intended that way like how fedora wants to push through.
).
