[11:50] <alan_g> alf__: happy with the latest renames in https://code.launchpad.net/~alan-griffiths/mir/extending-SurfaceObserver/+merge/213516?
[13:08] <alf__> greyback: Hi! Do you know which component in our stack handles the display-off signal from powerd and sets the new Mir display configuration?
[13:13] <greyback> alf__: I believe unity-system-compositor does that job. powerd does a dbus call, which USC receives and sets the display config
[13:18] <alf__> greyback: great thanks
[13:35] <anpok> kgunn: https://code.launchpad.net/~andreas-pokorny/mir/no-initial-display-configuration-sent-to-hosting-server/+merge/213126 do we need this to land soon - necessary for split greeter, but just a workaround - we are still discussing alternatives
[13:38] <kgunn> anpok: for split greeter...yes sir! i'd really like to get split in asap
[14:17] <alan_g> kgunn: it is a shame it didn't get into the 0.1.8 MP then.
[14:22] <kgunn> alan_g: drat....altho we can cherry pick
[16:18] <kdub> do we have any relatively recent build silos with the unity stack handy?
[16:34] <racarr> nnn
[16:34] <racarr> whoops
[16:38] <alan_g> Missing ffe?
[16:42] <anpok> 0xAFFE?
[16:42] <anpok> a C0
[16:44] <alan_g> Focus Follows Eyes
[16:45] <anpok> ah ok .. I thought you meant FFE in c0ffe
[16:46] <anpok> for some people coffee is like 23 .. you can find it everywhere
[16:56] <kdub> we store an address of a reference and use it as an ID in GLRenderer -_-
[16:57] <alan_g> kdub: you can't take the address of a reference. Only the address of what it references.
[16:58] <alan_g> That sort of trick breaks badly if the reference is bound to a temporary.
[16:59] <kdub> right, and the renderlist is about to become a temporary, so have to detangle that
[17:00] <kdub> unexpected surprises, all part of refactoring :D
[17:16] <anpok> kdub: I think input dispatch wants the same from the scene..
[17:16] <anpok> a list of things-on-screen that can take input
[17:16] <kdub> anpok, but the input stuff shouldn't really be taking a Renderable :)
[17:17] <kdub> anpok, that makes sense though, there's a for-each-if for input too
[17:17] <anpok> hm I wonder if it is worth to have something different than renderable
[17:17] <kdub> from an interface perspective, I'd say it would be better to have a Renderable and an InputTarget (or similar name)
[17:17] <anpok> I mean touch input dispatch is all about graphical items on screen
[17:19] <kdub> well, even at that there's a delta between what they're doing, like renderable has 'number_of_uncomposited buffers' and 'alpha'
[17:19] <anpok> yeah that part
[17:19] <kdub> whereas the input stuff would just need transform and 'input targettable'
[17:19] <anpok> well alpha == 0 means I dont care..
[17:19] <anpok> true
[17:20] <kdub> right, so basic surface could condense all the compositor reasons for not being onscreen into something simpler for input
[17:21] <kdub> If you have a reason to target the for_each_if (for the input-based iteration over the stack) for elimination, I'd be happy about that :)
[17:22] <anpok> I think I want to get a condensed from the scene, copies. of the current scene status.. so that no locks are needed.. so this part is similar to gettign a renderlist from scene.
[17:23] <kdub> sounds good to me, i'm doing something similar in lp:~kdub/mir/kill-scene-lock
[17:24] <kdub> you'd still need a lock on the scene... just for a shorter period of time
[17:24] <kdub> while the 'light' data is copied
[17:24] <anpok> hm and for all involved surfaces?
[17:25] <anpok> is basic surface still a Renderable?
[17:28] <kdub> it is currently, but it doesn't have to be moving forward
[17:29] <kdub> I see something like Renderable(BasicSurface) and InputTargetable(BasicSurface) in the future
[17:31] <kdub> like, Renderable is really what the compositor/displaybuffer needs to do its stuff, its unfortunate that its a lot of handy info in one place :)
[17:35] <anpok> hmm I see something like Renderable(SceneNode) InputTargetable(SceneNode) and SceneNode having a position/orientation/alpha/dunno and a reference to BasicSurface
[17:35] <anpok> BasicSurface only has the buffers a size and what is needed to talk to the clients..
[17:37] <kdub> sure, I think we mean the same thing, except SceneNode would be an interface that BasicSurface implements (in your case) and in mine, I wasn't specifying an interface
[17:37] <anpok> kdub: I asked because it is possible that you distill a list of renderables now, and someone moves the basic surface around afterwards..
[17:37] <kdub> but yeah, right :)
[17:37] <anpok> nope I mean SceneNodes are instances that refer to BasicSurfaces
[17:37] <kdub> 'moves' meaning what? like moves the object?
[17:37] <kdub> or moves the position on the screen
[17:37] <anpok> yeah new pos
[17:38] <anpok> I would like to be able to have one client surface shown in different places on screen..
[17:38] <anpok> so yeah SceneNode would be an indirection towards BasicSurface
[17:38] <kdub> sure, still not seeing the problem yet though
[17:39] <anpok> maybe also towards (BasicSurface|DecorationSurface)
[17:39] <anpok> with moving?
[17:39] <kdub> whichever problem is being posited :)
[17:39] <anpok> hehe
[17:39] <anpok> hm you might be drawing a frame with surface in State X+1 with occlusion filters applied to surfaces while they were in State X
[17:40] <anpok> *surfaces
[17:40] <anpok> thats why I thought copying would be better, and Renderable not being SceneNodes/BasicSurfaces(for now)
[17:40] <kdub> right, i think copying is better too
[17:42] <kdub> the Renderable(SceneNode) constructor does a copy (or lazy copy, where appropriate/feasible)
[17:43] <anpok> ok
[17:57] <kgunn> bregma: do you wanna approve
[17:57] <kgunn> https://code.launchpad.net/~robertcarr/unity-system-compositor/add-cursor-option/+merge/213896
[17:57] <kgunn> https://code.launchpad.net/~robert-ancell/lightdm/usc-hardware-cursor/+merge/213897
[17:57]  * bregma looks
[18:24] <anpok> racarr: what editor are you using, some of the n's ended up in a different window, I guess.
[18:26] <racarr> yes they were just accidental nns lol
[18:26] <racarr> keyboard drumming while thinking + accidental enter key
[18:26] <anpok> because one n might have made it to a MP
[18:47] <greyback> racarr: stupid question here, but is the "hardware cursor" a real overlay/plane cursor drawn by the driver, or is it drawn by Mir's Renderer/Compositor?
[18:51] <racarr> greyback: driver
[18:51] <greyback> racarr: nice, thanks
[19:25] <racarr> lunch back in a flash
[19:38] <racarr> back
[20:18] <dansuf> kgunn: I built touch system with old driver and when I run unity8 now I get the start screen but only that and I got repeating messages in the logcat
[20:18] <dansuf> E/qdgenlock( 1349): perform_lock_unlock_operation: GENLOCK_IOC_DREADLOCK failed (lockType0x1,err=Connection timed out fd=80)
[20:18] <dansuf> W/Adreno200-EGLSUB( 1349): <GetBackBuffer:2121>: genlock_lock_buffer GENLOCK_WRITE_LOCK failed
[20:18] <dansuf> W/Adreno200-EGL( 1349): <qeglDrvAPI_eglSwapBuffers:3477>: EGL_BAD_ALLOC
[20:18] <dansuf> which appear randomly or when I touch the screen
[20:22] <dansuf> w-flo, who inspired me to update my drivers, wrote in his commit that before using new drivers some changes to mir code and genlock fixes in hardware_qcom_display were needed
[20:23] <dansuf> I'll try to solve the problem of genlock on my own
[20:25] <kgunn> dansuf: yeah..sorry, i'd not have an idea on that one...
[20:25] <kgunn> dansuf: curious...when you say start screen? you mean...like this http://www.blogcdn.com/www.engadget.com/media/2013/02/ubuntu-hands-on-620-ces2013.jpg
[20:27] <dansuf> kgunn: it's more ugly because the fonts are too big, not in proper place with no smaller circles arond the big one and with no top panel (there is just a black space)
[20:27] <dansuf> kgunn: despite this, yes
[20:27] <dansuf> :D
[20:31] <kgunn> dansuf: ok...so at least _some_ progress
[20:32] <dansuf> kgunn: yeah, I have to leave now, If I have no clues about it I'll conbtact w-flo or developer who is providing unofficial support for my device
[21:39] <racarr> sometimes the put things in the namespace htey are used rule is difficult to follow...the cursor controller needs to use the change callback from scene, so I had to extend the change callback mechanism to support multiple change targets
[21:40] <racarr> so the thing is the compositor uses like set_change_callback(null callback) tl clear it, so when having multiple callbacks you need to have some sort of add_callback -> id
[21:40] <racarr> remove_callback(id) sort of system.
[21:41] <racarr> so mi::InputTargets and mc::Scene and ms::SurfaceStack gain like unsigned add_change_callback(unction) remove_change_callback(unsigned callback_id)
[21:41] <racarr> and you want to typedef unsigned CallbackID, or maybe even use RAII or something
[21:42] <racarr> but what namespace
[21:42] <racarr> can you put that return type in?
[21:44] <racarr> you have to put it in ms:: and in its own header...like say we do with depth id
[21:44] <racarr> which breaks the namespacing rule and contains license header to code in a ratio of 40:1 lol
[21:44] <racarr> cest la vie
[21:54] <racarr> nevermind im silly
[21:55] <racarr> if you use riaa and a unique_ptr+std::function deleter for
[21:55] <racarr> the type
[21:55] <racarr> you only need a forward declaration
[21:55] <racarr> in headers
[21:55] <racarr> its still breaks the namespace rule but eh
[22:04] <AlbertA> std::function deleter?
[22:04] <AlbertA> so add_change_callback will return what?
[22:04] <AlbertA> a unique_ptr<SomeType>?
[22:05] <AlbertA> racarr:^
[22:12] <racarr> AlbertA: Yes. i.e. unique_ptr<ChangeCallbackInterest, std::function<void(ChangeCallbackInterest*)>>
[22:12] <racarr> so you dont need a definition
[22:12] <racarr> for ChangeCallbackInterest
[22:12] <racarr> ID, Registration
[22:12] <racarr> something
[22:12] <racarr> I dont know the name yet
[22:12] <AlbertA> and the custom deleter is for unregistering automatically?
[22:12] <racarr> Yes
[22:13] <AlbertA> cool
[22:13] <AlbertA> I was looking into it briefly
[22:13] <AlbertA> because I want to also hook into the scene change
[22:13] <racarr> Ah
[22:13] <AlbertA> for screencast purposes
[22:13] <racarr> well I have a branch to do it, i just need to comment it
[22:13] <racarr> and look at the diff
[22:13] <racarr> but will have it mped by EOD