hyprwm
cursor behaves weirdly on Nouveau-driven displays
Hyprland Version
System/Version info
Hyprland, built from branch at commit 25aec3ac8ce65ed224f025f8f6dfef73780577a4 ().
Date: 2024-04-27
Tag: , commits: @COMMITS@
flags: (if any)
System Information:
System name: Linux
Node name: e6nix
Release: 6.8.7-xanmod1
Version: #1-NixOS SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980
GPU information:
00:02.0 VGA compatible controller [0300]: Intel Corporation CometLake-H GT2 [UHD Graphics] [8086:9bc4] (rev 05) (prog-if 00 [VGA controller])
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / Max-Q] [10de:1f99] (rev a1) (prog-if 00 [VGA controller])
os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.05.20240425.7bb2ccd"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.05 (Uakari)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.05 (Uakari)"
VERSION_CODENAME=uakari
VERSION_ID="24.05"
plugins:
Bug or Regression?
Regression
Description
when using Hyprland on a display driven by Nouveau (not the proprietary Nvidia driver!), the cursor (xcursor, hyprcursor, doesn't matter) behaves weirdly (fails to switch graphics but switches the offsets for example), whereas on other displays (Intel in my case) it's fine this does not happen on Hyprland v0.39.1
How to reproduce
- get an nvidia card
- use nouveau with hyprland
- watch as cursor trolls you
Crash reports, logs, images, videos
~~i tried screen recording this with OBS but it magically fixed itself once i started recording it????~~ phone footage never fails
https://github.com/hyprwm/Hyprland/assets/17727163/f9ebb78a-4911-4706-ae90-539403f4f1ba
can you
git bisectthis
i can try but i havent really done it before soo guess ill have fun
# only skipped commits left to test
# possible first bad commit: [cbed4fa5ec1c7e5b383964ce5783eba6bbed7736] flake.lock: update
# possible first bad commit: [a4f38a07d7578f0b06c09de7d04682e0aaddb12a] Nix: override wayland-protocols until merged
# possible first bad commit: [019d4900cb132f2ff43fea49334712a12c282a14] [gha] Nix: update wlroots
# possible first bad commit: [448e3208cae4f19d48021572d50b9d29efc1d74b] deps: update wlroots
# possible first bad commit: [8afdb8403bf71daf7e25bffbbdd87e0e3e61913c] style: fix clang-format
# possible first bad commit: [f041d763ae1d5ec58682e3ff1fe3159ba9c95a49] relative-pointer: fix missing header for g_pCompositor (#5681)
# possible first bad commit: [f587c3e0ba92109302032f89321d94b5d0f89236] alpha-modifier: add support for protocol
# possible first bad commit: [87173bd09daa4b56adabcfc72a29aec957cb8a13] protocols: fix for hyprwayland-scanner update
was skipping commits that were failing to build under Nix
448e3208cae4f19d48021572d50b9d29efc1d74b likely then, would make sense because https://github.com/hyprwm/wlroots-hyprland/compare/b9063af512a2326d5c519edc6a759da875deab21...5c1d51c5a2793480f5b6c4341ad0797052aec2ea#diff-07106da4199077936452d36747b7be0f942ec2be012f166a7968aac696e0559e
are you using hardware cursors? if so, try disabling them.
yep, that seems to be it. reverting 448e3208cae4f19d48021572d50b9d29efc1d74b and 019d4900cb132f2ff43fea49334712a12c282a14 mitigates the issue, and so does disabling hardware cursors (which explains why trying to record it with OBS 'magically' fixed it)
now i wonder why that breaks Nouveau but I'm guessing fixes the situation on the proprietary Nvidia driver. hardware cursors work fine on Nouveau before that patch
Yeah, feel free to tinker with the patch (maybe we should disable the functionality if nouveau is being used?)
it's definitely a wip patch for a reason, but for proprietary it did work
i know nothing about wlroots's code so i'm not really sure how i should go about fixing up the patch to work under nouveau or how to disable it if it's rendering to nouveau
Well the patch is its own file that you can remove or give a new name that doesn't end with .patch and the script won't apply it
Well the patch is its own file that you can remove or give a new name that doesn't end with
.patchand the script won't apply it
@Agent00Ming i'm aware but that's not going to be very fun to do from Nix and ideally should be fixed instead of mitigated
your solution for now is forcing no hardware cursors with WLR_NO_HARDWARE_CURSORS
Well the patch is its own file that you can remove or give a new name that doesn't end with
.patchand the script won't apply it@Agent00Ming i'm aware but that's not going to be very fun to do from Nix and ideally should be fixed instead of mitigated
We could add an option for enabled/disabled patches. But the better approach is simply overrideAttrs and modifying the postPatch or preConfigure phases.
{ pkgs, inputs, ... }:
let
hlPkgs = inputs.hyprland.packages.${pkgs.system};
in
hlPkgs.hyprland.override {
wlroots-hyprland = hlPkgs.wlroots-hyprland.overrideAttrs {
preConfigure = ''
rm patches/nvidia-hardware-cursors.patch
'';
};
}
does the trick for me :)
(assumes the Hyprland flake is in inputs in specialArgs)
I wonder whether you're actually using hardware cursors without the patch, or is the only reason why it's not jumping some fallback to software.
with hardware cursors off I can see them in my screenshots so it's definitely not falling back to software cursors
On 28 Apr 2024 19:49, Vaxry @.***> wrote:
I wonder whether you're actually using hardware cursors without the patch, or is the only reason why it's not jumping some fallback to software.
— Reply to this email directly, view it on GitHubhttps://github.com/hyprwm/Hyprland/issues/5776#issuecomment-2081573870, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEHH5O7OXP73TLUR7ERR2KTY7UZDZAVCNFSM6AAAAABG4K2HPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBRGU3TGOBXGA. You are receiving this because you authored the thread.Message ID: @.***>
I have the same problem as shown in the video. However, after setting WLR_NO_HARDWARE_CURSORS, I'm still seeing the same behavior. Somehow it works for a few seconds after logging in, but soon after starting FIrefox, the cursor reverts to the old behavior.
After also setting cursor::no_hardware_cursors = true in the Hyprland config file, it finally works. But now the cursor sometimes leaves traces behind.
how to repro?
Connect an external monitor to HDMI output that uses the discrete NVIDIA GPU. If hardware cursors are enabled in the hyprland config file, the cursor, while on the external monitor, behaves like shown in the video (offsets change as they should but the type stays the same).
After disabling hardware cursors, the cursor shows correctly but leaves a ghost trail behind on some surfaces.
Also, in my case, the WLR_NO_HARDWARE_CURSORS environment variable seems to be ignored by hyprland.