| RAOF | Hm. I wonder how hard it would be to get a mir_surface_swap_buffers with a MSC/SBC tag. | 04:24 |
|---|---|---|
| === jono is now known as Guest74174 | ||
| tvoss_ | good morning :) | 06:00 |
| duflu | tvoss_: Morning | 06:01 |
| tvoss_ | duflu, hey, happy Monday :) | 06:06 |
| duflu | tvoss_: Let's hope so | 06:06 |
| dholbach | good morning | 06:44 |
| RAOF | thomi: Can we fix unity-system-compositor in the mir-team PPA to not always be a revision behind Mir? | 06:47 |
| RAOF | thomi: It looks like the unity-system-compositor source upload happens at about the same time as the Mir upload, which means it's always building against a Mir that's about to become obsolete. | 06:47 |
| tvoss_ | dholbach, good morning :) | 06:48 |
| dholbach | hi tvoss_ | 06:48 |
| === didrocks1 is now known as didrocks | ||
| RAOF | Hm. I wonder if I can get hacky composite-bypass in XMir today... | 08:20 |
| duflu | RAOF: Today? Isn't it the evening for you? | 08:29 |
| * duflu edges closer to insanity | 08:33 | |
| mlankhorst | morning | 08:40 |
| alan_g | greyback: are you still unhappy with lp:~robertcarr/mir/implement-client-credentials? (It has changed a lot.) | 08:43 |
| greyback | alan_g: ah we're waiting for my approval too. racarr said he cannot do what I wanted immediately, so for now it will do. I'll approve | 08:44 |
| greyback | alan_g: you can top-level approve now. Thanks | 08:46 |
| alan_g | greyback: I don't need your approval, but it is polite to ask in case there's an issue | 08:46 |
| greyback | alan_g: it is indeed. Thank you :) | 08:46 |
| alan_g | greyback: yw | 08:46 |
| RAOF | duflu: It is, but it's almost done. | 08:51 |
| tvoss_ | RAOF, just did an upgrade, all good so far. This is intel switched to the sna accel arch, right? | 08:55 |
| duflu | tvoss_: SNA was turned on since raring. We turned it off in Mir driver builds tho | 08:57 |
| mlankhorst | but I fixed sna for intel, dno if raof enabled it yet or not | 08:58 |
| mlankhorst | s/intel/mir/ | 08:58 |
| tvoss_ | mlankhorst, I *think* so :) | 08:59 |
| === alan_g is now known as alan_g|physio | ||
| tvoss_ | mlankhorst, the updated radeon driver should fix two of the critical bugs on mir, right? | 09:00 |
| mlankhorst | probably | 09:05 |
| mlankhorst | theoretically it should create the surface parameters in the same way as mesa | 09:06 |
| mlankhorst | which should satisfy tiling constraints etc | 09:06 |
| tvoss_ | ack | 09:06 |
| duflu | alf_: Turning off MultiAcquisitionBackBufferStrategy in the synchronous case seems to solve all my problems. Now tell me why that's a bad idea... :) | 09:12 |
| alf_ | duflu: because it's needed to support multiple buffer consumers while minimizing buffer "loss" (a window placed between multiple screens, taking snapshots etc) | 09:15 |
| alf_ | duflu: however, that's for normal windows, fullscreen bypassed windows probably don't need this | 09:16 |
| alf_ | duflu: hmm, perhaps they need the snapshot part, but I don't believe it's critical for XMir | 09:18 |
| duflu | alf_: I'm tempted to push the logic of MultiAcquisitionBackBufferStrategy into the spin swapper. Just wondering why that's a bad idea... | 09:19 |
| duflu | Oh. It's a bad idea because the reference to the buffer I have right now only exists when bypass is turned on | 09:20 |
| duflu | :P | 09:20 |
| alf_ | duflu: how would that help you? | 09:21 |
| duflu | alf_: I mean I have to hold the buffer explicitly for DRM from before page flip n till after page flip n+1 | 09:22 |
| duflu | ... else tearing | 09:22 |
| alf_ | duflu: can't you do that in the bypass compositing strategy? | 09:23 |
| duflu | alf_: Yes, it could be held in the compositor or display buffer. Which one is a minor detail | 09:23 |
| alf_ | duflu: we are already enforcing a related policy in the existing compositing strategy: we are holding the buffer until after the swapbuffers | 09:25 |
| alf_ | duflu: (I mean the window buffers) | 09:26 |
| duflu | alf_: That's not sufficient for bypass. You have to hold the buffer for _two_ page flips | 09:26 |
| alf_ | duflu: sure, I just mean that enforcing this in the bypass compositing strategy is a reasonable option, since we are already doing something related in the existing strategy. | 09:29 |
| duflu | alf_: There are many such things I need to clean up and find a nicer home for. I will review them all before proposing anything | 09:29 |
| alf_ | duflu: ok | 09:29 |
| duflu | alf_: But before then, I need to solve this deadlock | 09:30 |
| duflu | 4 days with no progress is depressing | 09:30 |
| duflu | alf_: BTW you would be my best friend if you merged the swapper classes into a single one. It's very overcomplicated spreading a well-known buffer rotation algorithm between 3+ classes | 09:34 |
| alf_ | duflu: Which classes are you referring to? | 09:34 |
| duflu | alf_: SwitchingBundle, BufferSwapper{Multi,Spin}, MultiAcquisitionBackBufferStrategy | 09:35 |
| duflu | That's four classes for a relatively simple switchable rotation algorithm | 09:36 |
| duflu | I strongly suspect if it was simplified to one then I could get over this issue. But I'm not sure yet so won't jump the gun | 09:40 |
| alf_ | duflu: The problem with merging into one class is that we will create an overcomplicated class. Each layer is simple/testable enough on its own and builds off the layer below: the BufferSwapperMulti/Spin classes are the core swapping algorithms, the SwitchingBundle allows switching between the swapping algorithms at runtime, the MultiAcquisitionBackBufferStratey allows multiple consumers while minimizing buffer loss. Putting everything in one | 09:43 |
| duflu | alf_: I would almost do it myself to prove you wrong. :) | 09:44 |
| duflu | It's a simple well-known algorithm used in the industry. There's no need to spread it over so many classes | 09:45 |
| duflu | Using a single class would in fact simplify things a lot | 09:45 |
| alf_ | duflu: it's not spreaded, the core is in BufferSwapperMulti/Spin classes, everything else is extra | 09:46 |
| duflu | OK, I'll drop the idea. I can't really prove my point unless I do it, and that would take too much effort right now | 09:47 |
| alf_ | duflu: in any case, I would be happy to be proven wrong if the result is actually better :) | 09:48 |
| duflu | alf_: My first preference is to propose small diffs. So I won't be rewriting it if I can help it | 09:48 |
| duflu | alf_: I need to cook dinner. In the mean time, could you please look at MultiAcquisitionBackBufferStrategy and tell me if you think you can imagine a more elegant approach than the "partly_released" flag? | 10:03 |
| duflu | I think that might help | 10:03 |
| alf_ | duflu: what's the problem with that (so it can guide my thoughts)? | 10:06 |
| duflu | alf_: The flag is never set... because I always have at least one shared_ptr owning the TemporaryCompositorBuffer | 10:06 |
| duflu | ... and because the flag is never set, compositor_release never happens. | 10:09 |
| duflu | ... and because compositor_release never happens, the client runs out of buffers (hangs) | 10:10 |
| === alan_g|physio is now known as alan_g | ||
| === hikiko is now known as hikiko|lunch | ||
| === pete-woods1 is now known as pete-woods | ||
| === alan_g is now known as alan_g|lunch | ||
| === 17SAC504O is now known as tvoss | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | tvoss: ping | 13:35 |
| kgunn | bregma: just checking in, do you need any help ? | 13:46 |
| bregma | kgunn, armhf build MP is up and ready for review | 14:13 |
| kgunn | bregma: \o/ hell yeah! | 14:14 |
| bregma | if didrocks could take a look that would be especially useful, I suppose | 14:14 |
| didrocks | bregma: I'm more than busy right now, but I'll try having a look today | 14:15 |
| === alan_g is now known as alan_g|tea | ||
| === hikiko|lunch is now known as hikiko | ||
| hikiko | oups :p i forgot the lunch a few hours... :p | 14:26 |
| === alan_g|tea is now known as alan_g | ||
| alan_g | bregma: do you know if the input tests are still hanging on the armhf build? (I tried a fix at -c847 - but as I can't reproduced the failure locally...) | 14:49 |
| hikiko | alf_, I saw your branch for android where you separate the display and the display buffer, do you think it's necessary to do the same in the nested mir? | 14:50 |
| bregma | alan_g, I have never had the input tests hang on my N7, but I can kick off a test run to check (it'll take 2 hours or so) | 14:50 |
| hikiko | because atm I use 1 class that inherits from both the display and the displaybuffer classes | 14:51 |
| alan_g | bregma: I have the impression it only happens on the build farm | 14:51 |
| alan_g | s/happens/happened/ | 14:51 |
| alf_ | hikiko: yes, you need to do it because the Display and DisplayBuffer interfaces will soon become incompatible | 14:52 |
| hikiko | :s | 14:52 |
| hikiko | ok | 14:52 |
| bregma | alan_g, sounds likely, expecially if it depdends on underlying OS support | 14:52 |
| alan_g | hikiko: if you get your code landed first, then it won't be your problem. ;) | 14:53 |
| hikiko | I ll get your android changes as a reference then, thanx alf_ | 14:53 |
| hikiko | what do you mean? | 14:53 |
| alan_g | hikiko: if your code is on trunk when alf_ tries to change the interfaces, then he'll have to adapt your code, not you. | 14:54 |
| hikiko | hehe :) I am not done yet I need a few more days, so I guess better to separate it now... alf_ has an mp already from what I've seen :) | 14:55 |
| kgunn | alan_g: thanks so much for looking at bregma's mp! | 14:55 |
| alan_g | kgunn: np | 14:57 |
| kgunn | hikiko: alf_ i'll leave it to you guys to coordinate interface changes & landings...but multumonitor takes prioirty, e.g. try not to slow it down | 15:01 |
| hikiko | sure kgunn :) | 15:03 |
| didrocks | bregma: do you have a handy link? | 15:21 |
| bregma | didrocks, https://code.launchpad.net/~bregma/mir/lp-1195265/+merge/174478 | 15:22 |
| racarr | Morning | 15:26 |
| didrocks | bregma: if you: +ifeq ($(DEB_HOST_ARCH),powerpc) | 15:28 |
| didrocks | bregma: please reenable arch: any in debian/control | 15:28 |
| greyback | racarr: hey, when you've spun up, can we have a quick chat? | 15:46 |
| racarr | greyback: Morning! Yeah | 15:50 |
| greyback | racarr: cool, let me know when's good for you | 15:51 |
| racarr | greyback: Now is good want to start a hangout while I find my phone? | 15:51 |
| greyback | racarr: ok, am on it | 15:51 |
| kgunn | didrocks: what needs to happen next? shouldn't we be able to enter universe (once bregma's mp is merged) | 16:13 |
| didrocks | kgunn: I think we told with olli_ that we're going to use the ppa for some days | 16:15 |
| didrocks | and then decide of Thursday | 16:15 |
| didrocks | I would hope bregma is just going to fix the small query I have and then approve so that I can try a first daily to the next ppa tomorrow | 16:15 |
| kgunn | didrocks: thanks, sounds like a plan....good to be one step closer :) | 16:16 |
| didrocks | kgunn: same here :) | 16:16 |
| greyback | racarr: oh another thing I need: a good way to know that a surface was destroyed. I tried subclassing SurfaceBuilder - but that gives me a mir::frontend::Surface, which is private member of mir::shell::Surface - so I cannot seek for it in a list of surfaces | 16:22 |
| racarr | greyback: ok. it can probably just go on the_session_listener | 16:26 |
| greyback | racarr: sounds ok to me | 16:26 |
| mterry | kdub, poke about ~mterry/mir/session-for-surface branch, if you wanted to chat about where the need is coming from | 16:31 |
| kdub | mterry, sure | 16:31 |
| mterry | kdub, so my goal is to allow u-s-c to have the greeter stay on top of other sessions (and be transparent at will to expose the next session) | 16:32 |
| mterry | kdub, the plan was for lightdm to name the greeter session in a way that u-s-c can know | 16:33 |
| mterry | kdub, then u-s-c would override the surface builder, and any surface that belongs to the greeter session could be marked with a different depth | 16:33 |
| mterry | kdub, I'm open to other ways, this was just the way robert ancell recommended | 16:33 |
| kdub | mterry, i guess I just see that our surface stack has a weak ability to control what's in it | 16:34 |
| kdub | and would guess that expanding that SurfaceStack functionality would be more scalable in the long term | 16:34 |
| racarr | mterry: I am working on a solution for that for unity which is better too | 16:36 |
| racarr | well | 16:36 |
| racarr | maybe it's slightly different | 16:36 |
| racarr | I hope to have a good answer for matching the things up soon though without the session | 16:38 |
| racarr | unity 8 also needs surface->session eventually though | 16:38 |
| racarr | i.e. you click to raise a surface which application becomes active | 16:38 |
| racarr | err | 16:38 |
| racarr | surface->session | 16:38 |
| kdub | racarr, right... a restructuring of msh:: is needed | 16:39 |
| racarr | kdub: Maybe. I was just thinking simple. The surface needs a reference to it's session ;) the msh::Surface at least | 16:41 |
| kdub | where does the shell want to access a surface, and then get a session? shouldn't it be accessing the surfaces through the session? | 16:43 |
| kdub | rather, what's the case that the shell has a surface without knowing the session? | 16:43 |
| racarr | had a mild trip over | 16:46 |
| racarr | modem power cord | 16:46 |
| racarr | XD | 16:46 |
| racarr | um, so like click to focus right | 16:46 |
| racarr | youve clicked somewhere, the shell got an event | 16:46 |
| mterry | kdub, I seem to have lost connection :-/ | 16:46 |
| mterry | not sure what you saw from me, but I last sent " or at least, one way he thought it would be doable" | 16:46 |
| racarr | it wants to focus the surface underneath | 16:46 |
| racarr | but it needs to know which application is now focused to update the launcher | 16:47 |
| kdub | racarr, the shell gets an event from where in the system? | 16:47 |
| racarr | say mi::EventFilter::handle_event | 16:48 |
| racarr | I mean any number of cases | 16:48 |
| racarr | lets go with that one XD | 16:49 |
| racarr | or maybe it's not exactly there, | 16:49 |
| racarr | maybe there is some new cllback lter like | 16:49 |
| racarr | mi::EventFilter::handle_event_before_dispatching_to(Event, Surface) | 16:49 |
| racarr | which would be ideal for this kind of thing (now you ust say, raise_surface ,focus surface, whatever) | 16:50 |
| racarr | but it doesn't make sense to iterate through all the sessions here | 16:50 |
| racarr | but you still need to focus the application someho | 16:50 |
| kdub | why wouldn't we have mi::EventFilter::handle_event_before_dispatching_to(Event, Session) | 16:50 |
| didrocks | bregma: do you mind sending me a "ack" by email once your branch is merged please? that would win me some time :) | 16:53 |
| racarr | kdub: How would you know | 16:54 |
| racarr | what session | 16:54 |
| bregma | didrocks, sure | 16:54 |
| racarr | is targeted | 16:54 |
| racarr | sessions don't have | 16:54 |
| racarr | geometry | 16:54 |
| didrocks | thanks! :) | 16:54 |
| racarr | or anything | 16:54 |
| racarr | or necessarily a strict depth ordering | 16:54 |
| racarr | right I can stack a indow inbetween two other windows | 16:54 |
| racarr | of the gimp | 16:54 |
| racarr | so to pick the event | 16:54 |
| racarr | you hve to iterate by surfaces | 16:54 |
| racarr | and then find the session | 16:55 |
| racarr | it seems clumsy to find the surface and then search | 16:55 |
| racarr | for the session | 16:55 |
| kdub | racarr, i don't have the problem-context quite so strongly, but my first vague sense of what's going on is we're trying to work around ms::SurfaceStack's limitations | 16:56 |
| racarr | there are a bunch of cases | 16:56 |
| racarr | I think | 16:56 |
| racarr | that is more what mterry's problem is | 16:57 |
| racarr | but I am saying the surface->session assosciation | 16:57 |
| racarr | is required anyway | 16:57 |
| kdub | a bit tricky to talk about, but | 17:03 |
| kdub | if whatever needs that association would talk in terms of sessions, then it wouldn't | 17:03 |
| kdub | racarr, i guess I'm just a bit unsure what our data structure surrounding our 'group of surfaces' reflects | 17:05 |
| kdub | or rather, what its evolved into | 17:06 |
| alan_g | racarr: kdub: I'm about to disappear (EOD), but there is a difference between being able to find the "owning" session for a surface and the surface knowing its owner. Is that where you differ? | 17:07 |
| === alan_g is now known as alan_g|EOD | ||
| racarr | it could be by assosciation | 17:14 |
| racarr | but I don't see why there is a problem with the surace having a reference to the session really | 17:15 |
| racarr | it's only a 'circular dependency' in the same way | 17:15 |
| racarr | a circularly linked list is | 17:15 |
| racarr | XD | 17:15 |
| kdub | racarr, i might not have an objection either, its just kinda dawning on me that some of our data structures could be better | 17:17 |
| kdub | racarr, like, take msh::ApplicationSession | 17:19 |
| kdub | msh::ApplicationSession : public msh::Session | 17:19 |
| racarr | Mm | 17:21 |
| racarr | that doesn't mean much besides | 17:21 |
| racarr | msh::Session : public msh::SessionInterface | 17:21 |
| kdub | well, the full chain is msh::ApplicationSession : public msh::Session : public mf::Session | 17:21 |
| kdub | so we kinda tie msh::ApplicationSession to frontend concepts | 17:22 |
| kdub | when maybe what we want is a session that is more independent of ipc concepts? | 17:22 |
| racarr | maybe | 17:22 |
| racarr | im actually struggling to figure out | 17:22 |
| racarr | why msh::ApplicationSession exists | 17:22 |
| kdub | like, a grouping of surfaces by input association, as well as a grouping of surfaces by ipc association | 17:22 |
| racarr | hmm | 17:23 |
| racarr | surfaces aren't grouped by input necessarily though | 17:23 |
| racarr | I mean I think that's what 'Session' is | 17:23 |
| racarr | it's the IPC grouping | 17:23 |
| racarr | not in particular the IPC grouping, that's just a detail | 17:23 |
| racarr | but it's the 'client' grouping | 17:23 |
| kdub | well, i think that's where the problem might be though? | 17:24 |
| kdub | like, for graphics, obviously, we associate them so the compositor can make sense of them | 17:24 |
| kdub | in ms::SurfaceStack | 17:24 |
| kdub | and we group the surfaces by IPC connection in msh::Session | 17:24 |
| kdub | i'm kinda picking up on another association we want them to have | 17:25 |
| kdub | and that we're splicing that association into the already existing associations? | 17:25 |
| racarr | I'm not sure. | 17:26 |
| kdub | yeah, i guess i'm not sure either | 17:27 |
| racarr | there is definitely | 17:27 |
| racarr | something different than IPC connection | 17:27 |
| racarr | more akin, to client, or owner that is useful | 17:27 |
| racarr | for example, how does the shell recognize it's own surfaces to manipulate them | 17:27 |
| racarr | how do you tell any two surfaces apart :p | 17:27 |
| kdub | right | 17:28 |
| kdub | like, msh::Session should keep its IPC based roots, but perhaps the shell wants to keep its own groupings of surfaces | 17:28 |
| kdub | and the default grouping is simply the ipc grouping | 17:28 |
| racarr | what kind of other groupings? | 17:29 |
| kdub | like for instance :) when we were talking about sending events to surfaces and needing to know the ipc session associated with that | 17:30 |
| racarr | Isnt that the IPC grouping? | 17:30 |
| kdub | i guess i'm unsure | 17:32 |
| racarr | I think it is...there probably are other groupings though | 17:33 |
| racarr | like it's not clear where we would model workspaces atm | 17:33 |
| racarr | stages as well | 17:33 |
| kdub | right | 17:34 |
| kdub | i mean, i think that once we decouple a surface from the IPC portions, making the shell will be much more pleasant experience :) | 17:35 |
| kdub | at least more pleasant than overriding our factories so surface associations can be injected i guess | 17:36 |
| racarr | Mm | 17:37 |
| racarr | I guess for this particular case, probably the DepthId should be in msh::SurfaceCreationParameters | 17:38 |
| racarr | so you don't have to overrie the factory | 17:38 |
| racarr | then it's super reasonable to extend the interface | 17:38 |
| racarr | msh::PlacementStrategy::Place(Session, SurfaceParameters) | 17:39 |
| kdub | ah, ok | 17:39 |
| racarr | i.e. the shell places a surfce for a session | 17:39 |
| racarr | but I think it will come up again later aha | 17:39 |
| kdub | it will, its our central data structure, really | 17:39 |
| tvoss | racarr, why would the depthid need to be in the surfacecreationparameters? | 18:21 |
| racarr | tvoss: Wellllllllllll | 18:38 |
| racarr | it's about where | 18:38 |
| racarr | it's assigned and how | 18:38 |
| racarr | the shell can match up which surface gets what | 18:38 |
| racarr | potentially through associating with the session | 18:38 |
| tvoss | racarr, I would expect that it is not exposed to anyone creating a surface, as a lot of information is needed to determine the depth | 18:39 |
| racarr | well it would just be part of the surface creation parameters on the server, so its not expoed over IPC | 18:39 |
| racarr | but the_shell_placement_strategy | 18:39 |
| racarr | has the opportunity to add DepthId | 18:40 |
| tvoss | racarr, what is a depthid? | 18:40 |
| racarr | tvoss: Actually there isn't a lot of information, DepthId needs a better name ;) | 18:40 |
| racarr | haha | 18:40 |
| racarr | same line of thought | 18:40 |
| racarr | All it means is if there are two u rfaces with DepthID X and Y | 18:40 |
| racarr | and X>Y then X is always on top of Y | 18:40 |
| racarr | when X=Y they stack in the order they are put in and can be reordered | 18:40 |
| tvoss | racarr, why isn't that the absolute depth in z? | 18:41 |
| racarr | tvoss: Because it's easier this way | 18:41 |
| racarr | the surface gets | 18:41 |
| racarr | DepthId{1} | 18:41 |
| tvoss | racarr, not sure why? z establishes a total order | 18:41 |
| racarr | the shell surface* | 18:41 |
| racarr | the application surfaces all get DepthId{0} | 18:41 |
| racarr | then you can talk about raising an application to the top | 18:41 |
| racarr | or reordering them or whatever | 18:41 |
| racarr | without | 18:41 |
| racarr | having to worry about the fact that the shell is on top | 18:41 |
| tvoss | hmmm, sounds like a slice to me | 18:43 |
| racarr | It's more of a primitive form of | 18:43 |
| racarr | nested surface stacks or something | 18:44 |
| racarr | essentially each DepthId is it's own 'stack' | 18:44 |
| tvoss | it's not really nested, it's more like banded | 18:44 |
| tvoss | a part of a depth-spectrum | 18:45 |
| racarr | "primtiive form" :p | 18:45 |
| tvoss | or how about a bucket? we are essentially using it as a rough indicator to discretize the continuous z axis, right? | 18:46 |
| racarr | I don't entirely follow ;) | 18:47 |
| racarr | I don't know. I don't like thinking in terms of 'Z axis' | 18:47 |
| racarr | because it doesn't behave like the 'X and Y axis' | 18:48 |
| racarr | but, yes, it's to break that up | 18:49 |
| tvoss | well, what you basically say is: you have a bucket of surfaces that belong to the shell | 18:49 |
| racarr | but also to provide the shell an API to control such. | 18:49 |
| tvoss | sure @control | 18:50 |
| * kdub just likes normal z ordering, with the shell having fine grained control over how all the surfaces mix in the SurfaceStack | 18:51 | |
| tvoss | kdub, +1, what use case does the banding solve racarr? | 18:52 |
| racarr | what use case does Z ordering solve? | 18:52 |
| racarr | I would say it's the more general API that leaves a lot more room for 'user error' | 18:53 |
| racarr | so it needs a motivation | 18:53 |
| racarr | rather than the other way around | 18:53 |
| tvoss | racarr, but depth is the natural representation and the natural order that we are after here, isn't it? | 18:53 |
| racarr | Maybe. | 18:54 |
| racarr | I don't know. | 18:55 |
| racarr | but then what do we do, the shell assigns each surface a depth ID, or | 18:55 |
| tvoss | racarr, do you have any case in mind that is difficult to solve without the notion of buckets? | 18:55 |
| racarr | just inr esponse to everything that happens | 18:55 |
| kdub | i think once we start evolving SurfaceStack | 18:55 |
| racarr | reorders all the surfaces relative | 18:55 |
| kdub | we'll see that the depthid goes away | 18:55 |
| racarr | I think that's | 18:55 |
| racarr | difficult... | 18:55 |
| racarr | tvoss: Without the notion of buckets? What do you mean? | 18:56 |
| racarr | *shrug* DepthID should probably go away, but I would hope in favor of real hierarchal layers | 18:56 |
| tvoss | what use-case would break with depth-ordering only? | 18:56 |
| racarr | err, well I think both can support the use cases we need. | 18:57 |
| racarr | but I think the code that results in the shell | 18:57 |
| racarr | from having the shell mnually specify/manage Z order is painful | 18:57 |
| racarr | I mean what does it do? everytime a surface is created or destroyed walks the surface stack and reorders things relatively according to some state and rules (i.e. shell surface goes on top of all the application surfaces, which go on top of the desktop layer, oh but the shell surface goes under the OSK layer...) | 18:59 |
| racarr | I think it's more declarative with the DepthId's, or some sort of layer concept | 19:00 |
| racarr | even on the desktop, with weird WM stuff like always on top, always on bottom, etc | 19:00 |
| racarr | you can represent those as sort of 'statically stacked' layers | 19:01 |
| racarr | that applications move between | 19:01 |
| racarr | *shrug* | 19:01 |
| tvoss | racarr, need to think about it | 19:01 |
| racarr | Haha I feel like I am arguing against a proposal but I am not sure what the proposal is or why I am arguing | 19:01 |
| racarr | tvoss: Would appreciate thought on it, yes | 19:02 |
| racarr | robert_ancell's thought is that the shell should provide like a sort function to the SurfaceStack implementation | 19:02 |
| racarr | and just control Z order that way | 19:03 |
| racarr | but I guess my intutition is that the implementation of this function becomes messy. | 19:03 |
| racarr | Hand wavy, sorry :) | 19:04 |
| racarr | I mean, I guess I think | 19:05 |
| olli_ | :) | 19:05 |
| racarr | render(SurfaceStack) should really be a function of State(SurfaceStack) | 19:05 |
| * kdub smells tightly coupled notions | 19:05 | |
| racarr | whereas if you have some surface sorting object | 19:05 |
| racarr | its going to need state from all over the system | 19:05 |
| tvoss | racarr, well, if you compose the function implementation in a sane way, it should be a good primary interface to provide aa sorting interface | 19:05 |
| racarr | I think that sane implementation | 19:06 |
| racarr | ends up being a stack | 19:06 |
| racarr | of stacks | 19:06 |
| tvoss | in that I do agree, you gradually refine your sorting criterion until you end with "pure" depth | 19:06 |
| racarr | and the shell creates this object | 19:07 |
| racarr | and sends messages to it like filter_object->set_depth_for_shell_surface(above_application_surfaces) | 19:07 |
| racarr | so it seems like | 19:07 |
| racarr | nice unctionality for the surface stack to provide | 19:07 |
| racarr | directly | 19:07 |
| racarr | err s/filter/sort | 19:07 |
| tvoss | but it would in turn require the surface stack to know a lot about the notion of shell vs. app surfaces | 19:08 |
| racarr | well | 19:09 |
| racarr | I dunno ;) I don't think it's a lot to know | 19:09 |
| racarr | in the phone case, it's enough for some object the shell implements higher up | 19:09 |
| tvoss | @phone case: but that's a special case of the general problem, isn't it? | 19:09 |
| racarr | to assign DepthId{0} to app surfaces and DepthId{1} to shell surfaces | 19:09 |
| racarr | yeah but I think its the same on the desktop it's just | 19:09 |
| racarr | more difficult to enumerate, but I mean its like | 19:10 |
| racarr | there is a Desktop Layer, an Always on Bottom Application La yer, and Application Layer, etc. | 19:10 |
| tvoss | I don't think we should engrave that notion into the SurfaceStack | 19:10 |
| racarr | so instead you think there should be some shell component | 19:12 |
| racarr | that listens like "new surface created" | 19:12 |
| racarr | and searches the surface stack | 19:12 |
| racarr | for the right spot to put it in? | 19:12 |
| racarr | Or this sort function approach | 19:12 |
| racarr | or something else? | 19:13 |
| tvoss | racarr, I would think that it might make sense to collect the operations that the stack needs to support fast | 19:16 |
| tvoss | racarr, an interesting thought: a surface role could be interpreted as a depth id, too | 19:16 |
| racarr | that | 19:17 |
| racarr | is kind of a hope :) | 19:17 |
| racarr | but I don't think we ever found an exact set of roles that matches up | 19:17 |
| racarr | to stacking | 19:17 |
| racarr | MPT was trying | 19:17 |
| racarr | remember the big picture witht he layer and the drawing of the eye | 19:17 |
| tvoss | hmmm, I think our recent addition of an input method role could help there | 19:17 |
| tvoss | yup | 19:17 |
| racarr | I think one of the counterexamples was or example some input methods are system model and some input method are window/application/entry field modal or whatever | 19:18 |
| racarr | I think | 19:18 |
| racarr | you can define the stacking like | 19:18 |
| racarr | a sorting of roles first | 19:19 |
| racarr | i.e. application role is a layer under shell role is a layer under input method etc | 19:19 |
| tvoss | well, I would start over with sorting by app instances, where I consider the shell an app instance, too | 19:19 |
| racarr | if you also allow each err | 19:19 |
| racarr | "band" or whatever | 19:19 |
| racarr | to have | 19:19 |
| racarr | a modality layer | 19:19 |
| racarr | on top of it | 19:19 |
| tvoss | hmmm, let's reverse the question: given a surface stack layer, how can we test if the stacking is correct? | 19:20 |
| racarr | what do you mean layer here? | 19:21 |
| tvoss | remov ethe layer :) | 19:22 |
| tvoss | just surface stack | 19:22 |
| racarr | ok | 19:22 |
| racarr | well. I dunno, I mean, | 19:22 |
| racarr | each form factor shell | 19:22 |
| racarr | has some set of invariants | 19:22 |
| racarr | i.e. dash is above all applications | 19:22 |
| racarr | mostly recently used application is above the one before it | 19:22 |
| racarr | etc | 19:22 |
| tvoss | hmmm, that means that the first order is always "most interesting" in decreasing order, right? | 19:24 |
| tvoss | under the assumption that the shell is always most interesting to the user as the primary system interface, and most recently used is equivalent to most interesting application | 19:24 |
| racarr | yeah | 19:25 |
| racarr | I mean it's a statement about | 19:25 |
| racarr | who gets visibility | 19:25 |
| racarr | when screen space is contested | 19:25 |
| racarr | more than a "Z order" | 19:25 |
| tvoss | okay, so assume that we would reorder the list of apps (again, shell included) as opposed to the surfaces, then every surface would receive a base "layer" according to the apps's index in the list, right? | 19:26 |
| tvoss | per stack it's a per role ordering then | 19:27 |
| tvoss | but again a most interesting order, too | 19:28 |
| tvoss | so yeah, I do agree that the absolute z order that is finally calculated is only a result of all of these steps | 19:28 |
| racarr | I'm not sure it's ok to | 19:29 |
| racarr | assume apps, stck together | 19:29 |
| tvoss | with the constraint of minimally intrusive z position changes | 19:29 |
| racarr | i.e. I would expect to be able to stack a window from another app | 19:29 |
| racarr | between my 3 gimp windows | 19:29 |
| tvoss | s/stack/bucket/band | 19:29 |
| tvoss | for that,we need the constraint of minimal z order changes | 19:29 |
| tvoss | or better z coordinate changes | 19:29 |
| tvoss | you only really change z in the end if you detect a conflict between the semantics and the actual position | 19:30 |
| racarr | right | 19:30 |
| tvoss | that's why I think that defining the verification algorithm should solve most of the problem already | 19:30 |
| racarr | I dunno | 19:33 |
| racarr | that doesn't clarify it for me | 19:33 |
| racarr | I mean, one option from that perspective | 19:33 |
| racarr | is to provide an API the shell implements | 19:33 |
| racarr | bool obscures(Surface1, Surface2) | 19:33 |
| racarr | which is just the verification algorithm | 19:33 |
| racarr | and you call it | 19:33 |
| racarr | N^2 times | 19:33 |
| racarr | but it's pretty clear that's not correct | 19:33 |
| tvoss | it might be correct but inefficient | 19:33 |
| racarr | sure | 19:34 |
| racarr | by correct I mean, the correct code to put in a header file that gives us the best probability of a bug free performant shipping shell | 19:34 |
| tvoss | hah, I think we want a stable sort | 19:34 |
| tvoss | as the stack is always partially sorted | 19:35 |
| racarr | I think the thing with the sort plugin approach | 19:35 |
| tvoss | by definition | 19:35 |
| racarr | is...well.. | 19:36 |
| racarr | the first part is my opinion | 19:36 |
| racarr | that I don't think you want to recompute the sort each time you query the order | 19:36 |
| racarr | and then given that, you go on to cache is in this object, etc | 19:36 |
| racarr | but now to keep your cache valid | 19:36 |
| racarr | this object has to listen to signals from the rest of the system | 19:36 |
| racarr | i.e. surface destroyed, surface created, etc | 19:36 |
| tvoss | you only want to resort if something changes ... | 19:36 |
| racarr | so it's an object that gets messages like | 19:36 |
| racarr | surface destroyed, surface created | 19:36 |
| racarr | and maintains the orders the surfaces stack in | 19:37 |
| tvoss | yup | 19:37 |
| racarr | so why isn't it ust the | 19:37 |
| racarr | surface stack | 19:37 |
| racarr | because it has the same interface | 19:37 |
| tvoss | okay, bed time :) | 19:37 |
| tvoss | I'll keep it spinning | 19:38 |
| racarr | haha no fair | 19:38 |
| racarr | ok sleep well! | 19:38 |
| racarr | see you | 19:38 |
| racarr | lunch for me | 19:38 |
| thomi | morning | 19:59 |
| racarr | Morning! | 20:11 |
| olli_ | kgunn, are Chris' bug part of that list | 20:31 |
| kgunn | olli_: yes | 20:31 |
| kgunn | olli_: well...may i clarify what you mean ? | 20:32 |
| kgunn | olli_: e.g. radeon pixelated rendering...yes | 20:32 |
| kgunn | it is part of the list | 20:32 |
| olli_ | the ones he is tagging | 20:32 |
| olli_ | iow are there bugs yet from him? | 20:32 |
| olli_ | robert_ancell, RAOF, kgunn if someone wanted to get a better understanding of the xmir-x-drivers, who should be on the call? | 20:51 |
| olli_ | RAOF? | 20:51 |
| olli_ | anybody else? | 20:51 |
| robert_ancell | olli_, RAOF is the expert, he might know if the other X devs in Canonical might know too | 20:53 |
| kgunn | olli_: i think RAOF primarily...shared the same with hlh | 20:53 |
| olli_ | robert_ancell, thx | 20:54 |
| kgunn | olli_: robert_ancell maybe mlankhorst ? | 20:54 |
| olli_ | kgunn, like it when you are ahead of me ;) | 20:54 |
| robert_ancell | kgunn, yes, I was thinking so too, but I don't know how much he knows | 20:54 |
| kgunn | olli_: wrt ChrisG's "bugs"...so far, there has been a bug present, i haven't heard of any complaints from him that didn't already have a bug...but i will circle back for an inquisition | 20:55 |
| olli_ | kgunn, are the existing ones tagged | 20:55 |
| * olli_ wants to look at a list and see it turn "fix released" | 20:55 | |
| olli_ | robert_ancell, I suggested a meeting to include RAOF | 20:55 |
| olli_ | in a compatible tz | 20:56 |
| olli_ | well, at a NZ tz compatible time | 20:56 |
| olli_ | robert_ancell, kgunn, jfyi... our window in the cert lab closes on ~Thu this week | 20:56 |
| kgunn | olli_: wrt bugs that are actually being fixed....yes, there might be some cleanup to be done | 20:56 |
| robert_ancell | olli_, ack | 20:56 |
| olli_ | and /me is very eager to get results and I think you should be too :) | 20:56 |
| olli_ | kgunn, I think any bug that hits Chris should be tagged | 20:57 |
| olli_ | not sure how to parse your last statement | 20:57 |
| olli_ | :) | 20:57 |
| kgunn | olli_: i am sure its me :)...when you say "tagged" how ? what specifically do you mean ? | 20:58 |
| olli_ | kgunn, in LP you can add an arbitrary string to a bug | 20:58 |
| olli_ | i.e. what didrocks did for distro release | 20:58 |
| olli_ | I think we should have a similar tag for bugs that bother chris | 20:58 |
| olli_ | so we can make sure (via a simple query on that tag) that he is not blocked | 20:59 |
| olli_ | otherwise I see a team sprint in LEX for everybody on the horizon - as we all want these numbers ;) | 20:59 |
| olli_ | don't we? | 20:59 |
| * robotfuel waves at olli_ | 21:01 | |
| olli_ | ah | 21:01 |
| kgunn | olli_: got it | 21:01 |
| olli_ | /nick robotfuel reboot_robot | 21:01 |
| olli_ | scnr | 21:01 |
| robotfuel | olli_: kgunn here is the first bug, https://bugs.launchpad.net/xmir/+bug/1201565 I used needed-for-lab because launchpad didn't accept it with underscores. | 21:17 |
| ubot5 | Ubuntu bug 1201565 in XMir "unity doesn't run in xmir session " [Undecided,New] | 21:17 |
| kgunn | robotfuel: would it be possible to run the same machine / config in bug#1201565 just with the modification of commented out #type=unity in the /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf file | 21:33 |
| robotfuel | kgunn: yes | 21:33 |
| kgunn | robotfuel: thanks....assuming this might be the kind of thing the team would do when they get access | 21:34 |
| robert_ancell | RAOF, Can you look at the comment I made on the X log in https://bugs.launchpad.net/xmir/+bug/1201565 and see if that indicates a problem? | 21:35 |
| ubot5 | Ubuntu bug 1201565 in XMir "unity doesn't run in xmir session " [Undecided,Incomplete] | 21:35 |
| robert_ancell | actually, I'll just assign it to you - it's got to be either X or Unity failing | 21:36 |
| robert_ancell | racarr, did you see the build failure in https://code.launchpad.net/~robertcarr/mir/notify-surface-destruction/+merge/174834? Missing a file? | 21:50 |
| racarr | robert_ancell: ;) man I even remember hte exact details of creating that file and not doing M-x vc-register... | 21:51 |
| racarr | thanks haha | 21:51 |
| racarr | pushed a rev | 21:53 |
| robert_ancell | racarr, also, https://code.launchpad.net/~robertcarr/mir/simplify-depth-assignment/+merge/174872 has a merge conflict | 21:55 |
| racarr | robert_ancell: Just pushed the merge :) | 21:56 |
| kdub | RAOF, if we update the mir_client_library.h, that breaks xmir, right? | 22:02 |
| kdub | racarr, would you object to moving the client side event handler thread to the connection? | 22:13 |
| kdub | racarr, nevermind :) | 22:20 |
| olli_ | hey guys | 22:53 |
| olli_ | have you heard of Chromiums project Ozone? | 22:53 |
| olli_ | https://plus.google.com/100132233764003563318/posts | 22:53 |
| olli_ | puts Mir right next to Wayland as "alternative window system" | 22:54 |
| olli_ | good job everybody :) | 22:54 |
| olli_ | kgunn, ^ | 23:06 |
| kdub | olli_, yay | 23:06 |
| RAOF | kdub: If you touch things in mir_client_library.h that xmir uses, yes. | 23:38 |
| kdub | RAOF, so it would probably be better if all the client-api-facing changes for multimonitor configuration land at once... | 23:42 |
| kdub | just to minimize the amount of disruption | 23:43 |
| RAOF | kdub: As long as you're only *adding* ABI it's fine. | 23:43 |
| kdub | right... ~kdub/mir/display-grouping is a change, but after that, it should be just adding ABI | 23:44 |
| kdub | specifically, a change to the display info direct-query function | 23:44 |
| kdub | robert_ancell, that MP changes the protobuf protocol too, I guess that verison number should be bumped too | 23:51 |
| robert_ancell | kdub, just commenting on that | 23:51 |
| kdub | i guess i'll bump the soversion | 23:53 |
| robert_ancell | kdub, those protobuf changes mean an old libmirclient would break against the new libmirserver | 23:54 |
| kdub | yes | 23:54 |
| RAOF | Do we have any way of checking that? | 23:54 |
| RAOF | I mean, at the moment it's still (just!) reasonable to abort with an error message. | 23:55 |
| RAOF | On a similar note, do we have any infrastructure for extensions? | 23:56 |
| robert_ancell | RAOF, checking protobuf changes? | 23:56 |
| robert_ancell | RAOF, no to extensions | 23:57 |
| robert_ancell | (in that we have no infrastructure) | 23:57 |
| RAOF | robert_ancell: Either checking protobuf changes or checking the protocol version the client expects. | 23:57 |
| RAOF | Hrmph. Unity-system-compositor will want a (temporary) API for setting the position of the hw cursor. | 23:58 |
| robert_ancell | RAOF, if we use protocol buffers correctly we shouldn't need that, though it would be nice so we can log it. We don't check backwards compatibility because we only have the latest version of the lib on trunk | 23:58 |
| robert_ancell | RAOF, racarr just landed a patch for cursor support in u-s-c | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!