[wacomtablet] [Bug 454947] Cannot map buttons due to incorrect xsetwacom invocation
https://bugs.kde.org/show_bug.cgi?id=454947 --- Comment #4 from Tomasz Lemiech --- PR tested on Intuos 4. Works OK. -- You are receiving this mail because: You are watching all bug changes.
[wacomtablet] [Bug 454947] New: Cannot map buttons due to incorrect xsetwacom invocation
https://bugs.kde.org/show_bug.cgi?id=454947
Bug ID: 454947
Summary: Cannot map buttons due to incorrect xsetwacom
invocation
Product: wacomtablet
Version: unspecified
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jazzv...@gmail.com
Reporter: szpaj...@gmail.com
Target Milestone: ---
Commit dd97e6ab6a0a91d01d54a02131685e5d1fc78c05 ("Fix Qt 5.15 obsoletions")
introduced the new syntax of QProcess.start() routine in xsetwacomadaptor.cpp
(modified further in 88422002167f941e1457695a0e9fa3b1212c32f3). It requires
command arguments to be passed as a QStringList rather than as a single
QString. Unfortunately this broke the ability to map express buttons because
the resulting xsetwacom command line string is built incorrectly.
The current invocation in XsetwacomAdaptor::setParameter():
setConf.start(QString::fromLatin1("xsetwacom"), QStringList() <<
QString::fromLatin1("set") << device << param);
results in the following execve() call for button mappings:
execve("/usr/bin/xsetwacom", ["/usr/bin/xsetwacom", "set", "Wacom Intuos4 4x6
Pad pad", "Button 1", "key ctrl shift e"], 0x7ffe783a6088 /* 74 vars */
This is incorrect, because xsetwacom expects "Button" and the button number to
be in separate arguments, while the above call passes it as one. Executing the
above command string manually yields the following error:
$ "/usr/bin/xsetwacom" "set" "Wacom Intuos4 4x6 Pad pad" "Button 1" "key ctrl
shift e"
Parameter 'Button 1' is no longer in use. It was replaced with 'Button'.
The old way of doing this was:
cmd = QString::fromLatin1( "xsetwacom set \"%1\" %2 \"%3\"" ).arg( device
).arg( param ).arg( value );
QProcess setConf;
setConf.start( cmd );
which produced this:
execve("/usr/bin/xsetwacom", ["/usr/bin/xsetwacom", "set", "Wacom Intuos4 4x6
Pad pad", "Button", "1", "key ctrl shift e"], 0x7ffcfd4ad278 /* 75 vars */
and this works fine, because %2 is not enclosed in quotes, so "Button 1" gets
split in two arguments.
Further changes to the xsetwacom launching code introduced in commit
88422002167f941e1457695a0e9fa3b1212c32f3 did not fix the problem.
STEPS TO REPRODUCE
1. Install wacomtablet.so from current git master
2. Try to map some buttons in the Express Buttons GUI
3. Apply the changes or replug the tablet
OBSERVED RESULT
Mappings are set according to the settings entered in the GUI
EXPECTED RESULT
Mappings are kept at their defaults.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo
KDE Plasma Version: 5.23.5
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.3
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
[kdeconnect] [Bug 432643] kdeconnect slowing down system shutdown
https://bugs.kde.org/show_bug.cgi?id=432643 --- Comment #27 from Tomasz Lemiech --- (In reply to Eduardo from comment #26) > What happens to this new kdeconnectd when we have this patch applied? Does > it keep running forever or is it killed somehow? It gets killed together with everything else. I don't see it lingering after I log off from KDE. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 432643] kdeconnect slowing down system shutdown
https://bugs.kde.org/show_bug.cgi?id=432643 Tomasz Lemiech changed: What|Removed |Added Attachment #143454|ksmserver fix |ksmserver_reject_new_client description||s_when_in_killing_state.dif ||f -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 432643] kdeconnect slowing down system shutdown
https://bugs.kde.org/show_bug.cgi?id=432643 --- Comment #22 from Tomasz Lemiech --- Created attachment 143454 --> https://bugs.kde.org/attachment.cgi?id=143454&action=edit ksmserver fix -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 432643] kdeconnect slowing down system shutdown
https://bugs.kde.org/show_bug.cgi?id=432643 Tomasz Lemiech changed: What|Removed |Added CC||szpaj...@gmail.com --- Comment #21 from Tomasz Lemiech --- Same thing here. Gentoo, no systemd, plasma-workspace-5.22.5, kdeconnect-21.04.3. Here is what happens: - ksmserver sends SmsDie to its clients (including kdeconnectd) - kdeconnectd exits correctly and immediately gets restarted via dbus (requested by plasmashell) - the new kdeconnectd instance connects to ksmserver with a new client ID - ksmserver wants to kill it, but SmsDie times out (here comes the 10-sec delay) - finally everything quits. So it's not the original kdeconnectd process which is causing the problem, but the new one, which came up after the first one exited. Presumably it's a race condition of some sort - the process might not yet be ready to handle messages from ksmserver (or maybe the message callbacks are not yet registered). Never mind - at this stage it does not respond to SmsDie. Given the fact that ksmserver was about to shut down itself and was in the process of killing its clients, I think it shouldn't have accepted the new client in the first place. Otherwise if the new client had responded to SmsDie properly, it could have been restarted once again and in theory this could loop multiple times preventing ksmserver from emptying its client list completely. Attached patch (ksmserver_reject_new_clients_when_in_killing_state.diff) does what the file name says. Works for me, no more hangs on exit. Logs before (note the different client IDs of the initial kdeconnectd instance and the one which fails to respond to SmsDie): org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366413980190510004 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366413980190510004 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366413980190510004 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366413980190510004 ) (...) org.kde.kf5.ksmserver: Starting killing clients (...) org.kde.kf5.ksmserver: startKilling: client "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366413980190510004 ) (...) org.kde.kf5.ksmserver: We killed all clients. We have now clients.count()= 7 (...) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366414160190510008 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366414160190510008 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366414160190510008 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366414160190510008 ) org.kde.kf5.ksmserver: SmsDie timeout, client "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366414160190510008 ) Logs after (the new kdeconnectd instance tries to connect but gets rejected): org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366408890157090004 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366408890157090004 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366408890157090004 ) org.kde.kf5.ksmserver: New client properties: "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366408890157090004 ) (...) org.kde.kf5.ksmserver: Starting killing clients (...) org.kde.kf5.ksmserver: startKilling: client "/usr/lib64/libexec/kdeconnectd" ( 10e0656c6900016366408890157090004 ) (...) org.kde.kf5.ksmserver: We killed all clients. We have now clients.count()= 11 (...) org.kde.kf5.ksmserver: Connection rejected: ksmserver is shutting down -- You are receiving this mail because: You are watching all bug changes.
