Page MenuHomePhabricator

syndaemon tool makes E to be laggy
Closed, ResolvedPublic

Description

There's a strange issue when using syndaemon, I don't know what incompatibility is causing with E but when using it, it becomes laggy and slow, this can be a pretty annoying issue in E for tools that uses or runs the command syndaemon

Example: open a terminal and run:

killall syndaemon ; syndaemon -d -K -R -i 0.9

This command is quite needed for people with laptops which has an annoying touchpad that moves your mouse while typing in the keyboard (your palm touches it)

After to run this command, you can type in the same terminal and it will print error messages (cause of the issue?), but also if you type fast in the terminal you can see a delay between the keyboard events and what is printed in your screen, your entire desktop becomes slower since that moment, everything showing with a kind of visual delay in your desktop, same in your web browser

  • EFL & E builds: recent, Debian Buster based OS

Now, I don't know how much related is but I rebooted the machine and trying to login in E24 and the desktop shows even much more laggy (with an E process under 100% cpu), I can read these messages in the ~/.xsession-errors file:

DEV: change [SynPS/2 Synaptics TouchPad] [Synaptics Scrolling Distance] -> 115 115
DEV: CHANGES ... have 20 devices
DEV: change [SynPS/2 Synaptics TouchPad] [Synaptics Scrolling Distance] -> 115 115
DEV: CHANGES ... have 20 devices
DEV: change [SynPS/2 Synaptics TouchPad] [Synaptics Scrolling Distance] -> 115 115
DEV: CHANGES ... have 20 devices
DEV: change [SynPS/2 Synaptics TouchPad] [Synaptics Scrolling Distance] -> 115 115
DEV: CHANGES ... have 20 devices
DEV: change [SynPS/2 Synaptics TouchPad] [Synaptics Scrolling Distance] -> 115 115
DEV: CHANGES ... have 20 devices
DEV: change [SynPS/2 Synaptics TouchPad] [Synaptics Scrolling Distance] -> 115 115

Note: "syndaemon" command has not ben run this time

in x input goes directly to apps. the wm is not involved in key events getting to apps. all a wm does is set focus to a window (telling x where to send key events that are not grabbed). e's key bindings use grabs - so those keys will not go to apps but to e. i would believe your issue is with syndaemon and what it is doing with the xserver.

hmmm that new dev changes is part of new input config. e is seeing devices changing - something is adding/removing (seemingly not as count is the same) or modifying input device properties. every time this happens, e will look at all the devices you have and ensure they are configured based on the new touchpad config. it could be e requesting input device properties because syndaemon keeps altering device properties again and again very rapidly

try eeb015c0b972b6aa7322b21425077083df2be76b - avoid re-applying if device list looks the same...

Ok so these are my results, it seems like the lag is gone after the update, and now I read some messages about the device changes on my ~/.xsession-errors file, let me detail them:

example message:

DEV: CHANGES ... have 20 devices, changed=0

note: only the first line contains: changed=1, and these messages seems to be trigger when typing on the keyboard or moving the touchpad

  • if I uninstall the package xserver-xorg-input-synaptics (which includes synaptic drivers and also provides the syndaemon command), I have like 10 of these messages each minute
  • with the package installed seems like it increases a bit, to almost 20 per minute (no synademon command running)
  • after running the syndaemon command, there's like 60 messages per minute

I assume there's a bug in this xorg that sends those device change calls? (note that this happens also without syndaemon / synaptic drivers), but at least E is not lagging now and no cpu usage with those calls happening

Since there's no lag anymore, and following the previously described results, I assume this report should be closed?

raster closed this task as Resolved.Nov 27 2020, 9:29 AM

the change events are if a device was added, removed or properties in a device changed. its a direct result of an event from xorg ... :)