[04:48] <RAOF> Filtering systems, oh my!
[04:48] <RAOF> robert_ancell: You've found that XMir now works, I trust?
[04:48] <RAOF> It does here, even if I have all my GPUs powered up.
[04:53] <robert_ancell> RAOF, yes, been getting it working. I can do user switching now :)
[04:53] <RAOF> Woot!
[04:53] <robert_ancell> still input pass through issues though :(
[04:53] <robert_ancell> And I'm really struggling to get the appropriate information from Mir. I feel some patches coming on :)
[04:54] <RAOF> :)
[04:56] <robert_ancell> thomi, can you set up CI and autolanding (into mir-team staging PPA) for lp:unity-system-compositor?
[04:56] <thomi> robert_ancell: sure, but before it gets deployed Francis need to review it, and I won't see him now till oakland :-/
[04:57] <robert_ancell> thomi, ok, np. Just put it into the queue
[04:57] <robert_ancell> I'll do some manual uploads until then
[04:57] <thomi> ok
[04:58] <thomi> robert_ancell: what packaging branch are you using?
[04:58] <robert_ancell> thomi, it has packaging checked in
[04:58] <robert_ancell> thomi, also, we set up lp:~mir-team/lightdm/mir to autoland right? Can we switch that to lp:~mir-team/lightdm/unity instead?
[04:59] <thomi> robert_ancell: sure.
[04:59] <thomi> I wish you could file bugs against a person in LP
[04:59] <thomi> would make for a handy TODO list tracker for me
[04:59] <robert_ancell> thomi, you guys need to make a project for this :)
[04:59] <robert_ancell> the bug-thomi-for-stuff project
[04:59] <thomi> hmmmm, why not...
[05:00] <duflu> Hah. That's asking for trouble. Bug: "This person smells"
[05:01] <thomi> meh - started doing it, got bored
[05:16] <tvoss> RAOF, ping
[05:25] <RAOF> tvoss: Yo!
[07:36] <tvoss> alan_g|life, ping
[07:36] <tvoss> michi, ping
[07:36] <michi> tvoss: pong
[08:10] <alan_g> tvoss: pong (sorry for the delay)
[09:59] <hikiko> hello
[10:01] <hikiko> question :) when i initialize the gbm I need to connect to a drm device and then create a context etc
[10:02] <hikiko> but when I am inside X i have already a connection to the device and glx context
[10:03] <hikiko> is there any way to give the existing content to the gbm?
[10:03] <hikiko> (i couldn't find something)
[10:15] <RAOF> hikiko: No.
[10:17] <hikiko> RAOF,
[10:17] <hikiko> :D i was about to email you
[10:17] <hikiko> then
[10:17] <hikiko> the only way to have an X backend for mir
[10:18] <hikiko> is by implementing another buffer mechanism isn't it?
[10:18] <hikiko> :s
[10:18] <RAOF> hikiko: What you need to do (and what Mesa does) is open a connection to the drm device, call drmGetMagic on that fd, send the magic value to the X server via DRI2Authenticate, which will authenticate your fd, *then* pass that fd to gbm.
[10:21] <hikiko> http://www.x.org/releases/current/doc/dri2proto/dri2proto.txt this extension?
[10:22] <hikiko> ah I got it :)
[10:22] <hikiko> thank you R__
[10:22] <hikiko> RAOF*
[10:23] <RAOF> Correct!
[10:24] <hikiko> so then i can open a win get the current context
[10:24] <RAOF> Hm. Now that I think of it, there's still the problem of how to get your buffers *out* of gbm.
[10:26] <hikiko> there's no function to get the user data?
[10:29] <hikiko> ah you mean that then you have to pass through drm again
[10:29] <hikiko> ?
[10:30] <RAOF> Meaning you'll have a gbm bo with the rendering you want to display, but you need to get that into the X window somehow.
[10:31] <RAOF> Hah! The EGL_DRM_BUFFER_MESA target of eglCreateImageKHR will do what you want.
[10:31] <RAOF> Although you've got a GLX context, not an EGL context, right?
[10:32] <hikiko> I have a glx but I called the eglGetCurrentContext and then attempted to create a khr image :p
[10:33] <hikiko> but i used the native pixmap target
[10:33] <hikiko> which is wrong
[10:34] <RAOF> Hm. Actually we want to go the other way, don't we - you want to create an EGL image, then gbm_bo_import() that EGL image to get the gbm_bo that you hand off to the rest of the buffer machinery.
[10:36] <RAOF> So, I think you've got two options - create an EGL image and gbm_bo_import() that to feed to the gbm bits, or pull a gbm_bo out of the gbm bits, get the handle with gbm_bo_get_handle(), and eglCreateImageKHR() that handle with type EGL_DRM_BUFFER_MESA.
[10:37] <hikiko> the first seems easier but I think that the second is similar to what we already do isn't it?
[10:39] <RAOF> I think we actually do the first.
[10:39] <RAOF> :)
[10:39] <hikiko> :D
[10:40] <RAOF> Oh, no. We do the latter.
[10:41] <RAOF> Because we sometimes want to be all software rendering.
[10:42] <hikiko> why can't you do the first with software rendering?
[10:43] <RAOF> Because you may (and, in practise, do) need to allocate the buffer differently if you're going to write from the CPU to it.
[10:43] <RAOF> Unless you use something like TexImage2D, of course.
[10:43] <RAOF> But that was apparently too slow.
[10:46] <hikiko> so better to follow the 2nd way too? or we ll have software rendering only outside X (eg when we render to the framebuffer device)?
[10:46] <RAOF> Yeah, I think you'll need to go the second path.
[10:47] <hikiko> ok
[10:48] <hikiko> and RAOF I had a problem with libgbm
[10:48] <RAOF> Or, rather, gbm_buffer_allocator.cpp already goes the second path, and I think with the possible exception of using EGL_DRM_BUFFER_MESA rather than EGL_NATIVE_PIXMAP_KHR you'll be able to copy it wholesale.
[10:48] <RAOF> (This is why I need to refactor the platforms to separate display from buffer allocation)
[10:49] <hikiko> I see, I am trying to do all these outside mir first because if I start the changes on a mir branch I won't be able to debug easily
[10:51] <RAOF> That sounds sensible.
[10:52] <RAOF> Or, at least, a stinging indictment of our current architecture which makes what should be a reasonably simple task difficult :/l
[10:52] <hikiko> but I had a problem with libgbm: i upgraded and after that I couldn't run a very simple example that just creates a drm device and then a gbm buffer and was working fine. I switched to debian where I have the old versions and it was working :s
[10:55] <hikiko> but i can't continue on debian because I don't have half of the functions
[10:55] <alan_g> RAOF: we should be looking at fixing whatever makes simple tasks difficult
[10:56] <RAOF> alan_g: In this case, it's because display and buffer allocation are needlessly conflated.
[10:56] <RAOF> alan_g: It's on TODO.
[10:56] <alan_g> RAOF: I'll let you own it then. ;)
[10:58] <RAOF> hikiko: Hm, urgh. I'd ask for the sample code, but it's time for bed here.
[10:58] <RAOF> hikiko: We can sort it out in Oakland, I guess!
[10:58] <hikiko> sorry RAOF :) I forgot the time difference :)
[10:58] <hikiko> thank you very very much
[10:59] <RAOF> s'ok. I'm the one who'se silly enough to be on IRC at this point :)
[10:59] <hikiko> thanks :D
[14:30] <alan_g> mmrazik|afk: can you see what's wrong here? http://jenkins.qa.ubuntu.com/job/mir-quantal-amd64-ci/507/console
[15:23] <racarr> Hi :)
[15:25] <alan_g> Afternoon
[15:42] <mmrazik|afk> alan_g: mising xsltproc as build dependency? http://pastebin.ubuntu.com/5605060/
[15:42] <mmrazik|afk> just guessing
[15:43] <mmrazik|afk> but weird as its not something new
[15:44] <alan_g> mmrazik|afk: that makes sense - thanks, I couldn't find a signal in all the noise.
[16:28]  * kdub should get his laptop up to snuff before monday
[16:32] <olli> racarr, around?
[16:32] <racarr> olli: Yep!
[16:33] <olli> racarr, I am looking at BP https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone-iteration-0
[16:34] <racarr> Ok
[16:34] <olli> trying to see if we achieved Acceptance criteria for April
[16:34] <olli> do you have some insight into that
[16:34] <racarr> Almost
[16:34] <racarr> my outstanding workitems exist in local branches or
[16:34] <olli> almost got insight or almost achieved it ;)
[16:35] <racarr> sometimes branches with other people
[16:35] <racarr> it's just review is backed up
[16:35] <racarr> so hopefully can land the remainders monday and say we made it for april :)
[16:36] <olli> racarr, ok ;)
[16:37] <racarr> olli: Err...I had a brain error
[16:38] <racarr> and was reading the criteria for may ;)
[16:38] <olli> whot? impossible ;)
[16:38] <racarr> we are even
[16:38] <racarr> closer
[16:38] <racarr> to april :)
[16:38] <olli> for may?
[16:38] <olli> it says tbd
[16:38] <olli> don't get confused by the month-X suffic
[16:38] <racarr> Oh I was just seeing if the workitems were finished
[16:38] <olli> suffix even
[16:38] <olli> gotcha
[16:38] <racarr> the acceptance criteria
[16:39] <racarr> are great :)
[16:41] <racarr> what is the conceptual difference between
[16:42] <racarr> acceptance criteria  and all the work items being finished
[16:42] <racarr> I didn't really understand when those were added
[16:45] <alan_g|bbs> racarr: the blueprints are far from clear to me, glad you don't understand them either.
[16:54] <bschaefer> racarr, hello! I've a question about scroll events
[16:56] <bschaefer> or rather that its hard to get vscroll hscroll info without having to do this: http://paste.ubuntu.com/5605289/
[17:46] <olli> racarr, alan_g|bbs the Acceptance Criteria should be a description of the sum of work items, i.e. something I can understand ;)
[17:54] <alan_g|bbs> olli: ;)
[18:02] <tvoss> racarr, ping
[18:50] <racarr> Sorry have to run out again for apartment hunting nonsense :)
[18:50] <racarr> back in the afternoon...
[18:51] <bschaefer> good luck hunting!
[23:14] <racarr> back!
[23:14] <racarr> working on a bug where things seem to go wrong (fds get closed) when
[23:23] <racarr> focus cycles multiple times
[23:23] <racarr> whoops. forgot to press enter :)