05:18 fling: switching from xv to x11 in mpv helped
05:18 fling: not had a crash for a while, thanks!
10:59 alterjsive: karolherbst: I've found a solution for the high powerusage of my laptop. I've installed the latest nvidia drivers and set the following parameter: NVreg_DynamicPowerManagement=0x02
10:59 karolherbst: alterjsive: yeah, that enables runpm for nvidia
11:00 alterjsive: karolherbst: my laptop is cool now, no more fan noise or overheating
11:02 alterjsive: karolherbst: I see. too bad it isn't defaulted to this config.
11:02 alterjsive: It took me a long time to find this config
11:04 karolherbst: well.. distribution packages usually enable it by default
11:04 karolherbst: and if not, you might want to file a bug
11:05 alterjsive: karolherbst: ok thanks
11:54 karolherbst: Lyude, pmoreau, RSpliet: you were the ones mostly working on the wiki the last times and I was wondering if you have any issues with would be dealbreakers for moving over to gitlab pages (and adjust the domain to the new thing): https://gitlab.freedesktop.org/nouveau/wiki
11:54 karolherbst: I think I am mostly done with the migration
11:57 RSpliet: karolherbst: I don't care much tbh. Would be good to continue having write-access. And make sure that the old wiki disappears
12:34 alterjsive: karolherbst: which distro enables packages it by default? do you have an example?
12:57 karolherbst: alterjsive: hard to say as some distros have some magic around it like ubuntu or pop os. But there are aso fedora packages (negativo17 repo) which do so
12:59 kwizart: karolherbst, I'm {dramatically} against a single man project here. I would usually recommand rpmfusion over such repo
13:00 karolherbst: it's all the same anyway
13:00 kwizart: karolherbst, not really, can't let you say that sorry
13:00 karolherbst: if you say so...
13:00 kwizart: karolherbst, one is a community based project with peer reviewer
13:00 karolherbst: I meant the nvidia packages are bascially the same
13:01 kwizart: karolherbst, no, no really a full no
13:03 karolherbst: okay sure.. rpmfusion spec files use rpmfusion magic vars.. my bad
13:03 kwizart: karolherbst, rpmfusion magic vars what ?
13:03 karolherbst: $RPM_BUILD_ROOT instead of ${buildroot} eg
13:03 kwizart: never heard that since the atrpms days
13:04 karolherbst: or well.. RPM_BUILD_ROOT is not really rpmfusion, but it's an env var instead of a spec var
13:04 karolherbst: anyway
13:05 kwizart: karolherbst, I'm not going to quote how negativo a bad, but for the lest, the binaries are corrupted
13:05 karolherbst: the spec files I checked in regards to nvidia are mostly identical between rpmfusion, nvidia and negativo
13:05 karolherbst: kwizart: yeah well... if you say so
13:05 kwizart: nvidia have rebased to negativo for a very bad reason, but this in no way an argument that negativo is any better
13:05 karolherbst: hey.. I am not saying which one is better
13:05 karolherbst: I am just saying that's all the same techncially
13:06 karolherbst: sure rpmfusion has its community stuff, and for other packages it is doing proper stuff and so
13:06 karolherbst: but for nvidia it just doens't matter
13:06 kwizart: karolherbst, no, negativo still have some terrific issue, that I'm not even going to forward to the maintainer because!
13:06 kwizart: :
13:06 karolherbst: ...
13:06 kwizart: it's a single man project that none should ever use
13:07 karolherbst: honestly, if you have beef with the project that is _your_ issue, not mine, not anybodys here. I just pointed it out as an example, not as an "please use this"
13:08 karolherbst: if you want to go on a "negativo17 is shit" rampage, please do it where people actually listen and would take action, not here
13:09 kwizart: karolherbst, I'm not saying that, I'm saying that negativo packages is corrupting nvidia binaries for a reason that I'm not going to disclose
13:09 kwizart: because:
13:09 kwizart: it's a single man project that none should ever use
13:09 karolherbst: if you are here just for ranting, then just stop
13:09 kwizart: what rantin ?
13:10 karolherbst: well, it's quite obvious your are ranting as none of your remarks are in any way productive
13:10 karolherbst: not meaning it in a bad way, just saying here is not the palce for that
13:10 karolherbst: *place
13:10 karolherbst: I have nothing against you ranting over negativo17 in places where it would actually mattert
13:10 kwizart: karolherbst, you are rewording things as one or another point of view, but I'm still on community based project are way better for open source than single man project that doing unreviewed stuff
13:11 karolherbst: kwizart: when did I ever said the opposite of that
13:11 karolherbst: I am not disagreeing
13:25 karolherbst: RSpliet: well, the idea with gitlab was, that everybody can do MRs, and the nouveau gitlab group has write access
15:10 RSpliet: karolherbst: is that more work than pressing an edit button on the page, trying to remember my login details, editing the text in this page using some markup language, pressing preview to see it looks nice, and then press done to open a PR?
15:15 karolherbst: RSpliet: well.. however you login into gitlab
15:15 karolherbst: but sadly you only get the preview once you create a MR as it depends on the CI pipeline
15:16 karolherbst: looks like this then: https://gitlab.freedesktop.org/nouveau/wiki/-/merge_requests/7 there is this exposed artifacts below the pipeline thing
15:17 karolherbst: but yeah.. that is a bit annoying once you don't have a dedicated server anymore
15:18 RSpliet: Ok, sounds like a wiki with extra steps. Not a huge fan, but I'm hardly an active contributor - so don't let my opinion weigh too heavy
15:19 karolherbst: RSpliet: well, with the previous wiki only a limited amount of peopel could even do changes :p
15:19 karolherbst: so even if it's a bit more annoying to do it with gitlab, others might just do the changes for us instead of pinging us to change it :p
15:20 RSpliet: Yeah, I think the real problem there was the human involvement in access control, which was so infrequent that whoever had to add users had to look up a manual for it or sth. Quite a hurdle for a first-time contribution
15:20 karolherbst: yeah...
15:21 karolherbst: I think you had to edit the htaccess file or something...
15:21 karolherbst: anyway, it was annoying
15:22 RSpliet: Yep. I personally feel that such a git workflow is differently annoying, not nencessarily less annoying.
15:22 RSpliet: But let Lyude, pmoreau, mupuf chime in as well
15:51 karolherbst: actually.. I have an idea
15:57 karolherbst: mhhh
15:57 karolherbst: well.. my idea kind of works, but it fails for ikiwiki specific commands of course
16:32 Lyude: karolherbst: I think I'm fine with this, I just wonder if we should also use kdocs
16:32 Lyude: also ikiwiki probably won't be around forever, we want to convert some other stuff on X.org away from it at some point
16:36 RSpliet: What's a kdocs?
16:39 karolherbst: Lyude: yeah.. I am not against moving to different software, I just thought moving the stuff for now is easier than doing both at the same time
16:39 karolherbst: we want to clean up the files anyway, like removing the HTML stuff or other ikiwiki specific things to have valid markdown files
16:39 karolherbst: and then we can do whatever
16:42 karolherbst: like most/all pages have this google translate stuff, which we could move into the ikiwiki template
16:42 karolherbst: or just remove it :p
16:44 RSpliet: If it's a democracy, I vote for removing
16:45 karolherbst: yeah.. anyway, my point was it's easier to have it all in gitlab and do iterative changes, than messing on the server directly
16:45 RSpliet: It's most likely terrible at translating technical lingo, plus I'm not a fan of zealous tracking
16:45 karolherbst: especially as others depend on some stuff
16:45 karolherbst: and now we are in full control over the ikiwiki pipeline
16:46 RSpliet: Sure. It's maintainer friendly. Not sure whether it's user-friendly. But as I said, I'll let others battle over that
16:46 karolherbst: RSpliet: and browsers support that stuff anyway these days
16:46 karolherbst: RSpliet: well.. users couldn't change the wiki before at all, just a selective group of people :p
16:46 RSpliet: Yeah my browser deliberately doesn't. Just learn a language :-P
16:46 karolherbst: :D
16:47 karolherbst: right
16:47 karolherbst: anyway, I think the drawbacks aren't terrible
16:47 karolherbst: you can always generate stuff locally if you work on bigger changes
16:47 karolherbst: and the delay of 20 seconds online isn't terrible either
16:47 karolherbst: and tirival changes you can still do edit&commit style
16:48 karolherbst: I am more interested in issues we can fix before doing the migration
16:48 karolherbst: did a bunch of that stuff already
16:49 Lyude: hm, how would one convert an fbo from linear to nvidia's linear block format using the GPU with nouveau?
16:50 karolherbst: Lyude: I think it depends on the format as some formats are simply not supported by the GPU being linear
16:50 karolherbst: maybe the copy engine would be fine with it though
16:51 Lyude: karolherbst: yeah-ideally I want to use the ce for this. I would imagine it should be able to process any of the linear/tiling formats that the hardware can handle
16:51 Lyude: just not sure how to set that up from userspace
16:51 karolherbst: well, create a channel, do the subchan allocation on GPUs require them, create your pushbuf and submit
16:51 Lyude: oh ok
16:52 Lyude: and iirc the ce stuff is documented by nvidia isn't it?
16:52 karolherbst: reading mesas code should help with that
16:52 karolherbst: well.. we already use it anyway
16:52 Lyude: cool :)
16:52 karolherbst: ce is really ust m2mf p2mf
16:53 karolherbst: uhm..
16:53 karolherbst: I think
16:53 karolherbst: yeah..
16:53 karolherbst: it's a bit weird :)
16:53 karolherbst: but that's the stuff
16:55 karolherbst: Lyude: the annoying part is just that it has arch specific stuff
16:55 karolherbst: which makes it annoying
17:03 Lyude: karolherbst: that's fine - I kind of expected it and I believe that intel's blitting stuff in igt is the same way