06:50 <leon-p> I think I've finally come up with a neat bind abstraction that keeps the API simple without being too restrictive

06:50 <leon-p> binds are ordered in bind-groups; I figured that enabling/disabling binds will always be done in groups, so that's what they are for

06:51 <leon-p> the API makes no difference between pointer- and keybinds, mouse buttons are key names just as keyboard keys are

06:52 <leon-p> the bind triggers a callback, which is per-seat and just dumps the modifier description and keyname back as strings, so the user does not need to know xkb stuff

06:52 <leon-p>

06:52 <leon-p>

06:53 <leon-p> also I am treating shift as an implicit modifier, i.e. I don't allow setting it, and instead keynames are case sensitive

06:53 <leon-p> (this of course forbids certain things, like shift-space, but that is pretty wonky anyway)

06:54 <leon-p> works quite well in practice, only thing left is to wire up pointer binds and clean it up before I commit+push

06:54 <leon-p> after that I can finally add my own UI elements and then we're up to like 0.65 feature-parity with twm :)

06:56 <leon-p> UI stuff will be the most restrictive and most abstracted-away thing in the library I think, because I imagine having basic but limited widgets is better then having to do everything by hand if you want to have fun

09:39 <AlmostSurelyRob> Hello,

09:39 <AlmostSurelyRob> I seem to have a bit of a heat problem when using river, could you please advise? When running the same monitor setup in Gnome Shell and River I get respectively 40-50C and 70-90C. This seems like a lot and it happens even if I don't do anything - just launch a session and leave it.

09:39 <AlmostSurelyRob> My config, I think is pretty simple. I just use kanshi for monitors, mako for notification and swayidle for idle, I was commenting them out to see if any of them is an issue

09:39 <AlmostSurelyRob> https://pastebin.com/c3EMvuDC

09:39 <AlmostSurelyRob> https://pastebin.com/Md332D5c

09:39 <AlmostSurelyRob> I also tried

09:40 <AlmostSurelyRob> Hello,

09:40 <AlmostSurelyRob> I seem to have a bit of a heat problem when using river, could you please advise? When running the same monitor setup in Gnome Shell and River I get respectively 40-50C and 70-90C. This seems like a lot and it happens even if I don't do anything - just launch a session and leave it.

09:40 <AlmostSurelyRob> My config, I think is pretty simple. I just use kanshi for monitors, mako for notification and swayidle for idle, I was commenting them out to see if any of them is an issue

09:40 <AlmostSurelyRob> https://pastebin.com/c3EMvuDC

09:40 <AlmostSurelyRob> and it executes within the following wrapper script:

09:40 <AlmostSurelyRob> https://pastebin.com/Md332D5c

09:40 <AlmostSurelyRob> Sorry, I managed to double post... bad habits from Slack.

09:41 <vyivel> check cpu load by process?

09:41 <AlmostSurelyRob> My monitor setup may be be a bit unusual. I am running on a laptop, but using USB/Thunderbolt (home/office) docking station which has two monitors connected via DP. There's an NVIDIA card, but all of it is running on CPU as far as I know as I couldn't get river to work with NVIDIA.

09:43 <AlmostSurelyRob> Yes, so I am watching it with bpytop and htop and all I can see is that with river I have intermittent high usage of CPUs, but I can't narrow down which process is causing it.

09:43 <AlmostSurelyRob> It terms of memory footprint river is almost half that of Gnome shell, so I feel it should be better rather than worse in terms of overheating?

09:47 <AlmostSurelyRob> Could you please comment on two possibilities I'd like to check/eliminate

09:47 <AlmostSurelyRob> 1. I am logging river output to a file in $HOME river .. 2>&1 > river.log

09:47 <AlmostSurelyRob> 2. In bpytop Xwayland options are quite a bit different.

09:48 <AlmostSurelyRob> I do have two screenshots from bpytop I could share, but if there's anything better you could suggest to debug this.

09:48 <AlmostSurelyRob> The cooling fan action is very perceptible. Just swithing to Gnome Shell will make it all go quite in a matter of 1-2 minutes.

09:50 <vyivel> redirecting log messages to a file shouldn't affect performance much

09:50 <vyivel> neither should xwayland options

09:51 <vyivel> maybe you have some kind of service which tries to start over and over and fails for whatever reason?

09:55 <AlmostSurelyRob> Oh, that's a useful hint, thanks. This is very likely. I am going to run pidstat on both sessions and see. On river, river doesn't even make to top 5...

09:56 <AlmostSurelyRob> It's mostly systemd, irq/9-acpi, systemd-journal wdavdaemon

10:04 <AlmostSurelyRob> I seem to have several processes kworker/u64:<number>+events_unbound. They're the only processes which take any appreciable CPU time.

10:06 <leon-p> rive may be running with software rendering

10:06 <leon-p> could you also post the logs?

10:06 <AlmostSurelyRob> On Gnome kworker-events_unbound run as well but take only a fraction of CPU.

10:10 <AlmostSurelyRob> https://bpa.st/XK5A

10:10 <AlmostSurelyRob> That's the initial few lines of the log.

10:12 <leon-p> are your outputs set to the same resolutions in both gnome and river?

10:13 <AlmostSurelyRob> Yes, 1920x1080.

10:17 <leon-p> well if there is nothing suspicious in top, then I have no idea, sorry

10:17 <leon-p> you may want to stick around, others might have a clue

10:19 <AlmostSurelyRob> Thanks, I will do that. But I think it must be something to do with rendering any insistence on avoiding NVIDIA propriety...

10:19 <AlmostSurelyRob> I am on Fedora and there's another person on the forum who had the same problem and the issue forced them to switch to NVIDIA drivers:

10:19 <AlmostSurelyRob> https://discussion.fedoraproject.org/t/after-fedora-33-update-kworker-u32-2-events-unbound-killing-my-cpu/70053/25

10:20 <AlmostSurelyRob> My situation is not as dramatic as the machine works, but at 80C average it cannot be healthy over long time...

10:20 <AlmostSurelyRob> *my insistence on avoiding NVIDIA propriety drivers.

10:22 <leon-p> ifreund: I think I have found another bug in the rwm branch: trying to focus a new window when previously there were no other windows before the update event is received does not work. if there are already windows, auto-focussing new windows does work

10:23 <leon-p> I have checked and the requests is send, so not a bug on my end

10:23 <leon-p> sometimes it does seem to work though, might be racy

10:24 <leon-p> ok, not racy, it happens to work for the very first window in a river instance, after that auto-focussing new windows when going from 0 to 1 window no longer works

11:23 <leon-p> and I am also somehow triggereing a crash by changing window visibility

11:24 <leon-p> assert(window.pending.hidden == window.sent.hidden);

11:25 <AlmostSurelyRob> I'm wondering if my heating problem is to do with river somehow using nouveau driver. Is there a way to force it to use discrete GPU only?

12:24 <leon-p> also I think I'll try to make antares WM not have workspaces or anything like that, instead I'll try un/minimizing windows in groups. also focus-or-hide-or-spawn seems useful (minimize if foccused, otherwise try to focus or spawn if window does not exist)

12:25 <leon-p> the wall right now is river crashing when trying to change the visibility and the app-id not being send yet

13:44 <AlmostSurelyRob> Sorry, it's me again with my heating/kworker...events_unbound. Just noticed that dock is clearly part of the issue. When I disconnect it and therefore use only laptop monitor the kworker CPU utlisation goes down and fan goes quiet. If anyone has an idea where I could ask about this, I would appreciate. It's probably not a river specific problem,

13:44 <AlmostSurelyRob> but could be. My only reference is Gnome Shell, which seems to be working fine. Maybe wlroots?

13:45 <AlmostSurelyRob> If anyone has an experience or tested river/wlroots on USB/Thunderbolt dock with dual monitor.

14:55 <ifreund> AlmostSurelyRob: do test river 0.3.7 if you are currently using 0.3.6, there was a small regression in 0.3.6 related to damage tracking

14:56 <ifreund> if that doesn't help, the problem is probably lower in the graphics stack than river has control over

14:56 <AlmostSurelyRob> Would that be wlroots?

14:56 <AlmostSurelyRob> I will do as you say, but just wanted to double check what my next steps are.

15:04 <AlmostSurelyRob> Irrelevant question, it seems. It's much better on 0.3.7. Thanks.

15:05 <AlmostSurelyRob> The kworkers still jump up a little, but only when I am actually doing something.

19:25 <ifreund> leon-p: I replied to your comment on the PR, will hopefully get around to fixing those more minor issues you mentioned here today

21:18 <ifreund> leon-p: I fixed the faulty assert and implemented sending app-ids and titles

21:22 <ifreund> I can't reproduce the focus issue you mentioned with rivercompat, do you have a WAYLAND_DEBUG log of the window manager failing to set focus or can you tell me how to reproduce it with antares?

22:32 <ifreund> I actually did find a way to reproduce a bunch of bugginess there, working on fixes

22:47 <ifreund> it seems that foot segfaults if it gets a wl_keyboard.enter too early (before it is mapped?)

22:49 <ifreund> leon-p: ok, I've fixed all the bugs that might have been causing your focus issue that I could find, let me know if it works for you or if I need to do more digging :)