<novakane>
if you make a debug build you should have some info, it's a bit noisy though and you can try to launch zelbar with WAYLAND_DEBUG=1 too
<TheAnachron>
alright, currently running with WAYLAND_DEBUG=1, will try the buffer increase this evening probably
<leon-p>
novakane, TheAnachron: wlroots releases shm buffers fast enough that usually 2 are enough for simple clients, however that is not guaranteed.
<TheAnachron>
aha! I got it.
<leon-p>
That's why I now use a buffer pool with a dynamic amount of buffers and some heuristics to regularly cull unused buffers
<TheAnachron>
check the gist comment. it releases 2 buffers in a short time.
<TheAnachron>
I dont understand why that wont affect you though, novakane, it looks pretty basic wayland stuff?
<novakane>
leon-p: yeah I need to use your code someday, didn't have time to mess with it yet
<leon-p>
should be a drop-in replacement
<novakane>
TheAnachron: hmm why the first buffer is not released before, I haven't come across this in my testing
<leon-p>
if the buffer has not been displayed yet, perhaps?
<novakane>
but it should after wl_surface.commit()?
<novakane>
hmm couldn't the "exec" in the script messed up with this, like killing and relaunching everytime
<leon-p>
a committed buffer isn't immediately displayed
<leon-p>
there is a delay based on the outputs refresh rate
<leon-p>
and it's possible to commit new buffers during that time
<novakane>
ah ok then it maybe the explanation
<leon-p>
also hit this back with lavalauncher: I highlighted buttons when you'd hover over them, but quickly moving the mouse across all buttons caused to many updates to quickly. Back then I solved it with a frame callback, but that would be slight overkill for a simple client
<TheAnachron>
I am a bit lost here, so is the simple 2>3 change sufficient for now or do we really need to refactor the code to fix the issue?
<TheAnachron>
if the number change suffices for a quickfix/workaround, I would do that for now and rebuild
<novakane>
adding a buffer should fix it I think yeah
<ifreund>
In theory the server can hold on to as many buffers as it wants
<TheAnachron>
btw. your zig build uses named tags but when I clone your repo it has none. I worked around for now by creating a new one after clone with my credentials, did I miss something?
<ifreund>
git fetch --tags?
<ifreund>
In practice if you only render in response to frame callbacks then the server will only ever hold on to 1 buffer in the case of shm clients and a wlroots based server
<ifreund>
that is to say, changing 2 to 3 is just making the race less common, not fixing anythng
<ifreund>
the proper fix is rendering only in response to frame callbacks
<novakane>
TheAnachron: yeah there is no version for zelbar but the code is here, because it was copy/paste of build.zig
<ifreund>
some servers may require 2 or 3 buffers even if frame callbacks are used properly but I don't think it would ever be reasonable for a server to require more
<novakane>
ifreund: right that would not be a proper fix but would be quicker than to wait for me to have the time for the right fix lol
<novakane>
honestly the buffers part of Wayland is really the part I struggle with, I wrote so many version for it
<ifreund>
novakane: I think the important realization is that you need potentially infinite buffers if you don't render in response to frame callbacks
<TheAnachron>
are frame callbacks more work? novakane if you need a tester, push it to sourcehut, I will periodically check it
aktina has joined #river
<leon-p>
frame callbacks are mostly just boilerplate. the main hurdle is to remember that you need to commit a single buffer "normally" at the start for them to work
<TheAnachron>
okay I've rebuild with 3 buffers now, lets hope this will last longer.
<TheAnachron>
novakane btw, thanks for the neat project, I couldnt get myself to install the other bars, wayy to much overhead for my taste.
<novakane>
glad you like it :) I'll try to make a proper fix soon
<TheAnachron>
would be neat, my build templates has a few hacks now. When those are fixed I could publish it to void-packages
<novakane>
since there is no release yet I don't think can submit it to void-packages
TheAnachron has quit [Ping timeout: 268 seconds]
aldcor has joined #river
<aldcor>
hello! I installed river, however nothing is spawning. not rofi, not terminals.. i can move my coursor and exit with default keybinding (meaning it kind of works..) but that's about it
<aldcor>
i installed foot terminal
<ifreund>
probably some error in your init file, have you checked your logs?
<aldcor>
i used default example init file, just removed shift when spawning terminal
<aldcor>
ifreund: where should I look for river log file?
<aldcor>
oh wait, I think my distro didn't have that package
<ifreund>
yeah, it's probably using xwayland. I'd recommend something wayland-native
<aldcor>
oh, thanks!
<aldcor>
i think I have tried lemonbar in past iirc
<aldcor>
i will try yambar
<aldcor>
oh my..i can't ssh from foot terminal -> cannot find terminfo entry for 'foot'
ayushnix has joined #river
ayushnix has quit [Changing host]
ayushnix has joined #river
<aldcor>
riverctl map normal Super d spawn wofi --show run
<aldcor>
but nothing happens when I press `Super d`
waleee has quit [Quit: WeeChat 3.8]
<novakane>
aldcor: `riverctl map normal Super d spawn "wofi --show run"`
<aldcor>
novakane: i tried that too
<aldcor>
I also tried with `D`
<leon-p>
if you execute the riverctl command in a terminal, what is the output?
<aldcor>
error, no command given
<aldcor>
oh, you meant full command
<aldcor>
it seems like that keybinding is already used
leopoldek has joined #river
<aldcor>
hm not sure actually
<aldcor>
i don't see it duplicating
<aldcor>
and it says:
<aldcor>
overwrote and existing keybinding: normal Super D
<leon-p>
and you quoted the entire wofi command?
<leon-p>
can you try `riverctl spawn "your command goes here"`?
<aldcor>
ohhh.. fixed
<aldcor>
thank you!
<aldcor>
ok, it seems like `TERM=xterm` fixes the issue of not being able to ssh into raspberry, however, is there a way to make this option permanent so I don't have to type it always?
<leon-p>
TERM can be set in the foot config, see `man foot.ini`
<ifreund>
or you could just update your terminfo db on the target system
<ifreund>
foot's terminfo has been in upstream ncurses for a while now
Guest55 has joined #river
awesomerly has joined #river
<Guest55>
Hi, I've just installed river on FreeBSD 13.2-RELEASE. Pretty much everything seems to be working fine (after limited use) but I want to ask the following.
<Guest55>
I am using FreeBSD 13.2-RELEASE on Thinkpad T480s (Intel i7 8th gen) in case it matters.
<Guest55>
- Does river need D-BUS daemon? In other words, should I enable D-BUS service in /etc/rc.conf to start at system boot?
<ifreund>
Guest55: river itself does not use dbus at all or even know that it existt
<ifreund>
software you might want to use with river may use dbus though, for example notification clients
<Guest55>
- Any insight as to why my keyboard controls that change brightness up/down do not work?
<Guest55>
The commands work when I run them from the terminal but not on the button press.
<aldcor>
In bspwm I used this to change volume: (`-c 1` means card 1) `amixer -c 1 set Master 5%-`. I use only Alsa. What would be `river` way of dealing with volume? pamixer didn't work as I assume it's for Pulse so I tried `amixer` which also didn't work. I also added -c 1 but that didn't help
leopoldek has quit [Remote host closed the connection]
<ifreund>
Guest55: perhaps your keyboard uses something other than XF86MonBrightnessUp, you could use `xkbcli interactive-wayland` to determine the keysym name
<Guest55>
ifreund Thank you so much. I will enable it as once I start setting up notification clients and bunch of other desktop software, chances us I will need it. :)
<leon-p>
aldcor: there is a decent chance that you installed the desktop portals alongside river, which pull pipewire as a dependency. Make sure you really are running just alsa
<aldcor>
leon-p: I should've left that config as it was?
<leon-p>
what?
<ifreund>
in any case, there isn't really anything river specific about setting the volume. If it's not working the problem is elsewhere
<leon-p>
ah
<Guest55>
ifreund For some reason xkbcli is not detecting any presses of the F keys as media keys, regardless if I have the FnLock on or off. I will try to use some other utility to confirm their names although I assumed they would follow the standard on the thinkpad
<leon-p>
Guest55: the program will not receive any key-presses that already trigger a keymap
<aldcor>
leon-p: those portals - are they running as services or daemons or something? how are they called? In services I only see alsa regarding audio
<Guest55>
leon-p Excuse my ignorance but what do you mean by keymap? None of my Media Keys get registered, only if I use them as F keys which doesn't help much. In other words, how can I confirm if the brightness controls (F5/F6) are actually XF86MonBrightnessUp/XF86MonBrightnessDown
<leon-p>
aldcor: they are daemons. either startet as a service or via socket activation
<aldcor>
(fyi i got sound working, just volume keybindings didn't/doesn't work)
<leon-p>
Guest55: I mean that if a key produces XF86Whatever, river will only pass along that event if there is not command bound to XF86Whatever.
<leon-p>
meaning, you do not get events for the media keys, as the example init binds a fair amount of them
<Guest55>
leon-p Got it but that is not the case as I can confirm that my init is not using those F keys
<Guest55>
Thank you for the explanation btw
<leon-p>
No, you can just confirm that the command is not working correctly. It is very likely that the bind itself is working fine
<Guest55>
leon-p This is what I have: riverctl map $mode None XF86MonBrightnessUp spawn 'backlight incr 5'
<Guest55>
Running backlight incr 5 by itself works fine
<leon-p>
that does not necessariely mean that it is successful when spawned by river
<leon-p>
try running it with `riverctl spawn`
<Guest55>
okay will do
<Guest55>
Works fine: riverctl spawn 'backlight decr 5'
<Guest55>
And so does: riverctl spawn 'backlight decr 5'
<leon-p>
have you tried executing the command that creates the bind in the termina? what is the output`
<aldcor>
yes, problem is elsewhere because even though I don't have Pulseaudio, when I execute `pamixer` - ALSA lib pulse.c:242:(pulse_connect) PulseAudio: Unable to connect: Connection refused.
<leon-p>
Guest55: note that specifying a modifier is mandatory. if you want none, use "None"
<Guest55>
leon-p can I use None and still have the controls work? I tried both "normal" and "locked" and I get:
<leon-p>
that you again did not specifiy the mode :) remember: variable
<Guest55>
Ohh okay got it
<Guest55>
Fine
<Guest55>
But even when I set the mode, it does not work for brightness but it works for volume.
<Guest55>
How can I solve that
<leon-p>
try setting a different command as a test, like opening a terminal
<Guest55>
And I am pretty sure XF86MonBrightnessDown is a correct key as it worked in Sway on this computer
<Guest55>
Opening a terminal and running 'backlight decr 5' works. I see the screen getting dimmer
<Guest55>
oh you mean to map a different command to f5/f6
<leon-p>
no, I don't mean run the command in the terminal, change the brightness bind to a different command that you know works, like spawning a terminal
<leon-p>
to figure out if either the bind is simply never triggered, or if the command inside the bind is bad
<Guest55>
leon-p I tried setting it to open a terminal or increase the volume (a command that works for F3) but still no results
<Guest55>
I guess the binding never happens then
<leon-p>
apparently
<Guest55>
Thank you for your help anyways. I will report the solution if I figure it out
<leon-p>
no problem
Guest55 has quit [Quit: Client closed]
Guest55 has joined #river
jao has joined #river
leopoldek has joined #river
angry_vincent has quit []
Guest55 has quit [Quit: Client closed]
<aldcor>
how can I change gap size between windows?
<aldcor>
hm, maybe I found it
<aldcor>
yes, found it
<aldcor>
what is that color code? Doesn't look like hex
<leon-p>
it is hex
<leon-p>
both # and 0x are canonical prefixes for hex
<leon-p>
arguably 0x even more than #
<aldcor>
oh, didn't know
<aldcor>
can I change border thickness?
<aldcor>
of windows
<leon-p>
riverctl border-width
TheAnachron has joined #river
<aldcor>
hm, river do not have workspaces?
<TheAnachron>
it's differrent. tags are similiar to workspaces, but not quite so
<aldcor>
anyway it seems it works the same from UI standpoint - so the question is - is it possible to assing workspace number on bar in river wm?
<aldcor>
if not, it's not a big deal tho
<aldcor>
however, that's very expected wm behaviour
<TheAnachron>
novakane I also have issues with using multiple alignments causing flickering.
<TheAnachron>
So for example if I align all to the left/center/right, all is well
<TheAnachron>
if I start putting some on the right and others on the center it starts to flicker.
<aldcor>
q
<aldcor>
(wrong window)
<TheAnachron>
novokane do you think the new BufferPool is gonna fix that? btw, even with 3 displays the bar occasionally disappears, but its better now
<aldcor>
when I use theme selector in wofi it displays all themes perfectly and alt+a is supposed to save/change a theme but it's not changing
<aldcor>
also, is there specific tool I need to printscreen in riverwm?
<TheAnachron>
novakane I removed the font and the output selector and all is fine. but then again, your script barely updates the bar. my watcher can update it three or four times in a second
taupiqueur has quit [Quit: WeeChat 3.8]
<novakane>
it shouldn't really be enough to have flickering, but I'll try to write some script that update it more often to see
<TheAnachron>
the weird thing is: I ran some script 100 times a second and printing a random icon every time does not even cause flickering, something else is wrong
<novakane>
yeah three or four time a second should really be handled easily
<TheAnachron>
maybe the problem is when piping it to the bar before it finished rendering the last buffer?
<TheAnachron>
there are around 50 async jobs all writing to the bar file that triggers an update. some of them every 5 seconds, 10, 30, 60 etc.
<waleee>
might I suggest setting a single time for all of them?
<TheAnachron>
btw, modifying my "status-watcher" to not listen to write events but periodically (every second) still causes flickers.
<TheAnachron>
waleee well those have different purposes. a lot of things dont need to be checked so often, like system updates and alike. They also cause more load being more frequently and I want to avoid that
<waleee>
every 5 seconds for something seems a bit excessive
Szadek has joined #river
<waleee>
I would maybe go for a golden meam of something like 30 seconds or so since you get an "accurate enough" clock (ymmv)
<TheAnachron>
I do that for things like incoming ssh sessions, my VPN status and alike. Easy on the resources but important for me to know right away
<waleee>
a notification daemon instead perhaps?
<waleee>
would only fire once for each incoming ssh etc
<TheAnachron>
I try to keep it KISS. notifications only when nothing else suffices
<TheAnachron>
I only display information on my bar when its urgent/attention is required.
<TheAnachron>
My setup is supposed to be distraction-free.
<waleee>
I went with zero bar and mako bound to various keybindings (for showing time) and events instead
<waleee>
* time,battery, disk space etc
<TheAnachron>
I will maybe some day in the future move away from it. Currently really enjoying a minimal bar.
<novakane>
ok it seems I can reproduce some flickering with using some really fast script, I'll see what I can do, probably not today though
notzmv has quit [Ping timeout: 265 seconds]
Szadek has quit [Quit: WeeChat 3.8]
<TheAnachron>
no pressure, I reverted back to 1 second interval updates.
Guest79 has joined #river
<novakane>
welp I was wrong I can't see the flickering, it was just the width of text changing quickly with the background that made it seems like it was flickering
Guest79 has quit [Quit: Client closed]
<TheAnachron>
maybe I can figure out how to trigger it reliably.
<TheAnachron>
but that will be no task for today.
TheAnachron has quit [Ping timeout: 250 seconds]
<aldcor>
riverctl map normal PrtSc spawn 'grim'
<aldcor>
or Print, both doesn't work
<aldcor>
i'm sure it's not correct either way..
<RZ_MJ[m]>
aldcor: I believe it is called Sysrq under the hood or something similar.
kragacles_ has joined #river
zdykstra1 has joined #river
zdykstra has quit [*.net *.split]
kragacles has quit [*.net *.split]
<aldcor>
RZ_MJ[m]: that also doesn't work
zdykstra1 is now known as zdykstra
taupiqueur has joined #river
awesomerly has quit [Remote host closed the connection]
alexherbo2 has joined #river
daurnimator has quit [Ping timeout: 265 seconds]
<NickH>
aldcor: you should confirm if the problem is with the binding or if the problem is with launching grim.