=== chihchun_afk is now known as chihchun === marcusto_ is now known as marcustomlinson [09:42] alf_: answered? https://code.launchpad.net/~alan-griffiths/mir/update-libmirserver-symbols/+merge/252568 [09:43] alan_g: yes, thanks [10:13] 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] I have a pcduino3 board with a AllWinner A20 SoC [10:14] there's an Android image for the device [10:17] 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] okey, what dose USA-time mean in CET? [10:23] yes. [10:24] zzarr: hm expect them to arrive between 14:00 and 15:00 [10:24] is it -6 or -7 hours? [10:25] thanks :) [10:25] dunno... thats when they start to show up usually [10:25] UTC-6 [10:25] thanks :) [10:26] I love this community :) === chihchun is now known as chihchun_afk [10:56] zzarr, you will most likely want to read the ubuntu-touch porting guide [10:56] to get a shrunk down android container working that provides the necessary hybris setup [10:57] I'll look in to it [10:57] I'm about to port Ubuntu to a Android phone to... but that's next chapter [10:58] right, but i guess the setup you need will be the same in both cases [11:00] (or at least pretty close to each other) [11:06] I think so too :) [12:23] Why is mir_connection_create_spec_for_input_method() in mir_surface.h? [12:33] 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 === alan_g is now known as alan_g|lunch [13:48] thanks kdub :) [14:02] 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] would you have any ideas on why that is/where to start looking? [14:04] there is not such a high flip time with a client that respects vsync === dandrader is now known as dandrader|afk [14:05] greyback, so I guess the defaulte frame dropping in mir kicks in after 100ms, so that could account for some of it [14:06] hah, defaulte, that's the english spelling, right? [14:06] ye olde spelling perhaps :) [14:07] mir's framedropping timer causes it's own compositing to block? [14:07] it shouldn't but maybe that compositor_snapshot that's in the loop is causing the blockage? [14:08] I put a timer around mg::DisplayBuffer::flip() [14:08] hmm, and android or mesa platform? [14:08] mesa === alan_g|lunch is now known as alan_g [14:11] 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] Ubuntu bug 1377872 in Mir "Double-buffered compositing performance is very poor (30 FPS) on intel" [Medium,Confirmed] [14:11] Ubuntu bug 1377872 in Mir "duplicate for #1429264 Double-buffered compositing performance is very poor (30 FPS) on intel" [Medium,Confirmed] [14:11] 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] it must be something I'm doing wrong, as mir_proving_server doesn't behave so badly [14:12] you would have noticed 4fps as being broken :) [14:13] greyback: mir proving sever does weird shit - like compositing in an input event handler [14:13] alan_g: eee okay [14:13] we're just proving how robust we are? :) [14:15] 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] kdub: ok, I'll email with a branch & instructions [14:18] greyback, thanks === chihchun_afk is now known as chihchun === dandrader|afk is now known as dandrader [15:00] Defining default window position is doing my head in [15:03] “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] should be placed at the top left (LTR) or top right (RTL) of the display’s biggest non-shell space.” === dandrader is now known as dandrader|lunch === dandrader|lunch is now known as dandrader === alan_g is now known as alan_g|EOD [19:04] does mir handle pure KMS devices? [19:05] I'm running ubuntu on a tegra device that has a separate drm node for display and rendering [19:37] mlankhorst: what do you mean by pure KMS ? [19:37] I don't think there is a corresponding egl device for it [19:38] so it's a similar case to a displayport external usb [19:39] mmm, tegra w/o an egl [19:39] vogons ^ [19:39] shrug I'm testing with nouveau [19:40] itt's a jetson tk1 [19:40] eh, we probably need gbm/egl at some point of the initialization [19:41] so if I plug in a displaylink it won't work? [19:42] not sure [19:43] displaylink is a pure USB display that works with the modesetting driver in xorg [19:54] but there's no mesa driver for it since it has no acceleration [19:56] I think it wont work [19:56] thought as much [19:56] Because theres no GBM backend [19:57] rather than thelack of GL so to speak [19:57] the GL could be software [19:57] I guess we'vebeen hoping [19:57] that SimpleDRM/GBM (having a total blank...people from redhat are working on it...) or whatever its called [19:57] will solve this for us as iirc it includes [19:57] a software GBM backend [19:57] dumb GBM? [19:58] I think it's not dumb gbm haha [19:58] I mean that would be what you need there [19:58] using the 'dumb' interface :p [19:58] oh no but I mean I think [19:59] that interface doesn't quite do enough [19:59] thats what we use for software buffers on mesa (or I think...used to use?) [19:59] I think that doesn't provide a fake/software GBM 'device' though? [20:00] sorry it's been months and months since I've thought through this. [20:00] tl;dr; things without mesa bits wont work as it stands [20:00] bleh [20:00] we are kind of expecting someone else to provide themissing piece? [20:00] but that was months ago [20:01] why isn't the dumb interface sufficient? [20:03] mlankhorst: Hmm well the first problem is how would you even get gbm_device [20:05] same way? :p [20:08] mlankhorst: iirc though the dumb buffers are a feature of the [20:08] GBM DRI backend [20:08] but the DRI backend will fail to open a device [20:08] without [20:08] mesa bits [20:08] obv [20:09] you have a swrast gallium driver though? :P [20:09] why wouldn't that one work? [20:10] I dunno lol, you'd have to try [20:10] I guess the first point of failure would be mir only enumerating dri devices via udev (probably true?) [20:11] that's fine, it's a dri device.. [20:12] I guess I don't know whatI am talking about then :) [20:12] I thought it would be a DRM device but not a DRI device? [20:13] I now refer you to alf or raof :p [20:13] oke [20:14] Maybe it will work lol [20:14] there's some stuff about loading the swrast driver in [20:14] the gbm dri backend now that I dont remember [20:27] I think that's kms-swrast