vimproved has quit [Remote host closed the connection]
vimproved has joined #river
Guest40 has quit [Quit: Client closed]
haliucinas has quit [Read error: Connection reset by peer]
haliucinas has joined #river
sentry has joined #river
Snetry has quit [Ping timeout: 255 seconds]
eShaev9z_ has joined #river
eShaev9z has quit [Ping timeout: 255 seconds]
angry_vincent has joined #river
TGG has joined #river
<NickH>
cathalo: I don't think river implements title bars
<NickH>
Guest40: The ones with the "+" are all "modifiers". Have a look at the MAPPINGS section of the riverctl man page
TGG has quit [Remote host closed the connection]
TheAnachron has joined #river
haliucinas9 has joined #river
haliucinas has quit [Ping timeout: 272 seconds]
haliucinas9 is now known as haliucinas
leopoldek has quit [Ping timeout: 268 seconds]
osaut has joined #river
osaut has quit [Ping timeout: 256 seconds]
osaut has joined #river
osaut has quit [Ping timeout: 255 seconds]
osaut has joined #river
AlmostSurelyRob has joined #river
AlmostSurelyRob8 has joined #river
AlmostSurelyRob has quit [Ping timeout: 250 seconds]
emil2 has joined #river
AlmostSurelyRob8 has quit [Quit: Client closed]
<emil2>
Is there a way to change what window gets focus when switching views?
AlmostSurelyRob has joined #river
osaut has quit [Ping timeout: 255 seconds]
<emil2>
I added sticky windows as per the wiki, which I mostly use to play a video in a floating window, but the sticky window always gets focus when I switch views.
<emil2>
By views I mean the tags I'm viewing, still getting used to the terminology. :p
osaut has joined #river
<AlmostSurelyRob>
Hi,
<AlmostSurelyRob>
Sorry, I know this is a little bit left field, but I am also sure that people here will know a lot about it so I can check my understanding or get my pointers. Perhaps you can just show me the door or a door where I can go and ask this question properly.
<AlmostSurelyRob>
I've got a laptop with Intel and NVIDIA GPU cards. I also have a dock station with two monitors plugged in over DP. I've installed nouveau driver. I am noticing that laptop heats up really fast. CPU is at 60C for quite a long time even when just browsing. I believe this is too much if just running river+firefox?
<AlmostSurelyRob>
I am quite confused about all the technology for hybrid graphics. I know we have PRIME in the kernel, so I've tried running river by preceding DVI_PRIME=1 and without it, but I am not seeing much difference. Could anyone here suggest what should be a reasonable value for my CPU/GPU temperature and perhaps give a guideline of how to operate in my
<AlmostSurelyRob>
dual monitor over dock scenario?
<AlmostSurelyRob>
With nouveau there seems to be few tools to understand GPU occupancy. Should I move to NVIDIA propriety driver? I do use OpenGL for CAD rendering for work, but it's not too heavy. Having two monitors + tiling is way bigger productivity gain for me than having optimal performance, but I would like to understand it better.
osaut has quit [Remote host closed the connection]
<AlmostSurelyRob>
Thanks, that's very useful pointers. I will give it a read.
<ifreund>
you can also try playing with WLR_DRM_DEVICES to test using e.g. only the intel iGPU to see if that is sufficient for your use-case
<ifreund>
(using external monitors might require the nvidia dGPU though, I think it's hardware dependent)
<ifreund>
drm_info can tell you which card is which
<ifreund>
emil2: no, there's no way to configure that yet. The logic is that the most recently focused window gets focus
<AlmostSurelyRob>
Thanks, I will give it a go. My working assumption is that I am currently running on iGPU, but I wasn't able to verify it. When I was on X with nvidia driver I would run nvidia-smi and that would list process using dGPU including X, but I tried to go full open source on this OS and I am still learning.
<ifreund>
AlmostSurelyRob: your CPU being under heavy load could indicate that it is using software rendering rather than the either GPU with that configuration fwiw
<ifreund>
river will log the driver/renderer it is using on startup which could determine if that is the case
<AlmostSurelyRob>
Oh yes! It doesn't look too bad - it certainly detects them both https://bpa.st/UTDA.
<emil2>
ifreund: Ooh, I finally get it. It makes sticky windows a bit weird, as they will almost always be the most recent on every tag, and there doesn't seem to be any way of breaking out of the loop.
tiosgz has joined #river
<tiosgz>
emil2 / ifreund: i have an old branch on my computer that lets you push a window all the way down the last-focus stack
<tiosgz>
was never quite sure if that would make sense; the more now before the wm proto
<ifreund>
yeah, I agree that river's currently hardcoded behavior makes some workflows quite awkwardd
<ifreund>
but I development effort is better spend on the window management protocol currently which will make it possible to change behavior like that without modifying river itself
tiosgz has quit [Quit: nyaa~]
waleee has quit [Quit: WeeChat 4.1.2]
<ifreund>
I discovered that I had to change the window-management protocol approach to key bindings to make setting keyboard focus in response to a key binding race free
<ifreund>
I think the roundtrip on every key binding is unavoidable unfortunately
<ifreund>
this does mean we get to push the mode state machine out of the compositor process to the wm though
angry_vincent has quit [Ping timeout: 255 seconds]
TheAnachron has joined #river
brumus has joined #river
<brumus>
Hello i have a question, im not sure how to go about configuring my outputs/monitors as in setting their refresh rate and position. I was previously using hyprland where i could set it using variables, just wondering if there is a similar method for river, i have looked through man page but couldn't find much, thanks
<brumus>
never mind just found the answer on the wiki
<Cornelius-Figgle>
I was wondering if anyone could help me with dbus
<Cornelius-Figgle>
I start river directly via the binary (on void linux)
<Cornelius-Figgle>
playerctl doesn't work with anything, and flatpaks do not start unless I run them with dbus-launch
<Cornelius-Figgle>
meaning the .desktop shortcuts don't work
<ifreund>
you probably need to start a user dbus session before starting river if your disto doesn't do that for you
<ifreund>
i.e. start river as dbus-run-session river
<Cornelius-Figgle>
how can you tell if the distro does it for you?
<Cornelius-Figgle>
dbus is in /var/service (ie enabled as a system service)
<Cornelius-Figgle>
although it sounds like that is different?
<ifreund>
generally you need both a system dbus session for system services like iwd and a user session for user services like pipewire or notification daemons
<Cornelius-Figgle>
well, both dunst and pipewire work mostly fine
<Cornelius-Figgle>
I will try start it with dbus-run-session, thanks :)
<ifreund>
you may have better luck in #voidlinux in any case
<Cornelius-Figgle>
dbus-run-session did not improve anything
<Cornelius-Figgle>
I figured here would be the place to ask since it is todo with the graphical session instead of the distro itself? I may be wrong
<Cornelius-Figgle>
I will ask over there as well though. I appreciate your help and quick reply
The_Buhs has joined #river
<ifreund>
Cornelius-Figgle: I mean, you may need to dbus-update-activation-environment WAYLAND_DISPLAY after starting river depending on how your dbus session is started to make dbus activation of graphical stuff work
<Cornelius-Figgle>
hm lemme try that
<leon-p>
ifreund: I was only accidentally right, because I did not have that angle in mind :D
<Cornelius-Figgle>
no that seems to have no effect, and wayland display is still empty after I run that
<leon-p>
with the new pressed and released events, chording binds where you hold down multiple keys will now also be possible, nice!
<ifreund>
I think that was already possible, it should be a bit more straightforward now though :)
<Cornelius-Figgle>
$DBUS_SESSION_BUS_ADDRESS is also empty if that is relavent
<leon-p>
just wondering whether some sort of mode support in the server still makes sense: right now the client has to request enable/disable for every individual keybind. This may be a bit excessive, so I wonder whether we can bundle a bunch of keybinds up so one could enable/disable them collectively
<ifreund>
we could, but I don't think it's really worthwhile
<leon-p>
also wondering how locked keybinds will work now
<ifreund>
there are session_locked and session_unlocked events
<ifreund>
the wm has to deal with changing the enabled set of bindings in response to those
<leon-p>
that could be racy, no? don't we need some sort of ack_session_lock request from the wm?
<ifreund>
we already have atomic, race free event/request grouping in both directions
<ifreund>
see update, ack_update, commit
<leon-p>
Ah, so it just integrates with that, nice
<leon-p>
and it won't even stall the session lock
<leon-p>
will the TTY switching keys still be hard-coded? If so, I think that should be documented in the protocol
<ifreund>
yes, they will still be hardcoded
<ifreund>
I'd probably keep the language open-ended and give VT switching as one example of a binding the compositor might hardcode and not allow the WM to modify
TheAnachron has quit [Ping timeout: 256 seconds]
emil2 has quit [Quit: WeeChat 4.3.2]
<leon-p>
the only thing I don't really like about this iteration of the keybind mechanism is that the implementation leaks into the protocol: it's xkb specific. However I doubt xkb will be replaced any time soon, if ever, and a generic way to define keybinds across different keyboard libraries would probably be hard or impossible to design
<ifreund>
leon-p: I did give this some thought, its one reason I like having the xkb bits in a separate protocol
<ifreund>
*liked
<ifreund>
we can always add a new binding type for a new keyboard library if xkb actually dies someday before Wayland dies
<ifreund>
and deprecate the xkb binding type, stating that the compositor will ignore xkb bindings
<ifreund>
xkb will surely have a long slow death if it actually happens so it should give plenty of time for wms to migrate