=== infernixx is now known as infernix === chihchun_afk is now known as chihchun [08:29] * duflu falls into the obsession of finding new ways to reduce latency again [08:32] this time using an organic lvds interface? [08:36] anpok: Sounds difficult to patch into a stable release [10:08] It seems necessary that MIR_SERVER_NAME must be set to something in order for a nested client to work. That expected? [10:09] aha no, USC depends on it === Stskeepz is now known as Stskeeps === alan_g is now known as alan_g|lunch === chihchun is now known as chihchun_afk === alan_g|lunch is now known as alan_g === chihchun_afk is now known as chihchun === w00t_ is now known as w00t === chihchun is now known as chihchun_afk === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:29] * alan_g hates it when compiler optimizations affect behaviour (especially the result of tests) === dandrader is now known as dandrader|lunch [16:25] Any review volunteers for these USC fixes? [16:25] https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1353647/+merge/230370 [16:25] https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1230345/+merge/230844 [16:25] mterry: ^ [16:30] AlbertA2, OK [16:30] 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] mterry: yeah I guess it should be possible, but needs a bit of refactoring so we can disable each individually [16:51] 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] in case powerd is not available and there's a pending request to block suspend basically [16:52] for example if powerd crashes...and we turned on the screen [16:52] and the interface is not available but will in the future [16:52] or when booting when powerd may not yet be available, we issue the suspend block call when it does become available [16:55] 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] I'm not seeing why you would need the pending field [16:57] mterry: oh so it's because I'm not getting the serviceUnregister call if powerd restarts or crashes...I dunno why... [16:57] so [16:58] 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] AlbertA2, well... you don't necessarily *need* the unregister call. We can just pay attention to the register calls [16:59] AlbertA2, but any time you would set pending=true, why not just instead set requested=false? === alan_g is now known as alan_g|EOD [16:59] 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] mterry: yeah I thought I had a reason..but I don't see why it needs to be two fields... [17:01] let me simplify that then [17:03] mterry: oh, I think I remember... [17:04] mterry: in the case that powerd is not yet available...I wanted something to tell me [17:04] in case the suspend block call was issued [17:05] that we needed to request a suspend block... [17:05] AlbertA2, but wouldn't requested remain false then? [17:05] since powerdMediator [17:05] does not track the screen power state [17:05] right...but if it has not been requested... [17:05] then there's no need to actually make the call [17:06] basically if powerd restarts while the screen is off [17:06] there's no need to issue the call... [17:08] but I'll try and make that more clear... [17:08] AlbertA2, OK I think I get it..... But [17:10] 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] 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] mterry: yeah that makes sense...let me see === dandrader|lunch is now known as dandrader [17:29] It is impossible to uninstall Mir in Utopic [17:29] when I try to remove some Mir package, it tries to remove like all packages on the system === pete-woods is now known as pete-woods|away [18:10] mterry: updated https://code.launchpad.net/~albaguirre/unity-system-compositor/fix-1353647/+merge/230370 === dandrader is now known as dandrader|bbl === pete-woods|away is now known as pete-woods === dandrader|bbl is now known as dandrader