Fix XEmbed tray docking initialization - #264
Merged
Merged
Conversation
besendorf
force-pushed
the
agent/fix-xembed-tray-docking
branch
from
July 20, 2026 09:09
21bd6ec to
5e552d5
Compare
This was referenced Jul 20, 2026
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026080611-devel&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026050504-devel&flavor=update
Failed tests14 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 30 fixed
Unstable testsDetails
Performance TestsPerformance degradation:19 performance degradations
Remaining performance tests:92 tests
|
This was referenced Jul 20, 2026
marmarek
reviewed
Jul 21, 2026
| conf.width = 32; | ||
| conf.height = 32; | ||
| conf.override_redirect = 0; | ||
| write_message(g->vchan, hdr, conf); |
Member
There was a problem hiding this comment.
This looks a bit risky, because the above XMoveResizeWindow() call will eventually also result in a MSG_CONFIGURE message (in response to X11 event). But, IIUC the order or messages is important here, and the other MSG_CONFIGURE will be send after MSG_DOCK. So, maybe duplicate message is less bad...
Member
|
Finally the nm-applet icon is visible: https://openqa.qubes-os.org/tests/189082#step/clipboard_and_web/3 :) |
Member
|
Is it draft because of unverified commit signature? Or something else? |
besendorf
marked this pull request as ready for review
July 22, 2026 15:07
Contributor
Author
|
Converted. Can sign in about two weeks |
This was referenced Jul 23, 2026
Merged
This was referenced Jul 30, 2026
This was referenced Jul 31, 2026
Merged
Merged
Merged
Merged
Open
Correct the embedded-notify event, decode the mapped flag using the Xlib property representation, and publish the initial embedder geometry before docking.
besendorf
force-pushed
the
agent/fix-xembed-tray-docking
branch
from
August 6, 2026 16:10
5e552d5 to
77c2a09
Compare
Contributor
Author
|
@marmarek I signed the commits. Is anything else blocking this? |
marmarek
approved these changes
Aug 7, 2026
Contributor
|
Some reports on the forum that running certain software when this patch is present, does slow down the system. More information on: |
Contributor
Author
|
I will try to reproduce it. I have updated qubes-gui-agent in my appvms but not dom0 yet. I can see the icons and dont experience the performance issues mentioned in the thread so far |
Contributor
|
Could you please try the mentioned program, |
Contributor
Author
|
I could not reproduce with kde in dom0. Trying xfce next. Users in the forum mentioned high cpu usage for xfwm4 |
Contributor
Author
|
This fixes it for me: #265 |
marmarek
added a commit
that referenced
this pull request
Aug 20, 2026
* origin/pr/265: Limit XEmbed size normalization to 1x1 clients Pull request description: - read the tray client's actual geometry before docking; - apply the existing `32x32` fallback and pre-dock `MSG_CONFIGURE` only to clients whose initial size is `1x1`; and - preserve the geometry of clients such as Fcitx5 that already provide a usable size. PR #264 correctly repaired the XEmbed notification and property decoding, and added geometry initialization for tray clients that otherwise remain at `1x1`. However, it applies the `32x32` resize and synthetic configure message to every XEmbed tray client. Fcitx5 creates its tray window with a valid size and reacts to configure events by updating its size hints and resizing the tray window. Forcing another size before docking can therefore create a configure/resize feedback loop with some dom0 tray implementations. This matches the reported regression where starting Fcitx5 with GUI agent 4.3.19 makes an Xfce dom0 session sluggish and drives `Xorg`, `qubes-guid`, and `xfwm4` CPU usage upward. The decision must use geometry alone rather than the current `XEMBED_MAPPED` flag. A dock trace showed that `nm-applet` requests docking at `1x1` while that flag is still clear, then sets it shortly afterward. Requiring the flag caused it to remain a white `1x1` square. This change retains the `1x1` recovery needed by clients such as `nm-applet`, while avoiding an unnecessary geometry change for healthy clients. Related reports: - #264 (comment) - https://forum.qubes-os.org/t/qubes-became-extremely-sluggish-after-a-dom0-update/42922/7 Tray clients that start at `1x1` continue to receive the `32x32` initialization introduced by PR #264, including clients that set `XEMBED_MAPPED` after requesting the dock. Clients with an existing usable geometry are only reparented and moved to the embedder origin, restoring the pre-PR size handling for that case. - Built `gui-agent/qubes-gui` from a clean object state with the project's `-Wall -Wextra -Werror` flags on Arch Linux. - Installed the equivalent v4.3.19 hotfix in an Arch Qubes AppVM with Fcitx5 5.1.21 and `nm-applet` 1.36.0. - Captured the initial dock state: Fcitx5 arrived at `48x48` with `XEMBED_MAPPED` set and skipped normalization; `nm-applet` arrived at `1x1` with the flag clear and was normalized. - Confirmed both tray icons were displayed correctly. Their final mapped geometry was `32x32`. - Replaced and redocked Fcitx5 ten times over 25 seconds: the GUI agent used 0.32% CPU, guest Xorg used 3.40% CPU, and the service remained active with zero restarts. - Toggled the input method twenty times; the GUI agent consumed 0.01 seconds of CPU. - During a later 20-second steady-state interval with both clients present, the GUI agent consumed 0.07 seconds and guest Xorg consumed 0.64 seconds of CPU. - The GUI-agent journal contained only the expected X-server connection and temporary dock-probe messages. The runtime checks validate the guest-side docking behavior. The dom0-side Xfce process behavior still needs confirmation on an affected system. This change was investigated, developed, and tested with assistance from OpenAI Codex. The author directed the investigation and requested publication; the diff and validation evidence are provided here for maintainer review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix XEmbed tray clients that remain mapped as blank
1x1icons when proxied to a desktop tray.The live tray-docking path now:
XEMBED_EMBEDDED_NOTIFYevent instead of the address of the incoming-event pointer;XEMBED_MAPPEDusing theunsigned longrepresentation returned byXGetWindowProperty();32x32default embedder geometry; andMSG_DOCK, matching the ordering used when full window state is resent.Root cause
The incorrect
XSendEvent()argument prevented clients from receivingXEMBED_EMBEDDED_NOTIFY.Fixing only that call was insufficient for clients initially created at
1x1: dom0 still knew the pre-dock window as1x1and configured the docked client back to that size. Additionally, reading a format-32 X property throughint *selects the wrong slot on 64-bit systems, so the mapped flag could be missed.Validation
gui-agent/qubes-guifrom a clean object state with the project's-Wall -Wextra -Werrorflags.xembedsniproxyin dom0.1x1changed from receiving no embedded notification and remaining1x1to receivingXEMBED_EMBEDDED_NOTIFY,MapNotify, and a stable32x32configure event.32x32andIsViewable.sys-netwith the realnm-applet; the previously blank NetworkManager icon became visible and was tinted with the qube's red label color.AI assistance disclosure
This change was developed and tested with assistance from OpenAI Codex. The runtime tests and final visual confirmation were performed interactively on the affected Qubes OS system.