Latest tumbleweed updates after 2026-05-09 gives me a garbled desktop background, also some apps (for example VS Code) are unusable due to garbled graphics. Other apps seems not to have this problem. Also desktop overview is garbled, here’s an example:
This happens only of my box (Intel Core i7 2700K with internal graphics), on more recent boxes (for example the one I use at work) it does not happen.
GNOME desktop
@mrdave68 Hi and welcome to the Forum 
I suspect the old Intel GPU (HD Graphics 3000) can’t handle things eg vulkan, can you increase the vram available in the BIOS?
What is the output of inxi -GSaz
System:
Kernel: 7.0.5-1-default arch: x86_64 bits: 64 compiler: gcc v: 15.2.1
clocksource: tsc avail: hpet,acpi_pm
parameters: BOOT_IMAGE=/boot/vmlinuz-7.0.5-1-default
root=UUID=d9356f9f-a59d-4e7d-ae7a-200a5453de93 splash=silent
mitigations=auto quiet selinx=1 security=selinux selinux=1 enforcing=1
Desktop: GNOME v: 50.1 tk: GTK v: 3.24.52 wm: gnome-shell
tools: gsd-screensaver-proxy avail: xscreensaver dm: GDM v: 50.0
Distro: openSUSE Tumbleweed 20260512
Graphics:
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
vendor: ASUSTeK driver: i915 v: kernel arch: Gen-6 code: Sandybridge
process: Intel 32nm built: 2011 ports: active: HDMI-A-3 empty: DP-1,
DP-2, DP-3, HDMI-A-1, HDMI-A-2, VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0122
class-ID: 0300
Display: wayland server: X.org v: 1.21.1.21 with: Xwayland v: 24.1.11
compositor: gnome-shell driver: X: loaded: modesetting unloaded: vesa
alternate: fbdev,intel dri: crocus gpu: i915 display-ID: 0
Monitor-1: HDMI-A-3 model: HP 727pq serial: built: 2024
res: 2560x1440 dpi: 109 gamma: 1.2 size: 597x336mm (23.5x13.23")
diag: 685mm (27") ratio: 16:9 modes: max: 1920x1200 min: 720x400
API: OpenGL v: 3.3 vendor: intel mesa v: 26.1.0 glx-v: 1.4 es-v: 3.0
direct-render: yes renderer: Mesa Intel HD Graphics 3000 (SNB GT2)
device-ID: 8086:0122 memory: 1.46 GiB unified: yes display-ID: :0.0
API: EGL Message: EGL data requires eglinfo. Check --recommends.
Info: Tools: api: glxinfo x11: xprop,xrandr
Until 9 may it worked normally
@mrmazda any thoughts on this?
This looks wonky. I don’t think I’ve ever seen max less than current. I’d ask Harald what he thinks this suggests.
Given I’ve never had a Sandy Bridge, never use Gnome, and rarely use Wayland, I can do little more than speculate. The screenshot seems to be showing a memory management problem, a bit like https://gitlab.freedesktop.org/drm/nouveau/-/work_items/214, with a big difference in that here it’s apparently within the GUI, while there it’s only on the ttys. First thing I’d normally try is a different DE session type, to suggest whether Gnome provides the fault, or something else, but here there may be no other type available without installing a complete alternate Wayland-supported DE. Other things to try are:
[1] video= linux parameters normally only apply to the ttys, but the Intel display driver is a big exception
[2] in Xorg sessions this would be done via /etc/X11/xorg.con*, but whether it’s the same for Wayland I have no idea
There’s no hardware problem, if I run from a btrfs snapshot of 9 may 2026 the problem is not present, so it’s an updated package that has this problem.
Launching a IceVM session shows the problem on icevm menu texts but other apps, like on GNOME works correctly. A notable exception is VS Code where the editor is unusable due to garbled text.
@mrdave68 Launch vs-code with --ozone-platform-hint=wayland option…
Or the updated software is touching graphics allocated RAM differently, hitting a problem bit, byte or block that the previous software was reliably missing.
Warning: ‘ozone-platform-hint’ is not in the list of known options, but still passed to Electron/Chromium.
Still garbled in editor and menus
Note: scrolling changes garbled parts, sometimes they returns readable…
@mrdave68 If everything else is running ok, then it’s for sure a Wayland/Electron issue…
Other programs (Firefox, Thuderbird, Terminal, Text Editor, all GNOME software is not garbled.
YaST has window upper border corrupted, but not always, sometimes it is correct:
Other windows like Terminal, Editor etc. are correct and never corrupts
Hi all,
I am experiencing exactly the same thing with a laptop of the same generation (Sandy bridge), also using Tumbleweed Gnome.
I suspect an incompatibility with Gnome/GTK that appeared in recent upgrades, as this disappears if I rollback to an older snapshot. In this screenshot, the issue is clear on the desktop background as well as the photo displayed in Gnome’s photo viewer. Funnily, the same photo opened in Feh is displayed perfectly.
~> inxi -GSaz
System:
Kernel: 7.0.6-1-default arch: x86_64 bits: 64 compiler: gcc v: 15.2.1
clocksource: tsc avail: hpet,acpi_pm
parameters: initrd=\opensuse-tumbleweed\7.0.6-1-default\initrd-c9a6412b725a606dcbb910fbecaa62943942bc43
root=/dev/mapper/cr_root splash=silent quiet security=selinux selinux=1
mitigations=auto rootflags=subvol=@/.snapshots/1/snapshot
Desktop: GNOME v: 50.1 tk: GTK v: 3.24.52 wm: gnome-shell
tools: gsd-screensaver-proxy avail: xscreensaver dm: GDM v: 50.0
Distro: openSUSE Tumbleweed 20260515
Graphics:
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
vendor: Hewlett-Packard driver: i915 v: kernel arch: Gen-6 code: Sandybridge
process: Intel 32nm built: 2011 ports: active: LVDS-1 empty: DP-1, DP-2,
DP-3, HDMI-A-1, HDMI-A-2, HDMI-A-3, VGA-1 bus-ID: 00:02.0
chip-ID: 8086:0126 class-ID: 0300
Device-2: Chicony Integrated HP HD Webcam driver: uvcvideo type: USB
rev: 2.0 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 2-1.4:3
chip-ID: 04f2:b230 class-ID: 0e02 serial: <filter>
Display: wayland server: X.org v: 1.21.1.21 with: Xwayland v: 24.1.11
compositor: gnome-shell driver: gpu: i915 display-ID: 0
Monitor-1: LVDS-1 model: Seiko Epson 0x325a built: 2012 res: 1366x768
dpi: 101 gamma: 1.2 size: 344x194mm (13.54x7.64") diag: 395mm (15.5")
ratio: 16:9 modes: 1366x768
API: OpenGL v: 3.3 vendor: intel mesa v: 26.1.0 glx-v: 1.4 es-v: 3.0
direct-render: yes renderer: Mesa Intel HD Graphics 3000 (SNB GT2)
device-ID: 8086:0126 memory: 1.46 GiB unified: yes display-ID: :0.0
API: EGL Message: EGL data requires eglinfo. Check --recommends.
Info: Tools: api: glxinfo x11: xprop,xrandr
This is different from OP’s inxi output — this shows no display driver is loaded. For most Intel iGPUs, it should show what OP’s shows:
The intel display driver, provided by package xf86-video-intel, is mostly for truly ancient iGPUs, those unsupported by the modesetting display driver from around 2008 and older. If it’s installed, try uninstalling it.
Not correct. Both report the i915 driver as expected…
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
vendor: ASUSTeK driver: i915 v: kernel arch: Gen-6 code: Sandybridge
process: Intel 32nm built: 2011 ports: active: HDMI-A-3 empty: DP-1,
DP-2, DP-3, HDMI-A-1, HDMI-A-2, VGA-1 bus-ID: 00:02.0 chip-ID: 8086:0122
class-ID: 0300
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
vendor: Hewlett-Packard driver: i915 v: kernel arch: Gen-6 code: Sandybridge
process: Intel 32nm built: 2011 ports: active: LVDS-1 empty: DP-1, DP-2,
DP-3, HDMI-A-1, HDMI-A-2, HDMI-A-3, VGA-1 bus-ID: 00:02.0
chip-ID: 8086:0126 class-ID: 0300
As they are both using Gnome Wayland, the Xorg driver is irrelevant to this discusison.
Given that native GNOME/GTK applications render correctly while Electron/X11-related applications are garbled, this points toward a Mesa/Xwayland compositing or rendering regression affecting older Intel Gen6 hardware.
A bug report in order.
i915 is a kernel device module, for which I intentionally avoid use of the term “driver” when I write in the context of graphical.target activity, to distinguish it from display driver, even though most, including inxi, rightly equate kernel modules to and/or with drivers. Thus, my quote was indeed correct, according too mrdave68’s inxi output, in that no display driver was loaded.
I’m not going to try to question this assertion that Wayland works without any display driver, as I only use Wayland on about one out of about 300-500 boots (near zero instances of SDDM and Plasma6 use, and absolute zero instances of GDM and Gnome, so near zero DM support for opening Wayland sessions).
Nevertheless, a question remains in my mind why OP’s inxi “Display” driver output differs from mrdave68’s, when both are reported by inxi to be using “renderer: Mesa Intel HD Graphics 3000 (SNB GT2)” with their Sandy Bridge GPUs.
I agree a bug report is in order, not just for TW, but also upstream for inxi, if Wayland really does not depend on any display driver, as you and mrdave68’s inxi output both assert.
Both reported the same with respect to the “Display:” section, (except for the “X:” missing in the OP’s output which is irrelevant form a Wayland POV anyway). The “API: output” is of more interest with respect to Mesa, EGL, Vulkan info.
FWIW, here is the output I get from inxi (Plasma Wayland session):
Display: wayland server: X.org v: 1.21.1.21 with: Xwayland v: 24.1.9
compositor: kwin_wayland driver: X: loaded: modesetting unloaded: vesa
alternate: fbdev,intel dri: iris gpu: i915 d-rect: 3286x1848 display-ID: 0
In a Gnome Wayland session, Mutter talks directly to the kernel DRM subsystem via Mesa (user space driver) and KMS.
X11 applications run through Xwayland, which uses the generic modesetting path.
I did not assert that Wayland operates without display drivers. Under Wayland, the graphics stack is simply structured differently from a traditional Xorg session as I explained above. So no Xorg display driver loaded (as reported by inxi) should not be interpreted as “no graphics/display driver in use” from a Wayland context.
I have to suppose OP’s 2024 HP display might support a refresh at 2560x1440 resolution other than 60, which wlr-randr should report. If so, based on Mutter’s direct connectivity, to my list in post #5 I would add trying other(s), which might be as simple as adding e.g. video=2560x1440@75 as an additional bootloader linu line parameter, or via System Settings → Display Configuration → Refresh Rate. In Xorg sessions at least, boot parameter video= is limited to the ttys, unless the intel display driver is employed, which might be supported on Sandy Bridge.