[07:56] <zzarr> hello duflu :-) I'm back
[07:59] <duflu> zzar: Hello
[08:00] <duflu> zzarr: What happened when you started Mir? You only mentioned one log message yesterday. Was that the end?
[08:04] <zzarr> duflu, how do I start Mir? is it the sudo mir_proving_server you mean?
[08:11] <duflu> zzarr: Yes that
[08:13] <zzarr> duflu, if it is that command, I just ran it again, and it says that "gbm: failed to open any driver (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)"
[08:14] <zzarr> gbm also complains about not being able to open /usr/lib/dri/rockchip_dri.so
[08:14] <duflu> zzarr: Yeah that's the failure I expected all along. You either need some Mali driver for Mesa, or some new Mir driver for Mali.
[08:14] <duflu> Ooh, maybe rockchip_dri.so exists somewhere
[08:15] <zzarr> duflu, I'm scanning the internet
[08:16] <zzarr> duflu, is that driver a kernel driver or user driver?
[08:16] <duflu> zzarr: It's the user driver Mesa needs for hardware acceleration
[08:17] <duflu> zzarr: You might get around it with env LIBGL_ALWAYS_SOFTWARE=1
[08:18] <zzarr> duflu, ohh... in that case there might be way to find it (I think others have done it)
[08:18] <duflu> I can't see any evidence that rockchip_dri.so exists yet. But environment variable LIBGL_ALWAYS_SOFTWARE=1 should skip the need for it
[08:21] <zzarr> duflu, okey, I know that people have gotten 3D acceleration to work with X, are the rockchip_dri.so they used specific for X?
[08:22] <duflu> zzarr: That's just a file Mesa needs to implement OpenGL. If they got X working it might have been without any OpenGL
[08:24] <zzarr> duflu, okey, I tried sudo mir_proving_server after setting LIBGL_ALWAYS_SOFTWARE to 1, butI got the same error messages
[08:24] <zzarr> (from gbm)
[08:24] <duflu> zzarr: Yeah I just tested it and Mir weirdly ignores that common variable, still tries hardware acceleration or nothing. Sounds like a bug
[08:25] <zzarr> duflu, I agree
[08:26] <zzarr> duflu, a little off topic, do I need to add netdev to the lightdm user in order to login to a WiFi from lightdm?
[08:31] <duflu> zzarr: No idea. You will have to ask in ubuntu-desktop or some other channel
[08:31] <zzarr> duflu, I'll do
[08:31] <duflu> zzarr: You can follow this: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1543952
[08:31] <ubot5`> Launchpad bug 1543952 in mesa (Ubuntu) "Mir binaries ignore Mesa setting LIBGL_ALWAYS_SOFTWARE=1 and only ever try hardware acceleration" [Undecided,New]
[08:32] <zzarr> duflu, there it is
[08:32] <duflu> It is now anyway
[08:34] <zzarr> yea
[08:41] <anpok_> duflu: if there is no drm driver there is nothing to post buffers to
[08:42] <duflu> anpok_: I know. But there is one or two (sw) and Mesa won't let us use them
[08:43] <duflu> Which is odd. In regular Ubuntu, Unity7 relies on LIBGL_ALWAYS_SOFTWARE as a failsafe fallback
[08:43] <duflu> And it works
[08:44] <duflu> Maybe egl-platform-mir is forcefully choosing hardware drivers only...
[08:44] <anpok_> mir doesnt care what driver mesa uses. we just dont build mesa with the fbdev platform... so mesa may only work on top of x11, wl, mir and drm
[08:44] <anpok_> so if the kernel does not include drm-next patches it will be missing the rockchip drm driver that is currently being integrated
[08:44] <duflu> anpok_: Also doesn't matter. He has working DRM with the mali/rockchip GPU
[08:45] <duflu> anpok_: Also he built his own kernel with the required DRM.
[08:45] <anpok_> oh so then things should work just like within
[08:45] <anpok_> kvm
[08:45] <anpok_> where we use the software backend of mesa
[08:45] <duflu> Yeah but Mesa insists looking for rockchip_dri.so which may not even exist
[08:46] <duflu> And Mesa still insists even if you try to force it to use the software driver
[08:47] <duflu> When I do so on desktop it still gets Intel DRI
[08:47] <anpok_> hm is there a kms_swrast_dri.so?
[08:47] <duflu> anpok_: On my machine yes
[08:47] <anpok_> hm there is a good chance the respective env variable inside gbm/egl is different
[08:48] <anpok_> thats the one it should fall back to,,
[08:54] <zzarr> interesting
[09:16] <zzarr> duflu, would a fbdev user driver help?
[09:19] <duflu> zzarr: No, that would probably be worse. Looks like you're waiting on a Mesa/Mir fix
[09:21] <zzarr> duflu, do you mean for sw acceleration?
[09:22] <duflu> Yes (which is much easier than hw)
[09:23] <zzarr> duflu, would I be able to use an X11 hw driver with XMir?
[09:23] <duflu> You're probably making it more complicated and harder again
[09:24] <zzarr> duflu, sorry, it's a bad habit ;-)
[09:24] <zzarr> duflu, what about the android driver?
[09:24] <duflu> zzarr: Again, that's worse
[09:27] <zzarr> duflu, if I got my hands on the fbdev or X11 drivers source, how much work and is there a guide to write my own Mir driver? (please, it's not your monitors fault, it my fault the text is in front of you)
[09:28] <duflu> zzarr: alf_ is already working on fbdev (or some alternative) in theory. I suggest your best bet is to figure out the bug with the env var
[09:29] <duflu> Which would help us too
[09:29] <zzarr> duflu, okey
[09:30] <zzarr> duflu, at the moment I will try the X11 drivers
[09:32] <zzarr> duflu, but I will try to figure out what's up with the SW variable, where's the code that's related to the variable?
[09:32] <duflu> zzarr: Mesa :)
[09:32] <zzarr> duflu, okey, thanks alot for your help :-)
[09:33] <duflu> zzarr: No problem
[09:34] <zzarr> duflu, another OT question, how do I find out why Unity(7) don't appear for me even with the drivers in place?
[09:34] <zzarr> (the X11 drivers)
[09:35] <duflu> zzarr: #ubuntu-unity I think
[09:35] <duflu> could be wrong
[09:35] <zzarr> okey, thanks duflu
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[14:05] <zzarr> alf_, hello! I have to ask out of curiosity, how far along with the frame buffer support for Mir are you?
[14:05] <zzarr> alf_, I mean the fb driver support
[14:09] <alf_> zzarr: Hi! Just a proof of concept (and only for software buffers). I haven't touched the code in a long time now.
[14:10] <alf_> zzarr: (which isn't published anywhere at the moment)
[14:11] <zzarr> alf_, okey, will there be hw fb support in the future?
[14:15] <alf_> zzarr: What do you mean by hw fb support? The PoC code used the fbdev interface, by "software buffers" I mean the buffers posted by the client need to be software buffers (i.e. their pixels need to be directly accessible, contrast to accelerated/hw buffers used e.g. for GL rendering on the GPU)
[14:24] <zzarr> alf_, I'll tell the hole story, I have a Chromebook with a mali GPU and wish to get Mir running on it
[14:27] <zzarr> alf_, I only have a fbdev driver and a X11 driver
[14:36] <zzarr> alf_, I have the ASUS Chromebook Flip you see, and the way Unity8/Mir handles touch it's perfect :-)
[15:00] <mcphail> alan_g: Do you mind if I ask if that gcc bug is looking to be the culprit for the screen crashing on calls on the phone? I've be holding off updating my phone because of this, and it would be good to know if there has been a lead
[15:03] <alan_g> mcphail: maybe. In any case it is something we need to eliminate. Last I heard we've still not been able to reproduce the problem under controlled conditions but have stack traces pointing to that area.
[15:04] <mcphail> alan_g: thanks. I think it is fascinating that this could be the cause. Amazing detective work you're doing
[15:47] <alf_> alan_g: mcphail: FYI, our current understanding of that crash is that input and compositor threads deadlock during compositor startup, causing the compositor to throw an exception because it times out waiting for its threads to start, leading to a crash. We we will ship a fix for this in 0.19.2.
[15:48] <pete-woods> greyback: hey, did your MR to libqtdbustest help at all?
[15:48] <greyback> pete-woods: not got around to checking tbh
[15:48] <greyback> was gonna land it, and then see. I can't emulate what the jenkaas instance is doing
[15:49] <pete-woods> greyback: okay, no worries, was just wondering if it needed putting in a silo
[15:49] <greyback> pete-woods: it does. I was going to do that for next unity8 landing, but that might be a while away yet
[15:50] <pete-woods> greyback: sure, wasn't pressing you to do it now or anything, was more an offer to land it for you, but I'll hold off if you don't know it helps
[15:51] <greyback> pete-woods: fair. We'll stick it in our silo and see if it helps. No point landing if it doesn't
[15:52] <mcphail> alf_: brilliant. thanks for the info and teh hard work :)
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader
=== alan_g is now known as alan_g|EOD
=== DalekSec_ is now known as DalekSec
=== mariogrip_ is now known as mariogrip