Krita 4.0.0 (and sometimes the entire X system) crashes / hang when using a Wacom Cintiq Touch display. Context: My system is: Kubuntu 16.04 running on an 8 core AMD FX8350 processor, 16GB RAM and Nvidia GeForce GTX 1050 (details at the end) I have two fixed monitors (Philips and Samsung) and a Wacom Cintiq 27QHD Touch display connected to the GPU DisplayPort connector, that I switch on only when working with krita. It gets configured as the third monitor, at the far right. IMPORTANT: Krita 3.3.3 (appimage) works absolutely normally without any of the problems below described for Krita 4.0.0, either in KDE, in Xfce or in Enlightenment 0.22.2. Sequence, description of, and how the failure is triggered: (See below "Additional context information" for further pre-existing conditions) 1. Disable gesture issuing a `xsetwacom` command (see how and why below) so that fingers touching the screen won't paint. 2. Open krita 4.0.0 and create a new document. At this point: a) If in KDE: Fingers don't paint (OK) BUT also gestures are ignored (WRONG), namely the zooming or panning gestures don't work. Expected behaviour: fingers won't paint and gestures work (as in v3.3.x). Attempting at this point to change any Wacom configuration regarding touching, e.g. finger touch gesture on/off again will crash/hang Krita (it gets totally irresponsive) and sometimes the X system also (all input to X is ignored, including keyboard) and only solution is restart the system. Also, attempting to use Krita painting and zooming, rotating, at some point it crashes/hangs as explained. I could not figured out exactly what would crash it so badly, it's very annoying troubleshooting something this bad. So I changed to Xfce: b) If in Xfce: Fingers don't paint (OK) AND zooming and panning gestures do work (OK), as expected. BUT: open the pop-up palette and do some rotate of the canvas, using a finger to control the rotating slider. Click back on the document with the finger and now, bizarrely, the touch with the finger does PAINT and gestures are not recognized (the opposite to expected behaviours). Keep painting with the fingers. Bring back again the pop-up palette and try to rotate again the document using a finger, and the whole X system crash badly like described above. So I changed to Enlightenment: c) If in Enlightenment: Launching Krita4 with a desktop launcher doesn't work: there is an generic error from Enlightenment: "Krita stopped running unexpectedly. There was no error message". However, Krita appimage works if launched from the terminal: $ ./krita-4.0.0-x86_64.appimage The program launches. After creating a document: Fingers don't paint (OK) AND zooming and panning gestures do work (OK). HOWEVER: open the pop-up palette and do some rotate of the canvas, using a finger to control the rotating slider. Click back on the document with a finger and notice that it generates a stroke and gestures are not recognized (both unexpected wrong behaviours). Keep painting with the fingers. Bring back again the pop-up palette and try to rotate again the document using a finger, and Krita hangs badly as described above. The X system doesn't crash. These errors are displayed on the console after others (I will provide full listing if requested): krita.general: Could not find font QVariant(QString, "Source Sans Pro") with style QVariant(QString, "Light") krita.general: Could not find font QVariant(QString, "Source Sans Pro") with style QVariant(QString, "Regular") file:///tmp/.mount_krita-RfVPUL/usr/lib/qml/org/krita/sketch/components/Button.qml:84:9: QML Image: Failed to get image from provider: image://icon/opacity-decrease krita.input: KisAbstractInputAction "Zoom Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) krita.input: KisAbstractInputAction "Zoom Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) krita.input: KisAbstractInputAction "Pan Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) krita.input: KisAbstractInputAction "Zoom Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) krita.input: KisAbstractInputAction "Zoom Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) ...and 20 more like that. ----------- In general, in any system, if I avoid doing any of the things that provoke crash and try to just playing with the stylus and play with very basic things like painting random strokes, zooming, resizing brushes (max size are always per defaults), bringing the quick menu on and off and so on, Krita will frequently hang at some point. It does seem that gesture on/off and/or painting and operating certain things with fingers or trying to avoid that, is definitely at the center of this mess, especially as described in the latter experiments and the reported error. I can do all of that and much more challenging things in Krita3.3.3 (KDE and Xfce) and no crashes or hanging. ----------- Additional context information: 1. When I switch on the Cintiq, I have to manually configure it because there are no GUI tools for Linux. In a script, I have to map its devices to only the Cintiq screen area, using these commands xsetwacom set "Wacom Cintiq 27QHD touch Pen stylus" MapToOutput next xsetwacom set "Wacom Cintiq 27QHD touch Pen eraser" MapToOutput next xsetwacom set "Wacom Cintiq 27QHD touch Finger touch" MapToOutput next 2. I have Krita (3 and 4) configured to disable finger touch painting, BUT this setting doesn't do anything at all: fingers do paint no matter what. So I must issue this command to avoid painting with fingers: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off I do this before launching Krita (but sometimes after, and it does what I need in Krita 3.3.3 without problem). 3. Details of my system: Krita Version: 4.0.0 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.4.0-116-generic Pretty Productname: Ubuntu 16.04.4 LTS Product Type: ubuntu Product Version: 16.04 OpenGL Info Vendor: NVIDIA Corporation Renderer: "GeForce GTX 1050 Ti/PCIe/SSE2" Version: "4.5.0 NVIDIA 384.111" Shading language: 4.50 NVIDIA Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Current format: QSurfaceFormat(version 4.5, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 0, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Version: 4.5 Supports deprecated functions true is OpenGL ES: false
Hm... And of course, because you're on 16.04 we can't use debug packages and the lime ppa. It's weird, I have no come across these crashes on KDE Neon, which is also based off 16.04, while I do have very similar sets of warnings when zooming and the like. The only thing I can recommend with my little linux knowledge is to keep an eye on the memory usage. Maybe the other devs have better ideas what could be causing this :/
Thank you so much, Wolthera. I certainly will also watch that as well. I can't emphasize enough how exciting this new release is and how impatiently I have been waiting for it. I tried the alpha and beta versions and had same issues, so I kept waiting and watching krita's news every single day for the release. As soon as I can, I will try to test it in another computer which has Kubuntu 17.10, so perhaps with the Lima ppa and if I get pointers on how to, perhaps with the debug packages. Thanks a lot for all you do for this community.
Please get back to us when you've done those tests!
(In reply to Boudewijn Rempt from comment #3) > Please get back to us when you've done those tests! I haven't been able yet to test in the Kubuntu 17.10 system, but in the meantime I have installed the Cinnamon package in my main one, just to see if I get any more clues. I launched it from the console, to monitor (and record) the output of the session. At first, it looked promising, since I couldn't crash it with the same sequence of events as described previously for KDE, Xfce or Enlightenment. The happiness lasted only for five full minutes: While drawing, I tried one of my own brushes (nothing special, just a small change on a basic default brush) and I saw this error repeated like 12 times while painting: `Accessing uninitialized random source!` ..so I changed to an 'official' brush and kept drawing for few more seconds and when I tried to zoom in with the touch gesture then Krita hanged immediately; no more response from any input. I was simultaneously monitoring the system with htop: The only value for which I am not sure is the resident memory (RES column) for one of the two krita processes: '1379M', which accounts to 8.6% of my total system's RAM (16GB), according to the MEM% column, so that would be around 1.3GB. The other process shows '2600' (no units) which shows in the MEM% column as 0.0, and frankly is lower than many other processes so because the man pages don't say anything about units, I will have to assume that this is MB or lower unit (I don't get the htop's units logic). As for CPU%, both processes showed 0% at the time it crashed/hanged. I have a snapshot (picture) of htop at the moment of crash, let me know if that's interesting to attach. Also: is this 1.3GB typical/acceptable for the resident memory (htop's RES column) or should I somehow try to focus more in the memory, as Wolthera suggested, perhaps a memory leak? Bottom line, so far: Krita 4.0.0 crashes/hangs in all flavors of desktop environment that I have, when using a Wacom Cintiq touch display. The problem varies in severity: from taking down (freezing) the entire X system in KDE, to allowing to draw some 5 minutes and hang only Krita, with no exact identifiable pattern of what triggers the crash or how to reproduce it, other than (_apparently_) use fingers to interact with krita, as in a zoom gesture (Cinnamon), using the popup palette with fingers (Xfce, Enlightenment) or possibly those or another one in KDE. As I am having more information, I'll update, but for now I definitely am not using Krita 4.0.0 except for these experiments. I can't be more impatient to update my Kubuntu system to v18.04 in the hope that things might be better then. The stable release is supposed to be on the last week of April.
UPDATE: Krita 4.0.1 release does not change the situation (nor did it claim it, of course). All previous tests produce same results. After many tests, however, I think I can describe the problem in a better way now: I can now confirm, that there is a clear pattern: all points to the Touch function. 1. Crashes are always related with touching the canvas with bare finger(s). Either with documents created in krita 4 itself or krita 3.3.3 and even in the simplest document with default image color spaces, with only two or three brush strokes (any brush). Documents size is always the same: 2000px by 2500px and 300 dpi. 2. For these crashes to happen, at least one condition is needed: The Wacom Cintiq 27QHD touch Finger touch Gesture parameter (from xsetwacom) is set to off. 3. If the The Wacom Cintiq 27QHD touch Finger touch Gesture parameter is set to on (with xsetwacom, as explained before), I cannot reproduce the crashes as described previously. However: touching even barely with __any part of the hand__ on the canvas, will create a paint stroke, *regardless* of what the setting of the "Enable touch painting" setting is. This makes it impossible to work with krita 4 with a Wacom Cintiq 27QHD in (KX)ubuntu 16.04. 4. If the touch gesture parameter is set to off (xsetwacom), touching the canvas with bare fingers will end up in a crash, some times after a couple of minutes of working, but frequently (if not always) immediately if the first touch on the canvas is made with a bare finger instead of with the Stylus. 5. With the exact same system and conditions, Krita 3.3.3 works normally with the Wacom Cintiq 27QHD touch display, with the only exception that the "Enable touch painting" setting does not do anything at all, in both Krita 4.0.0/1 and Krita 3.3.3., which forces the user to issue: xsetwacom --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off ...to be able to work, to have access to gestures (this is counter intuitive!) and not create strokes with every skin contact on the canvas. These questions remain: - Why is it that the "Enable touch painting" doesn't seem to to anything at all, forcing a workaround that seems to enable the crazy crashes in Krita 4 but not in Krita 3.3.3 ? - Why turning gesture OFF with xsetwacom is the only way to *enable* gestures? Shouldn't it be the opposite?
For what is worth, just in case anyone having troubles with krita using a Wacom Cintiq and looking for answers, this information, gathered after countless experiments with various versions of krita and Kubuntu, might be helpful: 1. The **appimage** executables for krita versions 4.0.0, 4.1.0 AND 4.1.1 crash/hang when using a Wacom Cintiq 27QHD Touch display as soon as one touches the display with a finger or very soon thereafter, in both Kubuntu 16.04 AND in Kubuntu 18.04 with whatever latest updates. 2. In Kubuntu 18.04, the kritalime PPA installation of krita 4.1 AND 4.1.1 do NOT have the above problem. The touchscreen works (with a minor glitches) AS LONG as the following command is issued before launching krita: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 3. Enabling OR disabling finger touch painting in the krita settings does NOT have any effect in any krita version 4.x.x so far, appimage OR kritalime PPA installed. The above xsetwacom command remains the only way to allow using touch gestures in the Wacom Cintiq in krita >= 4 in kubuntu 18.04 and older.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to Andrew Crouthamel from comment #7) > This bug has been in NEEDSINFO status with no change for at least 15 days. > Please provide the requested information as soon as possible ... It comes to my attention that this is a standard/automated message, thus its content may not be 100% accurate to this context. I did get back to this thread with all info I could collect, first to the more specific request in comment #1, and second to the more generic request on comment #2. Testing in Kubuntu 17.10 is no more relevant as we are now in 18.04 and things changed, as extensively reported in this thread, so I have provided significant amount of information and even workarounds to this issue and I am the one waiting for info that may help me to provide more help or at least some comment. Therefore, I am setting the bug status as REPORTED, per the recommendations. Thanks
Created attachment 115313 [details] Hangup backtrace files - three cases Attached three backtrace files corresponding to three procedures, two of which caused hangup/crash, one that did not, as a control. Steps to reproduce and references to the files: Experiment 1 - 1A: (file: Exp1A_Krita_Hangup_Backtrace.txt) 1. Preparation: Run the following in the terminal: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 2. Run (with dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. At this exact moment, krita crashes/hangs(?). The GUI becomes irresponsive and doesn't refresh any longer. Collect the backtrace (needs to do <Ctrl><C> to get the gdb prompt) and close gdb to kill the hanged krita. - 1B: (file: Exp1B_Krita_NOHangup_Backtrace.txt) 6. Open (with dbg) krita v4.1.2 (installed from kritalime ppa) in /usr/bin/krit. NOPROBLEM 7. Open a different krita document created with krita 4.1.1 from kritalime, which has reference images embedded in it. 8. Touchscreen works normally, as this is not an appimage. Draw for a while. 9. Add a reference image to the existing ones. 10. Draw for a while. 11. Save the file: <Ctrl><S> => No problem. [ here it would have given the Error.] 12. Collect the backtrace "Exp1b" and quit krita Experiment 2 (file: Exp2_Krita_Hangup_Backtrace.txt) 1. If preparation of Experiment 1, step 1 was done, no action needed here. Else, do that. 2. Run krita (dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. It did not crash/hang and zoom gesture was recognized. Draw and do touch gestures, all seem OK. Close the document, but let Krita open. --> Problem will happen now: 6. Open another document. (in our case a trivial krita document (with only few lines) created with krita v4.0.4). 7. Repeat steps 4 and 5. Krita crashes/hangs as soon as touchscreen is touched with bare finger. Collect the backtrace (needs to do <Ctrl><C> to get the gdb prompt) and close gdb to kill the hanged krita.
---------------------------------------------------------------------------- --------- CORRECTION TO MY PREVIOUS POST (ocumo from comment #9) ----------- > Created attachment 115313 [details] > Hangup backtrace files - three cases > > Attached three backtrace files (...) This system doesn't allow to edit my posts, so PLEASE DISREGARD my post comment #9, which has unrelated information, and instead consider this one: Steps to reproduce and references to the files: Experiment 1 (file: Exp1A_Krita_Hangup_Backtrace.txt) 1. Preparation: Run the following in the terminal: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 2. Run (with dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. At this exact moment, krita crashes/hangs(?). The GUI becomes irresponsive and doesn't refresh any longer. Collect the backtrace (needs to do <Ctrl><C> to get the gdb prompt) and close gdb to kill the hanged krita. Experiment 2 (file: Exp2_Krita_Hangup_Backtrace.txt) 1. If preparation of Experiment 1, step 1 was done, no action needed here. Else, do that. 2. Run krita (dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. It did not crash/hang and zoom gesture was recognized. Draw and do touch gestures, all seem OK. Close the document, but let Krita open. --> Problem will happen now: 6. Open another document. (in our case a trivial krita document (with only few lines) created with krita v4.0.4). 7. Repeat steps 4 and 5. Krita crashes/hangs as soon as touchscreen is touched with bare finger. Collect the backtrace (needs to do <Ctrl><C> to get the gdb prompt) and close gdb to kill the hanged krita. There are indeed three files attached, but only the two mentioned here are relevant.
UPDATE Problem happens exactly the same in krita versions 4.1.3, 4.1.5 and even in the available preview of krita 4.2, as long as the appimage is used. This means that ALL available appimage versions 4.x.x released or not, including nightly builds cannot be used with a Wacom Cintiq Wacom Cintiq 27QHD Touch display without catastrophic failure. I have updated the report's "platform" field to "Appimage", since the problem doesn't manifest in installations made from the kritalime PPA.
Hi, Sorry for the late reply. I just missed the original bug report when it came in. The backtraces all point to a compatibility problem with XCB on your system. Which is strange, because I would sooner have expected issues with the nvidia drivers. I don't have exactly the same hardware, but with my setup (desktop with nvidia card, ubuntu 16.04 and 18.04, wacom cintiq hybrid companion), I don't see anything like this, but my cintiq is older and maybe does something different when it comes to touch :-(
Could you try with this specific appimage: https://www.dropbox.com/s/h8e3csvzauar2zw/krita-4.2.0-pre-alpha-539f7d0-x86_64.appimage?dl=0 This one doesn't use our own xcb implementation, so who knows... It might be better.
Thank you very much Boudewijn. This is a step forward! I will try the appimage as soon as I can and post here the results. I need to find a bit of time, but I will. Meanwhile, I really appreciate your efforts, I know how much the Krita team is busy in making a very tough work with limited resources. You guys are doing such a great work.
Created attachment 115703 [details] Backtrace and stdout of crash/hangup of krita-4.2.0-pre-alpha-539f7d0-x86_64.appimage Testing krita-4.2.0-pre-alpha-539f7d0-x86_64.appimage with a Wacom Cintiq 27QHD Touch display, in Kubuntu 18.04 (running Xfce). Outcome is not any better than with previous appimage versions, in fact first time the crash/hangup happened probably even touching the display with bare fingers.
I managed to do a quick test. Not good news. I have attached the outcome. This is exactly what I did: 1. Run the following in the terminal: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 2. Run krita with debugger: dbg ./krita-4.2.0-pre-alpha-539f7d0-x86_64.appimage 3. Create new document. 4. Draw a couple of color lines using the Stylus. Note that the krita pointer was covered by the normal mouse pointer from the window manager. 5. Touch the tablet touchscreen with a bare finger. 6. Krita crashes/hangs as soon as touchscreen is touched with bare finger or sometimes even before that, just while using the stylus to e.g. select some color or resize some panel. 7. Press <Ctrl><C> to get back the gdb promp. Collect the backtrace with this gdb command: thread apply all backtrace 8. Attach the whole krita stdout session from the console, which includes the backtrace. Note that the backtrace command is at line #317, and before that there is info that might be useful.
Okay, so this isn't an xcb implementation issue. There must be some weird incompatibility between the libxi the appimage contains and the libx11 on your system that only shows with this particular kind of touch event.
Created attachment 115736 [details] Installed libx11 related packages Ok, it seems that we need to understand whether the appimage is somehow built with an obsolete/inadequate library, or my system somehow has an inadequate/obsolete or somehow conflicting library. One thing that should be taken into consideration is that whatever you do to build the kritalime PPA version, is done OK and no one, including me, has complaints like this one about the hardware or system I am using with krita. What I can do is to analyse my system as thoroughly as needed to help reducing the scope of this investigation. I can't help with how the appimage is made, though. I can offer for starters, (please see the attached file), a list of all `libx11*` packages installed in my system; it's just the output of the command: `apt list libx11* --all-versions`. On top of that, the following information is relevant: All the installed packages come from the official ubuntu repos, either the bionic-updates or bionic sections. There are neither PPA versions nor manually compiled libraries, these or any others, as I am very careful with global systems files. If I ever have to compile anything, it's never a library or any kind of system files or files that somehow could have global scope. I actually almost never compile stuff and if I must, I would always do it in an isolated scope. Even Python programs that are not official are always enclosed in their specific environment. I know well how bad can it be to troubleshoot incompatible/conflicting dependencies. As for PPAs, I only risk those coming from serious projects, such as Krita. That being said, my interest is not to exclude my system out of the investigation. I certainly may have something bad in it, made some mistake or forgotten something. So, please if you could suggest more checks or system information that could help to simplify the troubleshooting, by all means, do. Important: is there a chance that someone from the appimage building team might also contribute their 5 cents? I also must remind the readers, because it's a long thread, that up to Krita 3.3.3, ALL those appimages work without any issue with my Wacom Cintiq device, even today! All the troubles started with the appimages of the Krita v4.x.x branch, all its versions. Apart from the Krita code: what else changed there? I am not yet convinced (though possible) that this is some kind of unique problem with my system, which is build on official Ubuntu packages on normal hardware. Finally: I don't like Flatpak, or Snaps: they are, by all comparisons I have been able to read online, quite inferior, by many reasons, to appimages. The reason why I would like to work with appimages, is for testing new versions of Krita, otherwise, I would just wait for your kritalime release and forget about it. So far I have seen Flatpak versions only for final releases. I'll try to find some time to test the available Flatpak, if you think that makes sense. Are there Flatpak versions of krita 4.2? In any case, I don't want to quit using appimages, unless Flatpak would work for me and there would be Flatpak versions for the testing Kritas. Thank you!
I have been testing the flatpak installation of krita 4.1.5 for several minutes. The good news is that the flatpak version does NOT have the crash/hangup issue. Though I need to test more, it clearly is not failing as with the appimage versions, and touch functionality works exactly as with the kritalime PPA version (not perfect, but quite good). This seems to confirm that definitely there is something not well with the appimages 4.x.x, because neither 3.x.x appimages nor kritalime PPA installations, nor flatpak 4.1.5, have any of the reported problems. The bad news is that the installation instructions of flatpak in the https://krita.org/en/download/krita-desktop/ webpage are wrong and incomplete, and even the instructions in https://flathub.org/apps/details/org.kde.krita fail to provide important information. There is, in addition, another issue. I will provide an attachment with these notes and details, in my next post, so please I would really appreciate feedback/comments.
Created attachment 115761 [details] Problems with the installation of the flatpak version of krita 4.1.5: Documentation issues and other In the attached file, I am detailing a number of problems faced when installing the current release of krita (4.1.5) using the Flatpak method. This is part of the investigation for the bug in this thread, thus the need to put this here, despite the fact that this opens new problems not directly related to the current bug. The relevance of this report about the Flatpak method, is that the Flatpak is an obvious and valid alternative to the appimages, which this thread show that have catastrophic compatibility issues with a very important, professional class hardware (Wacom Cintiq) that krita and Linux otherwise do support. In this case, Flatpaks can provide at the very least a fallback solution to broken appimages and/or the kritalime PPA has not been updated, among other scenarios in which users prefer/have to use Flatpak in their systems.
We don't support the flatpak version ourselves, and it's up to the people maintaining the flatpak to update us when they change how flatpaks are installed. I don't have access to a cintiq with this particular touch functionality, so I cannot test what's up with it, all I could think of is not shipping libxi, but I fear that that would break appimages for everyone.
(In reply to Boudewijn Rempt from comment #21) > We don't support the flatpak version ourselves, and it's up to the people > maintaining the flatpak to update us when they change how flatpaks are > installed. Yeah, but you guys certainly do care that whatever shows up in Krita's webpage is not wrong, wouldn't you? I hope the missing/truncated part of your sentence is "...so I will of course ask them to check and fix that as soon as possible, thanks for catching that one mate!" Is it? Otherwise, it doesn't take much to prove, for example, that 'flatpak remote-add --if-not-exists flathub' is not a valid command and will fail; in case my report is not convincing, the man page should suffice. So... Seriously?? What would be the point on, knowingly, keep incorrect installation instructions on the download page of the product that takes so much effort and money to put together? Somebody else's problem? I don't get it. I'm just trying to report a problem on the Krita webpage, to the Krita developers, on something relevant to this thread. I though you guys, Krita owners, should be the natural choice. "The people" and "they" are too vague for me. But hey. Still: Would it be somehow possible to kindly forward this information to someone who could do something to fix wrong information in the official Krita download webpage, where potential Krita users will have trouble with bad instructions? I mean, I don't need it for myself any more, I've had my bad experience and frustrations already. I thought other people, less savvy with computers, should be saved from that "User Experience" (pissed users === detractors of your project). Sorry, this time I catastrophically fail to see or understand your position on this. In this case, it's _not_ about whoever creates flatpaks or whatnot: it's about *Krita users* using Krita official documentation that is wrong, whoever wrote it. As user, I don't care if it was Bob, Jane or Alice. It says "Krita" all over the place. Users are the reason of your (or any) project. Without them, no project. Users don't have any business in the innermost administrative details of who is assigned what or who steps/doesn't step on who's toes, etc. That's how laundry works at home. It's far, far too much beyond what any user needs or wants to know. Sadly, this reminds me of Public Services where one asks at the Information Counter about something and they redirect us to another Information Counter in which we can ask where to find information on who may have information about the proper Information Counter. I hope I am wrong, but that's how it looks to me. Please show me how incredibly wrong I am, and I will fully retract all the rants. Anyone, please ? > I don't have access to a cintiq with this particular touch functionality, so > I cannot test what's up with it, all I could think of is not shipping libxi, > but I fear that that would break appimages for everyone. I totally understand. I can only say that I maintain my humble offer of contribution. If you would like to try some isolated experiments, please by all means let me know if I can help in any way. This is _not_ about me, though. We are talking about one of the top models, professional class, most popular and arguably the best brand on its business. The point is not Wacom. It's its users. Not me, in particular. I can always find my way with other solutions if necessary, FOSS or not. It's the "top professional" ones. Anyone who is _really_ serious about digital illustration business, won't survive with a BambooFun tablet, period. They do use the big toys, as it's public. I don't think Krita is meant to be exclusively for hobbyists, poor students or people who can't afford and won't use pirate copies of Adobe/Corel products. It's for all. Fully supporting some of the top Wacom devices, the most popular amongst professionals, should be just a natural goal for Krita. And removing any annoyances that disturb that goal should therefore be equally important. Any serious professionals googling for "Krita + Wacom Cintiq 27QHD" would get to this thread. I hope they understand that it is possible and don't get frustrated with my experience. If Krita could have one of those giant professional names we all admire (Aaron Blaise, Jason Seiler, Mike Luckovich, why not?) acknowledging and endorsing this project, we all would be very happy.
I can reproduce this issue on a Cintiq Pro 16, but not consistently. I've also had it happen on a Surface Pro 2 (wacom tech) a year or so ago, both using various versions of Kubuntu/KDE, both running appimages. I have so far not managed to get it when running a local build. Since palm rejection in general isn't great I ended up disabling touch entirely when drawing: xsetwacom --set "Wacom Cintiq Pro 16 Touch Finger touch" touch off While not a solution to this problem, it does work around the issue. As to why you have to disable gestures with xsetwacom to get gestures in Krita: xsetwacom gestures is an in-driver legacy feature, intended for systems that don't support multitouch. This means that when driver gestures are on, Krita won't receive touch events. See https://github.com/linuxwacom/xf86-input-wacom/wiki/Multitouch for more information.
No, you wouldn't get this problem when running a local build because the problem is some sort of binary incompatibility between the libraries inside the appimage and local X11 libraries. That shouldn't happen for properly versioned libraries, but it does... So we need to think whether we should include more or fewer libraries in the appimage. I need to consult the appimage people on this problem.
Sorry, your wall-of-text approach of admonishing us for being bad at figuring out how you messed up your system means we cannot do anything with your reports. I am closing all reports that you made that are still open. Please don't reopen them. Please refrain from making further reports; you are apparently incapable of normal interaction.