06:59 <cnsvc> hi, recently i started using xcompmgr and it has an issue with my i3lock. Whenever i3lock is triggered from xss-lock timeout, the screen is kept on the last frame, and the lockscreen doesn't show up until i start typing. It's working before the compositor.

07:00 <cnsvc> i started the compositor without fading. xcompmgr -c -C -t-5 -l-5 -r3.3 -o.33 > /dev/null &

07:04 <cnsvc> it seems picom has the same issues with slock, and it can be fixed by disabling the fade effect. I checked the source of xcompmgr and the fading effect is disabled by default. https://wiki.archlinux.org/title/picom#Troubleshooting

09:02 <eric_engestrom> cnsvc: this channel is about the infrastructure to run the services under the freedesktop.org domain

09:02 <eric_engestrom> cnsvc: you'll have more luck in #dri-devel (or better, any x11 channel, but I don't know them)

09:03 <eric_engestrom> anholt: your cache proxy (10.42.0.1) is down; I guess that auto-restart you put in place last time didn't work :]

13:39 <DavidHeidelberg[m]> bentiss: Hello. We would need developer access to the gfx-ci/linux (me and Sergi). daniels is on vacation, can you give us the rights?

13:41 <bentiss> DavidHeidelberg[m]: I can, but maybe mupuf, anholt or tomeu would be more appropriate to ask as they are maintainers (amongst a few others)

13:41 <mupuf> DavidHeidelberg[m]: I can do it

13:41 <bentiss> (unless you need owner privileges to do it, in that case you need an admin)

13:41 <mupuf> bentiss: thanks for the ping

13:43 <bentiss> DavidHeidelberg[m]: it's nothing against you, of course, but gitlab allows project maintainers to do their own policy on who does what, and even though I trust you, I'd rather have the maintainers decide who enters the project

13:46 <mupuf> DavidHeidelberg[m]: done, but could you please tell me why you need developer writes for the whole namespace?

13:47 <DavidHeidelberg[m]> Sergi and I need only gfx-ci/linux

14:35 <DavidHeidelberg[m]> we'll need push uprev of the kernel in upcoming days, should I create issue somewhere?

14:51 <sergi> Yes, sorry I haven't say anything before. mupuf, I'm doing an uprev of the kernel in mesa (by hand, not yet automatic) and I see mesa takes the tar file from gfx-ci/linux. I have something working with my fork, but when ready, the uprev MR will have to point to the gfx-ci/linux repo. If there is a way that I can do that with less privileges, I'll

14:51 <sergi> be more than happy

14:53 <mupuf> DavidHeidelberg[m]: sorry, I fixed it up :)

14:53 <mupuf> you are now both developers in gfx-ci/linux

14:54 <DavidHeidelberg[m]> mupuf: thank you :)

14:54 <mupuf> sergi: no worries

14:54 <mupuf> sergi: do you have a write up about what's your plan for the uprev project?

15:10 <sergi> mupuf, after the uprev of piglit in mesa, I thought to continue with the uprev of virglrenderer in mesa (the other direction of the first made uprev_mesa_in_virglrenderer). But I've saw the opportunity to take this uprev of the kernel in mesa and took the task. Do you have some interesting uprev that I can take?

15:10 <sergi> mupuf, I should write some plan. Something we can change, but something we can read

16:09 <mupuf> sergi: well, yeah, I do have takes on the topic, and I would love to see different argumented PoV on it :)

16:10 <mupuf> I come from the kernel testing background and, while some is applicable to other projects, some experience is actually counter productive