Autorepeat rate and delay in KDE suddenly excruciatingly slow

cfr · 2022-10-06 18:41:31

seth wrote:

Use https://wiki.archlinux.org/title/Power_ … stem-sleep and https://gist.github.com/AladW/de1c5676d93d05a5a0e1 and there also import DBUS_SESSION_BUS_ADDRESS from eg. kwin_x11
Alternatively simply hardcode "Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus" (assuming your UID is 1000, check "echo $DBUS_SESSION_BUS_ADDRESS" for the actual variable)
Edit: since qdbus won't block you might want to also briefly "sleep 0.5" or so to give KWin a chance to act before the system falls asleep

I think I'm misunderstanding something.

I created /usr/lib/systemd/system-sleep/cfr-kwin-compositor.sh

#!/bin/sh -
# ref. https://wiki.archlinux.org/title/Power_management#Hooks_in_/usr/lib/systemd/system-sleep
export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
echo dbus $DBUS_SESSION_BUS_ADDRESS
case $1/$2 in
  pre/*)
          /usr/bin/qdbus org.kde.KWin /Compositor suspend
          /usr/bin/sleep 0.5
          echo "Disabling kwin compositor for $2 ... $?"
          ;;
  post/*)
          /usr/bin/qdbus org.kde.KWin /Compositor resume
          /usr/bin/sleep 0.5
          echo "Enabling kwin compositor after $2 ... $?"
          ;;
esac
# vim: set nospell:

I assumed the

Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

wasn't something I could just put in a script. Or did you mean I needed to import the environment and then hardcode the DBUS_SESSION_BUS_ADDRESS? Or was that a suggestion for adapting the service files I'd tried using rather than switching to the script?

The journal says

systemd-sleep[176047]: Could not connect to D-Bus server: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

seth · 2022-10-06 21:36:53

"Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus" would have been for the service.
Your script looks ok, as long as "unix:path=/run/user/1000/bus" is indeed your session bus, but you'll have to run qdbus as your user, ie. eg.

sudo -u cfr env DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" qdbus org.kde.KWin /Compositor suspend

cfr · 2022-10-08 02:37:59

seth wrote:

"Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus" would have been for the service.
Your script looks ok, as long as "unix:path=/run/user/1000/bus" is indeed your session bus, but you'll have to run qdbus as your user, ie. eg.
sudo -u cfr env DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" qdbus org.kde.KWin /Compositor suspend

Thank-you. I should have thought of that, but DBUS is something of a mystery to me.

This now works. Whether it will have any effect on xorg CPU % remains to be seen, but it does disable the compositor when it goes to sleep.

cfr · 2022-10-09 23:54:04

The first time I put the computer to sleep, I'm sure this worked because KDE complained the compositor had been disabled by another application, before it was reenabled. However, subsequent sleep episodes have not resulted in any similar complaint and Xorg CPU % is climbing steadily. In the journal

Hyd 10 00:39:19 MyComputer systemd[1]: Starting System Suspend...
Hyd 10 00:39:19 MyComputer audit[196561]: USER_ACCT pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer audit[196561]: CRED_REFR pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="myname" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer kernel: audit: type=1101 audit(1665358759.541:2258): pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting grantors=pam_unix,pam_permit,pam_time acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer kernel: audit: type=1110 audit(1665358759.541:2259): pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="myname" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer sudo[196561]:     root : PWD=/ ; USER=myname ; COMMAND=/usr/bin/env DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus /usr/bin/qdbus org.kde.KWin /Compositor suspend
Hyd 10 00:39:19 MyComputer kernel: audit: type=1105 audit(1665358759.551:2260): pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="myname" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer audit[196561]: USER_START pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="myname" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer dbus-daemon[479]: [system] Activating via systemd: service name='org.freedesktop.home1' unit='dbus-org.freedesktop.home1.service' requested by '
:1.8161' (uid=0 pid=196561 comm="/usr/bin/sudo -u myname env DBUS_SESSION_BUS_ADDRE")
Hyd 10 00:39:19 MyComputer dbus-daemon[479]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.home1.service': Unit dbus-org.freedesktop.home1.service 
not found.
Hyd 10 00:39:19 MyComputer sudo[196561]: pam_systemd_home(sudo:session): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Hyd 10 00:39:19 MyComputer sudo[196561]: pam_unix(sudo:session): session opened for user myname(uid=1000) by (uid=0)

...

Hyd 10 00:39:19 MyComputer sudo[196561]: pam_unix(sudo:session): session closed for user myname
Hyd 10 00:39:19 MyComputer audit[196561]: USER_END pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="myname" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer kernel: audit: type=1106 audit(1665358759.857:2261): pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="myname" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer kernel: audit: type=1104 audit(1665358759.857:2262): pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="myname" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:19 MyComputer audit[196561]: CRED_DISP pid=196561 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_env,pam_faillock acct="myname" exe="/usr/bin/sudo" hostname=? addr=? terminal=? res=success'
Hyd 10 00:39:20 MyComputer systemd-sleep[196558]: Disabling kwin compositor for suspend ... 0

I don't think this necessarily means it isn't working as the failures don't seem to stop sudo happening, but I'm not entirely sure. I kind of hope it isn't working because, if it is, it isn't solving the problem!

seth · 2022-10-10 06:35:42

Disable the resume hook and see whether the system wakes w/ a disabled compositor, but it would seem that this isn't the cause
On a wild guess (continuing to blame kwin), delay the resume action (sleep 5s ahead or so) in case of a race condition during the wake.

You can trace the client/server interaction, but doing so for something fundamental like kwin and profile its comunication patterns over time is gonna be a PITA.
https://www.x.org/wiki/guide/debugging/#index3h2

cfr · 2022-10-10 16:02:33

seth wrote:

Disable the resume hook and see whether the system wakes w/ a disabled compositor, but it would seem that this isn't the cause
On a wild guess (continuing to blame kwin), delay the resume action (sleep 5s ahead or so) in case of a race condition during the wake.
You can trace the client/server interaction, but doing so for something fundamental like kwin and profile its comunication patterns over time is gonna be a PITA.
https://www.x.org/wiki/guide/debugging/#index3h2

It definitely works. If I disable the resume hook, compositing is disabled on wake, even though KDE doesn't complain. Should I still try extending the delay?

Is it possible to alter the script so it will sleep even if compositing is already disabled?

EDIT: If I was going to try to trace the interaction, would you recommend any of the listed programmes in particular?

Last edited by cfr (2022-10-10 16:06:18)

seth · 2022-10-10 16:18:29

Is it possible to alter the script so it will sleep even if compositing is already disabled?

?? Just "sleep 5" ahead of "qdbus org.kde.KWin /Compositor resume" - and yes, I'd try.

EDIT: If I was going to try to trace the interaction, would you recommend any of the listed programmes in particular?

Nope.
Wireshark is nice because it allows you to inspect the traffic conditionally, but it requires you to run X11 on tcp, which is anything but great (and stands a chance of preventing the COMPOSITE extension) and the others are all wrappers.
It's gonna be a PITA to do this w/ kwin no matter what

cfr · 2022-10-10 16:31:19

seth wrote:

Is it possible to alter the script so it will sleep even if compositing is already disabled?
??

As it stands, the laptop won't sleep if compositing is already disabled. I just wondered if it was possible to alter the script so it would ensure compositing was disabled and then sleep, regardless of whether compositing was enabled or disabled to begin with. It's not a big deal if it's difficult because I very rarely disable compositing, but I just thought there might be an easy way to make it work.

EDIT: So I now have

#!/bin/sh -
# ref. https://wiki.archlinux.org/title/Power_management#Hooks_in_/usr/lib/systemd/system-sleep
case $1/$2 in
  pre/*)
          /usr/bin/sudo -u myname env DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" /usr/bin/qdbus org.kde.KWin /Compositor suspend
          /usr/bin/sleep 0.5
          echo "Disabling kwin compositor for $2 ... $?"
          ;;
  post/*)
          /usr/bin/sleep 5
          /usr/bin/sudo -u myname env DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" /usr/bin/qdbus org.kde.KWin /Compositor resume
          /usr/bin/sleep 0.5
          echo "Enabling kwin compositor after $2 ... $?"
          ;;
esac
# vim: set nospell:

with two sleeps in the resume hook.

Last edited by cfr (2022-10-10 16:33:57)

seth · 2022-10-10 20:11:45

the laptop won't sleep if compositing is already disabled

???

In a regular konsole session, try

qdbus org.kde.KWin /Compositor resume # to ensure it's active
qdbus org.kde.KWin /Compositor suspend && echo foo
qdbus org.kde.KWin /Compositor suspend && echo bar

Does it print foo, bar or both?

cfr · 2022-10-11 15:54:50

seth wrote:

the laptop won't sleep if compositing is already disabled
???
In a regular konsole session, try
qdbus org.kde.KWin /Compositor resume # to ensure it's active
qdbus org.kde.KWin /Compositor suspend && echo foo
qdbus org.kde.KWin /Compositor suspend && echo bar
Does it print foo, bar or both?

It prints both.

EDIT: If compositing is disabled in a regular konsole session, the laptop sleeps OK. If it was disabled from the systemd script and not afterwards resumed, the laptop won't sleep until compositing has been re-enabled e.g. in a konsole session. Is there something about the logic of the sleep script I'm not understanding?

Last edited by cfr (2022-10-11 16:03:35)

seth · 2022-10-11 19:01:01

I thought that maybe a failing qdbus call (returning anything but 0 and couting as "false") cound, along an unfortunate bash setting, maybe shortcut the hooks and lead to a cancellation of the suspend.
But that isn't the case ("bar" would then not have been printed)

Is there anything in the system journal for those failing suspends?

cfr · 2022-10-11 19:41:20

seth wrote:

Is there anything in the system journal for those failing suspends?

Not much. I usually sleep by closing the lid. It seems to register the lid close but doesn't do anything in response. As soon as I reenable compositing, it's all fine.

Here's an excerpt. It starts with the end of a successful suspend, where compositing was disabled but not re-enabled. I've cut out the dhcp/avahi/network chatter.

Hyd 11 20:20:47 MyComputer systemd[1]: systemd-suspend.service: Deactivated successfully.
Hyd 11 20:20:47 MyComputer systemd[1]: Finished System Suspend.
Hyd 11 20:20:47 MyComputer audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Hyd 11 20:20:47 MyComputer systemd[1]: Stopped target Sleep.
Hyd 11 20:20:47 MyComputer systemd[1]: Reached target Suspend.
Hyd 11 20:20:47 MyComputer systemd[1]: Stopped target Suspend.
Hyd 11 20:20:47 MyComputer audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Hyd 11 20:20:47 MyComputer systemd-logind[486]: Operation 'sleep' finished.
Hyd 11 20:20:47 MyComputer kernel: audit: type=1130 audit(1665516047.956:2511): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Hyd 11 20:20:47 MyComputer kernel: audit: type=1131 audit(1665516047.956:2512): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
...
Hyd 11 20:20:52 MyComputer audit[216015]: USER_AUTH pid=216015 uid=1000 auid=1000 ses=3 msg='op=PAM:unix_chkpwd acct="username" exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res=success'
Hyd 11 20:20:52 MyComputer kernel: audit: type=1100 audit(1665516052.313:2513): pid=216015 uid=1000 auid=1000 ses=3 msg='op=PAM:unix_chkpwd acct="username" exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res=success'
Hyd 11 20:20:56 MyComputer systemd-logind[486]: Lid closed.
Hyd 11 20:20:56 MyComputer root[216018]: LID closed
Hyd 11 20:20:56 MyComputer root[216020]: arg1 is button/lid, arg2 is LID, arg3 is close and arg4 is
...
Hyd 11 20:21:12 MyComputer systemd-logind[486]: Lid opened.
Hyd 11 20:21:12 MyComputer root[216022]: ACPI group/action undefined: ibm/hotkey / LEN0268:00
Hyd 11 20:21:12 MyComputer root[216024]: arg1 is ibm/hotkey, arg2 is LEN0268:00, arg3 is 00000080 and arg4 is 00006032
Hyd 11 20:21:12 MyComputer root[216026]: LID opened
Hyd 11 20:21:12 MyComputer root[216028]: arg1 is button/lid, arg2 is LID, arg3 is open and arg4 is
...
Hyd 11 20:21:23 MyComputer sudo[215000]: pam_unix(sudo:session): session closed for user root
Hyd 11 20:21:23 MyComputer kernel: audit: type=1106 audit(1665516083.733:2514): pid=215000 uid=1000 auid=1000 ses=3 msg='op=PAM:session_close grantors=pam_systemd_home,pam_limits,pam_unixHyd 11 20:20:48 MyComputer kernel: Bluetooth: hci0: Malformed MSFT vendor event: 0x02
...
Hyd 11 20:20:52 MyComputer audit[216015]: USER_AUTH pid=216015 uid=1000 auid=1000 ses=3 msg='op=PAM:unix_chkpwd acct="username" exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res
=success'
Hyd 11 20:20:52 MyComputer kernel: audit: type=1100 audit(1665516052.313:2513): pid=216015 uid=1000 auid=1000 ses=3 msg='op=PAM:unix_chkpwd acct="username" exe="/usr/bin/unix_chkpwd" host
name=? addr=? terminal=? res=success'
Hyd 11 20:20:56 MyComputer systemd-logind[486]: Lid closed.
Hyd 11 20:20:56 MyComputer root[216018]: LID closed
Hyd 11 20:20:56 MyComputer root[216020]: arg1 is button/lid, arg2 is LID, arg3 is close and arg4 is
...
Hyd 11 20:21:12 MyComputer systemd-logind[486]: Lid opened.
Hyd 11 20:21:12 MyComputer root[216022]: ACPI group/action undefined: ibm/hotkey / LEN0268:00
Hyd 11 20:21:12 MyComputer root[216024]: arg1 is ibm/hotkey, arg2 is LEN0268:00, arg3 is 00000080 and arg4 is 00006032
Hyd 11 20:21:12 MyComputer root[216026]: LID opened
Hyd 11 20:21:12 MyComputer root[216028]: arg1 is button/lid, arg2 is LID, arg3 is open and arg4 is
...
Hyd 11 20:21:23 MyComputer sudo[215000]: pam_unix(sudo:session): session closed for user root
Hyd 11 20:21:23 MyComputer kernel: audit: type=1106 audit(1665516083.733:2514): pid=215000 uid=1000 auid=1000 ses=3 msg='op=PAM:session_close grantors=pam_systemd_home,pam_limits,pam_unix
,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/26 res=success'
Hyd 11 20:21:23 MyComputer kernel: audit: type=1104 audit(1665516083.733:2515): pid=215000 uid=1000 auid=1000 ses=3 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/26 res=success'
Hyd 11 20:21:23 MyComputer audit[215000]: USER_END pid=215000 uid=1000 auid=1000 ses=3 msg='op=PAM:session_close grantors=pam_systemd_home,pam_limits,pam_unix,pam_permit acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/26 res=success'
Hyd 11 20:21:23 MyComputer audit[215000]: CRED_DISP pid=215000 uid=1000 auid=1000 ses=3 msg='op=PAM:setcred grantors=pam_faillock,pam_permit,pam_faillock acct="root" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/26 res=success'

It looks to me as if it doesn't even try to suspend when the lid is closed in these cases.

I thought maybe it needed some kind of post hook in the script, so I tried with an empty post and also with one which just echoed the line to the journal, but neither seems to be sufficient. If compositing is disabled in pre and not reenabled, it wakes fine but won't sleep again. If I reenable compositing (e.g. with alt+shift+f12), it immediately sleeps quite happily.

seth · 2022-10-11 20:01:29

I suspect you can perfectly "sudo systemctl suspend" w/ the compositor being off?

It would then smell like the compositor has impact on the ACPI action configuration (through KDE/powerdevil)

cfr · 2022-10-12 18:05:16

seth wrote:

I suspect you can perfectly "sudo systemctl suspend" w/ the compositor being off?

Yes!

seth wrote:

It would then smell like the compositor has impact on the ACPI action configuration (through KDE/powerdevil)

I'm lost. What's the difference between suspending compositing in the script and

/usr/bin/qdbus org.kde.KWin /Compositor suspend

just in the terminal emulator? Shouldn't

/usr/bin/sudo -u cfrees env DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" /usr/bin/qdbus org.kde.KWin /Compositor suspend

be equivalent?

seth · 2022-10-12 19:57:53

The context (one happens while the system prepares of an S3) - why that has any impact on future LID handling is beyond me (but I suspect it's something KDE/powerdevil does)
You could try to also briefly sleep after "qdbus org.kde.KWin /Compositor suspend", eg. 1s or so

cfr · 2022-10-14 00:57:01

seth wrote:

The context (one happens while the system prepares of an S3) - why that has any impact on future LID handling is beyond me (but I suspect it's something KDE/powerdevil does)
You could try to also briefly sleep after "qdbus org.kde.KWin /Compositor suspend", eg. 1s or so

Do you mean try sleeping for 1s rather than 0.5s? Right now, I have pre as

  pre/*)
          /usr/bin/sudo -u cfrees env DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" /usr/bin/qdbus org.kde.KWin /Compositor suspend
          /usr/bin/sleep 0.5
          echo "Disabling kwin compositor for $2 ... $?"
          ;;

and post as

  post/*)
          /usr/bin/sleep 5
          /usr/bin/sudo -u cfrees env DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" /usr/bin/qdbus org.kde.KWin /Compositor resume
          /usr/bin/sleep 0.5
          echo "Enabling kwin compositor after $2 ... $?"
          ;;

Since this turns out to be so context-dependent, it isn't likely to be a practical problem. When I asked about getting it to sleep anyway I didn't realise the not-sleeping was only related to compositing disabled by the script before. I assumed it wouldn't sleep if I disabled compositing for some ordinary reason (e.g. taking a screenshot). However, if I can easily make it behave more sensibly even in the edge case, I will.

Last edited by cfr (2022-10-14 00:57:44)

seth · 2022-10-14 08:33:36

Since this turns out to be so context-dependent

We don't know that w/ absolute certainty…

Do you mean try sleeping for 1s rather than 0.5s?

For instance, but thb. I'd expect 0.5s to be sufficient, so this is probably not going to help…

cfr · 2022-10-14 13:47:42

Changing 0.5 to 1 made no difference. It still wouldn't sleep if compositing had been disabled with the pre hook. (So I've changed it back to 0.5 since longer doesn't help.)

Xorg CPU usage is still low after 1 day, so I'll see what happens and whether the sleep 5 in the post hook helps. I've also just plugged back into AC and I'm still not sure whether AC/battery is a factor. (Just got notified my non-replaceable battery needs replacing, but I'm assuming I can ignore this. My replaceable battery is reasonably healthy and I still get better battery life than I have with new laptops in the past.)

EDIT: Now CPU usage is jumping again. I don't suppose

psmouse serio2: Failed to disable mouse on synaptics-pt/serio0

is relevant, but I'm only seeing this for the last suspend and the CPU % just jumped. However, this is hard to monitor when you are trying to use the machine for stuff in between! Is there a way to get a snapshot of CPU % values for Xorg outputted to the journal? (That is, obviously there is, but is there a useful/sensible way of doing it?) The mouse in question is trackpoint, so I can't detach it, though if there's an easy way to disable it, I could try that. (I occasionally use the buttons and even more occasionally the pointer, but could easily manage without for testing purposes.)

I also see

psmouse serio1: synaptics: Your touchpad (PNP: LEN2046 PNP0f13) says it can support a different bus. If i2c-hid and hid-rmi are not used, you might want to try setting psmouse.synaptics_intertouch to 1 and report this to linux-input@vger.kernel.org.

However, that is for a different device.

Last edited by cfr (2022-10-17 21:59:29)

cfr · 2022-10-30 01:51:20

I am not currently seeing CPU % climbing for Xorg. I don't want to say the problem is no more because I've said that before, but the problem is certainly taking a more leisurely approach to life.

In addition to the sleep script, I've also updated the software and firmware (the stuff covered by fwupd - I know there are other utilities which might be relevant, but I've not used any of those).

I don't trust it .... I'm sure just posting this will make it spike immediately .

cfr · 2023-01-14 03:20:36

Yesterday or the day before yesterday this problem recurred. Again, Xorg is taking 100% CPU and I notice because typing becomes excruciatingly slow.

kwin_x11 --replace

brings the % down, but it does not bring it down to the low levels I was seeing when the problem had disappeared. Right after restarting kwin, Xorg was taking about 9% CPU. And I'm seeing visual artefacts in kile again, which I associate with this slowing down.

Here's the kwin terminal output:

kwin_xkbcommon: XKB: Unrecognized RMLVO option "terminate:ctrl_alt_bksp+eurosign:5+compose:caps" was ignored
kwin_xkbcommon: XKB: inet:323:58: unrecognized keysym "XF86EmojiPicker"
kwin_xkbcommon: XKB: inet:324:58: unrecognized keysym "XF86Dictate"
OpenGL vendor string:                   Intel
OpenGL renderer string:                 Mesa Intel(R) HD Graphics 620 (KBL GT2)
OpenGL version string:                  4.6 (Compatibility Profile) Mesa 22.3.2
OpenGL shading language version string: 4.60
Driver:                                 Intel
GPU class:                              Kaby Lake
OpenGL version:                         4.6
GLSL version:                           4.60
Mesa version:                           22.3.2
X server version:                       1.21.1
Linux kernel version:                   6.1.4
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
file:///usr/share/kwin/tabbox/informative/contents/ui/main.qml:123: TypeError: Cannot call method 'longestCaption' of null
OpenGL vendor string:                   Intel
OpenGL renderer string:                 Mesa Intel(R) HD Graphics 620 (KBL GT2)
OpenGL version string:                  4.6 (Compatibility Profile) Mesa 22.3.2
OpenGL shading language version string: 4.60
Driver:                                 Intel
GPU class:                              Kaby Lake
OpenGL version:                         4.6
GLSL version:                           4.60
Mesa version:                           22.3.2
X server version:                       1.21.1
Linux kernel version:                   6.1.4
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
BlurConfig::instance called after the first use - ignoring
ZoomConfig::instance called after the first use - ignoring
WindowViewConfig::instance called after the first use - ignoring
OverviewConfig::instance called after the first use - ignoring
KscreenConfig::instance called after the first use - ignoring
DimInactiveConfig::instance called after the first use - ignoring
DesktopGridConfig::instance called after the first use - ignoring

pacman.log from the day before the day before the day before yesterday:

[2023-01-11T04:11:59+0000] [PACMAN] Running 'pacman -Rs libva-intel-driver'
[2023-01-11T04:12:01+0000] [ALPM] transaction started
[2023-01-11T04:12:01+0000] [ALPM] removed libva-intel-driver (2.4.1-2)
[2023-01-11T04:12:02+0000] [ALPM] transaction completed
[2023-01-11T04:12:02+0000] [ALPM] running '30-systemd-update.hook'...
[2023-01-11T04:12:02+0000] [ALPM] running 'zzz-force-sync.hook'...
[2023-01-11 04:12] Exited with code 0
[2023-01-11T04:12:20+0000] [PACMAN] Running 'pacman -S intel-media-driver'
[2023-01-11T04:12:25+0000] [ALPM] transaction started
[2023-01-11T04:12:25+0000] [ALPM] installed intel-gmmlib (22.3.2-1)
[2023-01-11T04:12:25+0000] [ALPM] installed intel-media-driver (22.6.4-1)
[2023-01-11T04:12:25+0000] [ALPM] transaction completed
[2023-01-11T04:12:25+0000] [ALPM] running '30-systemd-update.hook'...
[2023-01-11T04:12:25+0000] [ALPM] running 'zzz-force-sync.hook'...
[2023-01-11 04:12] Exited with code 0
[2023-01-11T04:16:05+0000] [PACMAN] Running 'pacman -S intel-gpu-tools'
[2023-01-11T04:16:08+0000] [ALPM] transaction started
[2023-01-11T04:16:08+0000] [ALPM] installed peg (0.1.18-2)
[2023-01-11T04:16:08+0000] [ALPM] installed intel-gpu-tools (1.26-1)
[2023-01-11T04:16:08+0000] [ALPM] transaction completed
[2023-01-11T04:16:08+0000] [ALPM] running '30-systemd-update.hook'...
[2023-01-11T04:16:08+0000] [ALPM] running 'zzz-force-sync.hook'...
[2023-01-11 04:16] Exited with code 0

I did this because https://wiki.gentoo.org/wiki/Intel#Feature_support suggested I might have the wrong packages installed, but I'm not at all certain about this.

Any (sane) ideas why the issue seemed to go away only to reemerge would be especially welcome.

seth · 2023-01-14 08:31:15

https://wiki.archlinux.org/title/Hardwa … tion#Intel
Kaby Lake is between Broadwell and Coffee-Lake. I doubt the VAAPI implementation would have direct impact here.

Xorg was taking about 9% CPU

Either the server or one of its modules has trouble talking to the HW or some other process will still be generating lots of traffic.
If it's the latter, killing away all GUI processes will eventually calm the server. Otherwise *only* restarting would help.
Because of the WM involvement, I suspect some other client is going wild and (or just its compositor?) wastes CPU in chasing it.
That process might be kile?

I'm seeing visual artefacts in kile again

That's new?
What do they look like (photo?) and do they go away if you only suspend the compositor?

cfr · 2023-01-15 04:25:12

seth wrote:

That process might be kile?

Restarting kile seems to resolve it, so I think so. However, exiting kile in the usual way failed. Although the application disappeared visually, ps showed a process remained, so I had to kill that before I could start it again.

seth wrote:

I'm seeing visual artefacts in kile again
That's new?
What do they look like (photo?) and do they go away if you only suspend the compositor?

Will try to get a picture. They didn't disappear completely, but they became quite annoying again. Translated, this means they were occurring too frequently to be conveniently dealt with i.e. getting rid of one was closely followed by a new one etc. They are basically deformed bits of contextual menus. I'll try disabling the compositor and getting a photo next time I see them. (Xorg was only around 5-7% before I restarted Kile, so not seeing them much right now.) From memory, disabling the compositor gets rid of them, but I need to check.

Beginning to think I should abandon KDE, but I'd be reluctant to switch from Kile. It's distracting learning a new TeX editor.

seth · 2023-01-15 09:38:22

Next time you hit the problem, only restart kile and see whether that alone clears the stage.
If we can pin this to kile going rogue, we might be able to investigate the problem (by eg. attaching gdb or valgrind there and check what it's actually doing)
It might also explain why there're not widespread reports about this (because kile is in probably far less use than kwin)

abandon KDE, but I'd be reluctant to switch from Kile. It's distracting learning a new TeX editor.

The DE and any tool (tex editor) are ideally not inter-related and certainly not hardlinked.
Apparently https://archlinux.org/packages/communit … /texmaker/ is a Qt-only version of kile by the same creator which seems to have a clinch w/ its own fork, https://archlinux.org/packages/communit … texstudio/

bjourne · 2023-07-11 10:08:31

I'm having the same issue and have noticed it on all machines I run KDE on. I go to System settings and set the keyboard repeat rate and mouse pointer acceleration to comfortable values. It works but after an hour or two it resets to Xorg's sluggish defaults. The displayed settings in KDE's System settings remain unchanged though.

seth · 2023-07-11 12:08:47

That wasn't the subject of this tread at all.
Your keyboad re-attaches, perhaps in response to usb autosuspend or because of a sloppy connection or something™ reconfigures xkb, the xorg log will likely hint the cause.
=> https://wiki.archlinux.org/title/Xorg/K … ion_option

Arch Linux

#76 2022-10-06 18:41:31

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#77 2022-10-06 21:36:53

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#78 2022-10-08 02:37:59

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#79 2022-10-09 23:54:04

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#80 2022-10-10 06:35:42

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#81 2022-10-10 16:02:33

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#82 2022-10-10 16:18:29

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#83 2022-10-10 16:31:19

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#84 2022-10-10 20:11:45

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#85 2022-10-11 15:54:50

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#86 2022-10-11 19:01:01

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#87 2022-10-11 19:41:20

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#88 2022-10-11 20:01:29

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#89 2022-10-12 18:05:16

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#90 2022-10-12 19:57:53

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#91 2022-10-14 00:57:01

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#92 2022-10-14 08:33:36

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#93 2022-10-14 13:47:42

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#94 2022-10-30 01:51:20

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#95 2023-01-14 03:20:36

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#96 2023-01-14 08:31:15

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#97 2023-01-15 04:25:12

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#98 2023-01-15 09:38:22

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#99 2023-07-11 10:08:31

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

#100 2023-07-11 12:08:47

Re: Autorepeat rate and delay in KDE suddenly excruciatingly slow

Board footer