Significant input latency when processing output command even if no-op

[pedrocr]

• Sway Version: sway version 1.5.1-eca57594 (May 18 2021, branch 'HEAD')
• Debug Log: https://gist.githubusercontent.com/pedrocr/9aaf735494616e0dfa056df99a77a22c/raw/06ab4a9d9b56e4eb784a65734e8a0175061fe518/debug.log
• Configuration File: default
• Description:

There is something in sway that creates significant input latency when output commands run, even if they're actually no-ops. To reproduce:

• Start a new sway session with the default config
• Run in a terminal while true; do sleep 1; swaymsg "output * dpms on"; done
• Move the mouse or do some typing and notice the latency spikes whenever the output command runs

I noticed this because I had the following swayidle setup:

exec swayidle -w before-sleep '$lock' \
  timeout 5 'if pgrep --uid $(whoami) swaylock; then swaymsg "output * dpms off"; fi'\
  resume 'swaymsg "output * dpms on"'\

This results in very noticeable latency when typing or moving the mouse at any moment after 5 seconds as it runs the dpms on command unconditionally expecting it to be a no-op. It's common to see these kinds of warnings in the logs because of this:

[ERROR] client bug: timer event5 trackpoint: scheduled expiry is in the past (-91ms), your system is too slow

And the pointer lag is very noticeable because of this.

Edit: removed the part about XWayland. Although the presence of XWayland increases the latency it was already there before that. The problem is the output command not ending up as a no-op and reconfiguring inputs instead.

[pedrocr]

Seems like the input reconfigure is happening here:

sway/sway/config/output.c

Lines 482 to 489 in 12e223e

	// Reconfigure all devices, since input config may have been applied before
	// this output came online, and some config items (like map_to_output) are
	// dependent on an output being present.
	input_manager_configure_all_inputs();
	// Reconfigure the cursor images, since the scale may have changed.
	input_manager_configure_xcursor();
	return true;
	}

and it happens because nothing in the output command chain avoids no-op changes and this input reconfigure is unconditional. From the discussion around #5629 I think assuming this for the wlroots changes is fine as they will be no-ops down in the wlroots code but the sway part of the output config will still run and cause this kind of side effect.

A potential solution for this would be to keep a struct output_config current_config; in struct sway_output and bail out early from apply_output_config() if the new config is the same as the old one.

[mstoeckl]

It may also be helpful to understand what makes input_manager_configure_all_inputs(); slow, specifically. Running while true; do sleep 1; swaymsg "output * dpms on"; done, and looking at the debug logs for a terminal, I see each reconfigure sends the same keymap, 8 times each, even though nothing has changed. This happens for every client.

[1180301.653] [email protected](1, fd 14, 53374)
[1180305.868] [email protected]_info(26, 599)
[1180305.896] [email protected](1, fd 15, 53374)
[1180309.988] [email protected]_info(26, 599)
[1180310.051] [email protected](1, fd 16, 53374)
[1180314.103] [email protected]_info(26, 599)
[1180315.415] [email protected](1, fd 17, 53374)
[1180334.764] [email protected]_info(26, 599)
[1180334.850] [email protected](1, fd 18, 53374)
[1180339.043] [email protected]_info(26, 599)
[1180349.525] [email protected](1, fd 19, 53374)
[1180353.956] [email protected]_info(26, 599)
[1180354.021] [email protected](1, fd 20, 53374)
[1180357.837] [email protected]_info(26, 599)
[1180731.594] [email protected](1, fd 14, 53374)
[1180743.227] [email protected]_info(26, 599)

[rpigott]

That would be one per keyboard input device, I guess.