pedrohlc[m] has quit [Quit: You have been kicked for being idle]
pkap has joined #river
<Anderson-D>
ifreund: congrats! That's a power move for river!
<Anderson-D>
Makes me feel happy that there's still a cult around well-written and optimized software in this bloated world of JS/electron/RAM-hungry apps
<Anderson-D>
(No offense to JS devs, only to corporations who abuse it such with tools such as M$ teams)
<Anderson-D>
s/such with/with/
snakedye has joined #river
<pkap>
When I change the scaling factor of an output, am I supposed to change the positioning accordingly?
<pkap>
Because when set the scale of my left output to say 0.8 and I change nothing else, I have the cursor on both outputs at the same time.
<pkap>
Or more specifically, the outputs are overlapping.
<dnkl>
pretty sure the answer is yes. At least that's how it works in sway
<emersion>
yup, the mode resolution is divided by the scale
<pkap>
Ok thanks dnkl, emersion :)
Fr0stBit has joined #river
<Fr0stBit>
Hello!
<novakane>
o7
waleee has joined #river
<Fr0stBit>
Its almost xmas and I'm jumping into the wayland train with river!
<Fr0stBit>
I'm gradually making the setup viable, my only enemy now is hidpi
<Fr0stBit>
Any tips?
<Fr0stBit>
I did setup kanshi with scale 1.75 (as this is the proper scale for my laptop screen) and xwayland stuff are blurry :(
<Fr0stBit>
Even foot is blurry
<novakane>
I don't think xwayland support hidpi
<novakane>
also IIRC integer value are better for scale
<novakane>
although I never used scale so there is probably someone better than me to talk about this
<Fr0stBit>
Well scale 2 is waaay too big
<Fr0stBit>
Even on my external monitor I need scale 1.25
<dnkl>
well, fractional scaling means the compositor will downscale a 2x scaled image produced by the application
<dnkl>
that will always have some amount of blurriness
<Fr0stBit>
I have my dpi set in Xorg as 168 (scaling 1.75) and everything is crispy clean
<Fr0stBit>
I thought that the 'scale' factor was the dpi setting in wayland
<Fr0stBit>
waybar for example is crispy clean with scale factor 1.75
<dnkl>
crispy clean is impossible. But different fonts may perhaps look better or worse when downscaled
snakedye has quit [Ping timeout: 245 seconds]
<Fr0stBit>
dnkl: Actually it is possible? Display scaling does not mean take this framebuffer and scale it by 'x' factor, it means use this 'x' factor in your font rendering and render a 10pt font as a 16pt font, in order for it to look ok
<Fr0stBit>
Thats what the programs under X do
<Fr0stBit>
when they check the Xft.dpi setting
<dnkl>
no, in Wayland, it _does_ mean scale the buffer by X
<dnkl>
if you want truly crispy text, use s scaling factor of 1, and increase the font size instead
<Fr0stBit>
Ok so in that case, I do NOT want to scale the screen!
<Fr0stBit>
dnkl: What if the dpi that my monitor reports is not the desired one?
<dnkl>
set dpi-aware=no, or explicitly set the dpi on the font
<dnkl>
(font=name:dpi=X)
<dnkl>
(might be best to disable dpi-aware regardless)
snakedye has joined #river
Fr0stBit has quit [Quit: WeeChat 3.4]
pkap has quit [Quit: Client closed]
pkap has joined #river
<ifreund>
Thanks for the congrats all! Contributing to Zig has been a lot of fun :)
<tiosgz_>
hah. congrats also from me :)
<novakane>
ifreund: I was wondering reading the changelog, couldn't we use `std.build.FileSource` for like zig-wayland or maybe others deps in river build.zig?
<ifreund>
novakane: zig-wayland already uses std.build.GeneratedFile on the next-zig branch, what exactly are you proposing to change?
<novakane>
ifreund: oh, I guess I was confused by the example in the changelog then, I thoought it was something different in the next-zig branch
<ifreund>
novakane: I just used a bit of a different API than the example it seems
<novakane>
yeah I see that now, I should have look better before asking :P
<ifreund>
e.g. if EAGAIN is returned on the first flush() call and then the second call succeeds then the loop will be restarted as errno hasn't been reset
<ifreund>
and so you get stuck in a busy loop until flush() returns an error other than EAGAIN
<ifreund>
I think the proper loop condition would be the check if the return value is less than 0
<leon-p>
Hmmm... makes sense. I think the event loop is also missing a dispatch before entering poll.
<ifreund>
for some reason running multiple copies of river-tag-overlay in a nested session seems to consistently hit this case
<ifreund>
at least on my machine
<leon-p>
yeah, I can reproduce, but only in a nested session
<leon-p>
good timing, I wanted to replace the event loop anyway, so I guess I have a project tonight. Unfortunately I came up with the snippet over a year ago, so I have a lot of projects to patch :P
<ifreund>
nice :)
<leon-p>
although I am curious, what made you run multiple river-tag-overlay instances in a nested river?
<ifreund>
leon-p: I'm also seeing an issue where --timeout doesn't work in a nested session and was trying to debug that
<ifreund>
and because my init file automatically starts a river-tag-overlay instance I ended up with multiple
<leon-p>
I don't see how timeout would work differently in nested vs native...
<ifreund>
leon-p: could be the same or another event loop bug/race condition...
<ifreund>
hmm, I don't see how timeouts are supposed to work tbh. I don't see any code to cause a wakeup from poll when the timeout expires
<ifreund>
oh nvm, that's an argument to the poll call