<ifreund>
novakane: that enum is generated from the protocol xml for that protocol extension
waleee has quit [Ping timeout: 250 seconds]
<novakane>
ifreund: so I should do like `method: zwp.FullscreenShellV1.PresentMethod,`
<ifreund>
yup, that sounds right
<novakane>
thanks, well one more binding done
<ifreund>
what do you need fullscreen_shell for? I don't think river will ever need that
<novakane>
no need tbh just did the first one in the list, I intend to bind everything, not really following any priority
<novakane>
if you're not interested in this though just close the PR
<ifreund>
Oh I think binding all of wlroots is the end goal here, I'm just annoyed that this would require scanning the fullscreen shell protocol in river's build.zig even though river doesn't depend on it
<ifreund>
so I might just leave your PR open until either someone has a use-case or I find a better way to do that
<novakane>
oh yeah makes sense, well fine for me, I do binding when I have some time, and you do what you want it after :P
<ifreund>
novakane: looks like the zig std doesn't have definitons for clockid_t yet, from looking at musl's source it seems to be a c_int for all targets though so just use that
<ifreund>
hmm, glibc headers seem to say that it should be an i32
<novakane>
hmm so what do you want?
<novakane>
hmm in zig std.os there is u32 for wasi and i32 for freebsd
<ifreund>
all posix says is that it must be an "arithmetic type"
<ifreund>
thanks posix
tmpm697 has joined #river
<ifreund>
novakane: I trust richard dalias's judgement, let's match musl and use c_int for now
<ifreund>
I doubt river would build on a system with @sizeOf(c_int) != 32 anyways
<ifreund>
s/sizeOf/bitSizeOf/
<ifreund>
maybe I'll add clockid_t definitions to the zig std before 0.8.1
<ifreund>
(though I'd be happy if someone else beat me to it)
<novakane>
allright, sounds good to me
<novakane>
yeah, you know I like zig because it doesn't have all *_t shit
<novakane>
anyway, I pushed all bindings I started and haven't time to finish, enough binding for today :P
tmpm697 has quit [Quit: Lost terminal]
notzmv has joined #river
tmpm697 has joined #river
elshize has quit [Quit: WeeChat 3.2]
elshize has joined #river
<elshize>
I'm trying to install river on fedora. the wlroots version in the repo is 0.12, so I compiled and installed wlroots 0.14; I installed it in ~/.local ; how can I point zig to that so that it uses it during compilation of river?
<ifreund>
elshize: same way as you would for a C compiler, you need to set C_INCLUDE_PATH, LD_LIBRARY_PATH and PKG_CONFIG_PATH
<elshize>
ifreund: thanks, managed to build, will test it out soon
<elshize>
trying to switch on my work computer but not sure if I can trick the compliance script that I'm still using kde
<leon-p>
elshize: you could use river windowed in KDE, although I am not sure tricking your employer is such a great idea…
<ifreund>
heh, well best of luck :)
<elshize>
well, let me rephrase it: there's a bunch of checks they do, which will probably not work on river, like: is screen lock on
<elshize>
they don't specifically require me to work on kde or gnome, but the script might still fail because they have only so many options that they check, and if they recognize that I'm not running KDE or gnome, I don't think if they check for swaylock ;)
<elshize>
anyhow, if I'm no compliant, I'll find out soon enough.
<ifreund>
that seems kinda ridiculous tbh
<ifreund>
(the checks, not your efforts to foil them :D)
<elshize>
a bit annoying, especially since even on plasma I had some false-positives and had to manually tweak my config files to "fool" the script even though my config was compliant
<elshize>
but it is what it is
<elshize>
at least they let me use linux
<ifreund>
yeah, true
<elshize>
once in a different company I had to run a VM on a mac to get anything done lol
<ifreund>
luckily the place I work for doesn't care at all what I use as long as I get stuff done
<elshize>
that's the dream. but I kind of understand their reasoning with compliance, they want to avoid stuff leaking out, blah, blah, blah. that's fair. could be worse :)
notzmv has quit [Ping timeout: 252 seconds]
elshize has quit [Quit: WeeChat 3.0.1]
elshize has joined #river
elshize has quit [Client Quit]
elshize has joined #river
elshize has quit [Quit: WeeChat 3.0.1]
elshize has joined #river
tmpm697 has joined #river
<elshize>
I'm having some multi-monitor setup issues with river. I have one 3840x2160 display on left and one 2560x1440 on the right. I'm setting them with position 0,0 and 3840,0 respectively (using wlr-randr) but my mouse won't move from one display to another. am I doing something wrong? not setting any scaling at the moment.
<ifreund>
elshize: hmm, are you sure river is using the mode you expect? What's the output of wlr-randr say?
<leon-p>
elshize: have any of the outputs scale or transform? That throws off the coords AFAIK.
<elshize>
no, transform is normal on both, and scale 1
<leon-p>
elshize: maybe try setting it in a graphical program (https://github.com/atx/wlay) and then copy the coords that program uses for wlrranr in your init script
<ifreund>
I think using wlr-randr in the init script is racy, I'd recommend kanshi for "persistent" display config
<elshize>
ifreund: I'm not setting it in the init yet but I'll try kanshi, too
<elshize>
leon-p: thanks, I'll give wlay a try
<leon-p>
the interface is not exactly straight-forward, but it has an option to generate a wlr-randr script or kanshi configuration.
<ifreund>
what happend to the wdisplays repo?
<ifreund>
it's gtk which is kinda meh but is more widely packaged than wlay
<leon-p>
the user who developed that program deleted their account, so idk
<leon-p>
there is a fork somewhere, but I couln't find it
<elshize>
ok, I managed to fix the display settings with wdisplays
<elshize>
though I notice that the external display is laggy
<elshize>
say, if I move a mouse, it lags visibly
<elshize>
I had the same experience on sway
<leon-p>
those are not exactly small displays. Perhaps your graphics chip can't keep up?
<elshize>
it works fine under Xorg though
<elshize>
hmm, it works much better when I disable the builtin display
<elshize>
but also if they're both enabled, it's only happening when my cursor is on the external one, but not the internal... so that's weird
<ifreund>
that does sound strange, but since it happens with sway as well it's likely a wlroots/driver issue that I don't really know how to debug :/
elshize has quit [Quit: WeeChat 3.0.1]
elshize has joined #river
<elshize>
ifreund: yeah, something very strange; sometimes it just freezes, the entire screen
elshize has quit [Client Quit]
elshize has joined #river
<elshize>
the good news is that it seems like setting DESKTOP_SESSION=sway and running swayidle with swaylock passes the compliance test
elshize has quit [Quit: WeeChat 3.0.1]
tmpm697 has quit [Quit: Lost terminal]
yyp has joined #river
elshize has joined #river
<elshize>
hm, I tried gnome on wayland, and it seems to work fine
<elshize>
it's so weird though, just running wdisplays alone on the external display makes it run a bit smoother, but when I close it, it lags again
<leon-p>
that is definitely weird. wdisplays way of showing what's on the screen is pretty terrible (taking a ton of screenshots), so I would assume it makes the performance worse
<elshize>
actually, it's the "show what's on the screens" option that fixes it!
<elshize>
when I disable it, it goes to **** again
<elshize>
it's insane
yyp has quit [Ping timeout: 268 seconds]
<leon-p>
and that happens in sway too?
<elshize>
I haven't tested that yet on sway, but I remember I noticed lagging before
elshize has quit [Quit: WeeChat 3.0.1]
<ifreund>
hmm, that actually sounds like a damage issue, but damage would only affect software cursors
elshize has joined #river
notzmv has joined #river
<ifreund>
elshize: I have an idea, give me a few minutes to write a patch
<ifreund>
I bet it works on sway though
<ifreund>
oh nevermind, wlroots handles damage tracking for cursors internally
<elshize>
ifreund: ok, just tried sway and it's much better; there might be a little bit of lag but it doesn't just freeze and looks much smoother
<elshize>
but than again I use sway directly to handle outputs.
<ifreund>
I think that shouldn't change anything if I correctly understood the wlroots code, but it wouldn't hurt to try
<elshize>
ifreund: ok, let me see
tmpm697 has joined #river
<elshize>
ifreund: nope, didn't help
<ifreund>
found another thing I messed up with regards to damage that could be causing this
<elshize>
ifreund: here's what I found: I log in, not touching mouse, open terminal, move mouse over the terminal, and all is good; the moment I move it out to the background, or close the terminal, it starts choking
<ifreund>
just to check, you are using river master right?
<elshize>
ifreund: yes, using master just tried pulling just to make sure i'm up to date
<elshize>
but the patch didn't work :(
<elshize>
still same thing, craps out the moment it touches the background
<ifreund>
huh, and craps out means what exactly? the cursor doesn't move smoothly?
<ifreund>
are any other programs affected?
<ifreund>
for example, does keyboard input in a terminal work properly?
tmpm697 has quit [Quit: Lost terminal]
<elshize>
it just stops refreshing, the external monitor that is
<elshize>
everything else seems to work
<elshize>
after a while, it does refresh
<elshize>
and I can focus with my keyboard but if I move the mouse there, it freezes again
yyp has quit [Read error: Connection reset by peer]
<ifreund>
so you're saying that if you keep the mouse off of the external monitor, everything works as expected?
<ifreund>
I wonder if starting river with `WLR_NO_HARDWARE_CURSORS=1 river` would have any affect
<elshize>
ifreund: yeah, more or less, it's not 100% consistent but now I'm playing a youtube video in firefox, everything plays, then I move cursor to external monitor, and it freezes (sound keeps going), move it back out, and it starts moving again
elshize has quit [Quit: WeeChat 3.2]
elshize has joined #river
<elshize>
ifreund: whoa it's working!
<elshize>
`WLR_NO_HARDWARE_CURSORS=1 river` seemed to fix it
<ifreund>
alright, well that's interesting
<ifreund>
to be clear it was the output which the cursor was on which was freezing?
<elshize>
yes
<elshize>
but only the external
<elshize>
the internal display was always working fine, regardless of the cursor being there or no
<elshize>
it's so weird
<elshize>
what is this hardware cursors thing supposed to do exactly?
<ifreund>
huh, this definitely feels like a bug somewhere lower in the graphics stack than river, but you said it works fine on sway...
<elshize>
maybe they're disabling it? not sure
<elshize>
idk, it's a little over my head
<ifreund>
elshize: normally cursors are drawn on a separate GPU plane for efficiency. Disabling that feature of wlroots causes them to be composited into the same buffer as everything else
<ifreund>
this explains why wdisplays showing what was on your outputs fixed things: when doing a screencopy wlroots disables hardware cursors so that the cursor is visible in the screen copy buffer
<ifreund>
I don't think sway disables that by default though, so I'm not sure why it works on sway but not river
<ifreund>
elshize: oh, one idea: what sway version are you testing with? is it built against wlroots 0.14.0?
elshize has quit [Quit: WeeChat 3.2]
elshize has joined #river
<elshize>
ifreund: I'm running sway 1.6
<ifreund>
elshize: not 1.6.1 then? There's a chance this is a wlroots regression
<elshize>
it's unlikely it uses wlroots 0.14 because it's not in my repos, and I installed sway from the official repos
<ifreund>
if you want to help track this down you could build sway 1.6.1 from source and try that
<ifreund>
what GPU do you have by the way? I'm guess intel?
<elshize>
I'm currently running river from before 0.14 on my personal laptop, so I might try upgrading that and seeing if I detect anything on the other machine
notzmv has quit [Ping timeout: 272 seconds]
<elshize>
I'll do that later tonight and let you know what the outcome is
<ifreund>
it's probably hardware-specific since I can't reproduce it on my amd system
<ifreund>
thanks for helping debug this!
<elshize>
no problem, thanks for helping me fix it :)
<elshize>
yeah, probably harware
<elshize>
though I have quite similar setup on both but maybe this one is a newer gpu
yyp has joined #river
waleee has joined #river
novakane has quit [Quit: WeeChat 3.2]
novakane has joined #river
notzmv has joined #river
tmpm697 has joined #river
tmpm697 has quit [Quit: Lost terminal]
novakane has quit [Quit: WeeChat 3.2]
yyp has quit [Remote host closed the connection]
skuzzymiglet1 has quit [Remote host closed the connection]