Skip to content

Linux WorkSpaces client: rendering artifacts (scrollbar overlapping taskbar + border) in multi-monitor extended fullscreen mode

0

Summary: On Ubuntu 24.04 with the AWS WorkSpaces Linux client (DCV protocol), a DCV-based WorkSpace connected in extended fullscreen mode across two monitors shows persistent rendering artifacts on the primary monitor: a horizontal scrollbar element overlapping the Windows taskbar (obscuring the Start button and search box), and a thin vertical border on the right edge. Neither artifact should be present; the remote desktop content is expected to fill the local display exactly.

Environment:

  • Client version: workspacesclient 2026.0.5677-1 (noble/24.04 repo, confirmed latest available via apt, no newer candidate exists)
  • OS: Ubuntu 24.04.4 LTS
  • Kernel: 6.8.0 (stock GA, AMD amdgpu, no mainline kernel patch applied)
  • Hardware: Mini PC, AMD Ryzen 3 5300U, Radeon integrated graphics
  • Display setup: Two external monitors, both 1920x1080 @ 60Hz, extended left-to-right (combined virtual desktop 3840x1080), connected via HDMI-1 (primary, left) and HDMI-2 (secondary, right)
  • Window manager: Openbox 3.6 (minimal X11 kiosk session, no compositor running)
  • Connection protocol: DCV (WSP)

Steps to reproduce:

  • Connect to a DCV-based WorkSpace from the Linux client on a dual-monitor Ubuntu 24.04 host, both monitors 1920x1080, extended horizontally.
  • Enter fullscreen across both monitors (via window manager _NET_WM_STATE_FULLSCREEN on each per-monitor dcvviewer window, or via the client's fullscreen-all toggle).
  • Observe the primary (left) monitor.

Expected behavior: The remote desktop content fills the full 1920x1080 area of each monitor with no visible borders, scrollbars, or overlapping UI elements.

Actual behavior:

  • A horizontal scrollbar (with visible thumb/handle) renders directly on top of the Windows taskbar on the primary monitor only, obscuring the Start button and taskbar search box. This blocks interaction with part of the taskbar, not just cosmetic.
  • A thin vertical border/line is visible along the right edge of the primary monitor's content.
  • The secondary monitor renders perfectly clean, no scrollbar, no border, taskbar fully visible and usable.

Isolation testing performed:

  • Switching to single-monitor (non-extended) fullscreen removes the scrollbar entirely; the thin border remains, but the intrusive scrollbar does not appear. This confirms the scrollbar is specific to extended/multi-monitor mode, while the border is a separate, lower-severity issue present in both modes.
  • Confirmed the window manager side is not the cause: xprop on both per-monitor dcvviewer windows shows identical, correct state on both: _NET_WM_STATE_FULLSCREEN and _OB_WM_STATE_UNDECORATED set, _NET_FRAME_EXTENTS all zero, and xwininfo geometry exactly matching each monitor's physical resolution and position (1920x1080+0+0 and 1920x1080+1920+0). Both windows are byte-identical in WM-level configuration; only the primary shows the artifact. This rules out our own window manager (Openbox) or kiosk automation as the cause; the issue is internal to the DCV client's own rendering/compositing.
  • Ruled out a local desktop-background bleed-through theory (initial hypothesis): the artifact is present even with the custom kiosk background unset, and visually is a genuine scrollbar/border rendering by the client itself, not a gap revealing content behind the window.
  • No related output found in the client's own logs (--log-level info) at the time the artifact appears; no errors, warnings, or anything scrollbar/resolution-related logged.

Related issue (lower severity, both modes): Separately, even in single-monitor mode (tested on different, non-multi-monitor hardware, same client version), a thin (~10-12px) border is visible around the DCV content on the primary display specifically, never observed on secondary/non-primary displays in other multi-monitor testing. This may be a related or shared root cause with the scrollbar issue above, but is reported here as a secondary data point, not the main bug.

Impact: For kiosk/shared-desktop deployments, this is a real usability regression: the taskbar search box and Start button are partially unusable on any dual-monitor kiosk running this client version. Current workaround is to disable extended/multi-monitor mode, which is an acceptable but undesirable tradeoff (loses the second display's utility).

Request: Confirmation of whether this is a known issue, and guidance on whether a client update is expected to address it, or whether there's a supported configuration workaround short of disabling multi-monitor mode entirely.

  • Update: checked the display scaling suggestion from Florian's answer. Display scaling inside the WorkSpace OS is set to exactly 100% on both monitors, so that's not the cause here. Still seeing the artifact. Will look at filing a formal AWS Support ticket next.

2 Answers
2

In addition to the previous response, since you already verified the _NET_WM_STATE_FULLSCREEN and X11 geometry flags, I recommend adding three specific isolation checks to your AWS Support ticket. Proprietary remote desktop clients occasionally miscalculate Xrandr/Xinerama geometries when running outside of fully-featured compositors:

  • Compositor Check: Briefly test the client under the default Ubuntu GNOME (Mutter) session. If the artifact disappears, the DCV client specifically struggles to interpret the multi-monitor geometry in a pure Openbox (non-composited) kiosk environment.
  • Host-Side DPI Scaling: Ensure that the display scaling inside the Windows WorkSpace OS is strictly set to 100% for both displays. Fractional scaling mismatches between the host and the client often force rendering engines to inject scrollbars.
  • Version Rollback: If possible, downgrade the Linux client to the previous version via apt to establish whether this is a direct regression introduced in 2026.0.5677-1. Including these data points in your support case will eliminate standard tier-1 troubleshooting loops and significantly speed up the engineering team's root cause analysis.
EXPERT

answered 22 days ago

0

Based on the available documentation, I can confirm that the WorkSpaces Linux client does support multi-monitor configurations with up to four displays at a maximum resolution of 3840x2160 per monitor. The client includes functionality to extend the display across multiple monitors and enter full screen mode across all connected displays.

However, the specific rendering artifacts you're experiencing—the horizontal scrollbar overlapping the Windows taskbar and the thin vertical border on the primary monitor in extended fullscreen mode—are not documented as known issues or expected behavior in the current release notes.

The release notes for the 2026.0 version you're running mention several improvements and fixes, including:

  • Added support for opening the client in full screen mode on all connected displays by default when provisioned on thin client devices
  • Improvements to the disconnection experience
  • Various bug fixes related to session handling and application stability
  • Updates to the DCV SDK

The fact that the issue is isolated to the primary monitor in extended mode, while the secondary monitor renders correctly, and that your window manager configuration shows identical settings for both displays, suggests this is likely a client-side rendering issue specific to how the DCV client handles the primary display in multi-monitor extended configurations.

For troubleshooting and resolution, I recommend:

  1. Report this issue directly to AWS Support through the AWS Support Center (https://console.aws.amazon.com/support/). Include the detailed reproduction steps, environment information, and isolation testing you've already performed, as this level of detail will be valuable for the engineering team.

  2. Enable diagnostic logging if you haven't already, and capture logs during a session where the artifact appears. While you mentioned no relevant output at info level, verbose diagnostic logs may capture additional details that could help identify the root cause.

  3. Monitor for client updates: Given that this appears to be a client-side rendering issue in a specific configuration (dual-monitor extended fullscreen on the primary display), a future client update would be the most likely path to resolution.

Your current workaround of using single-monitor mode is reasonable for the immediate term, though I understand it's not ideal for your kiosk deployment requirements.
Sources
WorkSpaces Linux client application - Amazon WorkSpaces

answered 22 days ago

EXPERT

reviewed 22 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.