racarrreading kDBus thread...01:31
racarr* With priority-inheritance, we can do synchronous calls into trusted01:31
racarrpeers and let them optionally use our time-slice to perform the01:31
racarraction. This allows syscall-like/binder-like method-calls into other01:31
racarrprocesses. Without priority-inheritance, this is not possible in a01:31
racarrsecure manner (see 'priority-inheritance').01:31
racarrthat could be cool for us...(the time slice donation)01:31
=== chihchun_afk is now known as chihchun
=== marcusto_ is now known as marcustomlinson
=== marcusto_ is now known as marcustomlinson_
alan_gI love it when a test tells me I accidentally broke something I didn't even realize I was touching11:19
=== DalekSec_ is now known as DalekSec
=== marcusto_ is now known as marcustomlinson_
kdubalan_g, with ~alan-griffiths/mir/first-pass-of-surface-spec-modification and my comment about rejecting some spec requests12:49
kdubit 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:50
alan_gkdub: 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.12:57
alan_gIt isn't as though anything is outside their control13:00
kdubso, 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 contract13:02
kduband 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 client13:04
alan_gaborting is better for the client writer than trying to carry on and having unexpected behaviour later13:08
alan_gviolations of policies (trying to resize a maximized window) are not invalid surface specifications but things the window management policy decides13:10
alan_gand that doesn't break contract and lead to an abort13:11
kdubright, so there's no such thing as an invalid MirSurfaceSpec?13:13
kdubits more that the client is just setting preferences (which can't fail), and that the server tries to respect the preferences, according to WM policy13:13
alan_gThere can be a MirSurfaceSpec that is invalid for create, but not for apply13:16
alan_gBut, yes that's the model13:19
kdubokay, 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!13:22
=== chihchun is now known as chihchun_afk
=== dandrader is now known as dandrader|afk
duflualan_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:11
alan_gduflu: not yet. But it likely will be done in terms of the bufferstreams kdub has started15:12
duflualan_g: No I just mean the input region (which has no buffer stream)15:12
dufluIt needs to extend beyond the buffer streams15:13
alan_gExactly, currently there's a buffer stream conflated with the surface15:14
duflualan_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:14
alan_gduflu: buffer stream comes into it because it is currently conflated with the surface (and needs separating)15:15
kdubright, so it would be a surface of size 100x100, and the buffer stream would be at 10,10 of size 80x80?15:15
duflukdub: No, the input surface would be at (-10,-10) of the surface. Because the aura doesn't affect placement either15:16
dufluWe already have input::Surface. Just need to unconflate it with the visible surface/buffer stream15:17
dufluPossibly with two separate input::Surfaces per surface15:17
kdubah, yes I see15:17
dufluOr three15:17
kdubso maybe a MirSurface can have multiple buffer streams, and multiple input regions...15:18
duflukdub: Yeah one or more. But only input over the client area goes to the client. Input to the aura should be handled by the server15:19
duflu-server + shell15:19
dufluPresently 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 windows15:20
duflukdub: 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 aware15:24
dufluIt's also then independent of the decoration mode (client, server or hybrid)15:25
alan_gThat's similar to what we have for title bar in examples15:28
dufluMaybe. I'm not aware of anyone making the input surface dimensions different to the buffer stream though15:28
kdubso, having aura as a new input::Surface seems like a good idea to me, and having the input surface dimensions be different also seems okay15:30
kdubwith the limitation that the client api cant go grabbing input from anywhere on the screen15:31
duflukdub: No the client would never be aware of it. It's all shell handled15:32
=== dandrader|afk is now known as dandrader
kdubright, so that plan seems even better then15:37
duflukdub: We might want to start calling each app a window now :)15:38
=== chihchun_afk is now known as chihchun
dufluUmm, the demo servers are all freezing on my laptop today. Did we break Mir or the kernel or something else?16:11
=== chihchun is now known as chihchun_afk
alan_gduflu: quick test of mir_demo_server seems OK - any clues to reproducing?16:21
duflualan_g No clues yet16:21
dufluEverything worked yesterday but not today16:21
dufluI do update my system and Mir every day16:22
alan_gYou just start it and it hangs?16:22
alan_gHmm. I've not updated system today16:22
dufluMouse doesn't move and can't switch VTs16:22
duflualan_g: Yeah bisecting now. We broke lp:mir this past day16:35
alan_gduflu: confirmed, must be since I updated mir around lunchtime16:45
alan_gThe only plausible culpret is -c 248016:46
duflualan_g: Yeah testing that one now16:46
duflualan_g: No r2480 is also broken. r2477 works so guess16:48
duflukgunn: Built as a deb solves all my Xmir problems. I'll do that and learn what I did wrong from debian/* later16:50
dufluYesterday was going on 3 hours sleep at most16:50
alan_gduflu: I think one of us misunderstands - I'm guessing 2480 broke it (so predicting 2479 works)16:50
duflualan_g: Yes, whoops. probably16:50
duflualan_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 fix16:54
alan_gduflu: +116:54
duflualf__: Re flickering we did land Android buffer changes yesterday.... :)17:00
dufluOr not using 0.13?17:01
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== ahayzen_ is now known as ahayzen
=== essembe is now known as sbeattie

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!