01:38 bleb: in kde I changed my cursor theme from breeze to adwaita
01:39 bleb: after rebooting, the cursor looks correct, except when it is in the shadow of the firefox window it reverts to breeze
01:40 bleb: I read that under wayland each application is responsible for drawing the cursor including when it's over the shadow of the window
01:41 bleb: so it seems like maybe firefox has cached the old cursor somewhere and it comes back even after reboot
01:42 bleb: is there a way to tell firefox to forget the cursors it drew in the past, so that it loads them properly from my current settings?
01:43 bleb: I don't have the problem with other applications, but I did have firefox open at some point before I changed the cursor
02:01 bleb: hmm so I uninstalled firefox and nuked ~/.mozilla, then reinstalled
02:01 bleb: and I still have the same problem!!
07:59 ifreund: bleb: Firefox uses gtk3 which is responsible for drawing the cursor
07:59 ifreund: you probably need to tweak some GNOME setting or something
08:00 ifreund: hopefully GTK will support the cursor-shape-v1 protocol eventually, which would make this much smoother
08:08 tkna: Hi, The music creation software Renoise does not allow clipboard copy/paste to Wayland and I am going to make that request to the author. Is it advisable to have them read this page? Is there any other appropriate documentation? https://emersion.fr/blog/2020/wayland-clipboard-drag-and-drop/
08:28 dottedmag: tkna: Does Renoise use any toolkits? If it does, then this blog post is counterproductive.
08:31 WhyNotHugo: I have a toplevel which I want to move around by click-dragging on any part of it. When the user clicks, I would call xdg_toplevel::move. But it's not clear to me how to _actually_ move the toplevel once the move is taking place, nor how to _end_ the move sequence when the mouse is released.
08:38 kennylevinsen: WhyNotHugo: when you call move, if approved the server takes over - you lose pointer focus during, and only maybe get it back afterwards when the move is done
08:38 kennylevinsen: How the window is moved and stuff like stopping when the button is let go is implemented in the compositor
08:40 tkna: dottedmag: Renoise does not use GTK, QT, etc. It should be accessing something like SDL, just like the game. But the real problem is that Renoise does not yet support Wayland and Renoise running on my sway's Xwayland cannot access the clipboard. I may need to get the X11 clipboard to work in my environment. I will investigate this a bit.
08:46 llyyr: Is a client expected to handle keys pressed in the wl_keyboard::enter event? see discussion here https://github.com/mpv-player/mpv/pull/14210#issuecomment-2149324783
08:47 soreau: kennylevinsen: should you only get an enter event after moving the mouse after the move grab is finished? or should it happen immediately on grab end, and who's in charge of this behavior?
08:49 ifreund: llyyr: mahkoh's comments seem pretty accurate to me
08:50 ifreund: as I understand it, the keys arg of the enter event exists to ensure that release events sent for keys held on enter make sense
08:51 soreau: but you can still know which modifiers are pressed at least..
08:51 soreau: (on enter)
08:54 WhyNotHugo: kennylevinsen: ah, so when the cursor is released the move is finished by the compositor (assuming the typical desktop compositor). My client doesn't need to do anything, right?
08:54 soreau: WhyNotHugo: right
08:54 soreau: you just call move and.. that's it
08:54 WhyNotHugo: thanks. Nice and simple.
08:54 WhyNotHugo: Now I wish layer-shell have a move request too
09:02 dottedmag: tkna: SDL has a Wayland backend, so if enabled it probably will work just fine
09:03 dottedmag: My guess will be that enabling it is going to require some changes to the software, it usually is.
10:22 kennylevinsen: soreau: From the perspective of the spec, you just lost focus when the move started and there's no guarantee you get it back
10:25 soreau: kennylevinsen: oh no ;)
10:27 soreau: I think if the compositor is sane enough, you can at least expect enter on mouse move after grab end
10:28 soreau: but it seems like the better behavior would be to send enter on button released
10:36 bluetail: Hello. A lot of people who switch to Wayland made implementations complain about 'floaty' or 'laggy' mouse cursor. coming from x11. How can we make sense of that, is there any truth to it?
10:41 soreau: bluetail: I think the best way for you to find out is to try some wayland compositors (on real hw) and see for yourself
10:43 bluetail: soreau the only thing I can say for sure that the FPS for some x11 based games is frequently dipping. And just this week the OpenGL backend of dolphin-emulator broke suddenly, showing invisible textures. So I use Vulkan.
10:43 soreau: bluetail: what changed that broke dolphin?
10:43 bluetail: I do >not know<. I am sorry about that.
10:43 bluetail: But I got a good excuse.
10:44 dottedmag: bluetail: I saw laggy cursor somewhere once, I think it was an app that rolled everything itself instead of using a toolkit. This is most likely a bug.
10:44 bluetail: I reported https://bugs.winehq.org/show_bug.cgi?id=57120 which is super important to know when using any application running from wine. If you are not on coordinates 0,0, then you won't be able to interact with the x11 wine implementation of that application.
10:44 bluetail: and yep, from wayland
10:44 bluetail: dottedmag I see. Thanks for your insights!
10:46 soreau: if you're using mesa drivers, you might try vblank_mode=0 so clients render as fast as possible
10:46 soreau: for transparent textures, is there a screenshot or issue anywhere?
10:46 bluetail: Sure, I will provide one
10:48 soreau: but I'm a bit confused.. are you saying that dolphin only breaks when using it in wayland gl mode? and x11 gl mode works?
10:51 bluetail: soreau thats a good idea to test. BUT no, I say the opengl thing broke, I am using amdgpu and I am on latest. https://up.tail.ws/images/opengl-fzero-dolphin-latest.png
10:51 bluetail: I experience the exact same behavior using a old Dolphin build just for smash bros melee, called ishiruuka
10:52 bluetail: Let me check if on i3 it works properly.
10:52 soreau: so the problem is not that it's transparent to what is behind the application
10:52 bluetail: Probably, I am not good at articulating
10:53 soreau: it's most likely a bug in dolphin emulator but maybe less likely, a bug in mesa
10:53 bluetail: noo
10:53 bluetail: it cant be a dolphin bug
10:53 bluetail: it used to work, and it misbehaves both on most recent and really old build
10:53 bluetail: let me check from i3
10:53 soreau: presumably you're using sway to test wayland?
10:54 bluetail: yea, with minimum config
10:56 bluetail: same behavior in i3 (x11)
10:57 soreau: so if you didn't upgrade dolphin and it was working but now not, it might be that upgrading mesa broke it somehow but I still think it's more likely a bug in dolphin or some config option changed in settings
10:58 bluetail: or corruption. But for corruption snapraid should have told me. But then it wouldn't work with Vulkan backend
10:59 soreau: you can also try dolphin GL on zink
10:59 soreau: if that makes any difference, maybe it is a driver bug
10:59 bluetail: headache. I used to know how to enforce zink.
10:59 soreau: but idk if dolphin will even run on zink, never tried it
11:00 bluetail: u can even force java to do that. It's translation work
11:01 bluetail: Well, I am not up-to-date with mesa. https://aur.archlinux.org/packages/mesa-git
11:01 bluetail: maybe I should try building mesa-git from outside of AUR?
11:02 soreau: why outside?
11:04 bluetail: because I need to alter PKGBUILD because it is 9 subversions older than latest commit on gitlab
11:04 bluetail: and I don't know what to put into pkgver...
11:05 bluetail: otherwise I would just put latest commit 3886a3014d5ba132f9ceced00b44b3bf0daa1ca8 into it, but I doubt that'll do
11:05 soreau: well you can, but I would recommend installing to a nonstandard prefix and pointing LD_LIBRARY_PATH at the relevant directory to use it
11:05 soreau: then you can compare easily with system mesa and git
11:06 soreau: and this way if git's broken, you don't bork your system mesa
11:06 bluetail: soreau I think you overestimate me. I probably need to google quite a bit for that :D
11:07 soreau: not so much, it's just changing the --prefix, really :P
11:19 llyyr: ifreund: would it make sense to add text to the protocol to convey these things more clearly? I understand that there's no guarantee the keys array in the enter event may not be in the order they were pressed, so I shouldn't rely on that assumption, but it doesn't prevent someone from reading it that way and I honestly don't feel like arguing about this with people
11:19 llyyr: see: https://github.com/mpv-player/mpv/pull/14803#issuecomment-2333818724
11:19 llyyr: I'm also fine with making an issue on w-p repo so someone could respond to it with clarification that I could then link on that PR
11:22 soreau: also, there's nothing stopping key duplicates, IIRC
11:22 llyyr: but if someone wants to argue "Wayland doesn't tell me I can't make my client put itself on fire and abort, so I will do that" then what can I do?
11:23 kennylevinsen: well
11:23 soreau: tell them they're doing it wrong? *shrug*
11:23 kennylevinsen: Wayland doesn't tell you that your client can't put itself on fire and abort, that's juts bad UX
11:24 kennylevinsen: Wayland dictates some policies and mechanisms, but there are limits to what's within our "jurisdiction"
11:24 kennylevinsen: I left a comment
11:25 soreau: yea like requiring compositors to blacken behind fullscreen surfaces in the spec, I still think this part should be removed, since a compositor can disable scanout for transparent views and render behind it just fine if it wants
11:29 wlb: wayland Merge request !424 opened by () protocol: clients should not emulate key-press events on enter https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/424
11:38 bluetail: what is fire and abort? Is this holding space on a button, exiting the 'proposal' with escape so that it does NOT fire the button?
13:20 MrCooper: bluetail: 'floaty' or 'laggy' mouse cursor is an issue of the specific compositor, the Wayland protocol doesn't say anything about how the compositor should handle cursor movement
13:20 bluetail: MrCooper I blame xwayland tho
13:20 bluetail: like I don't believe sway or KDE is the cause
13:20 MrCooper: Xwayland isn't involved in cursor movement in any way
13:21 bluetail: MrCooper thats the point
13:21 MrCooper: it's all compositor internal
13:21 bluetail: people may feel mouse being floaty when fps isn't stable enough
13:21 bluetail: I know games where you get frequent 7 fps dips
13:22 bluetail: from my side, mouse never felt any floaty / laggy. Game did in some circumstances
13:22 MrCooper: hmm, are you talking about the actual cursor, or something drawn by the game as part of its window?
13:27 bluetail: I think they refer to the cursor as it is not asynchronous to the game drawing
13:27 bluetail: so the game feels stuttery sometimes
13:27 bluetail: at least thats what I think. I could be wrong
13:31 MrCooper: the cursor can move independently from game drawing though
13:31 ofourdan: most likely a game drawn cursor, I suspect…
14:18 bluetail: Keep in mind, only assumptions. MrCooper in FPS, you move your weapon with the mouse most likely. So when they talk of the cursor, they mean that the movement is disrupted. As effect,there can be a delay in the action and it being delayed / feels like missing target consecutively.
14:19 zamundaaa[m]: That sounds more like being used to a different acceleration curve than anything else
14:37 MrCooper: if you were talking about FPS games, "mouse cursor" was a bit confusing terminology
15:10 bluetail: Maybe we should get input from the users complaining and not talk through a filter. I don't feel comfortable doing that.
15:10 bluetail: Theres enough people complaining [...]
22:19 wlb: weston Merge request !1611 opened by () tests: Make the kiosk test dependent on the shell-kiosk option https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1611
22:50 llyyr: is there a way to figure out which edge/corner is being used for resize if it comes from ssd?