Windows build number:
26200.8037
Your Distribution version:
24.04
Your WSL versions:
WSL version: 2.7.1.0
Kernel version: 6.6.114.1-1
WSLg version: 1.0.73
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8037
Steps to reproduce:
- Start any WSLg GUI application
- Verify cursor changes shape correctly (e.g. I-beam over text areas)
- Put the system to sleep
- Wake the system
- Hover the cursor over the WSLg application window
WSL logs:
No response
WSL dumps:
No response
Expected behavior:
Cursor continues to update its shape based on what is under it within the WSLg application, as it did before sleep.
Actual behavior:
Cursor remains as the default Windows arrow pointer regardless of what it hovers over within the WSLg application. The application itself remains responsive.
Workaround
Restarting the Weston compositor restores correct cursor behaviour without restarting the application:
wsl --system sh -lc "pkill -9 weston"
Rolling back to WSL 2.6.1.0 prevents the issue entirely.
Windows build number:
26200.8037
Your Distribution version:
24.04
Your WSL versions:
WSL version: 2.7.1.0
Kernel version: 6.6.114.1-1
WSLg version: 1.0.73
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8037
Steps to reproduce:
WSL logs:
No response
WSL dumps:
No response
Expected behavior:
Cursor continues to update its shape based on what is under it within the WSLg application, as it did before sleep.
Actual behavior:
Cursor remains as the default Windows arrow pointer regardless of what it hovers over within the WSLg application. The application itself remains responsive.
Workaround
Restarting the Weston compositor restores correct cursor behaviour without restarting the application:
wsl --system sh -lc "pkill -9 weston"
Rolling back to WSL 2.6.1.0 prevents the issue entirely.