00:32 Mangix: from the openwrt wiki on smartphone tethering: usbmuxd needs to be started manually after every reboot
00:33 Mangix: This should be fixable with procd
06:50 tzimmermann: javierm, could you take another look at the fbdev patchset? i've found that patches 19 and 29 have no r-b or a-b yet. https://patchwork.freedesktop.org/series/131037/
07:05 javierm: tzimmermann: provided my r-b on the list. I noticed that these two already had tags in patchwork but didn't notice that was just a t-b
07:41 pq: Lucretia, disable glvnd maybe?
07:49 tzimmermann: javierm, thank ouy so much. i'll send out another update with the DMAMEM_OPS change and then it's hopefully ready
07:58 javierm: tzimmermann: great
08:04 Lucretia: pq: is there anything else I should disable?
08:06 pq: Lucretia, I don't know, that's just a wild guess. But if you have glvnd enabled, then libGL.so and friends from from glvnd project and not Mesa.
08:07 Lucretia: que?
08:08 pq: If glvnd is enabled in Mesa, then Mesa will not build libGL.so and other libs that applications will link to.
08:09 Lucretia: well, we can't have so's, they need to be static to start.
08:09 pq: sure, applies to static libs too
08:09 Lucretia: currently disabled: all -Werror;s, llvm, shared-glapi, glx, vulkan-drivers, zstd, xmlconfig, expat, tools,shader-cache, glvnd, b_staticpic
08:09 pq: I'm not sure glvnd *can* do static libs to begin with.
08:10 Lucretia: I had to modify libosmesa to be static
08:10 pq: I have no idea if it is even possible to build a static lib from Mesa.
08:11 Lucretia: can't see why not, if the shared_library function is changed to static_library
08:12 emersion: the mesa loader uses dlopen(), i think
08:13 pq: there are several frontend libraries like libEGL, libGL, libOpenGL, libGLESv2 that apps picks and choose, and they all tend to want to have a single instance of the same internal dynamic dispatching library or whatever, and somewhere at the end there are the hardware drivers, though those are built into a single blob I think.
08:13 Lucretia: this is odd: https://bpa.st/ZHXQ
08:14 pq: so I'm not at all certain that it would be easy or possible to make everything link statically
08:14 pq: I mean, even simple small projects like libwayland have problems being linked fully statically.
08:15 Lucretia: the aim is to 1) get it building, so getting bits missing from the support libs added
08:15 Lucretia: hmm
08:15 Lucretia: what is the mesa laoder?
08:15 emersion: Lucretia: sounds like someone assumed GLint==GLfixed
08:15 Lucretia: 2) osmesa, swrast, libGL.a
08:18 pq: I think mesa loader is the code that searches for, opens and loads the driver components (a.k.a DRI drivers).
08:18 emersion: Lucretia: sounds like there is a mistake in src/mapi/glapi/gen/OES_fixed_point.xml
08:18 Lucretia: thing is open amigaos, shared libs are different, there more like oop libs, they can only be functions, so you get a vector table of functions at negative offsets to the base of the library, you get the base when you OpenLibrary()
08:18 emersion: the third parameter there is declared GLint
08:18 emersion: for TexGenxOES
08:18 emersion: according to this, and to the Mesa impl, should be GLfixed
08:18 emersion: https://registry.khronos.org/OpenGL/extensions/OES/OES_texture_cube_map.txt
08:20 Lucretia: yeah, it's GLint
08:20 emersion: probably went under the radar because GLfixed happens to match GLint on most platforms
08:21 Lucretia: there is a libdl, but not sure how well it works
08:23 Lucretia: emersion: yeah, changing it fixed it.
08:23 Lucretia: so, I read that the glx, wgl, agl style libs are deprecated in favour of egl, is that right?
08:24 pq: EGL can take their place, yes - more or less
08:24 Lucretia: so not deprecated?
08:25 pq: but since applications must be written for one of those, the old ones are still needed
08:25 pq: they are not drop-in replacements, each has a different API
08:25 Lucretia: I know
08:25 pq: but the same fundamental purpose
08:25 emersion: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28825
08:26 Lucretia: I was thinking about writing a lib for amiga, there has been that functionality in the past, so probably see what they did there.
08:27 Lucretia: are there any docs/talks covering the whole architecture of mesa?
08:27 pq: EGL is preferred, because you don't have to reinvent everything you would in a GLX style OS-specific lib.
08:59 MrCooper: Lucretia: note that softpipe will be too slow for real-world apps, it's a reference driver not intended for normal usage
09:00 Lucretia: I know, this is to "get something working"
09:00 Lucretia: first have to work on getting it going with what we have or see if we need something else.
09:02 Lucretia: but, tbh, I have doubts about the whole thing now.
09:03 Lucretia: mesa isn't as portable as I'd hoped it'd be, considering it started on amiga.
09:05 Lucretia: well, it's portable if you're linux, elf and/or posix ,I suppose :/
09:08 MrCooper: it started on Amiga almost 30 years ago :)
09:10 MrCooper: when I started getting involved around the millennium, the main focus was already on Linux
09:10 Lucretia: am aware when it started, was using amiga's back then when it started, even tried mesa on it...
09:10 Lucretia: aye
09:13 MrCooper: same here, with the Permedia 2 GPU connected to the PowerPC accelerator
09:13 Lucretia: ooh get you, it was pricey enough getting a blizzard 1230-iv+scsi+256mb going.
09:14 MrCooper: then I started using Linux on that system and got involved in Linux graphics stack development, and here we are some 25 years later
09:14 Lucretia: I was at uni and had to move the entire machine into a tower because using Linux on it caused it to overheat
09:15 MrCooper: yeah I used a tower case as well
09:15 Lucretia: I hacked mine together.
09:15 Lucretia: pc keyboards didn't work well back then
09:16 Lucretia: have you seen the pistorm? it's mental.
09:16 MrCooper: nope
09:18 Lucretia: check it out
09:22 MrCooper: I will, thanks
09:26 Lucretia: so, what is mesa loader?
09:27 emersion: it's the part that looks at hw devices and loads the correct Mesa driver
09:27 emersion: Mesa drivers are .so's in /usr/lib/dri
09:27 Lucretia: MrCooper: https://linuxjedi.co.uk/2021/09/26/this-week-in-pistorm-2021-09-26/
09:29 Lucretia: emersion: ok. are the driver's api imperative or oo?
09:29 emersion: although, seems like most of the drivers are hard-links of each other
10:19 mlankhorst: When doing pull requests, is it even worth it to mention 'assorted small fixes to XXX/YYY, etc'?
14:50 zmike: @ people who run traces in ci https://gitlab.freedesktop.org/mesa/mesa/-/issues/11043
14:50 zmike: I think after deleting piano, this is the only other one I've seen that changes randomly, which should go a long way towards reducing ci noise
15:07 lynxeye: tzimmermann: may I kindly remind you to take a look at https://lore.kernel.org/dri-devel/6ca9f9361fc04a285326a9e2e4b67c24b03b79b5.camel@pengutronix.de/ ?
15:07 lynxeye: or whoever else takes an interest in looking at shadow plane helpers
15:10 tzimmermann: lynxeye, thanks! i would have missed that patch
15:12 DavidHeidelberg: zmike: thank you a lot! :)
15:24 tzimmermann: lynxeye, shall i merge this patch for you?
15:27 lynxeye: tzimmermann: that would be appreciated
15:27 tzimmermann: ok, i'll add the r-b and cc
15:30 lynxeye: tzimmermann: I didn't think of adding the stable cc, as the stable team seems to pick patches into the appropriate branches from the Fixes: tag
15:30 tzimmermann: i'm not sure if it makes a difference either