[01:31] <racarr> reading kDBus thread...
[01:31] <racarr> * With priority-inheritance, we can do synchronous calls into trusted
[01:31] <racarr> peers and let them optionally use our time-slice to perform the
[01:31] <racarr> action. This allows syscall-like/binder-like method-calls into other
[01:31] <racarr> processes. Without priority-inheritance, this is not possible in a
[01:31] <racarr> secure manner (see 'priority-inheritance').
[01:31] <racarr> that could be cool for us...(the time slice donation)
[11:19] <alan_g> I love it when a test tells me I accidentally broke something I didn't even realize I was touching
[12:49] <kdub> alan_g, with ~alan-griffiths/mir/first-pass-of-surface-spec-modification and my comment about rejecting some spec requests
[12:50] <kdub> it kinda feels like i'm coming late to the party on this discussion, but if there are some specs that can be invalid, isn't aborting on those a bit unfriendly to the client-api-users?
[12:57] <alan_g> kdub: if the client wilfully creates a spec intended for change and then tries using it for create they are breaking the contract and we shouldn't hide that.
[13:00] <alan_g> It isn't as though anything is outside their control
[13:02] <kdub> so, it just seems that aborting for misuses is harsh... and I guess I also see some degree of difference between requesting an invalid operation for a specific MirSurfaceType, and trying to do something that clearly violates the contract
[13:04] <kdub> and I guess I'm also assuming that there are some violations of policies that are more subtle, like, trying to resize or reposition type X that would be unclear to a client
[13:08] <alan_g> aborting is better for the client writer than trying to carry on and having unexpected behaviour later
[13:10] <alan_g> violations of policies (trying to resize a maximized window) are not invalid surface specifications but things the window management policy decides
[13:11] <alan_g> and that doesn't break contract and lead to an abort
[13:13] <kdub> right, so there's no such thing as an invalid MirSurfaceSpec?
[13:13] <kdub> its more that the client is just setting preferences (which can't fail), and that the server tries to respect the preferences, according to WM policy
[13:16] <alan_g> There can be a MirSurfaceSpec that is invalid for create, but not for apply
[13:19] <alan_g> But, yes that's the model
[13:22] <kdub> okay, so I based the comment on the idea that there was an "apply spec" that could be invalid, but if there's not, then I guess, comment resolved!
[15:11] <duflu> alan_g: We're going to need an expanded input::Surface in the stack to cover the "aura" or invisible resize area. I can imagine it could be either a secondary input::Surface underneath the existing one, or an expansion of the existing input::Surface. Do you have plans either way?
[15:12] <alan_g> duflu: not yet. But it likely will be done in terms of the bufferstreams kdub has started
[15:12] <duflu> alan_g: No I just mean the input region (which has no buffer stream)
[15:13] <duflu> It needs to extend beyond the buffer streams
[15:14] <alan_g> Exactly, currently there's a buffer stream conflated with the surface
[15:14] <duflu> alan_g: "buffer stream" shouldn't come into it. I'm not talking about pixels, just the invisible input region (that doesn't overlap any bufferstream)
[15:15] <alan_g> duflu: buffer stream comes into it because it is currently conflated with the surface (and needs separating)
[15:15] <kdub> right, so it would be a surface of size 100x100, and the buffer stream would be at 10,10 of size 80x80?
[15:16] <duflu> kdub: No, the input surface would be at (-10,-10) of the surface. Because the aura doesn't affect placement either
[15:17] <duflu> We already have input::Surface. Just need to unconflate it with the visible surface/buffer stream
[15:17] <duflu> Possibly with two separate input::Surfaces per surface
[15:17] <kdub> ah, yes I see
[15:17] <duflu> Or three
[15:18] <kdub> so maybe a MirSurface can have multiple buffer streams, and multiple input regions...
[15:19] <duflu> kdub: Yeah one or more. But only input over the client area goes to the client. Input to the aura should be handled by the server
[15:19] <duflu> -server + shell
[15:20] <duflu> Presently you can click the invisible input region of a non-focused window to raise it. That might not be important, but you still need to be able to do that to resize non-focused windows
[15:24] <duflu> kdub: I like the idea of adding the aura as a new input::Surface under the existing one. If input hits that then the shell handles it without the client being aware
[15:25] <duflu> It's also then independent of the decoration mode (client, server or hybrid)
[15:28] <alan_g> That's similar to what we have for title bar in examples
[15:28] <duflu> Maybe. I'm not aware of anyone making the input surface dimensions different to the buffer stream though
[15:29] <duflu> Yet
[15:30] <kdub> so, having aura as a new input::Surface seems like a good idea to me, and having the input surface dimensions be different also seems okay
[15:31] <kdub> with the limitation that the client api cant go grabbing input from anywhere on the screen
[15:32] <duflu> kdub: No the client would never be aware of it. It's all shell handled
[15:37] <kdub> right, so that plan seems even better then
[15:38] <duflu> kdub: We might want to start calling each app a window now :)
[15:43] <kdub> yay
[16:11] <duflu> Umm, the demo servers are all freezing on my laptop today. Did we break Mir or the kernel or something else?
[16:21] <alan_g> duflu: quick test of mir_demo_server seems OK - any clues to reproducing?
[16:21] <duflu> alan_g No clues yet
[16:21] <duflu> Everything worked yesterday but not today
[16:22] <duflu> I do update my system and Mir every day
[16:22] <alan_g> You just start it and it hangs?
[16:22] <duflu> Yep
[16:22] <alan_g> Hmm. I've not updated system today
[16:22] <duflu> Mouse doesn't move and can't switch VTs
[16:35] <duflu> alan_g: Yeah bisecting now. We broke lp:mir this past day
[16:45] <alan_g> duflu: confirmed, must be since I updated mir around lunchtime
[16:46] <alan_g> The only plausible culpret is -c 2480
[16:46] <duflu> alan_g: Yeah testing that one now
[16:48] <duflu> alan_g: No r2480 is also broken. r2477 works so guess
[16:50] <duflu> kgunn: Built as a deb solves all my Xmir problems. I'll do that and learn what I did wrong from debian/* later
[16:50] <duflu> Yesterday was going on 3 hours sleep at most
[16:50] <alan_g> duflu: I think one of us misunderstands - I'm guessing 2480 broke it (so predicting 2479 works)
[16:50] <duflu> alan_g: Yes, whoops. probably
[16:54] <duflu> alan_g: Doing final verification now. If that's it I'll just revert it. The change is too non-trivial and the bug too critical to wait for the proper fix
[16:54] <alan_g> duflu: +1
[17:00] <duflu> alf__: Re flickering we did land Android buffer changes yesterday.... :)
[17:01] <duflu> Or not using 0.13?