[08:29]  * duflu falls into the obsession of finding new ways to reduce latency again
[08:32] <anpok> this time using an organic lvds interface?
[08:36] <duflu> anpok: Sounds difficult to patch into a stable release
[10:08] <greyback_> It seems necessary that MIR_SERVER_NAME must be set to something in order for a nested client to work. That expected?
[10:09] <greyback_> aha no, USC depends on it
[15:29]  * alan_g hates it when compiler optimizations affect behaviour (especially the result of tests)
[16:25] <AlbertA2> Any review volunteers for these USC fixes?
[16:25] <AlbertA2> https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1353647/+merge/230370
[16:25] <AlbertA2> https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1230345/+merge/230844
[16:25] <AlbertA2> mterry: ^
[16:30] <mterry> AlbertA2, OK
[16:30] <mterry> AlbertA2, in the second one, the timeout-over-dbus one, values <=0 are ignored.  We don't want them to disable a timeout?
[16:32] <AlbertA2> mterry: yeah I guess it should be possible, but needs a bit of refactoring so we can disable each individually
[16:51] <mterry> AlbertA2, in the other merge, why split acquired_sys_state into two fields?  With (!requested_suspend_blocker || pending_suspend_blocker), you are allowing for calling requestSysState twice and overriding your existing cookie, aren't you?
[16:51] <AlbertA2> in case powerd is not available and there's a pending request to block suspend basically
[16:52] <AlbertA2> for example if powerd crashes...and we turned on the screen
[16:52] <AlbertA2> and the interface is not available but will in the future
[16:52] <AlbertA2> or when booting when powerd may not yet be available, we issue the suspend block call when it does become available
[16:55] <mterry> AlbertA2, but if you see that powerd comes back up, you just clear the requested_suspend_blocker and sys_state_cookie fields and request it again, right?
[16:55] <mterry> I'm not seeing why you would need the pending field
[16:57] <AlbertA2> mterry: oh so it's because I'm not getting the serviceUnregister call if powerd restarts or crashes...I dunno why...
[16:57] <AlbertA2> so
[16:58] <AlbertA2> The pending flag is kinda used to force to issue the call again, since the internal state in powermediator is out of sync
[16:58] <mterry> AlbertA2, well...  you don't necessarily *need* the unregister call.  We can just pay attention to the register calls
[16:59] <mterry> AlbertA2, but any time you would set pending=true, why not just instead set requested=false?
[16:59] <mterry> AlbertA2, two fields complicates the logic and means that the code can (if requested=true and pending=true) request a second cookie and forget it requested the first
[17:00] <AlbertA2> mterry: yeah I thought I had a reason..but I don't see why it needs to be two fields...
[17:01] <AlbertA2> let me simplify that then
[17:03] <AlbertA2> mterry: oh, I think I remember...
[17:04] <AlbertA2> mterry: in the case that powerd is not yet available...I wanted something to tell me
[17:04] <AlbertA2> in case the suspend block call was issued
[17:05] <AlbertA2> that we needed to request a suspend block...
[17:05] <mterry> AlbertA2, but wouldn't requested remain false then?
[17:05] <AlbertA2> since powerdMediator
[17:05] <AlbertA2> does not track the screen power state
[17:05] <AlbertA2> right...but if it has not been requested...
[17:05] <AlbertA2> then there's no need to actually make the call
[17:06] <AlbertA2> basically if powerd restarts while the screen is off
[17:06] <AlbertA2> there's no need to issue the call...
[17:08] <AlbertA2> but I'll try and make that more clear...
[17:08] <mterry>  AlbertA2, OK I think I get it.....  But
[17:10] <mterry> AlbertA2, seems like we should save the desired state in one field.  And whether or not we have a cookie in another (maybe just examine if cookie string is empty).  That way we can always know what to do
[17:11] <mterry> If we notice that powerd restarted, we can clear the cookie and look at desired state to see if we should make the request
[17:11] <AlbertA2> mterry: yeah that makes sense...let me see
[17:29] <smallfoot-> It is impossible to uninstall Mir in Utopic
[17:29] <smallfoot-> when I try to remove some Mir package, it tries to remove like all packages on the system
[18:10] <AlbertA2> mterry: updated https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1353647/+merge/230370