vkcube hangs

[UjinT34]

vkcube --wsi wayland hangs/renders black screen and constantly pops ANR. Works fine in kwin. Probably caused by some explicit sync issue, acquire/release points are stuck at 1/2 values:

[3072129.293]  -> wp_linux_drm_syncobj_surface_v1#37.set_acquire_point(wp_linux_drm_syncobj_timeline_v1#41, 0, 1)
[3072129.294]  -> wp_linux_drm_syncobj_surface_v1#37.set_release_point(wp_linux_drm_syncobj_timeline_v1#41, 0, 2)

HL logs doesn't show anything interesting except [TRACE] discard for invisible surface for every frame.

WAYLAND_DEBUG logs:
vkcube-hl.log
vkcube-kwin.log

cc @gulafaran @ikalco

[gulafaran]

I havent checked sway or other tilers but it began hanging because of a vkcube commit, it even happens on that commit long before most buffer changes got merged. tried bisecting until this got posted #10437 (reply in thread)

[gulafaran]

this patch effectively reverts fcd9d77 since it seems to be the only place where this code is called. predictSizeForNewWindow has two codepaths: predictSizeForNewWindowTiled and predictSizeForNewWindowFloating. for tiled it should return 0, 0. looks like it for some reason thinks that vkcube should be floated. probably a bug in g_pXWaylandManager->shouldBeFloated or some mismatch in tiled/floating conditions in some other place.

no reversed, floated it should return 0,0 so client decides, tiled it tries to predict it so the client attaches the first buffer to the predicted size. breakpointing it, it seems to work as intended. the bug is at vkcube

[UjinT34]

Just looked at the interface default which is virtual Vector2D predictSizeForNewWindowTiled() = 0... Still should go back to 0, 0 if predicted is larger than requested

Hyprland/src/layout/IHyprLayout.cpp

Lines 981 to 984 in d890178

	Vector2D maxSize = pWindow->m_xdgSurface->m_toplevel->m_pending.maxSize;
	if ((maxSize.x > 0 && maxSize.x < sizePredicted.x) || (maxSize.y > 0 && maxSize.y < sizePredicted.y))
	sizePredicted = {};

m_pending.maxSize isn't set at this point? [3072128.418] -> zwp_linux_buffer_params_v1#40.create_immed(new id wl_buffer#33, 500, 500, 875709016, 0) happens before [3072129.248] {Default Queue} xdg_toplevel#9.configure(2048, 1440, array[0])

If only vkcube is affected then it's probably not worth fixing. This issue might affect other apps in less severe way though. E.g. incorrect initial size, floating or fullscreen state.

[gulafaran]

the first empty commit is to apply states, sizes, scales, etc. we have no maxSize set yet no. so the maxsize is default to Vector2D maxSize = {1337420, 694200}; but the predictSizeForNewWindowTiled() still returns a valid size. i still believe the fault is at vkcube and this shouldnt make other clients misbehave either unless they also break spec.

[gulafaran]

max size itself is just a hint aswell

The client should not rely on the compositor to obey the maximum size. The compositor may decide to ignore the values set by the client and request a larger size.

[gulafaran]

https://wayland.app/protocols/xdg-shell#xdg_surface:event:configure

The configure event marks the end of a configure sequence. A configure sequence is a set of one or more events configuring the state of the xdg_surface, including the final xdg_surface.configure event.

Where applicable, xdg_surface surface roles will during a configure sequence extend this event as a latched state sent as events before the xdg_surface.configure event. Such events should be considered to make up a set of atomically applied configuration states, where the xdg_surface.configure commits the accumulated state.

Clients should arrange their surface for the new states, and then send an ack_configure request with the serial sent in this configure event at some point before committing the new surface.

If the client receives multiple configure events before it can respond to one, it is free to discard all but the last event it received.

vkcube just ignores this and proceeds with the 500,500 buffer and dies breaking vulkanspec

[lfdominguez]

Happens to me:

After execute the vkcube command lag for 5 or 6 secs then show the black window with the non responsive message, on dmesg show:

[50897.636551] NVRM: GPU at PCI:0000:01:00: GPU-3e26cd63-ef49-60bc-e5db-45dec8deae7e
[50897.636556] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception on GPC 0: 3D WIDTH ZT Violation. Coordinates: (0x108, 0x0)
[50897.636622] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x500420=0x80000004 0x500434=0x108 0x500438=0xd0000 0x50043c=0x0
[50897.636730] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception on GPC 1: 3D WIDTH ZT Violation. Coordinates: (0x110, 0x0)
[50897.636795] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x508420=0x80000004 0x508434=0x110 0x508438=0xd0000 0x50843c=0x0
[50897.636879] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception on GPC 2: 3D WIDTH ZT Violation. Coordinates: (0x100, 0x0)
[50897.636944] NVRM: Xid (PCI:0000:01:00): 13, Graphics Exception: ESR 0x510420=0x80000004 0x510434=0x100 0x510438=0xd0000 0x51043c=0x0
[50897.638287] NVRM: Xid (PCI:0000:01:00): 13, pid=777786, name=vkcube, Graphics Exception: channel 0x0000003d, Class 0000c797, Offset 00000000, Data 00000000

with xcb wsi works

[lfdominguez]

But using vkcube --wsi wayland --width 3840 --height 2160 works great hehehe

[tekstryder]

It was in an off-topic thread, but I mentioned all this here:

• #10437 (reply in thread)

Likely fixed by upstream commit:

• KhronosGroup/Vulkan-Tools@36f2e75

[tekstryder]

Likely fixed

Nope I was wrong.

Built vulkan-tools 1.4.323 tag to verify a separate vkcube issue was fixed.

Unfortunately, that commit didn't change the behavior when launched tiled in Hyprland.

[code-monad]

I have met this problem too.
Not only vkcube hangs, zed editor, steam games that use wayland backend are likely to have same issue.

[gulafaran]

vkcube is a vkcube bug, KhronosGroup/Vulkan-Tools#1144 , zed editor is a nvidia bug zed-industries/zed#35948 , and what steam games?

[lfdominguez]

Yes, same, now zed editor not working El dom, 17 de ago de 2025, 13:36, Code Monad ***@***.***> escribió:

…

I have met this problem too. Not only vkcube hangs, zed editor, steam games that use wayland backend are likely to have same issue. — Reply to this email directly, view it on GitHub <#11344 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKYGIZMWBWJUI5WSEKK6RT3OCVP5AVCNFSM6AAAAACDEMIFP6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJTGI4TINI> . You are receiving this because you commented.Message ID: ***@***.***>

[lfdominguez]

So, maybe vkube add a workaround, but there are others apps that was working and now not works, like zed editor

[gulafaran]

WAYLAND_DEBUG=1 log of zed editor?

[code-monad]

No outputs, the window just hangs and no responding

[code-monad]

More information about this:

1. vkcube works with no issue in Plasma in wayland backend, but no response in hyprland with wsi platfrom wayland(x11 works), but works with param vkcube --wsi wayland --width 3840 --height 2160
2. zed will stuck on both these two, but different behaviour. in hyprland, it will hangs immediately; in plasma, it works and can open projects, editing file, but will stuck when try to close the window.
3. This happens to me after i did a system upgrade several days before. can't remember if the video drive was updated.

btw my hardware:

 CPU: AMD Ryzen 9 7950X (32) @ 5.88 GHz
 GPU 1: NVIDIA GeForce RTX 3080 [Discrete]
 GPU 2: AMD Raphael [Integrated]

nvidia driver version: 580.76.05

[gulafaran]

zed is most likely different issue then, probably even running in xwayland

[gulafaran]

yeah zed is nvidia driver bork. zed-industries/zed#35948 , just tried it locally, WAYLAND_DISPLAY= zeditor to force it to xwl makes it run.

[tekstryder]

This is fixed with Vulkan 1.4.328 release.

vkcube and vkgears no longer require to be set floating, and work as expected in tiled windows with default options.

Fullscreen, floating, and user-specified dimensions also work without any issue.

==========
VULKANINFO
==========

Vulkan Instance Version: 1.4.328


Instance Extensions: count = 24
-------------------------------
VK_EXT_acquire_drm_display             : extension revision 1
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_EXT_surface_maintenance1            : extension revision 1
VK_EXT_swapchain_colorspace            : extension revision 5
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_portability_enumeration         : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6
VK_LUNARG_direct_driver_loading        : extension revision 1
VK_NV_display_stereo                   : extension revision 1

Instance Layers: count = 3
--------------------------
VK_LAYER_KHRONOS_validation Khronos Validation Layer 1.4.328  version 1
VK_LAYER_NV_optimus         NVIDIA Optimus layer     1.4.312  version 1
VK_LAYER_NV_present         NVIDIA GR2608 layer      1.4.312  version 1

Devices:
========
GPU0:
	apiVersion         = 1.4.312
	driverVersion      = 580.95.5.0
	vendorID           = 0x10de
	deviceID           = 0x1c82
	deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU
	deviceName         = NVIDIA GeForce GTX 1050 Ti
	driverID           = DRIVER_ID_NVIDIA_PROPRIETARY
	driverName         = NVIDIA
	driverInfo         = 580.95.05
	conformanceVersion = 1.4.1.3
	deviceUUID         = 3973861e-23b6-6c51-70e7-60235a3f1ebf
	driverUUID         = b92269a1-b525-5615-ab8a-e2095ee37192

$ hyprctl version
Hyprland 0.51.0 built from branch main at commit b965fb2a40b132209b58f511e2604a2939461818 dirty (flake.lock: bump hyprutils).
Date: Thu Oct 9 01:35:34 2025
Tag: v0.51.0-70-gb965fb2a4, commits: 6488

Libraries:
Hyprgraphics: built against 0.2.0, system has 0.2.0
Hyprutils: built against 0.10.0, system has 0.10.0
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.3, system has 0.6.3
Aquamarine: built against 0.9.5, system has 0.9.5

flags set:
no xwayland

I see KhronosGroup/Vulkan-Tools#1144 is still open to track that issue, if it's valid.

However the Hyprland issue is fixed with the new upstream release.

@UjinT34 , please test and consider closing this issue if you can no longer reproduce.

[gulafaran]

KhronosGroup/Vulkan-Tools@e3ecc39 yeah seems to be fixed