10:42 <Guest25> Hi, i'm running river with nouveau and xf86-video-nouveau and the mouse cursor is moving extremely slow. I am currently running the example init file.

10:43 <Guest25> The mouse cursor slows down if 1. i have windows open on two monitors (i only have a need for one, so i disabled the other) 2. i run applications like firefox (mouse slows down a lot) and waybar (mouse movement comes to a halt almost completely)

10:49 <Guest25> If i change to a different workspace with no window present the mouse cursor is speedy again.

10:50 <Guest25> i tried both WLR_NO_HARDWARE_CURSORS=1 and 0

11:01 <leon-p> Guest25: what do the logs say?

11:05 <Guest25> waybar itself (launched on the terminal) throws no errors, "sudo -f journalctl" throws errors regarding the portal service

11:06 <Guest25>  Failed to start Portal service (GNOME implementation). This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Failed to start Xdg Desktop Portal For KDE.  Failed to start Portal service.

11:09 <Guest25> Umm... One thing i might have done wrong is forgetting -Dxwayland while building. Might that be it?

11:10 <leon-p> no

11:10 <leon-p> that just means you have no XWayland

11:10 <leon-p> also I meant rivers logs :)

11:11 <leon-p> start river with `river -log-level debug 2> river-logs`

11:32 <Guest25> log incoming (:

11:35 <Guest25> https://paste.opensuse.org/abf343fc

11:49 <leon-p> ah, as I expected: nouveau is failing and wlroots is falling back to software rendering

11:51 <leon-p> probably a driver bug?

11:52 <leon-p> actually, I think line 16 indicates that a library is missing

11:54 <Guest25> Mesa and Mesa-dri packages are installed on openSUSE. But yeah that line is worrysome

11:56 <Guest25> There is a package Mesa-dri-nouveau, which i have not installed. It warns that is experimental stuff so i didn't  bother. The package "Mesa-dri" also has "3D acceleration" in it's discription

12:00 <Guest25> That package includes the missing so file, so i will try and see if the problem is then solved

12:01 <Guest25> thanks for troubleshooting :)

12:03 <Guest25> Just reporting back, problem solved! Aesome thanks :)

14:43 <novakane> ifreund: any reason zig-wayland doesn't have wl_display_prepare_read?

16:21 <leon-p> managed to soft-lock river again

16:21 <leon-p> not sure if I can reproduce though

16:22 <leon-p> yes, I can reproduce :D

16:25 <leon-p> I am connecting to an ftp server with nautilus (via gvfs) and when the server is slow to respond / the connection is failing and I try to manually disconnect, river does not respond until nautilus crashes. Moving the mouse cursor works, but nothing else. If I have a terminal open and Ctrl-D it, the shell will exit but the view won't close until river is good again. Switching to a TTY still works, where some riverctl commands work (f.e. quit) while

16:25 <leon-p> others don't (close, list-inputs, focus-previos-tags, etc.)

16:31 <novakane> how do you manage to always crash river :P

16:43 <leon-p> well, it's not a crash, after a minute or so nautilus usually dies and river is good again :D

16:44 <leon-p> but it's probably because of the hardware. It's not particularly fast, so I'll probably notive things a bit stronger and longer that on more modern hardware isn't quite as noticable

16:45 <leon-p> my current hypothesis is that fuse manages to gobble up all IO time. Maybe I'll need to play with rivers IO niceness a bit.

16:47 <novakane> you just need to upgrade these hardware and stop blaming river :P

16:47 <novakane> but I guess better IO would be great too :D

16:49 <leon-p> I'll upgrade as soon as there is a more modern device with libre firmware and no IME / PSP crap. So probably not anytime soon :P

16:49 <leon-p> *affordable device

16:49 <leon-p> the Power9 architecture by IBM is pretty close to what I'd like, but nowhere near my price range

16:50 <ifreund> novakane: no particular reason, I probably just skipped it as I think mixing threads with libwayland is a bad idea

16:51 <ifreund> that said, I wouldn't be opposed to adding bindings for it

16:52 <novakane> leon-p: yeah affordable not gonna happen soon unfortunately

16:53 <novakane> ifreund: allright, so what would be the better solution for multithread, just using system library?

16:57 <novakane> and client_display_functions.zig is like wayland-client-core.h?

16:59 <ifreund> novakane: better solution would be to avoid threads altogether :P

17:00 <ifreund> I suppose they do have some use cases though

17:00 <ifreund> client_display_functions.zig is only the wl_display_* functions from wayland-client-core.h

17:01 <leon-p> as long as you only do Wayland things in one single thread it should be fine, the problems arise when you have multiple threads trying to send and receive things. You can get by using message queues, but it's not very nice.

17:02 <novakane> well yeah but trying to do a wayland lemonbar I'm not sure how I could avoid multi threads, I spend way too long thinking about the design/abstractions lol

17:03 <novakane> ifreund: thanks maybe I'll do the missing functions then

17:03 <leon-p> novakane: do you really run into problems when using only a single thread? Can't you just poll?

17:05 <ifreund> you may need a separate thread for non-blocking read/write I/O without io_uring

17:06 <ifreund> that doesn't mean you can't keep your libwayland usage to a single thread though

17:06 <leon-p> for a status bar, non-blocking read/write is probably a bit overkill

17:06 <ifreund> I would do nearly anything to avoid multiple threads though

17:06 <ifreund> yes indeed, I'm sure lemon bar just blocks

17:07 <leon-p> I'd just arrange the event loop so that Wayland events take precedence over stdin being readable and it should be fine

17:07 <novakane> well I try with one thread then, I"ll see what I can do

17:08 <novakane> one of my problem is the order of info I receive, I feel like sometime wayland events are random ^^

17:08 <leon-p> unless the order of events is specified, then they effectively are

17:09 <leon-p> but this is really not that different from your river-tag-overlay clone: just instead of a timeout you have an additional fd

17:11 <novakane> yeah I'm trying to use wl_surface.frame(), it's not conclusive at the moment^^

17:11 <leon-p> I think I use that in lavalauncher, if you need an example

17:12 <novakane> I think I started with too many idea at the same time

17:12 <leon-p> wl_surface.frame only really makes sense if you expect to render many times a second

17:13 <novakane> yeah? like for a clock module or something like that, like someont using sleep 1 it doesn't makes sense?

17:13 <leon-p> not really I think

17:15 <leon-p> and you can always add it later, if it turns out you do need it

17:15 <ifreund> novakane: generally wl_surface.frame will be called at roughly the output's refresh rate if the surface is visible, which means 60 times a second or more

17:15 <ifreund> that's 60 times more often than a clock needs to be re-rendered

17:15 <novakane> ah yeah doesn't makes sense then, thanks

17:15 <ifreund> also I personally wouldn't want my status bar sucking up so much cpu rendering that often

17:16 <novakane> I don't see a use case where something would be updated so often yeah

17:16 <leon-p> ^ only if you attach it that often, IIRC an instance dies after receiving the event

17:16 <ifreund> yes, if you always create a new callback after rendering

17:17 <leon-p> you are free to delay your rendering after receiving a frame callback. I only use it to reduce rendering on mouse movement events.

17:20 <novakane> well I'm gonna simplify all that, already spend too much time on the wayland part wich is the simplest part :P

17:48 <novakane> the zig-wlroots ci is really a mystery :/

17:50 <ifreund> yeah, no idea what's up there

17:56 <novakane> that's annoying, and good luck for debugging somthing like this

18:23 <novakane> how safe is it to select an output with wl_output.name? I mean using like a flag --output "eDP-1" to chose the monitor

18:36 <Guest26> Hi, i'm running the latest river release and my touchpad does not work, so i tried issuing the "rivertctl list-inputs" command and get "error: The Wayland server does not support river-control-unstable-v1; Do your versions of river and riverctl match?" -> How can river and riverctl not match, since they are build and installed from the same repo ?

18:36 <Guest26> -> Do you have any suggestions how i can get the riverctl command working again?

18:40 <novakane> so on river 0.1.3?

18:42 <Guest26> glad you asked :) river -version shows 0.2.0-dev-8943307, i had the wrong assumption that building from the master branch would have the stable version

18:44 <leon-p> novakane: pretty safe, I guess.

18:45 <leon-p> Guest26: it's actually quite easy to have mismatched river and riverctl version. For example instead of installing with zig build, some people manually copy the executable

18:46 <novakane> leon-p: I hope so because it the easiest way

18:46 <Guest26> ah ok. Anyways, i'm off trying with 0.1.3 and willl report back here :)

18:47 <novakane> how did you install it? you shouldn't have any problem with master

18:48 <leon-p> novakane: it's not the easiest way, I am pretty sure it's the /only/ way to match outputs

18:49 <leon-p> but be prepared for the case that the server does not send that events

18:49 <leon-p> I don't think it's mandatory

18:49 <novakane> right, so still the easiest way, also the hardest :P

18:50 <novakane> yeah I probably use the first output in the list if the name is null

18:51 <leon-p> I'd probably sync after binding the registry and then sync again after the sync handler has been called the first time. By the second time the sync handler is called, it's pretty safe that you'll have received wl_output.name events for all outputs you have bound during the initial registry wave.

18:54 <novakane> yep, that's what I have

19:02 <Guest26> Ok i'm here again, with river 0.1.3 riverctl works again. I tried configuring the touchpad, but that doesn't work.  I configured the touchpad like so: "riverctl list-inputs" -> Chose device with "*_Touchpad" and  "type: pointer" and "configured: true" and then isued the commands "riverctl input INPUTNAME events enabled" "riverctl input INPUTNAME

19:02 <Guest26> tap enabled" "riverctl input INPUTNAME tap-button-map left-right-middle" with INPUTNAME being XXXX:XXXXX:XXXXXXXX:XX_XXXX:XXXX_Touchpad".

19:04 <leon-p> the latest release changed the format of input device names, are you sure you got the right one?

19:08 <novakane> heh classic zig :P https://0x0.st/o84r.txt

19:09 <leon-p> :D

19:18 <Guest26> leon-p: Well i just took the name output by "riverctl list-inputs" and used that.

19:21 <leon-p> did you run riverctl list-inputs before or after updating river?

19:21 <Guest26> after building river 0.1.3

19:21 <leon-p> because the naming scheme XXX:XXX:XXX_Touchpad you said to have used is definitely wrong for version 0.1.3

19:22 <Guest26> river -version shows 0.1.3.

19:23 <leon-p> whoops, wait a minute

19:23 <leon-p> ifreund: I think you made a mistake when tagging 0.1.3, you included the first commit from the input dev name PR, but not the second :D

19:24 <Guest26> :D do i need to move one commit furhter?

19:24 <ifreund> leon-p: wasn't the second a breaking change?

19:24 <leon-p> yes, it was

19:24 <ifreund> it can't be in 0.1.3 then, it would have to be 0.2.0

19:25 <leon-p> makes sense, I was somehow under the impression it belonged into 0.1.3

19:26 <leon-p> Guest26: you don't necessarily need to update to master branch, use the device names your current river version gives you

19:36 <Guest26> yeah i'm fiddling around but the touchpad is not doing anything

19:37 <leon-p> riverctl list-inputs should show whether the device is configured or not. That's a good way of seeing if you used the right device name

19:39 <Guest26> configured: yes and type: pointer

19:39 <Guest26> configured: true

19:40 <leon-p> well, then the problem is probably the command

19:41 <novakane> and what does `riverctl list-input-configs` say?

19:41 <Guest26> 1739:32552:MSFT0001:00_06CB:7F28_Touchpad

19:41 <Guest26>     events: enabled

19:41 <Guest26>     natual-scroll: enabled

19:41 <Guest26>     tap: enabled

19:41 <Guest26>     tap-button-map: left-right-middle

19:43 <novakane> doesn't looks like the problem comes from here then

19:43 <Guest26> ok :) so the kernel might be at fault

19:44 <Guest26> I will reboot and  try gnome or kde and see if the touchpad works there

19:44 <Guest26> Thank your for your help