<zmatt>
another trick possible to creating an empty libgbm.so.1 that just pulls in libgbm.so.2 as dependency
<zmatt>
*is creating
<Guest1566>
Well previously I was using a symlink the other way, linking to a mesa library unknowingly
<Guest1566>
And that worked.
<Guest1566>
Well that worked *if* those things all stayed in /usr/lib/arm-linux-gnueabihf/
<zmatt>
define "worked" ? since what you're saying doesn't really make sense, mesa libgbm is most definitely incompatible with the sgx libraries
<Guest1566>
I mean worked. I could run all the OGLES demos and my Qt application also worked. They ran without issue.
<zmatt>
and you weren't accidently using mesa egl (software rendering) ?
<Guest1566>
How would I have known?
<Guest1566>
Really there were two cases:
<Guest1566>
First eglinfo worked. Then I installed Qt from apt and eglinfo no longer worked.
<Guest1566>
Second eglinfo worked. Then I installed Qt from apt and eglinfo still worked.
<zmatt>
this information is much too vague to be useful
<Guest1566>
Between case 1 and case 2 I applied the ldconfig "fix" so for me it was pretty clear
<Guest1566>
Well clear that elginfo still worked. Does eglinfo work with mesa egl?
<zmatt>
of course
<zmatt>
well, I'd assume so?
<Guest1566>
Well I guess that's all useless info ;p
<zmatt>
I should probably refrain from making firm statements given that it's been ages since I dug into this stuff :P
<Guest1566>
I know I don't want anything mesa, but I can't stop apt from installing it and I'm not ready to repackage Qt just yet.
<Guest1566>
If I knew which files belonged to mesa, then I could delete them after the packages are installed.
<zmatt>
so I didn't touch the qt packaging, rather I packaged the sgx libs and ti's libgbm such that they satisfied the dependencies of the qt packages (and conflicted with mesa's libraries thus making sure that having both installed was simply impossible)
<Guest1566>
Oh. That's a better approach. How?
<zmatt>
I'd need to dig it up again... basically just stick the files together with some metadata into a directory and use dpkg-deb to build a package from it
<Guest1566>
yes, but what metadata exactly ;) Earlier you said it confliced with mesa libs so just copy that metadata so it looks like the same package?
<Guest1566>
copy the metadata from the mesa libs I meant
<zmatt>
no, you don't imitate the mesa package
<Guest1566>
specifically libgbm1?
<zmatt>
libgbm is the only one that does need to be imitated since it's a real package and not a virtual one
<zmatt>
or at least that's how it was
<zmatt>
not sure if that's still the case
<zmatt>
potentially a better solution is using the newer drivers since I have a vague recollection that TI improved the situation
<zmatt>
I should really try to find a moment to see about getting the current drivers working and packaged and put the packaging metadata/scripts on github... but I generally have too many things I want to do :P
<Guest1566>
I understand completely ;)
<zmatt>
hmm looks like libgles1 was virtual in debian stretch but is a real package (providing a "vendor-neutral dispatch layer") since buster
<Guest1566>
You might as well be speaking Greek right now. I don't understand debian packaging all that well.
<zmatt>
the problem with libgbm is nicely illustrated by the description of the official libgbm package: "It provides a mechanism for allocating buffers for graphics rendering tied to Mesa.
<zmatt>
_tied to Mesa_
<zmatt>
ti's libgbm has the same purpose and API, but is tied to the sgx libraries
<zmatt>
so applications that link against libgbm are essentially tied to mesa specifically, which is a bit annoying
<Guest1566>
I see. But ti versioned their libgbm as .2
<zmatt>
yeah not sure why they did that, and they actually reverted that in the 1.17 drivers
<Guest1566>
Interesting. So the right fix is to symlink .1 as .2 then ;)
<zmatt>
if you compile your system from source (like e.g. yocto does) then it doesn't matter since your programs will link to whichever version of the shared library is present at link-time
<zmatt>
I don't know what exactly the consequence is of symlinking like that
<Guest1566>
We don't use yocto. We bootstrap debian.
<zmatt>
I know
<zmatt>
but TI's sdk does use yocto, so they didn't run into any problems as a result of bumping the libgbm version
<Guest1566>
bastards
<zmatt>
but I'm guessing they got complaints hence rolled it back to .1 :)
<Guest1566>
Well it would then conflict with the other .1 so back to the same problem symlink or no.
<zmatt>
?
<zmatt>
the other .1 should not be installed
<Guest1566>
It gets pulled in with Qt.
<zmatt>
which therefore needs to be prevented
<Guest1566>
Right which means faking a libgbm package, but that only works if one is truly using egl only.
<zmatt>
but I can't spend more time on this right now, I need to go
<Guest1566>
Well thanks for all the help. It's gotten me going at least.
<zmatt>
not sure what you mean by "truly using egl only"
<Guest1566>
I don't understand what mesa is, but if there's any other reason to use it on the beaglebone that's all I was thinking.
<zmatt>
faking the packages definitely works, although as long as you're using the 1.14 drivers the libgbm version issue also needs to be solved (and I don't know if a symlink works correctly, I suspect it may not)
<rcn-ee>
Guest1566, IMG doesn't provide "opengl"...
<zmatt>
opengl is a standardized API
<rcn-ee>
They give us OpenGL ES...
<zmatt>
and ES2
<rcn-ee>
When you just say opengl.. The "desktop" OpenGL is no where in that...
<zmatt>
yeah it's egl, gles, gles2
<zmatt>
not gl as such
<Guest1566>
I guess what I'm saying is that ti provides the libraries that any program can use so no need for mesa?
<rcn-ee>
Guest1566, in our case.. Mesa is a backup "software" rendering..
<zmatt>
they implement the same api
<zmatt>
rcn-ee: well you can't have both installed at the same time in a sane way
<rcn-ee>
exactly, when accelerated calls are used thru EGL IMG would be used.. call and OpenGL , mesa will load..
<zmatt>
I'd strongly advise against having any mesa library on your system if you want the sgx libraries to work
<rcn-ee>
Most users fire up glxgears on a BBB and like, yes OpenGL works... (thru mesa..) With the EGL we have from IMG, it's framebuffer or the old QT egl... somethign name..
<zmatt>
old?
<rcn-ee>
"EGLFS"
<rcn-ee>
i say old, didn't qt drop that?
<zmatt>
that's a qt5 platform backend layered on egl
<freq>
and like, i guess i get excited about it and stuff
<freq>
so
freq has quit [Client Quit]
buzzmarshall has quit [Quit: Konversation terminated!]
rcn-ee_ has joined #beagle
rcn-ee has quit [Read error: Connection reset by peer]
agentnocent has joined #beagle
agentnocent has quit [Client Quit]
vd has quit [Quit: Client closed]
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
Shadyman has quit [Quit: Leaving.]
otisolsen70 has quit [Remote host closed the connection]
giort has joined #beagle
rob_w has joined #beagle
giort has quit [Quit: giort]
rob_w has quit [Remote host closed the connection]
rob_w has joined #beagle
ikarso has joined #beagle
argonautx has joined #beagle
CrazyEddy has quit [Ping timeout: 264 seconds]
CrazyEddy has joined #beagle
florian has joined #beagle
blech has quit [Quit: WeeChat 1.9.1]
ikarso has quit [Quit: Connection closed for inactivity]
<set_>
vd: A while back you asked what is ldo3. It is the regulator for the adc on the am335x.
buzzmarshall has joined #beagle
Guest1566 has quit [Quit: Client closed]
linkliu61 has joined #beagle
thinkfat has joined #beagle
lucascastro has quit [Quit: Leaving]
lucascastro has joined #beagle
thinkfat has quit [Remote host closed the connection]
thinkfat has joined #beagle
thinkfat has quit [Remote host closed the connection]
thinkfat has joined #beagle
<zmatt>
not just the adc, it's the main 1.8v regulator (I answered that already a bit ago)
thinkfat has quit [Quit: Konversation terminated!]
thinkfat_ has joined #beagle
set_ has quit [Ping timeout: 260 seconds]
rob_w has quit [Quit: Leaving]
vd has joined #beagle
thinkfat_ has quit [Remote host closed the connection]
waldo323_ has quit [Remote host closed the connection]
thinkfat_ has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 246 seconds]
waldo323 has joined #beagle
charlie5 has quit [Ping timeout: 246 seconds]
thinkfat has quit [Ping timeout: 265 seconds]
thinkfat has joined #beagle
jkridner[m] has quit [Remote host closed the connection]
RossSchulman[m] has quit [Write error: Connection reset by peer]
mvaittin has quit [Remote host closed the connection]
shoragan[m] has quit [Write error: Connection reset by peer]
jduchniewicz has quit [Remote host closed the connection]
waldo323_ has joined #beagle
buckket has quit [Quit: buckket]
Shadyman has joined #beagle
shoragan[m] has joined #beagle
waldo323 has quit [Ping timeout: 265 seconds]
mvaittin has joined #beagle
RossSchulman[m] has joined #beagle
jkridner[m] has joined #beagle
jduchniewicz has joined #beagle
argonautx has quit [Ping timeout: 252 seconds]
vagrantc has joined #beagle
calculus has joined #beagle
calculu5 has quit [Ping timeout: 252 seconds]
buckket has joined #beagle
ikarso has joined #beagle
florian has quit [Quit: Ex-Chat]
calculus has quit [Ping timeout: 252 seconds]
calculus has joined #beagle
argonautx has joined #beagle
vd has quit [Quit: Client closed]
argonautx has quit [Ping timeout: 252 seconds]
vd has joined #beagle
mag has quit [Remote host closed the connection]
thinkfat has quit [Ping timeout: 264 seconds]
vd has quit [Quit: Client closed]
vd has joined #beagle
mag has joined #beagle
Guest15 has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
argonautx has joined #beagle
<Guest15>
@zmatt @rcn_ee Just wanted to report back that my Qt app is working on top of eglfs on the beaglebone ai. However, the issue with libgbm.1 remains. I put all the ti libs (both libgbm and the user mode libs) into /usr/local/lib/arm-linux-gnueabihf and that's at the top of /etc/ld.so.conf.d/arm-linux-gnueabihf.conf. This puts the ti libs first in
<Guest15>
the library search order so the right library always gets used, except for libgbm.1. I tried making a symlink to libgbm.2, but lddconfig doesn't 'see' the symlink (rightfully so). The solution then is to compile ti's libgbm as both libgbm.1 and libgbm.2. I think...
<zmatt>
no you don't want two copies of the library loaded in
<zmatt>
that is a recipe for crashes
<zmatt>
most likely
<zmatt>
maybe it would work since iirc libgbm is mostly a shim, but there's no reason to find out
<zmatt>
though if you say you have it working somehow, what issue remains exactly?
<zmatt>
like, I'm not quite clear on that
<zmatt>
or rather, I'm not really clear how exactly you have it working
Guest1591 has joined #beagle
Guest15 has quit [Quit: Client closed]
Guest1591 is now known as Guest15
<Guest15>
If there are two copies of the same library what's the issue? Don't the functions get suffixed with the version of the library?
<zmatt>
they don't
<zmatt>
by default, all symbols from all shared libraries loaded into an application (along with those of the application itself) get dumped into a single namespace
<zmatt>
in case of conflicts, it will simply use whichever comes first in the load-order
<Guest15>
So if it's the same copy of the library, sounds like the conflict will resolve itself?
<Guest15>
I know the real answer here is to recompile Qt.
<zmatt>
it may or it may not, I've absolutely seen crashes due to multiple copies of shared state, but whether that will happen in practice will depend on details
<zmatt>
recompiling everything that might reference libgbm seems like an act of desperation and wouldn't be my solution tbh
<zmatt>
this seems fine? it finds the one in /usr/local first
<Guest15>
But there are two entires? Shouldn't ldconfig show me the ones it will actually use?
<zmatt>
evidently it reports everything it found
<zmatt>
regardless of one shadowing the other
<Guest15>
Is there a way to see which library a running binary is using?
<zmatt>
ldd /path/to/program
<zmatt>
running one... there's a way to do that too I think
<zmatt>
ls -l /proc/$PID/map_files/ (where $PID is the pid of the program you want to examine) shows all files mapped into the program's address space, including shared libraries
<zmatt>
so to just list shared libraries: readlink /proc/$PID/map_files/* | grep -P '\.so(\.\d+)*$' | sort -u
<Guest15>
ldd is reporting the correct library on the binary and seems like the correct library being used:
<Guest15>
So the issue here is that some binaries (like the imagetec ones) depend on both libgbm.1 and libgbm.2, meanwhile the Qt libs depend only on libgbm.2 it seems.
<zmatt>
the sgx libs depend on libgbm.so.2
<zmatt>
any dependency on libgbm from a debian package will be libgbm.so.1
<zmatt>
direct dependency on libgbm.so.1 is quite rare i think
<Guest15>
Ah, that's what's happening then beause libgbm.so points to libgbm.so.2.
<zmatt>
qt5's eglfs depends on libgbm.so.1
<zmatt>
(or rather, depends on libgbm, hence the debian packaged qt5 depends on libgbm.so.1)
<Guest15>
So it's expected then that programs with dependency on libgbm1 won't work?
<zmatt>
yep
<zmatt>
or maybe they do
<zmatt>
who knows
<zmatt>
depends on whether they use functionality that doesn't exist in TI's fork of libgbm
<Guest15>
I'm under the impression that libgbm.so.1 and libgbm.so.2 implement the same api?
<zmatt>
mostly yes, but I guess mesa added stuff
<Guest15>
So we're back to the real problem. For my usecase, I'm fine using only qt. But for anyone else wanting to use ti's libgbm as a replacement they're screwed.
<zmatt>
depends on what libgbm functionality they use
<zmatt>
most of the API is the same, mesa just added more stuff over time
<zmatt>
such as gbm_bo_map/gbm_bo_unmap
<Guest15>
So if I were to remove the libgbm.so.1 shim library and let the system use mesa's libgbm.so.1 the result would be software rendering, but otherwise no ill effects?
<zmatt>
no the result would almost certainly be crashes
<zmatt>
libgbm has no way to affect what rendering is used
<zmatt>
and you'd end up using a mix of symbols from the two libgbms
<zmatt>
in effect, passing the struct gbm_device* from one library to another library where that internal struct has different contents
<Guest15>
So no guarantee that ti's libgbm will be a direct replacement for debian packages.
<zmatt>
it's just an older version of the api
<Guest15>
Right, but for any newbie trying to get their 3d accelerated video working there's not out of box solution.
<zmatt>
those people generally has no reason to directly use libgbm
<Guest15>
Right, but here I am trying to use Qt...
<zmatt>
point in case: your qt5 application doesn't use it directly, nor does any part of qt5 except specifically the eglfs_kms library
<zmatt>
right, and that works now
<Guest15>
but not out of box
<zmatt>
not sure what your point is... especially since the main thing you've done is installed the sgx libs and TI's libgbm into /usr/local and configured it into the search dirs for the dynamic linker
<zmatt>
(you could also install it into a random directory and use LD_LIBRARY_PATH probably)
<Guest15>
my point is only that a new user who buys a beagbone because acclerated graphics is advertised gets into a world of hurt trying to make it work.
<zmatt>
creating the libgbm.so.1 with my trick turned out unnecessary for your use-case
<zmatt>
it's advertised?
<zmatt>
hmm
<Guest15>
Only that it has "Dual-core PowerVR® SGX544™ 3D GPU". There's no indication you can't use it.
<zmatt>
yeah I think those are just meant as hardware specs rather than listing stuff that works out of the box but I agree that's misleading
<zmatt>
the gpu has unfortunately always been a hassle
<zmatt>
(on every TI SoC afaik)
<Guest15>
Yes I struggled for awhile with beaglebone black. I was hoping I could use what I learned here to improve the situation somehow.
<Guest15>
I think the least worst case might be to have rcn-ee libgbm1 package provide both libgbm.so.1 and libgbm.so.2 using the trick you suggested.
<zmatt>
the libgbm1 package is mesa
<Guest15>
Well mesa and ti can't coexist.
<zmatt>
correct
<Guest15>
So why can't ti replace mesa? It won't work everywhere, but at least you don't get the mixed library situation.
<Guest15>
Or is the real fix libglvnd?
<zmatt>
I'd need to test if a Provides: declaration works for non-virtual packages, I seem to recall it didn't but that might be different now
<zmatt>
if it doesn't then there's no real fix possible other than providing manually installed debian packages or a special separate repo
<zmatt>
since the package would have to be named libgbm1 to satisfy the dependency from qt5
<zmatt>
which would break things for everyone using mesa (intentionally or not), including everyone using X11
<Guest15>
Only if X11 is using parts of the api not implemented. But even still shouldn't the priority then be to patch ti libgbm? It doesn't sound like it does a whole lot other than buffer creation?
<zmatt>
no, it would break X11 period
<zmatt>
actually I have no idea what would happen... it would use the buffer allocation routines from the sgx libraries
<zmatt>
at the very least it would add a hard dependency on the sgx libraries, while there are definitely people who don't want them on their system
<zmatt>
(because closed-source)
<Guest15>
But *if* the apis were compatible, how the memory was allocated shouldn't matter.
<zmatt>
not sure that's true, I don't know enough about how libgbm works in mesa vs the sgx libs
<zmatt>
regardless, the api isn't compatible
<zmatt>
and it would still break anything that uses mesa functionality not available in the sgx libs
<zmatt>
such as opengl
<zmatt>
(since sgx is only opengl ES and opengl ES2)
<zmatt>
and anything that tries to use any flavor of opengl on x11 in general
<Guest15>
Right. So the bottom line is that sgx libs don't provide a direct replacement for mesa.
<zmatt>
correct
<Guest15>
If that's the case, then naming libgbm.so.2 that way was not a bad thing. The system can still work with libgbm.so.1 (from mesa). Qt on top of eglfs works fine with libgbm.so.2. Or do I have it wrong?
<zmatt>
until both libgbms accidently get loaded into one application and it crashes
<zmatt>
and "the system" can't work with mesa's libgbm since it is designed to work with mesa, not with the sgx libs
<zmatt>
which won't be found if they're shadowed by the sgx libs
<zmatt>
*mesa's libs won't be found
<Guest15>
Right, but in that case, LD_LIBRARY_PATH should be used with Qt.
<zmatt>
that could be a solution
<Guest15>
The ti libs should NOT be installed into the standard libraries
<zmatt>
well, that's your opinion... I wouldn't want mesa installed on a bbb
<Guest15>
The ti libs can only be used with select programs though. Debian packages depend on mesa.
<zmatt>
almost none do
<zmatt>
and this also doesn't really matter, in the rare case I'd want to use opengl on a BBB, I certainly wouldn't want to use software rendering
<zmatt>
so anything that doesn't work with the sgx libs would simply be "doesn't run, too bad" for me
<zmatt>
there's no perfect solution here
<Guest15>
Right, but you know what you're doing... The average user doesn't.
<zmatt>
just different compromises
<zmatt>
the average user uses the BBB headless
<zmatt>
or uses mesa
<Guest15>
That's my point.
<zmatt>
given the restrictions of using the sgx libs, that's never going to change
<Guest15>
Somewhere the compromises should be documented so the user can decide what to do.
<zmatt>
would be nice yes
<zmatt>
the process can certainly be made easier
<zmatt>
it's just something few people care about hence little effort has been put into it
<Guest15>
Well I'm happy to try to write something up, but honestly I don't know enough to get it right.