snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
talismanick has quit [Ping timeout: 255 seconds]
talismanick has joined #river
<ghostbuster>
is it fair to say river shouldn't crash even if i do abusive things like hot plug/unplug external monitors and try to apply modes with kanshi
<tleydxdy[m]>
well, it shouldn't crash always imo
<ghostbuster>
this looks like the start of where things went wrong river: types/output/render.c:103: output_attach_back_buffer: Assertion `output->back_buffer == NULL' failed.
<tleydxdy[m]>
speaking of crash, I just had river "crash" on me again, but no coredump :(
<tleydxdy[m]>
maybe I need to keep river running under gdb
<ghostbuster>
i start it from a vt like this: river -log-level debug 2>&1 | tee river_tmp.log
<ghostbuster>
not sure if i'm getting cores though
<tleydxdy[m]>
I do have stdout and stderr
<tleydxdy[m]>
but nothing in them
<tleydxdy[m]>
err: wayland.c:1163: failed to read events from the Wayland socket: Broken pipe
<tleydxdy[m]>
just this
<ghostbuster>
oh i forgot i'm running an old version
snakedye has quit [Ping timeout: 256 seconds]
testy has joined #river
anniehallmoon has left #river [#river]
akhil has joined #river
akhil has quit [Client Quit]
talismanick has quit [Read error: Connection reset by peer]
lxsameer has joined #river
akhil has joined #river
<akhil>
can someone help me get the valid input name for my devices
<leon-p>
akhil: riverctl list-inputs
<akhil>
yes but I am not able to figure out the exact format of name required in riverctl input *name*
<leon-p>
The one you get in the list.
<akhil>
I want to enable tap for my touchpad and this is the relevant list-inputs ```1267:12541:ELAN0712:00_04F3:30FD_Touchpad
<akhil>
type: pointer
<akhil>
``` but I cant figure out the exact format for my name
<akhil>
configured: false
akhil has quit [Quit: Leaving]
akhil has joined #river
<akhil>
can anyone help?
akhil has quit [Client Quit]
<leon-p>
The name is right there at the top.
<leon-p>
The entire first line is the name
snakedye has joined #river
<ifreund>
ghostbuster: yeah, that's been fixed on master
<ifreund>
and on 0.1.3 iirc
daurnimator has joined #river
dvzrv has joined #river
<daurnimator>
ifreund: dvzrv is trying to package for Arch; hoping you can help him out
<daurnimator>
uh, waylock that is
<dvzrv>
ifreund: hi, I'm currently looking into building waylock 0.4.0. unfortunately zig build does not yet allow full RELRO, so some manual plumbing might be required to get this off the ground
<dvzrv>
ifreund: I guess my main issues are currently with the code generation done using zig-wayland in the context of the waylock build. is this something I would be able to construct/call separately? I need to call `zig build-exe` specifically for gaining full RELRO
<ifreund>
dvzrv: Ah, I didn't have RELRO on my radar for distro packaging as void doesn't require it. I'll put together a patch to get this enabled in the upstream asap
<ifreund>
as for packaging waylock 0.4.0, I actually wouldn't recommend doing so yet. There aren't any released wayland compositor versions that support the ext-session-lock-v1 protocol
<ifreund>
sway master branch supports it and river will also support it with the next release (as soon as wlroots 0.16.0 is out)
<dvzrv>
ifreund: oh, good to know. then i'll hold off.
<ifreund>
the patch to enable RELRO in the zig build system should be quite small, the best path forward for arch packaging before the next zig release might be to backport that patch to the 0.9.1 zig package
<dvzrv>
ifreund: ah yes, I saw the packaging info. that kind of documentation is very much appreciated! :)
<ifreund>
dvzrv: that patch adds support to `zig build-exe/build-lib/build-obj` but didn't expose those flags to `zig build` unfortunately
<ifreund>
it should just take a few lines of glue code
<dvzrv>
ah, I see. sorry, never dealt with zig before :D
<ifreund>
no worries!
<dvzrv>
ifreund: fwiw, it might be good to add the info about not packaging waylock 0.4.0 (in regards to its dependency on a wlroots >= 0.16.0 and a wayland compositor supporting the protocol)
<ifreund>
dvzrv: hmm, yeah it wouldn't hurt to say that a bit more explicitly
<ifreund>
added a note to the top of PACKAGING.md :)
talismanick has joined #river
<bw>
someone asked about quality of life things... what about sending stuff like app-id along to the layout manager?
<NickH>
I noticed that the build.zig for river only install river-layout-v3.xml but not river-control-unstable-v1.xml or river-status-unstable-v1.xml
<NickH>
Is there a reason for that?
<ifreund>
dvzrv: Hmm, Looking at lld's source it seems relro is enabled by default unless explicitly disabled with -z norelro
<ifreund>
zig uses lld to link on linux, so I suspect waylock is built with full RELRO already. Or were you able to see with objdump or something that that isn't the case?
<novakane>
NickH: because they're not stable, I don't think a lot of clients use the installed protocols anyway tbh
lxsameer has quit [Ping timeout: 256 seconds]
<ifreund>
NickH: Originally when we started installing protocol files I was planning on keeping river-layout around indefinitely and replaceing the other two with something else in the near future, so I wasn't trying to encourage their use
<ifreund>
now I plan to replace all three eventually, so it's a bit of a moot point
<ifreund>
ah, it looks like "full relro" is -z relro and -z now
<ifreund>
or really just -z now since -z relro is default
<novakane>
yep that's what I found too
<ifreund>
nice, I can get that tool to turn up all green except for the FORTIFY_SOURCE check if I manually pass -z now
<ifreund>
FORTIFY_SOURCE isn't appliciable to zig code if I understand correctly, it inserts bounds checks into C code but building zig code in release safe mode should be even better
<novakane>
yeah it seems like this is for buffer overflows
<NickH>
Ok, just asked because I'm using them.
snakedye has joined #river
<leon-p>
bw: we used to have that actually, but removed it for various reason
<leon-p>
reason 1: no body used it
<leon-p>
reason 2: it had the potential to make layouts behave weirdly
<leon-p>
reason 3: since layout can't modify the actual view stack, only the position on screen, it is a bit useless anyway
<leon-p>
that's by the way why they're called layout /generators/, not /managers/, because they don't manage anything :)
lxsameer has quit [Ping timeout: 256 seconds]
lxsameer has joined #river
<dvzrv>
ifreund: hard to say. I currently can't run zig build (if scdoc is installed), as that tries to install the man page during build time (where it does not have root)
<dvzrv>
ifreund: the same happens for the pam file: `cp /build/waylock/src/waylock/pam.d/waylock /etc/pam.d/waylock error: AccessDenied`
<dvzrv>
and if I do not provide --prefix=/usr to zig build, the build environment is not able to find wayland-util.h (https://paste.rs/oqA)
<dvzrv>
are components built *and* installed unconditionally when using zig build? I was under the impression that the `install` keyword is used for installation specifically
<dvzrv>
it is a bit odd to install to a temporary directory during build and then install again in an install environment
<leon-p>
there are no separate build and install steps with zig build
<ifreund>
dvzrv: hmm, I think you need to provide `--libc libc.txt` where libc.txt is based on the output of `zig libc`
<dvzrv>
ifreund: thanks, that worked! unfortunately full RELRO is not achieved using zig build though: "waylock W: ELF file ('usr/bin/waylock') lacks FULL RELRO, check LDFLAGS."
snakedye has quit [Read error: Connection reset by peer]
<ifreund>
yeah, I realized that LLD only does -z relro not -z now by default, so just partial RELRO
<dvzrv>
either way, I'll wait until the release of a compatible wlroots/sway version I think :)
snakedye has joined #river
<tleydxdy[m]>
I found something very strange, when I quit out of this software https://github.com/Nixola/VRRTest the screen gets stuck in the last frame and switching tag etc doesn't work. seems like I had to switch to a different vt, wait a bit and then switch back
<dvzrv>
but if this is fixed in zig directly, it would allow us to write some packaging guidelines for zig as well (currently it's rather hacky due to the direct call to `zig build-exe` and it is complicated to reimplement parts of the build process that way)
<ifreund>
yeah, that's definitely not how we want the UX for distro maintainers to be :/
<ifreund>
tleydxdy[m]: interesting, not sure if that'd be an issue with river or wlroots. I wonder what that programs is doing
snakedye has quit [Ping timeout: 252 seconds]
snakedye has joined #river
<tleydxdy[m]>
strange, I can't repro it again now, it still get stuck, but switching tags fixes it
<ifreund>
tleydxdy[m]: river doesn't even support VRR/adaptive sync currently, I meant to add it to the wlr-output-management but haven't managed to yet
<ifreund>
I should do that before wlroots 0.16.0
<tleydxdy[m]>
I added it in my local build
<tleydxdy[m]>
also to prefer the highest refresh modes instead of the advertised one, since my monitor is 144hz but advertise 60
<ifreund>
ah
<ifreund>
the refresh rate should be configurable with wlr-output-management already
<tleydxdy[m]>
yeah, but it get lost when the monitor goes on a sleep :)
<leon-p>
that means the output get's removed, which really shouldn't happen in a simple power-saving scenario such as blanking an output. Are you sure you are not accidentally disabling the output using smth. like swayidle instead of turning it off using an output power management client?
<leon-p>
I mean, we probably should keep output configuration for removed outputs regardless, but this sounds more like a configuration error
<leon-p>
for reference, the right way to turn off an output without disabling it would be using something like this: https://sr.ht/~leon_plickat/wlopm/
<tiosgz>
leon-p: enjoying your photo from the future, btw :)
<leon-p>
:D
<leon-p>
whooops
<leon-p>
fixed. you saw nothing
souxd has joined #river
souxd has quit [Client Quit]
<tleydxdy[m]>
I didn't turn it off myself, the monitor has a built in sleep
<leon-p>
it just turns itself off? That sounds annoying, especially since the monitor can't reliably know whether you are actually using it in that moment or not...
<tleydxdy[m]>
yeah, it turns off after like an hour or something and if the content didn't change
<tleydxdy[m]>
probably some environment regulation make it does that
<tleydxdy[m]>
no idea
<tleydxdy[m]>
and there's no nob in the monitor setting to turn it off
<tleydxdy[m]>
still, it would be the same result as if I turned off my monitor when I go to sleep etc.
<tleydxdy[m]>
I'm really perplexed by how wlr_pointer_constraints is supposed to work
<tleydxdy[m]>
it doesn't seem to map clearly to the protocol itself
<ifreund>
tleydxdy[m]: No idea tbh, I was planning on rewriting that stuff entirely after updating to wlr_scene
<ifreund>
pretty sure our pointer constraints impl is fairly broken for anything other than the most common client behavior
<tleydxdy[m]>
yeah, I tried to read sway but it's so many layers of abstraction my head kinda went blank
<tleydxdy[m]>
maybe dwl would be a better place to look
<tleydxdy[m]>
lol, it just doesn't handle set_region at all
<leon-p>
IIRC our pointer constraints impl. was developed against the behaviour of specific clients, not against the spec
<leon-p>
ifreund: are you planning on implementing lingering output configuration yourself? Otherwise I might do it
<ifreund>
leon-p: go for it, I haven't started anything
<ifreund>
I'll probably take a look at that xwayland thing then
waleee has joined #river
souxd has joined #river
souxd has quit [Client Quit]
lxsameer has quit [Ping timeout: 255 seconds]
lxsameer has joined #river
xenon2022 has joined #river
xenon2022 has left #river [#river]
<tleydxdy[m]>
is there some clients that does pointer constraints I should test?
<ifreund>
tleydxdy[m]: there's a wlroots example client I believe
<ifreund>
maybe something from weston as well
<ifreund>
other than that it's usually first person video games I believe
<tleydxdy[m]>
I wonder if there's any fps games that natively support wayland
<tleydxdy[m]>
wth there can be disjoint constraint region
<tleydxdy[m]>
how could that work :(
<ifreund>
even if they don't natively support wayland, xwwayland uses pointer constraints
<ifreund>
no idea about disjoint regions, I haven't really looked into the details of that protocol in depth
elshize has quit [Ping timeout: 240 seconds]
elshize has joined #river
<tleydxdy[m]>
ayy, seem like my impl works as expected using the examples
<tleydxdy[m]>
ig I should test some games now
<leon-p>
ah yes, "test"
<tleydxdy[m]>
😃
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
TheoParis has joined #river
<TheoParis>
I am on archlinux and randomly riverwm started crashing with iot instruction. it says attatching empty buffer to output for modeset and then it crashes and it also says "is 16:16, but the hw limit is 4:2048" at the end
TheoParis has quit [Client Quit]
TheoParis has joined #river
<TheoParis>
hm now it seens to be getting further but it just hangs and my pc stops responding after a backend seatd failed to open seat skipping message
TheoParis has quit [Client Quit]
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
waleee has quit [Ping timeout: 258 seconds]
snakedye has quit [Read error: Connection reset by peer]
snakedye has joined #river
waleee has joined #river
waleee has quit [Ping timeout: 252 seconds]
waleee has joined #river
TheoParis has joined #river
<TheoParis>
hm it seems to not be a riverwm problem - wayfire also hangs