00:03 <elshize> chipps: I couldn't run river on nouveau. had to run proprietary, and have tearing with it and some flickering

00:04 <elshize> it's good enough so that I don't want to switch to X, but a bit annoying at times.

00:05 <chipps> elshize: I see. for me river seems to do fine on the nvidia drivers

00:05 <chipps> elshize: do you have a newer gpu?

02:01 <elshize> chipps: honestly, I don't know :D i'm not on that computer right now, can't check; as I don't have much use for them (don't game or do graphics or anything like that), I don't really pay attention.

02:11 <leon-p> TBH the only interesting use case I have for dedicated GPUs these days is compute stuff. They are tremendously helpful for accelerating highly parallel tasks, like basically all simulations. Integrated graphics have just gotten so good that unless you want to play expensive games or make your render export a little faster, you don't actually need a dedicated GPU.

02:20 <elshize> leon-p: exactly my feeling; I just don't run any computations like that on my workstation; at work, anything like that is run on a server or a distributed cluster; back at the university, we also had some dedicated server for that type of stuff.

02:21 <leon-p> same here

02:21 <elshize> so when I was recently buying a computer for myself, I went with intel in a heartbeat

02:21 <leon-p> we have a "compute server" (basically a desktop with four graphics card) in one of the institutes and you can rent time on there

02:22 <leon-p> never needed to yet though

02:24 <leon-p> everytime I iterate over a 10.000+ items numpy array I always think "hey, that could probably be faster with some compute magic", but realistically that is still way to small to warrant the extra effort and time spent on the code

02:24 <elshize> yeah, I never had a lot of need for that, we did one paper with algorithms on gpus, but not much beside it. we also had HPC clusters available, but that was always a pain to submit jobs

02:25 <elshize> oh, yeah, 10k is nothing :) I used to have some jobs that could be sped up with gpu, but I don't think it would have been worth the effort

02:26 <elshize> but I can imagine if some people do really heavy computation, waiting for a week is not an opiton

02:26 <leon-p> yeah, the nice thing about the simulations I am doing is that you can get away with a pretty low resolution wrt time and space and still get decent results

02:27 <elshize> but let's be honest, the no. 1 reason people buy nvidia gpus is gaming

02:27 <elshize> I think

02:27 <elshize> at least on laptops and such that is

02:28 <leon-p> probably, but I honestly have the suspicion that gaming (to a degree where on explicitly chooses a device with a GPU) is still a lot more niche than people commonly think

02:29 <leon-p> to be fair, as a uni student my peer group is of course not exactly known to have lots of free time, so there might be some bias, but I don't know a lot of people who game that often

02:30 <elshize> I don't know that many either, but I hear that it's something people do, that's all :)

02:33 <elshize> I heard there are shortages, so someone must be buying

13:44 <pkap> Is there a scenario for having multiple seats?

14:00 <ifreund> pkap: it's planned but not yet fully implemented

14:01 <ifreund> a fair amount of river's code already assumes multiple seats, the main missing piece is a way to configure a mapping of input devices to seats

14:28 <pkap> But I can just assume there is is exactly one seat when I write a client?

14:30 <ifreund> pkap: on river currently yes, but that will change in the future

14:30 <leon-p> pkap: you can,but you really should not

14:31 <leon-p> however you can probably assume that the first advertised seat is the main seat, that will be correct in 99% of all situations

14:32 <pkap> Alright, thanks guys!

14:38 <ifreund> there isn't really any such thing as a main seat as far as the protocol is concerned

14:53 <leon-p> main seat in this case refers the one where your primary keyboard and mouse are connected, assuming a single-user setup

14:54 <leon-p> FWICT the most common use case for multiple seats is attaching your drawing tablet to a different seat to get a second cursor. In that context it makes perfect sense to talk about a "main" seat IMO

14:56 <leon-p> and when you want to for example display the title of a focused view in a status panel, you have to decide which seat you care about, as displaying two view titles likaly messes with the UI

15:15 <pkap> Yes that makes sense, thanks :)

21:43 <Anderson-D> Is it possible to somehow query tags & active tag?

21:44 <Anderson-D> So far I've only found `wlr-foreign-toplevel-management-unstable-v1`, but it's for clients

21:55 <leon-p> Anderson-D: use the river-status protocol

21:56 <Anderson-D> leon-p: Is there any definition for it? The only XML I've seen in river is the `river-layout-v3` protocol

21:57 <Anderson-D> Oh, I see it on github. For some reason it's not included in my package that I built from AUR

21:57 <Anderson-D> Thanks!

22:24 <andrea> Anderson-D: I did not include them in the PKGBUILD because community/sway doesn't, and because it is common practice to include the xmls in the repo of the project instead of sourcing them from the filesystem. Feel free to try to change my mind :)

22:30 <Anderson-D> andrea: makes sense :)

22:32 <Anderson-D> I have another question, maybe someone with wayland knowledge might help me. I'm trying to retrieve a list of wl_output instances, but I can't find an interface which provides this. Any ideas?

22:32 <Anderson-D> I'm still new to wayland protocol so a lot of stuff still goes over my head

22:35 <Anderson-D> tl;dr: `river-status` protocol wants an instance of wl_output but I don't know how to initialize wl_output instance

22:37 <dnkl> Anderson-D: there's no Interface to get a list. They're pushed, one at a time, as global objects

22:37 <Anderson-D> Hmm, so is there a specific interface to receive them?

22:39 <dnkl> the "registry" Interface

22:39 <dnkl> https://codeberg.org/dnkl/foot/src/branch/master/wayland.c#L961

22:39 <dnkl> (not sure why my phone keeps uppercasing interface...)

22:42 <dnkl> Anderson-D: since you're interested in the river status interface: https://codeberg.org/dnkl/yambar/src/branch/master/modules/river.c

22:48 <Anderson-D> Yay, I've finally got it to work. dnkl, thanks!

22:49 <dnkl> welcome :)

23:12 <Anderson-D> One more questions: so Wayland itself does not name outputs (eDP-1 etc), but the XDG interface does, right?

23:13 <Anderson-D> Basically, I'm doing get_xdg_output for each wl_output, then listening for their 'name' signals. Am I doing it right?

23:13 <Anderson-D> Essentially, I'm trying to find an output by a predefined name

23:29 <leon-p> Anderson-D: sounds right. IIRC there was the plan to eventually make "name" an event of wl_output, but that has not happened yet, so you'll need to use xdg-output