I wasn't sure what component to pick, please feel free to move this bug into the right place. I could not find this bug to be reported before. SUMMARY When running krita with "-platform wayland" seems to require xwayland to be enabled for start up. I have tested this on sway. STEPS TO REPRODUCE 1. Disable xwayland in your wayland compositor. 2. run `krita -platform wayland` OBSERVED RESULT qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb. zsh: abort (core dumped) krita -platform wayland EXPECTED RESULT krita to start up. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux Qt Version: 5.15.1-3 Krita: 4.4.1-1 sway: 1:1.5.1-1 wlroots: 0.12.0-1 ADDITIONAL INFORMATION Krita starts up fine when xwayland is enabled and as far as i can tell all windows are running natively under wayland. It just seems to need xwayland for startup.
Sorry... But why would this be a bug? Wayland falls in the "later, when someone steps up and adds support for drawing tablets to Qt's Wayland plugin" category for us.
(In reply to Boudewijn Rempt from comment #1) > Sorry... But why would this be a bug? Wayland falls in the "later, when > someone steps up and adds support for drawing tablets to Qt's Wayland > plugin" category for us. Fair enough. I could not find that information in the documentation, so i figured it would be a bug. Feel free to close it if you don't consider it to be a bug.
We try to document what Krita supports, not what it doesn't support.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
(In reply to Boudewijn Rempt from comment #1) > Sorry... But why would this be a bug? Wayland falls in the "later, when > someone steps up and adds support for drawing tablets to Qt's Wayland > plugin" category for us. Boudewijn, I'm interested learning more about what needs to be done to get "support for drawing tablets to Qt's Wayland plugin". I don't know that I'm up to it, but I think this would be very beneficial for Krita and other tablet-based apps. I experience quite a bit of lag using my own Wacom tablet because of the X11/Wayland issues. I am `dcunit3d` on IRC.
I would need to do a bit of research, because there are quite a few parts involved: not just the Qt wayland platform plugin needs to get tablet support, but kwin needs that too, and while gnome apparently supports tablets in mutter and gtk3/wayland, one needs to investigate whether the protocol can be reused. So: * first https://github.com/wayland-project/wayland-protocols/tree/master/unstable/tablet -- that's the tablet protocol, but it's not really finished, as far as I know * Qt's wayland platform plugin * Kwin and maybe other window managers that support wayland... * Krita then needs to get rid of its explicit dependency on xcb
(In reply to Boudewijn Rempt from comment #6) > I would need to do a bit of research... Duly noted. Thanks, Boudewijn. This would help performance for me, but it looks like it's quite far away. I will explore the projects you've mentioned. If nothing else, when the first piece in wayland-protocols is done, this would hopefully drive progress in the middle layers.
*** Bug 430426 has been marked as a duplicate of this bug. ***
Git commit ac9a2a12e00e61e4a4d4702c3078e91e80a365d5 by Boudewijn Rempt. Committed on 15/12/2020 at 14:01. Pushed by rempt into branch 'master'. Warn the user when trying to run Krita on Wayland We don't support the wayland platform plugin until it has tablet support and color management support. Related: bug 430426 M +6 -0 krita/main.cc https://invent.kde.org/graphics/krita/commit/ac9a2a12e00e61e4a4d4702c3078e91e80a365d5
Git commit de17b3af87c3520b98b48d8a58d36c2f0469490e by Boudewijn Rempt. Committed on 15/12/2020 at 14:11. Pushed by rempt into branch 'krita/4.4.2'. Warn the user when trying to run Krita on Wayland We don't support the wayland platform plugin until it has tablet support and color management support. Related: bug 430426 (cherry picked from commit ac9a2a12e00e61e4a4d4702c3078e91e80a365d5) M +6 -0 krita/main.cc https://invent.kde.org/graphics/krita/commit/de17b3af87c3520b98b48d8a58d36c2f0469490e
Git commit 75f597455fa587278c2108cfbfbe3f9075d3a59e by Boudewijn Rempt. Committed on 15/12/2020 at 14:12. Pushed by rempt into branch 'krita/4.3'. Warn the user when trying to run Krita on Wayland We don't support the wayland platform plugin until it has tablet support and color management support. Related: bug 430426 (cherry picked from commit ac9a2a12e00e61e4a4d4702c3078e91e80a365d5) M +6 -0 krita/main.cc https://invent.kde.org/graphics/krita/commit/75f597455fa587278c2108cfbfbe3f9075d3a59e
Hi, just wanted to report that krita works fine in a pure wayland setup (Sway) so the limitation with `-platform=wayland` looks quite wrong now. Launched it with QT_QPA_PLATFORM=wayland-egl, which seems to be what the original reporter lacked.
(In reply to Haelwenn (lanodan) Monnier from comment #12) > Hi, just wanted to report that krita works fine in a pure wayland setup > (Sway) so the limitation with `-platform=wayland` looks quite wrong now. > > Launched it with QT_QPA_PLATFORM=wayland-egl, which seems to be what the > original reporter lacked. Have you disabled xwayland? I initially thought it works in pure wayland, but once you disable xwayland it does not start.
Krita links to the X11 libraries and uses functionality from them, so without xwayland, krita cannot work. We'll start working on wayland once basic things like tablet support and color management in Wayland are ready.
(In reply to David Plassmann from comment #13) > (In reply to Haelwenn (lanodan) Monnier from comment #12) > > Hi, just wanted to report that krita works fine in a pure wayland setup > > (Sway) so the limitation with `-platform=wayland` looks quite wrong now. > > > > Launched it with QT_QPA_PLATFORM=wayland-egl, which seems to be what the > > original reporter lacked. > > Have you disabled xwayland? I initially thought it works in pure wayland, > but once you disable xwayland it does not start. Machine where I tested it doesn't have X11 at all.[1] I removed QtX11extras from two CMakeLists.txt files for building it without any X11 but I thing it otherwise should just work with X11 present (going to try on another machine). Will upstream my changes for X11-less Wayland if I get it working properly with X11 being present as well. 1: https://hacktivis.me/notes/pure-wayland
Also tablet support works, I don't know where the code for it is but it hooks up properly to the tablet protocol of wayland (as seen with WAYLAND_DEBUG=1), tested with a "Wacom Co., Ltd CTL-470". Positioning, Pen, Pressure, … are working. Not sure how to test for color management but maybe this is more something that Krita's rendering has to manage rather than the wayland compositor
(In reply to Haelwenn (lanodan) Monnier from comment #16) > Also tablet support works, I don't know where the code for it is but it > hooks up properly to the tablet protocol of wayland (as seen with > WAYLAND_DEBUG=1), tested with a "Wacom Co., Ltd CTL-470". > Positioning, Pen, Pressure, … are working. > > Not sure how to test for color management but maybe this is more something > that Krita's rendering has to manage rather than the wayland compositor No, as far as we understand the Wayland philosophy, the last part of the color management has to be handled by the compositor. There's a protocol being worked on here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14 https://gitlab.freedesktop.org/swick/wayland-protocols/-/blob/color/unstable/color-management/color.rst The textbook problem comes with multiple monitors which each have their own colorspace characteristics. For example, a fancy wide gamut monitor and a simple srgb monitor. Krita then needs to know whether the canvas is on screen 1 or 2 to be able to convert the image colors to the display colors. Wayland's big deal with monitor information is that it doesn't think programs should know where on the monitor they are. So then, the final conversion from image to display color needs to be done by Wayland if such multi monitor setups are to work correctly. I hope this makes sense. As for the tablet stuff, I got the impression we were using libinput via Qt, and libinput has wayland support, but I am hardly an expert on wayland.
Linuxwacom developer reporting in with some clarification on the status of tablet support in Wayland. The "tablet_unstable_v2" protocol that was linked above is pretty much unstable only in name at this point*. XWayland, GNOME, and wlroots (Sway, etc.) have supported the compositor half of the protocol for a few years now. Basic support landed in the KWin compositor in mid-2020 as part of their 5.19 release and then extended for the early-2021 release of 5.21. On the toolkit obviously GTK3 has supported it for some time, but more interesting is "basic support" in Qt 5.15 (see https://github.com/qt/qtwayland/commit/222455cd643c128fa9730c9c527a7fdcadd0acfe for specifics). All the upstream pieces should be in place for tablets to work with Krita in Wayland. Note, however, that it may be buggy even if you can get it working somehow. The KWin/Qt Wayland tablet code has had very little real-world use at this point and there are bound to be little problems that get discovered as more people are able to test them out. * Transitioning a protocol from "unstable" to "stable" is an API break that requires all compositors / toolkits to update. Its a lot of effort for basically zero benefit. Wayland-protocols recently replaced "unstable" with "staging" to fix this issue for new protocols, but there are lots of "stable unstable" protocols like ours that may never migrate into the "stable" directory.
We cannot move to Qt 5.15 at this point because there are too many regressions, so this will have to wait until we port to Qt6.