I realise this is probably a stupid question, but is it possible to downgrade qt on Tumbleweed, say to 5.8, or lower, and still end up with a working KDE desktop? I tried the obvious thing and added the KDE:qt5.8 repo and tried switching system packages to that, but the end result is that plasma and KDE apps are uninstalled; trying to reinstall then requires some qt.5.9 libraries which defeats the purpose.
Why would I want to do such a thing? As of a few months ago touchscreen input stopped working properly on KDE (lifting my finger off the screen does not register a button release, this makes it virtually impossible to click anything open. This is not a hardware issue, the touchscreen works fine on Gnome 3 and Windows). I recently tried KDE on Fedora 26 which has qt 5.7, and the touchscreen worked as it used to, so I suspect a qt upgrade is the culprit. I would like to test if the touchscreen works with 5.8 on Tumbleweed to try and narrow down where the problem is.
So is there a way to do this? I am not very concerned with having a reliably working KDE desktop, I only really want it for as long as I can test the touchscreen on it, so I can narrow down where, and against what, to file a bug.
TW is a rolling distro never standing still always evolving always with the newest packages while TW once did come with Qt 5.8 I doubt you can find it as it’s not in the main TW repo I’m not sure if old snapshots are archived
afaik there was a serious bug with Qt 5.8 in TW so it was removed and for a time TW got rebuild with Qt 5.7
I think there are 2 things you can do #1 downgrade to LEAP which comes with Qt 5.6 and Plasma 5.8 (you can do this online just change your repo’s to point too LEAP and do zypper dup) #2 open a bug report at https://bugzilla.opensuse.org/
tell them your issue so it gets fixed
Then IMO the best way to do this is in a machine built from scratch as a dedicated test machine.
I wouldn’t recommend building a multi-boot, that’d be too risky…
But I would recommend installing virtualization like Virtualbox and building a Guest with your described parameters.
as far as I know tell there is no way to get back old Qt libs on TW
if you think the issue is with plasma 5.10 you can get plasma 5.8 lts for tw from here http://download.opensuse.org/repositories/KDE:/Frameworks5:/LTS/openSUSE_Tumbleweed/
you’d need to do a full vendor change with that repo but as far as I can tell that repo does not come with any Qt libs so it was probobly build against the current TW Qt 5.9
Thanks for your responses. I hadn’t thought of downgrading to LTS, so I tried that. Like you said it still uses qt 5.9, and the touchscreen still does not work the way it used to. But that is still useful information since it rules out that the touchscreen issue is not KDE specific.
I’m pretty sure Qt doesn’t handle input devices (I remember an old bug about using alt+num to input extra chars not being supported under kde, the kde team passed it to Qt, Qt said it was up to X to handle such matters freedesktop hasn’t gotten around to fixing it as they’ve been working on wayland)
my point being this could be an X issue try running plasma 5 under Wayland I’ve never done it but afaik Wayland has better support for input devices (I remember reading that the above mentioned bug does not exist on systems running Wayland I haven’t tested it)
you can try pulling plasma5-session-wayland that should install the needed packages and give you an extra plasma5-wayland option at login
This is in part what I am wondering, whether this is a KDE specific issue, or not. One reason for thinking it was qt was that this seems to affect only qt applications and not necessarily KDE ones only (e.g. 4pane, vlc, even when run in Gnome, under both wayland or xorg, btw touch works fine in Gnome with both xorg and wayland), Likewise gtk/non-qt applications work as expected in kde, e.g. firefox. I reasoned that qt is the difference here. But I admit freely that I know next to nothing about the internals here, so I am happy to be set straight if qt is the wrong thing to be investigating. I also thought that it might be whatever is taking care of the new touchscreen features in KDE (see https://blog.martin-graesslin.com/blog/2017/04/how-input-works-touch-screen-edge-swipe-gestures/); which was another reason to see if a different version of qt, but the same kde version, made the difference. Fundamentally, my problem is that I don’t know who to report the bug to, and I’m trying to narrow things down, so I am happy with any suggestions for things to test.
BTW, I did try kde under wayland several months ago, but it was so buggy and unstable on my device that I wasn’t really able to test touchscreen input; plasma kept crashing whenever I tried to launch something. It might be worth a try again; certainly gnome on wayland works just fine.
the thing is gtk provides some features independently from the window manager (X or Wayland) kde depends exclusively on X this could be an X not a kde/plasma issue that’s why I posted the arch wiki links
and that blog from the kde developers specifically mentions KWin/Wayland setup not X
Thanks, I think that is what I needed to set me on the right track. I tried kde on wayland again. It is stable enough now that I can say the touchscreen works as expected. It is not a solution since a wayland session is still not really that stable (after a few minutes it starts to freeze and then the session crashes), but this and what you say leads me to think that the problem has something to do with X, or with how kde interacts with X. I suppose the thing to try is another desktop that does not use gtk and relies exclusively on X (LXqt) and see how the touchscreen works there, in order to test if its a kde problem.