[09:42] <alan_g> alf_: answered? https://code.launchpad.net/~alan-griffiths/mir/update-libmirserver-symbols/+merge/252568
[09:43] <alf_> alan_g: yes, thanks
[10:13] <zzarr> hello!  I need guidance to get 3D acceleration to work with the mir display server with the help of libhybris with a mali 400 gpu
[10:14] <zzarr> I have a pcduino3 board with a AllWinner A20 SoC
[10:14] <zzarr> there's an Android image for the device
[10:17] <alan_g> zzarr: you'll likely get the best help from kdub or AlbertA who are on USA time - they know most about bringing up android based devices.
[10:19] <zzarr> okey, what dose USA-time mean in CET?
[10:23] <alan_g> yes.
[10:24] <anpok_> zzarr: hm expect them to arrive between 14:00 and 15:00
[10:24] <zzarr> is it -6 or -7 hours?
[10:25] <zzarr> thanks :)
[10:25] <anpok_> dunno... thats when they start to show up usually
[10:25] <alan_g> UTC-6
[10:25] <zzarr> thanks :)
[10:26] <zzarr> I love this community :)
[10:56] <ogra_> zzarr, you will most likely want to read the ubuntu-touch porting guide
[10:56] <ogra_> to get a shrunk down android container working that provides the necessary hybris setup
[10:57] <zzarr> I'll look in to it
[10:57] <zzarr> I'm about to port Ubuntu to a Android phone to... but that's next chapter
[10:58] <ogra_> right, but i guess the setup you need will be the same in both cases
[11:00] <ogra_> (or at least pretty close to each other)
[11:06] <zzarr> I think so too :)
[12:23] <alan_g> Why is mir_connection_create_spec_for_input_method() in mir_surface.h?
[12:33] <kdub> zzarr, yes, you have to have that porting guide followed so that the android container is set up properly, but after that, the mali 400 should work with mir
[13:48] <zzarr> thanks kdub :)
[14:02] <greyback> kdub: hey, I was testing qtmir with duflu's favourite: a client which renders as fast as possible (mir_demo_client_egltriangle -n). I'm relying on mir's frame-dropping ability - so when qt renders, it just grabs a buffer with compositor_snapshot and releases it after swap & flip. However flip is taking >270ms in this case!!
[14:02] <greyback> would you have any ideas on why that is/where to start looking?
[14:04] <greyback> there is not such a high flip time with a client that respects vsync
[14:05] <kdub> greyback, so I guess the defaulte frame dropping in mir kicks in after 100ms, so that could account for some of it
[14:06] <kdub> hah, defaulte, that's the english spelling, right?
[14:06] <greyback> ye olde spelling perhaps :)
[14:07] <greyback> mir's framedropping timer causes it's own compositing to block?
[14:07] <kdub> it shouldn't but maybe that compositor_snapshot that's in the loop is causing the blockage?
[14:08] <greyback> I put a timer around mg::DisplayBuffer::flip()
[14:08] <kdub> hmm, and android or mesa platform?
[14:08] <greyback> mesa
[14:11] <kdub> greyback, so duflu and I are looking into these bugs, https://bugs.launchpad.net/mir/+bug/1377872, and https://bugs.launchpad.net/mir/+bug/1429264
[14:11] <kdub> I think there's something amiss with the switch to double buffering... if its easy to reproduce, probably best to file a bug and we can dig further
[14:12] <greyback> it must be something I'm doing wrong, as mir_proving_server doesn't behave so badly
[14:12] <greyback> you would have noticed 4fps as being broken :)
[14:13] <alan_g> greyback: mir proving sever does weird shit - like compositing in an input event handler
[14:13] <greyback> alan_g: eee okay
[14:13] <kdub> we're just proving how robust we are? :)
[14:15] <kdub> greyback, at any rate, I think either me or duflu would be interested in seeing if we can reproduce and figure out what's going on
[14:15] <greyback> kdub: ok, I'll email with a branch & instructions
[14:18] <kdub> greyback, thanks
[15:00] <mpt> Defining default window position is doing my head in
[15:03] <mpt> “Cascaded relative to another window means positioned one title-bar height lower than the other window, and one title-bar height to the right in an LTR language, or one title-bar height to the left in an RTL language — unless this would result in any part of the window being off-screen or in shell space, in which case the window should be shrunk the minimum amount to avoid this if that would not make it smaller than its minimum width/height, or otherwise
[15:03] <mpt> should be placed at the top left (LTR) or top right (RTL) of the display’s biggest non-shell space.”
[19:04] <mlankhorst> does mir handle pure KMS devices?
[19:05] <mlankhorst> I'm running ubuntu on a tegra device that has a separate drm node for display and rendering
[19:37] <kgunn> mlankhorst: what do you mean by pure KMS ?
[19:37] <mlankhorst> I don't think there is a corresponding egl device for it
[19:38] <mlankhorst> so it's a similar case to a displayport external usb
[19:39] <kgunn> mmm, tegra w/o an egl
[19:39] <kgunn> vogons ^
[19:39] <mlankhorst> shrug I'm testing with nouveau
[19:40] <mlankhorst> itt's a jetson tk1
[19:40] <kdub> eh, we probably need gbm/egl at some point of the initialization
[19:41] <mlankhorst> so if I plug in a displaylink it won't work?
[19:42] <kdub> not sure
[19:43] <mlankhorst> displaylink is a pure USB display that works with the modesetting driver in xorg
[19:54] <mlankhorst> but there's no mesa driver for it since it has no acceleration
[19:56] <racarr> I think it wont work
[19:56] <mlankhorst> thought as much
[19:56] <racarr> Because theres no GBM backend
[19:57] <racarr> rather than thelack of GL so to speak
[19:57] <racarr> the GL could be software
[19:57] <racarr> I guess we'vebeen hoping
[19:57] <racarr> that SimpleDRM/GBM (having a total blank...people from redhat are working on it...) or whatever its called
[19:57] <racarr> will solve this for us as iirc it includes
[19:57] <racarr> a software GBM backend
[19:57] <mlankhorst> dumb GBM?
[19:58] <racarr> I think it's not dumb gbm haha
[19:58] <mlankhorst> I mean that would be what you need there
[19:58] <mlankhorst> using the 'dumb' interface :p
[19:58] <racarr> oh no but I mean I think
[19:59] <racarr> that interface doesn't quite do enough
[19:59] <racarr> thats what we use for software buffers on mesa (or I think...used to use?)
[19:59] <racarr> I think that doesn't provide a fake/software GBM 'device' though?
[20:00] <racarr> sorry it's been months and months since I've thought through this.
[20:00] <racarr> tl;dr; things without mesa bits wont work as it stands
[20:00] <mlankhorst> bleh
[20:00] <racarr> we are kind of expecting someone else to provide themissing piece?
[20:00] <racarr> but that was months ago
[20:01] <mlankhorst> why isn't the dumb interface sufficient?
[20:03] <racarr> mlankhorst: Hmm well the first problem is how would you even get gbm_device
[20:05] <mlankhorst> same way? :p
[20:08] <racarr> mlankhorst: iirc though the dumb buffers are a feature of the
[20:08] <racarr> GBM DRI backend
[20:08] <racarr> but the DRI backend will fail to open a device
[20:08] <racarr> without
[20:08] <racarr> mesa bits
[20:08] <racarr> obv
[20:09] <mlankhorst> you have a swrast gallium driver though? :P
[20:09] <mlankhorst> why wouldn't that one work?
[20:10] <racarr> I dunno lol, you'd have to try
[20:10] <racarr> I guess the first point of failure would be mir only enumerating dri devices via udev (probably true?)
[20:11] <mlankhorst> that's fine, it's a dri device..
[20:12] <racarr> I guess I don't know whatI am talking about then :)
[20:12] <racarr> I thought it would be a DRM device but not a DRI device?
[20:13] <racarr> I now refer you to alf or raof :p
[20:13] <mlankhorst> oke
[20:14] <racarr> Maybe it will work lol
[20:14] <racarr> there's some stuff about loading the swrast driver in
[20:14] <racarr> the gbm dri backend now that I dont remember
[20:27] <mlankhorst> I think that's kms-swrast