<anb>
looks like it works if I upgrade mesa from 21.1.4 to 21.2.3
<ifreund>
anb: interesting, glad you got it worked out
<ifreund>
I'd guess you were hitting a hardware-specific mesa bug :/
<anb>
Or it's something related to nixos. The mesa opengl drivers is not pure, so when I installed latest version of river, it pulled a new version of mesa while indirectly depends on an old version of mesa-opengl
<anb>
But anyway, thanks for your help.
adelaide has joined #river
adelaide has quit [Remote host closed the connection]
leon-p has quit [Quit: leon-p]
waleee has quit [Ping timeout: 264 seconds]
adelaide has joined #river
Guest35 has joined #river
leon-p has joined #river
<leon-p>
399 is ready for the next round of review
leon-p has quit [Client Quit]
leon-p has joined #river
<leon-p>
actually, wait, it's not ready yet. I forgot the high polling rate stuff
<leon-p>
I incorporated the high polling rate fix now. I do not have the hardware to test this though, so it would be nice if someone who does tried it out.
leon-p has quit [Quit: leon-p]
<Guest35>
Guys I having an error
<Guest35>
When doing zib build -Drelease-safe --prefix ~/.local install
<Guest35>
I get /home/snow/river/deps/zig-wayland/src/scanner.zig:995:13: error: unused function parameter
<Guest35>
options: std.fmt.FormatOptions
<Guest35>
^
<Guest35>
I need help guys
<Guest35>
nvm version was too new
Guest35 has quit [Quit: Client closed]
leon-p has joined #river
snowedowl has joined #river
<snowedowl>
Hey there everyone!
<snowedowl>
I'm running into a problem while trying to run "river'
<snowedowl>
I have copied the example init script to ~/.config/river/init
<snowedowl>
but when i run river it gives a PermissionDenied error when trying to open that exectuable
snowedowl has quit [Remote host closed the connection]
snowedowl has joined #river
snowedowl has quit [Remote host closed the connection]
snowedowl has joined #river
snowedowl has quit [Remote host closed the connection]
snakedye has quit [Ping timeout: 245 seconds]
<tiosgz_>
how hard would it be to compile river with statically linked wlroots? was quite disappointed recently discovering that half my testing collection of compositors doesn't work :P
<tiosgz_>
i already managed to get statically linked kiwmi (though that was ~ a month ago), so i guess i just need zig-specific stuff
<tiosgz_>
if you've got any pointers what to look at
notzmv has quit [Ping timeout: 260 seconds]
novakane has joined #river
adelaide has quit [Remote host closed the connection]
adelaide has joined #river
<tiosgz_>
ah, in the end it was only about building wlroots correctly. damn.
snakedye has joined #river
snakedye has quit [Ping timeout: 246 seconds]
snakedye has joined #river
<novakane>
oh that's nice this new xdg-activation feature, can"t wait for wlroots 0.15.0, lot of great things for compositors
talismanick has joined #river
notzmv has joined #river
talismanick has quit [Ping timeout: 260 seconds]
snowedowl has joined #river
<snowedowl>
Hello there! I'm having an error "Failed to open any DRM device" when doing river, here's the log: https://termbin.com/gy1m
<snowedowl>
Other than that, I'm on river with zig 0.8.0 with wayland, wayland-protocols and wlroots installed
snowedowl has quit [Remote host closed the connection]
leon-p has joined #river
<leon-p>
ifreund: what do you think about adding a comptime type paramter to View.getConstraints()? The logic with the maxInt(i32) is specific to the case of wanting the constraints as i32, while the function returns them as u32 and I don't think it makes sense to add that check for the u32 case.
<leon-p>
actually, I can't remember why I wanted them as i32. Maybe it makes sense to keep them as u32 for the calculations.
<leon-p>
ah, because the x and y of box are i32 and I decided to keep that. Makes sense.
snowedowl has joined #river
<snowedowl>
So I tried debugging it for my own
<snowedowl>
but now when I launch river, all I get is a black screen
<snowedowl>
May someone help me please?
<novakane>
snowedowl: are you using nvidia?
<snowedowl>
novakane: I'm using Virtualbox, I've enabled DRM in the kernel and all other necessary modules
<snowedowl>
novakane: The adapter is VMSVGA II
<snowedowl>
I've taking a look at the Github issues page to see what I could find
<snowedowl>
but there wasn't anything relevant (at least I couldn't find it the way I searched it)
<leon-p>
snowedowl: please note that although IRC is instant messaging, it does not guarantee instant responses, you'll need to stick around for a bit. The logs show you asked this already but left pretty much immediately afterwards (most of us here are in european time zones and you asked in the middle of the night).
<snowedowl>
leon-p: The reason of leaving was not because I didn't got response, it was because I thought of trying other things before swarming you ppl
<snowedowl>
leon-p: Neither did I knew it was night time because it was day on my side
<leon-p>
ok, since you have done some debugging yourself apparently, you probably want to re-post your logs
<leon-p>
use `-log-level debug` please
<snowedowl>
leon-p: I'll do it RN
<snowedowl>
leon-p: I'm currently stuck in the black screen after doing "river -log-level debug 2>&1 | tee river2.log"
<leon-p>
can you switch TTYs? If yes, river is at least not blocking.
<snowedowl>
leon-p: I've tried doing Ctrl+Alt+F2 but the black screen still exits
<snowedowl>
exists*
<leon-p>
then river is probably blocking
<snowedowl>
i see
<novakane>
what did you do to go from the DRM error to the black screen error?
<ifreund>
leon-p: maybe we should make the constraints function return u31 instead of u32
<snowedowl>
Hmm vmwgfx driver is missing
<snowedowl>
I'll fix this
<leon-p>
ifreund: I just tried out the approach of making it a comptime parameter and I think it works ok
<ifreund>
(an i32 can represent all values of a u31, so u31 to i32 coercion is safe)
<ifreund>
I think a comptime parameter is needlessly complex
<leon-p>
ifreund: Also, is there any reason why we don't simply apply View.min_size in View.getConstraints() ?
<ifreund>
we could do that
<leon-p>
yeah, then I'll add a third commit to the PR that makes getConstraints nicer
<leon-p>
both applying min_size and the type stuff
<ifreund>
nice, splitting it up into a separate commit would be great
<leon-p>
do you want it before or after the resize bits?
<snowedowl>
novakane: I tried fixing, same results :|
<snowedowl>
novakane: Wait I guess i'm missing DRI drivers
<novakane>
snowedowl: yeah maybe try installing mesa drivers if you don't have it
<snowedowl>
novakane: I'm currently re-installing mesa to see if it works
<ifreund>
leon-p: before probably makes more sense I think
<snowedowl>
novakane: I've recompiled mesa but now the screen is all dark cyan
<snowedowl>
I'll post logs
<dnkl>
snowedowl: sounds like it's up and running
<novakane>
yeah dark cyan is the default background color
<snowedowl>
I'll try doing some shortcuts then
talismanick has joined #river
talismanick is now known as Guest2621
<snowedowl>
Sorry I was busy installing foot
<snowedowl>
Thank y'all for the help.
snowedowl has quit [Remote host closed the connection]
<novakane>
oh 1k stars, congrats ifreund
<ifreund>
thanks :)
<ifreund>
though it's not like I'm doing this for the stars :P
<novakane>
of course, but it's an indication that you're doing something right :P
snowedowl has joined #river
<snowedowl>
So foot has finally compiled
<snowedowl>
But when I try to insert any shortcuts, it doesn't work
<snowedowl>
neither my cursor is showing up
<snowedowl>
I do have fonts installed
<snowedowl>
virt
<dnkl>
maybe try running foot from your river init script, and redirect its output to a file? Don't forget to background foot, or your init script will hang...
<snowedowl>
So I did ./init in the ~/.config directory but all I got is this (https://termbin.com/pk2c)
<dnkl>
snowedowl: have you copied the example init to ~/.config/river/init?
<snowedowl>
dnkl: Yes I have
<dnkl>
and you added foot there?
<snowedowl>
dnkl: It was already there
<dnkl>
snowedowl: no, there's a key binding (mapping) for it
<snowedowl>
where the modifier is the Logo aka Windows key
<dnkl>
what I'm suggesting is you actually try to launch foot from river's init
<dnkl>
while redirecting its output to file
<dnkl>
to see if foot is complaining about something
<dnkl>
(since the key binding) doesn't appear to work)
<dnkl>
so try adding "foot &> /tmp/foot.log & " to ~/.config/river/init
<dnkl>
then start river, exit again, and check the log file
<snowedowl>
So basically foot &> /tmp/foot.log & ~/.config/river/init
<snowedowl>
and Then do river?
<dnkl>
yes, add "foot &> /tmp/foot.log &" inside ~/.config/river/init, then start river
<snowedowl>
Here's the command "riverctl map normal $mod+Shift Return spawn foot &> /tmp/foot.log &"
<snowedowl>
dnk: Is this correct?
<dnkl>
might work, though you'd have to quote the whole foot command line. But I was actually suggesting you just add "foot &> /tmp/foot.log &" at the beginning or at the end of .config/river/init. Just like that, all by itself. Not as part of a riverctl command
<snowedowl>
I guess you probably would have seen the xkb error in the log
<snowedowl>
Because of which I can't use my keyboard
<snowedowl>
which means the problem now is in xkb not in river or foot
<dnkl>
XWayland often logs xkb warnings/errors that can be ignored... you're sure this is something else?
<snowedowl>
Hold on, let me show you the log
<ifreund>
snowedowl: if you're running this inside a VM, make sure the host environment isn't eating your key bindings
<snowedowl>
ifreund: Its not the keybinds, it is the whole keyboard not working
<ifreund>
and yeah, it's totally "normal" for xwayland to complain about keyboard stuff on startup :/
<snowedowl>
ifreund: Both mouse and keyboard are not working
waleee has joined #river
<dnkl>
bad permissions?
<ifreund>
maybe, it's gentoo so it's hard to guess what went wrong :D
<ifreund>
adding yourself to the input group would be worth a try though
<snowedowl>
ifreund: I'm sure it wouldn't be keyboard since i've loaded it
<ifreund>
I don't know whatyou mean by that
<snowedowl>
ifreund: I've enabled Keyboard support in the kernel
<ifreund>
that's a good first step
<snowedowl>
ifreund: Also I have my user in the input group already
<novakane>
maybe you need to enable something with `riverctl input <whatever>` commands
<ifreund>
snowedowl: it would be useful to see the ouput of `libinput debug-events` inside river, I think `river -c "foot libinput debug-events"` should work
<dnkl>
snowedowl: when you started foot directly from init (or from the command line, as novakane suggested), did you see a terminal window at all? Or was is still just the plain background?
<snowedowl>
dnkl: There was the window but I failed to interact with it
<ifreund>
if you see your input events showing up there, then river or wlroots is at fault somehow. If you don't see them there then the problem is lower in the input stack
<snowedowl>
Could type something or move the mouse (neither was the cursor visible
<snowedowl>
ifreund: it shows events
<snowedowl>
ifreund: Including the mouse movement
<snowedowl>
ifreund: What should I do now?
<ifreund>
snowedowl: do you see your input devices in the output of riverctl list-inputs?
<snowedowl>
but else than those, they are the devices which I've enabled
<snowedowl>
ifreund: Interestingly, it is should that the input devices have not been configured (configured: false)
<leon-p>
input devices will work just fine if unconfigured, they'll just use libinputs defaults for their device type
<snowedowl>
I see
<snowedowl>
leon-p: Then whats going wrong :|
<snowedowl>
i am confusion
crypt_ has joined #river
<leon-p>
you know, this might be a good indicator to rethink either the gentoo or VM part :P
<snowedowl>
VM doesn't have any shortcuts mapped to the predefined keymaps in the configuration
<snowedowl>
And AFAIK, I don't think there is something missing in the configuration because I've done what the Gentoo Wiki suggested
<leon-p>
ok, so you are on windows, right?
<snowedowl>
leon-p: And if that meant to either leave Gentoo or a VM, then both are not feasible
<leon-p>
maybe windows eats the super key?
<snowedowl>
leon-p: Nope. I've tried it. There is no shortcut mapped to it.
<leon-p>
windows most definitely has an entire family of shortcuts behind the super key. try using Mod1 instead of Mod4, that should be Alt.
<snowedowl>
I'll do it RN.
<snowedowl>
So if the shortcut is "$mod+Shift Return"
<snowedowl>
I should do Alt+Shift+Return?
<leon-p>
no
<snowedowl>
then
<leon-p>
Alt is not a modifier name
<leon-p>
Mod1
<snowedowl>
no should I press Alt+Shift+Return?
<snowedowl>
I have the mod="Mod1" done
<leon-p>
ah, that is what you mean. Yes, it should be Alt+Shift+Return
<snowedowl>
leon-p: Then, congratulations it doesn't work
<snowedowl>
don't mind the sarcasm
<leon-p>
try binding something without a modifier
<leon-p>
use the modifier name "None" and some random letter as keybind to spawn foot and try if that works
<waleee>
isn't mod1 usually the "super" key (aKa windows-flag key)?
<leon-p>
waleee: Super is Mod4
<waleee>
ah. I don't look at my configs enough
<snowedowl>
leon-p: How about "riverctl map normal Shift Return spawn foot"?
<leon-p>
snowedowl: no, more like this: riverctl map normal None N spawn "foot"
snakedye has quit [Ping timeout: 245 seconds]
<leon-p>
just using the letter n as an example for testing
<snowedowl>
leon-p: What keybind should I press?
<leon-p>
snowedowl: the one you just defined
<snowedowl>
I've pressed N after putting what you mentioned
<snowedowl>
and it doesn't work
<leon-p>
then you either have done something wrong, or river does not (correctly) receive input events
<leon-p>
try in your init to auto-launch a foot instance which executes a program called wev (you might need to install it first). It will print to the foot instance what input events it receives
<snowedowl>
leon-p: and then press "n"?
<leon-p>
no, press whatever. try a few different keys. try modifier plus key combinations. And then see if the printed information makes sense for the keys you pressed.
waleee has quit [Ping timeout: 268 seconds]
snakedye has joined #river
<snowedowl>
leon-p: river -c "foot wev"?
<leon-p>
should work
<leon-p>
by the way, you could work on this a bit faster if you could perhaps ssh into the VM
<snowedowl>
well that's the problem
<snowedowl>
leon-p: I'm pressing keys but it doesn't show anything
<leon-p>
then you could run all the commands in a working terminal instead of constnantly re-starting river with a new init
<snowedowl>
hold on, i'll try something
<leon-p>
snowedowl: congrats, your gentoo is borked. Or your VM. Or your windows. But if wev does not receive any input events, then river does not either, and in that case it is no wonder keybinds do not work.
<snowedowl>
leon-p: thank you thank you :D
<snowedowl>
leon-p: I'll try changing the keyboard that's emulated
snakedye has quit [Ping timeout: 245 seconds]
<snowedowl>
leon-p: I'm sure about the gentoo part as I've literally done what the gentoo official wiki instructed to do
snakedye has joined #river
<leon-p>
well, the gentoo wiki is third party documentation. The thing about third party documentation such as wikis and tutorials is that they easiely get out of sync with the real software. Always refer to the real docs.
<snowedowl>
leon-p: Huh? No! The installation of the Gentoo is present on the wiki from where I configured my Gentoo machine
<snowedowl>
It is not third party
<leon-p>
snowedowl: btw, does the cursor work? If yes, the problem is probably XKB (maybe missing keyboard layouts, check your gentoo use flags). If not, well ... good luck.
<snowedowl>
leon-p: Cursor doesn't work, thanks for the luck.
<leon-p>
snowedowl: Is there a gentoo IRC channel? They'll have experience with misconfigured systems.
<snowedowl>
leon-p: there is but what would I ask them?
<snowedowl>
leon-p: it is #gentoo
<snowedowl>
leon-p: Is the xbcommon a library of X11?
<snowedowl>
leon-p: Because I have three options here: x11-libs/libxbcommon, x11-apps/xbcopm, dev-libs/ucommon
<leon-p>
snowedowl: how about "hello, I installed gentoo in oracles VM on windows following your lovely wiki and I do not get any input events, neither pointer nor XKB, in the wayland compositor I am trying. Any ideas?"
<snowedowl>
leon-p: I've just copy-pasted what you just said
snowedowl has quit [Remote host closed the connection]
snowedowl has joined #river
snowedowl has quit [Remote host closed the connection]
<leon-p>
ifreund: changed view constraints to u31, which definitely simplifies the code a bit. I still have the feeling an overflow is possible for very high values when one of the other values is also very high, but it's not something that should ever be encountered IRL.
<ifreund>
leon-p: that's probably fine, we can switch to zig's saturating artithmetic eventually
<leon-p>
oh, that's right, those are thing. That would simplifiy a few things for sure.
<leon-p>
well, now I only need change the offset from f64 to i32 and maybe see if I can simplify some casts a bit more
<ifreund>
saturating arithemetic is implemented in master zig by the way, so we can use it as soon as 0.9.0 releases :)
<ifreund>
I need to make some food then I'll be ready for some more review and testing.
<leon-p>
guten appetit!
snakedye has quit [Ping timeout: 245 seconds]
waleee has joined #river
leon-p has quit [Ping timeout: 264 seconds]
leon-p has joined #river
waleee has quit [Ping timeout: 260 seconds]
<novakane>
whats saturating arithmetic?
<dnkl>
non-wrapping arithmetic
<dnkl>
I guess you could call it
<ifreund>
but also not panicing on what would normally be overflow
<dnkl>
oh right, zig does that?
<ifreund>
if add INT_MAX + 1 you get INT_MAX
<ifreund>
dnkl: yeah, zig has special wrapping operators
<novakane>
ifreund: isn't that like math.maxInt()?
<ifreund>
no? math.maxInt(u32) is a constant
* dnkl
is hoping his next working-from-home project will be zig-based
<Guest2621>
Has anyone tried running river in an LXD container?
<Guest2621>
Should I display it on my desktop over VNC?
<novakane>
yeah that's weird but then its firefox so...
<leon-p>
you're right. Firefox breaks it.
<leon-p>
I don't understand why though. Works perfectly with foot
<leon-p>
I'll try some other gtk things
<novakane>
works perfectly with spotify too, I only have this with firefox for now
<leon-p>
so some other gtk programs are also a bit glithy, but nowhere near to the level of firefox.
<leon-p>
I suspect it has something to do with those programs updating to new sized rather slowly
<leon-p>
not sure though if the error is a mistake in my logic or in the float pointer resize transaction system
<novakane>
yeah I pcmanfm does it, but it clearly way less crazy
<novakane>
could be just gtk fault, wouldn't be the first time lol
snakedye has joined #river
<dnkl>
leon-p: try resizing a foot window with a scrollback full of "ls --hyperlink" output
<dnkl>
I e "while true; do ls --hyperlink /usr/bin; done" for a while
<dnkl>
If that breaks resizing in foot then it's probably performance related
<dnkl>
(resizing with lots of hyperlinks is slow)
adelaide has quit [Remote host closed the connection]
<novakane>
yes it do it for me like that with foot
<novakane>
leon-p: ^
<leon-p>
hmm... so I have filled scrollback with `while true; do ls --hyperlink; done` for a few seconds and there is an initial tiny glitch at the beginning of the resize operation, but it still works fine overall. And I don't have a particularly good CPU (intel core 2).
<novakane>
hmm weird because for me it do it, not as crazy as firefox but still
<leon-p>
maybe my small screen resolution and therefore smaller buffer sizes counteracts the slow processor
<tiosgz_>
not sure if you're all doing the same (keep the loop running vs stop it before resizing)
<leon-p>
novakane: could you try other terms, like alacritty? I'd do it myself, but the hardware accelerated terminals do not run my laptop :P
<novakane>
tiosgz_: not sure it would change something
<novakane>
leon-p: sure
<tiosgz_>
novakane: me neither
<leon-p>
I am not expecting anything spectacularly different
<leon-p>
I just want to get a feeling for how the "average" client will work with this
n8_ has joined #river
<n8_>
anyone know how to screen mirror?
<leon-p>
n8_: I think there is a program called "wdomirror" or something like that which can be used this, although it is a hack
<dnkl>
Hyperlinks forces foot to split up rows into smaller parts, to handle hyperlinks correctly. I.e it can't simply memcpy the row contents.
<dnkl>
Foot should be much faster at resizing when the contents isn't saturated with hyperlinks...
<novakane>
make sense, not like having hundreds of hyperlinks is something I usually do anyway :P
Guest2621 has left #river [Using Circe, the loveliest of all IRC clients]
<leon-p>
ok, new plan: get rid of floating views, get rid of the concept of resizing, get rid of pointers. I am only half-joking...
<novakane>
get ride of screen, fix all problems
<novakane>
also getting ride of gtk sounds like a better things :P
<leon-p>
let's just return to proper teletypes. I prefer reading on paper anyway
<novakane>
the only problem with paper is storage
notzmv has quit [Read error: Connection reset by peer]
notzmv has joined #river
<ifreund>
why do we call a view a view, why not just "window"
* ifreund
is editing docs
<novakane>
view, window, toplevel, wayland lost me since a long time
<ifreund>
for some reason I suspect X11 is to blame
<Nulo>
"Blame X11"
<Nulo>
RIIW (Rewrite it in Wayland)
<novakane>
We need a wayland glossary
<emersion>
a view is weston internals cargo-culting
<emersion>
a view is not something defined by wayland
<emersion>
x11 uses windows for things like menus and popovers
<novakane>
poor x11 wrongfully accused then
<ifreund>
novakane: the fact that everything is a window in X11 is probably why the early weston developers chose to call windows "views" instead :P
<emersion>
the idea behind "views" was to be able to display them multiple times
<emersion>
but that didn't really pan out
<novakane>
ifreund: allright I let you blame x11 then, I see you really want to :P
<novakane>
ngl even this explanations, "views" still doesn't sounds like a great name to me
<leon-p>
"window" isn't that great either, it has just been cargo-culted since the earliest commercial graphical desktops
<ifreund>
:D
<leon-p>
both are certainly better than "toplevel" though
<novakane>
wayland should use "doors" it would really make the difference when someone ask you why they should use wayaland :Pa
<leon-p>
but I don't think I can come up with a good alternative, so +1 for using "window" in rivers docs
<ifreund>
there's one problem with that though, we have commands such as focus-view, set-view-tags, etc
<leon-p>
no major release == no guarantees w.r.t. interface stability
<ifreund>
yeah but this one feels like pointless bikeshedding
<leon-p>
in the end it really doesn't matter much as long as we are strictly consistent
<ifreund>
I already plan to break everything by 0.2.0 or 0.3.0, it can just wait till then
<novakane>
right, kinda confusing, imo the thing it just to use one and only one
<ifreund>
the man pages only use "view" as far as I can tell
<leon-p>
novakane: if you think that is confusing, here is a little fun fact: In Emacs, a window is called a "frame" and the multiple buffer frames per window are called "windows"
<ifreund>
I think I'll use "window" in my introductory blog post though
<leon-p>
probably better for people not up with Wayland-lingo
<novakane>
leon-p: okay that is confusing
<leon-p>
although I do think "frame" is kinda nice. Like "this is drawn by the application and framed by the compositor"
<novakane>
well "frame" is already taken
<snakedye>
My interpretation of view was any displayed surface.
<snakedye>
Some kind of extremely vague umbrella term that could translate in almost anything