| 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) | 01:31 |
| === chihchun_afk is now known as chihchun | ||
| === marcusto_ is now known as marcustomlinson | ||
| === marcusto_ is now known as marcustomlinson_ | ||
| alan_g | I love it when a test tells me I accidentally broke something I didn't even realize I was touching | 11:19 |
| === DalekSec_ is now known as DalekSec | ||
| === marcusto_ is now known as marcustomlinson_ | ||
| kdub | alan_g, with ~alan-griffiths/mir/first-pass-of-surface-spec-modification and my comment about rejecting some spec requests | 12:49 |
| 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:50 |
| 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. | 12:57 |
| alan_g | It isn't as though anything is outside their control | 13:00 |
| 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:02 |
| 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:04 |
| alan_g | aborting is better for the client writer than trying to carry on and having unexpected behaviour later | 13:08 |
| alan_g | violations of policies (trying to resize a maximized window) are not invalid surface specifications but things the window management policy decides | 13:10 |
| alan_g | and that doesn't break contract and lead to an abort | 13:11 |
| 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:13 |
| alan_g | There can be a MirSurfaceSpec that is invalid for create, but not for apply | 13:16 |
| alan_g | But, yes that's the model | 13:19 |
| 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! | 13:22 |
| === chihchun is now known as chihchun_afk | ||
| === dandrader is now known as dandrader|afk | ||
| 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:11 |
| 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:12 |
| duflu | It needs to extend beyond the buffer streams | 15:13 |
| 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:14 |
| 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:15 |
| duflu | kdub: No, the input surface would be at (-10,-10) of the surface. Because the aura doesn't affect placement either | 15:16 |
| 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:17 |
| kdub | so maybe a MirSurface can have multiple buffer streams, and multiple input regions... | 15:18 |
| 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:19 |
| 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:20 |
| 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:24 |
| duflu | It's also then independent of the decoration mode (client, server or hybrid) | 15:25 |
| 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:28 |
| duflu | Yet | 15:29 |
| 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:30 |
| kdub | with the limitation that the client api cant go grabbing input from anywhere on the screen | 15:31 |
| duflu | kdub: No the client would never be aware of it. It's all shell handled | 15:32 |
| === dandrader|afk is now known as dandrader | ||
| kdub | right, so that plan seems even better then | 15:37 |
| duflu | kdub: We might want to start calling each app a window now :) | 15:38 |
| kdub | yay | 15:43 |
| === chihchun_afk is now known as chihchun | ||
| duflu | Umm, 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_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:21 |
| 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:22 |
| duflu | alan_g: Yeah bisecting now. We broke lp:mir this past day | 16:35 |
| alan_g | duflu: confirmed, must be since I updated mir around lunchtime | 16:45 |
| alan_g | The only plausible culpret is -c 2480 | 16:46 |
| duflu | alan_g: Yeah testing that one now | 16:46 |
| duflu | alan_g: No r2480 is also broken. r2477 works so guess | 16:48 |
| 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:50 |
| 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 | 16:54 |
| duflu | alf__: Re flickering we did land Android buffer changes yesterday.... :) | 17:00 |
| duflu | Or 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!