From 2cd0809a46ac84a6a6ae44cd0129bac014f452f0 Mon Sep 17 00:00:00 2001 From: Vincent Bernat Date: Thu, 18 May 2023 11:29:30 +0200 Subject: [PATCH] fix(randr): avoid querying hardware to get current configuration (#2470) When using `get_screen_resources`, XRandR will query the hardware to detect any change. This takes some time. `get_screen_resources_current` uses the cached information and is pretty fast. In my case, the information is always already present in cache because it was set by the program that did configure the screens (autorandr in my case, but this applies to most frontends). As polybar is not used to configure stuff, I think this is fine. There should be something configuring the screen before polybar is able to use it. However, maybe some people are using `polybar --list-monitors` just after plugging a screen. It won't display the new screen in this case. So, maybe this is not a good idea. It makes polybar starts faster (500ms faster in my case when there are 3 screens plugged). Also, I did this change because running `polybar --list-monitor` in parallel with starting `polybar` (in a for loop for example), I get some curious bug where my screens disappear and reappear. I don't need this change as this was easy to fix by avoiding the parallel access to XRandR properties, but maybe this would avoid other people running into the same problem. Your take! --- src/x11/extensions/randr.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/x11/extensions/randr.cpp b/src/x11/extensions/randr.cpp index e57c6a36..279f69cb 100644 --- a/src/x11/extensions/randr.cpp +++ b/src/x11/extensions/randr.cpp @@ -145,7 +145,7 @@ namespace randr_util { primary_name = {name_iter.begin(), name_iter.end()}; } - for (auto&& output : conn.get_screen_resources(root).outputs()) { + for (auto&& output : conn.get_screen_resources_current(root).outputs()) { try { auto info = conn.get_output_info(output); if (info->crtc == XCB_NONE) {