ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
iive has quit [Quit: They came for me...]
Company has quit [Quit: Leaving]
sadlerap3 has joined #dri-devel
sadlerap2 has quit [Ping timeout: 480 seconds]
Kayden has joined #dri-devel
chloekek has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
rauji____ has quit []
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
flynnjiang has joined #dri-devel
co1umbarius has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
yuq825 has joined #dri-devel
rz has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
sarnex has quit [Read error: No route to host]
sarnex has joined #dri-devel
luben has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
cphealy has joined #dri-devel
cphealy_ has joined #dri-devel
cphealy has quit [Ping timeout: 480 seconds]
luben has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #dri-devel
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #dri-devel
Aura has quit [Ping timeout: 480 seconds]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
phire has quit [Remote host closed the connection]
phire has joined #dri-devel
caef^ has quit [Remote host closed the connection]
fab has joined #dri-devel
tomba has joined #dri-devel
tzimmermann has joined #dri-devel
csbaur^ has joined #dri-devel
kts has joined #dri-devel
fab has quit [Quit: fab]
itoral has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
macslayer has quit [Remote host closed the connection]
rasterman has joined #dri-devel
frieder has joined #dri-devel
Peuc_ has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
mvlad has joined #dri-devel
molinari has joined #dri-devel
fab has joined #dri-devel
Peuc has joined #dri-devel
glennk has joined #dri-devel
sima has joined #dri-devel
kugel_ has quit [Remote host closed the connection]
kugel has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jsa has joined #dri-devel
Haaninjo has joined #dri-devel
jsa has quit []
rgallaispou has joined #dri-devel
pcercuei has joined #dri-devel
jfalempe has quit [Read error: Connection reset by peer]
jfalempe has joined #dri-devel
hansg has joined #dri-devel
tursulin has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
donaldrobson has joined #dri-devel
<tzimmermann> airlied, sima, could you please comment on the UMS removal patchset? https://patchwork.freedesktop.org/series/126754/
apinheiro has joined #dri-devel
cmichael has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
vliaskov has joined #dri-devel
<airlied> tzimmermann: ack from me, getting rid of it ftw
<javierm> mairacanal: your convert a DRM driver to rust LPC talk was awesome :)
<soreau> tzimmermann: Does this mean anything for kernel options `nomodeset` and `driver.modeset=0`? Would the nomodeset cases try to use fbdev where it used to use UMS or what will happen?
<javierm> soreau: it will use any driver that relies on the system provided framebuffer (e.g: efifb, vesafb, simpledrm)
dviola has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
itoral has quit [Remote host closed the connection]
<tzimmermann> soreau, this change has no effect on nomodeset.
<tzimmermann> airlied, thanks
cmichael has quit [Remote host closed the connection]
kts has quit [Ping timeout: 480 seconds]
<sima> tzimmermann, also ack from me
<sima> tzimmermann, I guess just needs an ack from ppc maintainers for merging through drm-misc and I guess intel folks for the one i915 bit and then go land it all and celebrate :-)
<sima> airlied, agd5f given all the agp disabling, I also wonder whether we shouldn't just nuke all that too?
<sima> or do we need the drivers just to make sure agp mode is off?
<sima> but I guess nuking the uapi is really the thing that matters
cmichael has joined #dri-devel
kts has joined #dri-devel
kts has quit []
jsa has joined #dri-devel
ascent12 has joined #dri-devel
ascent12_ has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<emersion> sima, just fyi, not sure this is the right way to multi-tree merge https://lore.kernel.org/dri-devel/bc60a7fd-8de7-4856-b5ed-e1172b9b79f7@amd.com/
<emersion> maybe it is, but if it isn't, please reply :P
<sima> uh no
<emersion> yeah, i think i remember something about… not doing this lol
<sima> git doesn't realize it's the same patch, which means the 3-way merge gets extremely confused by the changed context and makes an absolute mess of it at merge time
<sima> hwentlan__, agd5f ^^
<sima> I'll reply on-list too
<emersion> ty
<tzimmermann> sima, thanks
<sima> hwentlan__, we should have a patch to dim docs that any kind of cherry-picking is for maintainers only, somehow this came up a few times recently
<sima> hwentlan__, https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#merge-criteria <- probably should add it here to the list of non-linear actions
<sima> something like "Any non-linear actions (like cherry-picking, backmerges, merging topic branches and sending out pull requests) ..."
<sima> if you could do the patch&mr?
<javierm> sima: what about backports from let's say drm-misc-next to drm-misc-next-fixes ? Should we ask maintainers to do that if is needed?
<sima> javierm, yeah, there's dim cherry-pick for that which helps with making sure you have dependencies and stuff like that
<sima> and subsequent bugfixes, if there's any
<javierm> sima: yes, I know. But was a question do your comment "any kind of cherry-picking is for maintainers only"
<sima> javierm, yeah imo cherry-picking to multiple trees or from -fixes to -next is just wrong, and cherry-picking from -next to -fixes has enough warts that you should inform maintainers anyway, so might as well put it on their shoulders
<javierm> sima: makes sense
<sima> it's also why dim cherry-pick is documented under the "cmds for maintainer" section
<sima> just that we have a few gaps in the docs where it's not clear enough
<javierm> got it
<sima> javierm, there's also some details like you must sob that cherry-pick and you really should put a full reference to the commit in -next in so it's less confusing for -next and cc: stable people
<sima> *linux-next I mean
<javierm> sima: but dim cherry-pick already does that IIRC
<sima> yeah it takes care of all that
<sima> but you need to know it exists :-)
<javierm> but still makes sense for me that should be on maintainers' shoulders. They may decide that is OK to wait for the next release, or that should really be part of the -rc cycle, etc
<javierm> so definitely seems to be something that is for them to weight in and decide the course of action
<sima> it's more that cherry-picks tend to create really entertaining conflicts
<mairacanal> javierm: thanks! now, i'm starting to work on upstreaming the dependencies of DRM (like Xarray)
<sima> in practice at least
<javierm> sima: yeah, and that's why maintainers can decide whether to cherr-pick to -fixes (and possibly cause a conflict) or just wait for the next release (if the fix is not critical or for a patch in this merge window, etc)
<javierm> sima: anyway, just wondered if your comment also applied to cherry-picking fixes and why I asked. Thanks for the confirmation :)
<javierm> mairacanal: nice!
Net147 has quit [Ping timeout: 480 seconds]
yyds has quit [Remote host closed the connection]
Net147 has joined #dri-devel
chloekek has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
kts has quit [Quit: Leaving]
jsa has quit []
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
cmichael has quit [Quit: Leaving]
cmichael has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.1.1]
apinheiro has quit [Quit: Leaving]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
yyds has joined #dri-devel
HaikuUser has joined #dri-devel
HaikuUser has quit []
hansg has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
Aura has joined #dri-devel
agd5f has quit [Read error: Connection reset by peer]
hansg has joined #dri-devel
fluix_ is now known as fluix
agd5f has joined #dri-devel
<agd5f> sima, AGP in amdgpu has nothing to do with traditional AGP. The driver uses uses the AGP aperture for direct access to system memory (without going through a GPU page table) as an optimization. That got broken with a recent rework, so we disabled it, but we did finally fix it.
<agd5f> The on GPU AGP aperture just forwards requests directly to the bus
<agd5f> that said, I don't object to getting rid of AGP in general
fxkamd has quit []
Peuc has quit [Quit: Peuc]
Peuc has joined #dri-devel
heat has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
macromorgan_ has quit []
macromorgan_ has joined #dri-devel
fab has quit [Quit: fab]
macromorgan_ has quit []
macromorgan has joined #dri-devel
<kusma> Did someone force-push to main recently?
<kusma> (mesa main, I mean)
<jenatali> kusma: the Marge problem was being discussed in #freedesktop
<kusma> Something went very wrong here, and I see commits without Marge's part-of tags in the recent commit history, exactly where things started diverging: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26077
<kusma> jenatali: OK, thanks
<jenatali> "oh, I should've check sooner: the error marge is giving ("these changes already exist in branch main") is actually correct, so this MR should be closed"
<agd5f> airlied, sima any objections to me including Felix' revert in my -fixes PR today?
<kusma> jenatali: Yup, that's the one.
libv has quit [Ping timeout: 480 seconds]
<Lynne> new dedicated sparse queue patches break vulkan video decode
<Lynne> why was it that CTS was not enabled for decode on radv again?
libv has joined #dri-devel
kzd has joined #dri-devel
<Lynne> triggers the only assert in radeon_check_space()
macslayer has joined #dri-devel
<Lynne> moving the order in pQueueFamilyProperties fixes it for some reason, that function is not very straightforwardly written
fab has joined #dri-devel
yyds has quit []
yyds has joined #dri-devel
donaldrobson has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
<pepp> I'd like to add a new trace_dma_fence_sync_to event to debug sync issues - would that be ok or should I make this an trace_amdgpu_... event?
<pepp> (see the 2 top patches from https://gitlab.freedesktop.org/pepp/linux/-/tree/add_trace_dma_fence_sync_to_event for the current implementation)
flom84 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
bmodem has joined #dri-devel
dviola has quit [Quit: WeeChat 4.1.1]
<sima> agd5f, I'm still a bit confused since everyone is talking about the follow up in -next but the revert in -fixes, which is why I suggested to backport when actually needed
<sima> but also meh, just send it :-)
<sima> when/if actually needed
<sima> (there's some pretty simple syntax that you can add to the cc: stable for the first patch that needs the revert so it's not really any more work than other cc: stable)
<sima> airlied, ^^
<sima> agd5f, oh I've just seen christian's reply
yyds has quit [Remote host closed the connection]
<sima> agd5f, a-b: me for the revert in your -fixes pull today, that's very much a reason I can get behind :-P
flom84 has quit [Quit: Leaving]
donaldrobson has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
kts has joined #dri-devel
hansg has quit [Quit: Leaving]
idr has joined #dri-devel
<idr> Ugh. So... my MR failed debian-testing-asan. As far as I can tell... it detects a leak in fclose called from a unit test. :facepalm:
donaldrobson has quit [Ping timeout: 480 seconds]
<idr> cmarcelo: Actually... the open_memstream(&my_string, ...) parameter has to be freed after the stream is closed.
<idr> But asan blames fclose because... it had the last pointer to it? It seems like it should blame open_memstream. That would have made the real problem more obvious.
fxkamd has joined #dri-devel
rgallaispou has quit [Quit: Leaving.]
<bwidawsk> melissawen: Any chance to look into modifiers for vkms?
<melissawen> bwidawsk, yeah, forgot to get back with findings. So, VKMS already supports MOD_LINEAR since it's added by DRM by default.
<melissawen> I also checked the IGT tests that use this modifier, and it's working as expected
<bwidawsk> melissawen: hmm, I guess I need to dig more than as to why I get back INVALID
<bwidawsk> thanks for looking
<melissawen> the only thing I found is that VKMS is not rejecting the MOD_INVALID properly
<bwidawsk> well, it's some gbm/vkms combo here, and I just sort of guessed it was vkms' fault
<melissawen> do you think it would be the case for your gbm case? a bad handling of MOD_INVALID from vkms?
<melissawen> I'm not used to gbm, so I'd need much more time to debugging the stack.
hansg has joined #dri-devel
<bwidawsk> no, iirc it uses the regular bo_alloc without modifiers because modifiers2 interface isn't supported
<melissawen> let me know if you have any news from your side. I'll try to find a time to investigate the bad management of MOD_INVALID anyway
<bwidawsk> so this falls back to MOD_INVALID
<bwidawsk> melissawen: okay, I'll let you know if I find anything new
<bwidawsk> Is there a way to limit drm.debug to only a specific card?
<emersion> melissawen: KMS drivers can't indicate that INVALID is not supported
<emersion> IOW, INVALID must always be supported
<emersion> in general, drivers assume LINEAR in trhat case
DodoGTA has quit [Quit: DodoGTA]
<daniels> idr: asan blames fclose because, unless you explicitly flush, the file only gets flushed on close
DodoGTA has joined #dri-devel
<bwidawsk> emersion: so I guess the ultimate question is should I able to allocate a LINEAR buffer from vkms
<bwidawsk> because it doesn't seem to work (for reasons I haven't debugged)
<zamundaaa[m]> bwidawsk: it's not vkms, llvmpipe is the issue
<emersion> apparently vkms doesn't have DRM_CAP_ADDFB2_MODIFIERS?
<emersion> ie, it advertises lack of modifier support
<bwidawsk> emersion: yes, that's what I saw
<zamundaaa[m]> Heh, maybe there's multiple issues :D
vliaskov has quit [Remote host closed the connection]
<bwidawsk> zamundaaa[m]: in my case I am not using llvmpipe
<bwidawsk> this is with a pixman renderer
<zamundaaa[m]> Okay, that's unrelated then
<bwidawsk> it /seems/ like it should be an easy thing to fix
<bwidawsk> but I also vowed not to write any more kernel patches, so it's a stalemate
bmodem has quit [Ping timeout: 480 seconds]
<melissawen> emersion, I can inspect better but I don't think the missing CAP is the case, since when running IGT kms_addfb_basic VKMS always pass the `igt_require_fb_modifiers` requirement
<melissawen> vkms passes the requirement, but fails in rejecting the ioctl
<emersion> `bwwhy no more kernel patches?
<emersion> bwidawsk: ^
<bwidawsk> I lost the grit to write 37 versions of the same patch
<bwidawsk> though writing drivers in Rust is very appealing
<bwidawsk> and I did notice VGEM was being rewritten in Rust
<bwidawsk> though I can't seem to find a good use for vgem
cmichael has quit [Quit: Leaving]
glennk has quit [Ping timeout: 480 seconds]
sewn has joined #dri-devel
<sewn> why was commit 0a564171f63eac6d81bbcb2aae72c788747c3c02 not included as part of the 23.3.0 release?
<sewn> if it was before commits that were included in the release
<kisak> sewn: https://gitlab.freedesktop.org/mesa/mesa/-/commit/0a564171f63eac6d81bbcb2aae72c788747c3c02 Branches containing commit -> main which tells us the merge request is after the branchpoint. https://gitlab.freedesktop.org/mesa/mesa/-/blob/23.3/.pick_status.json?ref_type=heads#L16385 nominated false means it wasn't marked for backport.
<sewn> oh i see
<sewn> thanks
<melissawen> emersion, the drmdb snapshot seems outdated, probably since https://patchwork.freedesktop.org/patch/471383/ (?)
<melissawen> than, maybe an old kernel is the issue of bwidawsk too (?)
<emersion> ah right
<melissawen> I'll send a new kernel to drmdb to populate it anyway
<melissawen> https://paste.debian.net/hidden/d2345c09/ <- using kernel 6.3
<bwidawsk> hmm, I don't think this is the case for me
kts has quit [Quit: Leaving]
<bwidawsk> I think the oldest I have anywhere is 6.3
<bwidawsk> I will try again, when I get out from under the pile
<bwidawsk> melissawen: ^^
<melissawen> if you can try current drm-misc-next is the best option
<bwidawsk> melissawen: thanks for digging into it
<bwidawsk> yeah, I can do that when I have something that builds again :D
<melissawen> I'm trying vkms on amd-staging-drm-next tree because it's my current working tree
<emersion> melissawen: nice!
<melissawen> bwidawsk, no problem. and sorry for delaying. I wanted to inspect more again before replying you and I ended up missing the timing :(
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
ungeskriptet has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
Anorelsan has joined #dri-devel
alyssa has quit [Quit: alyssa]
molinari has quit [Ping timeout: 480 seconds]
<idr> daniels: Ah. That makes sense. It's fixed now anyway. :)
fxkamd has quit []
alyssa has joined #dri-devel
jsa has joined #dri-devel
hansg has quit [Quit: Leaving]
siva has joined #dri-devel
fxkamd has joined #dri-devel
Anorelsan has quit [Quit: Leaving]
Kayden has quit [Quit: -> JF]
glennk has joined #dri-devel
fxkamd has quit []
frieder has quit [Remote host closed the connection]
molinari has joined #dri-devel
yang is now known as Guest8684
Guest8684 is now known as yang
gouchi has joined #dri-devel
sravn has quit [Quit: WeeChat 3.5]
tomba has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
hansg has quit []
Venemo has quit [Read error: Connection reset by peer]
glehmann has quit [Read error: Connection reset by peer]
Venemo has joined #dri-devel
glehmann has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
chloekek has quit [Remote host closed the connection]
<alyssa> any idea why KHR-GL33.packed_pixels.rectangle.* would fail while KHR-GLES3.packed_pixels.rectangle.* passes?
<alyssa> like.. those should be the same, no?
<idr> alyssa: There might be different formats available in GLES and desktop GL? Or at least different formats tested.
Kayden has joined #dri-devel
<alyssa> idr: yeah, seemingly
<alyssa> but..
<alyssa> Gradient comparison failed during ReadPixels for input = [GL_RGBA, GL_UNSIGNED_BYTE] output = [GL_BGRA, GL_UNSIGNED_INT_8_8_8_8
<alyssa> I find it... unlikely that BGRA8 readpixels is broken, that would be breaking a lot more than this CTS case
luben has joined #dri-devel
<alyssa> (and the trace looks fine..)
<idr> That is odd. :(
<alyssa> Ooooooh
<alyssa> setting pipe_cap_texture_transfer_modes = default, the test passes
<alyssa> with = blit, fails
<alyssa> granted iris has it =blit too, but
<alyssa> apparently my blits are broken /somehow/
<alyssa> but its.. just util blitter..
<alyssa> and it's.. specifically bgra8..
<alyssa> but ARGB8 and BGRA4 are seemingly fine?!
martin19 has joined #dri-devel
<airlied> do the test results file say what pixels are wrong?
<alyssa> <Text>Non-integer comparison: 1, 0, 18, 0.00787402: 0.141176 == 0.0705882: not equal.</Text>
<airlied> wierd it's like half the value
<alyssa> I assume it's BGR channel swapped
<airlied> maybe a missing swizzle somewhere
<alyssa> presumably, but the trace looks right and I'd expect more fireworks if that were wrong
fab has quit [Quit: fab]
martin19 has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
<glehmann> does any of the non amd hw have an instruction for u2u32(pack64(a, b) >> (c & 0x1f))?
martin19 has joined #dri-devel
<alyssa> glehmann: agx does
<alyssa> well, almost
<alyssa> wrong
<alyssa> wrong mask on c because agx (-:
<alyssa> gotta love inexplicably non-sm5 shifts
<alyssa> the agx instruction also has an optional mask on it
<alyssa> extr (Extract From Register Pair)
<HdkR> ooo, it supports extr with a register specifying the lsb? That's nice
<alyssa> HdkR: consolation prize for no 64-bit shifts
<alyssa> Ooooo. I think the problem is actually ARGB, not BGRA
<alyssa> yay endianness
<alyssa> :p
<alyssa> yep. siiigh
<alyssa> thanks for rubberducking :)
<alyssa> yep. just needed to invert swizzles when writing out
martin19 has quit [Read error: Connection reset by peer]
alyssa has quit [Quit: alyssa]
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
martin19 has joined #dri-devel
martin19 has quit [Read error: Connection reset by peer]
luben has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
airlied has quit [Ping timeout: 480 seconds]
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #dri-devel
martin19 has joined #dri-devel
airlied has joined #dri-devel
<illwieckz> Do someone knows a bit about glvnd? What problems is it trying to solve? Unless we do something wrong with the Dæmon game engine, accumulated experience over two years is that building an OpenGL application with GLVND ABI instead of LEGACY one 1. breaks compatibility with legacy Nvidia drivers, 2. breaks compatibility with AMD OGLP driver, 3. breaks compatibility with Wayland with Prime…
<illwieckz> Is glvnd expected to be backward compatible and all of these problems are bugs, or is it considered OK that maybe only current Nvidia drivers on Xorg is expected to work and we are just lucky if current Mesa drivers are compatible with it on Xorg too ?
<Kayden> so there are two aspects to glvnd
<Kayden> first is just the new vendor neutral dispatch library. glvnd provides libGL.so, and it loads the vendor drivers (libGLX_mesa.so, libEGL_mesa.so, libGLX_nvidia.so, etc)
<Kayden> that should be fully backwards compatible, and is meant as a way to let you parallel install mesa drivers, nvidia proprietary drivers, fglrx (not that that's a thing anymore) & whatever else
<Kayden> as long as you're linking against libGL.so it should not matter whether it's glvnd or mesa or nvidia directly
<illwieckz> I guess I never seen backward compatibility to be working, then
<Kayden> but it sounds like you may be running into the second aspect
<Kayden> which is...glvnd decided to define a new ABI for OpenGL, libOpenGL.so
<Kayden> which is not backwards compatible
<illwieckz> yes, that's my concern
<Kayden> IIRC it only has OpenGL core profile support. It also does not contain GLX
<Kayden> libGL has both OpenGL core, OpenGL compatibility (legacy), and GLX
<Kayden> which is awkward if you're trying to do, say, EGL only, on a non-X11 windowing environment
<illwieckz> so, does it mean that I can build an app with -DOpenGL_GL_PREFERENCE=LEGACY
<illwieckz> but use a glvnd libGL.so ?
<Kayden> I've not heard of that flag, but yes, it should be possible
<Kayden> you shouldn't have to target libOpenGL.so as an app / engine author unless you -want- to
<illwieckz> that's the cmake flag for selecting either LEGACY ABI or GLVND ABI
airlied has quit [Ping timeout: 480 seconds]
<illwieckz> ok, good to know
<illwieckz> because CMake defaults to -DOpenGL_GL_PREFERENCE=GLVND
<illwieckz> even if the developer has no idea this will break backward compatibility if I understand it right