linux-capture: Make X11 display captures handle resolution changes #12937
+44
−6
Conversation
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
AlexTMjugador
force-pushed
the
feat/xshm-resolution-changes-handling
branch
from
5806da1 to
c8f04f0
Compare
kkartaltepe
reviewed
Jan 18, 2026
|
|
||
| data->xshm = xshm_xcb_attach(data->xcb, data->adj_width, data->adj_height); | ||
| if (!data->xshm) { | ||
| blog(LOG_ERROR, "failed to attach shm after resize!"); |
Collaborator
There was a problem hiding this comment.
Leaving the wrong sized texture hanging here might cause rendering to be weird
Author
There was a problem hiding this comment.
Good point, xshm_video_tick should early-return if this branch is taken but not necessarily xshm_video_render. I've pushed a commit that destroys the texture if this fails, so we don't risk rendering a texture with inconsistent dimensions in any case.
The XSHM display source has been unable to handle screen resolution changes on the fly for over 11 years (see commit 76d2bf2): when screen resolution changes while such a source is active, the source fails to resize accordingly, resulting in incorrect output. While this rarely affects the most typical workflows, as users seldom change physical display resolutions while recording, it becomes a more significant issue with virtual displays and multi-monitor setups. For example, virtual screens created by remote desktop clients like xrdp may be frequently resized during window drag and resize operations. I have identified and tried several workarounds, but none are ideal: - The third-party [`obs-gstreamer` plugin](https://github.com/fzwoch/obs-gstreamer) can delegate screen capturing to [GStreamer's `ximagesrc` element](https://gstreamer.freedesktop.org/documentation/ximagesrc/index.html). However, this incurs higher CPU usage than the native XSHM source. - Manually changing any source configuration parameter triggers `xshm_update`, restarting the capture with the new screen geometry. But manual solutions are inconvenient, and may cause visible artifacts while being applied. - A custom OBS plugin or WebSocket client could listen for resolution changes and automate the above workaround, but this solution is inelegant and beyond most users' reach. Thus, this commit fixes the problem at its root by following an approach inspired by other sources and GStreamer's `ximagesrc`: checking for screen geometry changes on each video tick. When a change is detected, the OBS and XSHM textures are resized to match, avoiding unnecessary reinitialization steps for better performance. I didn't observe any material performance impact in the happy path of a constant screen resolution.
AlexTMjugador
force-pushed
the
feat/xshm-resolution-changes-handling
branch
from
c8f04f0 to
4b0db51
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Motivation and Context
The XSHM display source has been unable to handle screen resolution changes on the fly for over 11 years (see commit
76d2bf2): when screen resolution changes while such a source is active, the source fails to resize accordingly, resulting in incorrect output.While this rarely affects the most typical workflows, as users seldom change physical display resolutions while recording, it becomes a more significant issue with virtual displays and multi-monitor setups. For example, virtual screens created by remote desktop servers like xrdp may be frequently resized during client window drag and resize operations.
I have identified and tried several workarounds, but none are ideal:
obs-gstreamerplugin can delegate screen capturing to GStreamer'sximagesrcelement. However, this incurs higher CPU usage than the native XSHM source.xshm_update, restarting the capture with the new screen geometry. But manual solutions are inconvenient, and may cause visible artifacts while being applied.Description
These changes fix the problem described above at its root by following an approach inspired by other sources and GStreamer's
ximagesrc: checking for screen geometry changes on each video tick. When a change is detected, the OBS and XSHM textures are resized to match, avoiding unnecessary reinitialization steps for better performance. I didn't observe any material performance impact in the happy path of a constant screen resolution.How Has This Been Tested?
I've built OBS 32.0.4 from source on a Debian Unstable X11 environment, both with and without this patch. Then I manually tested the two builds side by side, and confirmed that this patch fixes the intended issue without introducing any regressions. I conducted my tests under the xorgxrdp X server.
Types of changes
Checklist: