| === thomi_ is now known as thomi | ||
| duflu | kdub_: Around? | 02:32 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| alan_g | RAOF: you say "Breaks/Replaces" should work, sil2100 and mterry both say Conficts/Replaces/Provides should work. Any reason for the difference? | 08:35 |
| duflu | alf_: Sanity check: After eglSwapBuffers, you can trash your texture data right? | 09:16 |
| duflu | I always thought so | 09:16 |
| alf_ | duflu: yes for normal textures, for EGLImage backed textures the situation is not clear in the specs, but we have always assumed the same | 09:22 |
| duflu | alf_: Yeah I think more things would blow up if the data was still required after swapbuffers | 09:22 |
| duflu | Ah Friday afternoon... the best time to tackle complex problems | 09:24 |
| duflu | providing you don't need to have a Friday evening | 09:24 |
| sil2100 | alf_: hello! Are you familiar with qtubuntu codebase? | 10:29 |
| alf_ | sil2100: I've browsed it, but I wouldn't say I am familiar with it. | 10:30 |
| alf_ | sil2100: what's up? | 10:30 |
| === chihchun is now known as chihchun_afk | ||
| sil2100 | alf_: we're trying to identify the source of a recent crash in qmlscene that's most likely caused by qtubuntu and since ricmm doesn't seem to be around right now we're looking for someone that could help in the identification here | 10:34 |
| alf_ | sil2100: I can take a look in ~1h, where do I get information? | 10:36 |
| sil2100 | alf_: thanks! The bug is here https://bugs.launchpad.net/ubuntu-app-launch/+bug/1329141 | 10:37 |
| ubot5 | Ubuntu bug 1329141 in Ubuntu Application Launcher "qmlscene crashed while running test_can_launch_multiple_applications" [Critical,Confirmed] | 10:37 |
| sil2100 | It might be hard to pin-pointing, but maybe at least you could have a look and check if it's not anything obvious | 10:37 |
| alf_ | sil2100: The crash as retraced in https://bugs.launchpad.net/ubuntu/+bug/1340571 , is caused by qtubuntu for some reason not being able to create a server connection. It's not a real crash caused by some programming error (at least not at the crash site). | 10:59 |
| ubot5 | Ubuntu bug 1329141 in Ubuntu Application Launcher "duplicate for #1340571 qmlscene crashed while running test_can_launch_multiple_applications" [Critical,Confirmed] | 10:59 |
| === jibel_ is now known as jibel | ||
| === renato is now known as Guest57300 | ||
| === Guest57300 is now known as renato__ | ||
| kdub_ | racarr__, (when you're up) or dandrader, what do you think about this branch? lp:~vanvugt/mir/fastlog | 13:55 |
| kdub_ | (changing the input logging for mir) | 13:55 |
| * kdub_ approved, but then again I don't use that log very often :) | 13:55 | |
| * dandrader looks | 13:56 | |
| alan_g | AlbertA: alf_ kdub_ Anyone think we need more discussion of this: https://code.launchpad.net/~vanvugt/mir/server-ABI-24/+merge/227137 | 14:28 |
| kdub_ | alan_g, I approved, didnt see a problem | 14:33 |
| alan_g | kdub_: thanks (I didn't either) | 14:33 |
| AlbertA | alan_g: seems like the usual course of action so +1 | 14:39 |
| racarr__ | Morning :) | 14:44 |
| greyback | racarr__: hey, have you any more comments on qtmir QPA plugin? | 14:45 |
| racarr__ | greyback: Don't think so! | 14:46 |
| greyback | racarr__: ok great, thank you for looking into it | 14:50 |
| racarr__ | np :) | 14:54 |
| === dandrader is now known as dandrader|afk | ||
| alf_ | racarr__: standup? | 15:05 |
| === dandrader|afk is now known as dandrader | ||
| racarr__ | alf_: Sorry was breakfasting... | 15:21 |
| alf_ | racarr__: no worries, I have a question for you | 15:21 |
| racarr__ | nothing exciting from me...been doing some reviews and a little side work and working on cursor renderable | 15:21 |
| racarr__ | small hang up in cursor renderable...the | 15:22 |
| racarr__ | well it would be nice to be able to creat ean EGL image from the cursor buffer | 15:22 |
| racarr__ | to unify the software path | 15:22 |
| racarr__ | but you caont because there is no "DRIImage" for the dumb bos | 15:22 |
| racarr__ | alf_: Yeah? | 15:22 |
| alf_ | racarr__: I was looking into https://bugs.launchpad.net/mir/+bug/1344024 and traced the problem in our ConsumingPlacementStrategy | 15:23 |
| ubot5 | Ubuntu bug 1344024 in Mir "Clients cannot create surfaces when the screen is off" [High,In progress] | 15:23 |
| racarr__ | oh sounds right | 15:24 |
| alf_ | racarr__: when a screen (or the only screen) is off, the strategy will return size=(0,0) | 15:24 |
| alf_ | racarr__: I was wondering if we should have a more reasonable strategy as default. Is someone relying on current ConsumingPlacementStrategy behavior? | 15:25 |
| racarr__ | alf_: I don't think so no...it's kind of a hangover | 15:26 |
| racarr__ | I mean the strategy is reasonable right? size to outputs | 15:26 |
| racarr__ | presumably the problem is something like | 15:26 |
| racarr__ | using output.current_mode_index | 15:26 |
| alf_ | racarr__: Currently, if the client has asked for a particular size, we clip that the size of the output it's in. The problem is that if there are not outputs the new size will be (0,0) which is consistent, but fails | 15:30 |
| alf_ | racarr__: But taking a step back, I don't think we should be resizing the surface (by default) if the client has explicitly asked for a particular size. | 15:30 |
| alf_ | racarr__: Orthogonally to the above, we are currently using available display buffers to find the available outputs (and we don't create a display buffer for a screen that's off), so perhaps we should switch to DisplayConfiguration and take into account all "used" outputs (regardless of their power state) | 15:35 |
| racarr__ | alf_: Note about display configuration v. display buffers definitely seems right | 15:51 |
| racarr__ | resizing the surface...I dunno | 15:51 |
| racarr__ | I guess maybe we shouldnt by default | 15:51 |
| racarr__ | its | 15:51 |
| racarr__ | the unity behavior | 15:52 |
| racarr__ | but there is no reason to have it | 15:52 |
| racarr__ | in the mir tree | 15:52 |
| alf_ | racarr__: well, the client can get all the information about the display configuration, so if it asks for a particular size the we should respect that (in the default impl., a proper shell is another story) | 15:53 |
| alf_ | racarr__: although, I guess since the client can't place the surfaces exactly this is less useful | 15:55 |
| racarr__ | mm | 15:57 |
| racarr__ | I think it makes sense to remove from mir...no sense in the model now for having it as | 15:57 |
| racarr__ | a random bit of behavior | 15:57 |
| alf_ | racarr__: currently ConsumingPlacementStrategy has three subpolicies: 1. if the client has asked to be placed in a particular output (output_id is valid) => place it there | 16:00 |
| alf_ | racarr__: 2. if the client has asked for a particular size => clip the surface to the size of the output it is in | 16:00 |
| alf_ | racarr__: 3. if the client has asked for 0 size => make it fullscreen in the output it is in | 16:02 |
| racarr__ | yes | 16:02 |
| racarr__ | carefully designed to justify an elaborate series of cucumber tests | 16:02 |
| racarr__ | lol | 16:02 |
| racarr__ | um | 16:02 |
| racarr__ | I don't think any of the behaviors make sense for us to have | 16:03 |
| racarr__ | I mean maybe in demo-shell or something | 16:03 |
| racarr__ | but they are all shell-mediated right | 16:03 |
| racarr__ | even asking to be placed in a particular output | 16:03 |
| racarr__ | its the kind of thing where the shell says, eh, no thanks. | 16:03 |
| racarr__ | so I am not sure there is a point in having the default strategy impl if each shell is going to write its own | 16:04 |
| alf_ | racarr__: we should at least have a null implementation to allow the source to build :) | 16:08 |
| alf_ | racarr__: (and run the tests) | 16:08 |
| alf_ | racarr__: But I think something that includes only (1) would make sense as a default | 16:08 |
| racarr__ | Yeah I was wondering if it should have 1 but | 16:10 |
| alan_g | racarr__: does it make sense to move the other behaviours to the examples? | 16:10 |
| racarr__ | it should probably be in demo shell | 16:10 |
| alf_ | racarr__: plus just placing all surfaces at 0,0 with the size they have requested, a size of 0,0 being an error | 16:10 |
| racarr__ | why have (1) in tree if every shell | 16:10 |
| racarr__ | is expected to override | 16:10 |
| racarr__ | the placement strategy | 16:10 |
| alf_ | racarr__: well USC doesn't (currently) need to override it | 16:11 |
| racarr__ | presumably it will at some point though | 16:11 |
| alf_ | racarr__: yes, probably when we want to make it smarter about multiple monitors | 16:12 |
| alf_ | racarr__: I am inclined to include (1) in the default just because it's explicitly provided in the client API | 16:13 |
| alan_g | It is good to have a default that is sensible enough for a hypothetical developer to use until they need to change it. (Like what we have with USC now) | 16:13 |
| racarr__ | I was thinking about that | 16:13 |
| racarr__ | but then | 16:13 |
| racarr__ | surface states are provided in the client API too | 16:13 |
| racarr__ | right? so what is | 16:13 |
| racarr__ | the conceptual difference between the output-id placement behavior | 16:13 |
| racarr__ | and mir_surface_state_fullscreen leading to your surface becoming fullscreen | 16:14 |
| alf_ | racarr__: one difference is that the client can fake fullscreen size (it can get the display config), whereas it has not control of placement outside the output_id API. | 16:18 |
| alf_ | racarr__: Another point is: let's say that we don't support output_id, a client gives us an output_id, what do we do? | 16:19 |
| alf_ | racarr__: do we place that where we want and lie to the client, or do with error out? | 16:20 |
| alf_ | racarr__: s/do with/do we/ | 16:20 |
| racarr__ | alf_: But the null impl never runs | 16:22 |
| racarr__ | so place it whever you want :p | 16:22 |
| racarr__ | demo shell should certainly | 16:23 |
| racarr__ | support 1. | 16:23 |
| alf_ | racarr__: the problem is that output_id is supposed to provide a kind of guarantee (in my mind at least) that the output will be placed where the client told it to. | 16:24 |
| alf_ | racarr__: and a null default impl. breaks that guarantee | 16:25 |
| racarr__ | only a kind of guarantee because | 16:26 |
| racarr__ | the shell can always say | 16:26 |
| racarr__ | no thats ridiculous im not placing you on that monitor | 16:26 |
| alf_ | racarr__: then I think the output_id param is not useful if it's only a hint | 16:27 |
| alf_ | racarr__: Imagine XMir running and wanting to place the screen surface in a particular screen | 16:27 |
| racarr__ | Presumably the shell policy would be yes that something like XMir could always | 16:28 |
| racarr__ | specify output_id | 16:28 |
| racarr__ | whereas...maybe apps cant? | 16:28 |
| alf_ | racarr__: The API should give it that guarantee (with conforming implementations, of course), XMir shouldn't care about what's running beneath it. So I think that the mir server either supports output_id and places the surface properly, or it doesn't and errors. | 16:30 |
| alf_ | racarr__: and sure that could be a policy in the shell depending on the client | 16:31 |
| racarr__ | it's not really much of a guarantee | 16:31 |
| racarr__ | I man the shell | 16:31 |
| racarr__ | mean* | 16:31 |
| racarr__ | could respect output_id | 16:31 |
| racarr__ | and then | 16:32 |
| racarr__ | resize you and put you on another monitor | 16:32 |
| alf_ | racarr__: but treating it either as a guarantee or as a hint depending on the client is inconsistent | 16:32 |
| alf_ | racarr__: but the client asked for that particular id, not "fullscreen on any monitor you like" | 16:33 |
| racarr__ | maybe it should be an error if its not permitted and people who | 16:34 |
| racarr__ | don't really care about the actual physical setup of the displays (i.e. xmir because of monitor configuration I guess) | 16:34 |
| racarr__ | shouldn't use output_id | 16:34 |
| racarr__ | maybe this is imaginary but I have the thought that the answer isnt to always | 16:35 |
| racarr__ | support it from the client | 16:35 |
| racarr__ | i.e. should my phone app be able to open fullscreen on the external monitor | 16:35 |
| racarr__ | may be a permission or something | 16:35 |
| alf_ | racarr__: I guess I don't mind an almost-null implementation, as long as it errors out if an output id is provided ("I cannot provide that guarantee"). | 16:36 |
| racarr__ | I still think its a weird guarantee | 16:36 |
| racarr__ | what if you request an output-id and the user | 16:36 |
| racarr__ | moves you | 16:37 |
| racarr__ | is that an error? | 16:37 |
| racarr__ | probably not so is there some additional constraint like its only for certain surface types which are not movable by the user | 16:38 |
| racarr__ | but even then what happens when the monitor dissapears or something | 16:38 |
| racarr__ | so what the guarantee just becomes | 16:39 |
| racarr__ | if you provide an output-id you will be fullscreen on that output for some non zero amount of time | 16:39 |
| racarr__ | but then how can the client | 16:39 |
| racarr__ | use the guarantee? | 16:40 |
| racarr__ | because the time could be arbitrarily small | 16:40 |
| alf_ | racarr__: user move: fair point, monitor disappears: if the client cares about a particular id, it probably means it selected that based on the current display config, and it should monitor display config changes and adapts | 16:40 |
| racarr__ | hmm thats an interesting problem how do | 16:41 |
| racarr__ | ok so it could be for only non user movable windows | 16:41 |
| racarr__ | like say XMir, perhaps some presentation windows, etc | 16:41 |
| racarr__ | and then, when the outputs dissapear | 16:42 |
| racarr__ | you could add something that like | 16:42 |
| racarr__ | until a new output_id is assigned or | 16:42 |
| racarr__ | the output is cleared | 16:42 |
| racarr__ | the surface just dissapears | 16:42 |
| racarr__ | i.e. isn't on screen | 16:42 |
| racarr__ | and that makes the guarantee a little stronger | 16:42 |
| alf_ | racarr__: I think that's reasonable, the client should react quickly anyway | 16:42 |
| racarr__ | I am thinking about like | 16:42 |
| racarr__ | to prevent flicker | 16:42 |
| racarr__ | i.e. monitors 1 2 3 | 16:43 |
| racarr__ | client with output id 3 | 16:43 |
| racarr__ | monitor 3 unplugs | 16:43 |
| racarr__ | shell places | 16:43 |
| racarr__ | on 1 | 16:43 |
| racarr__ | client receives display configuration | 16:43 |
| racarr__ | change | 16:43 |
| racarr__ | places on 2 | 16:43 |
| racarr__ | but then you can make the guarantee if setting the output-id is successful | 16:44 |
| racarr__ | then if a surface appears | 16:45 |
| racarr__ | it will appear on that output | 16:45 |
| racarr__ | and then, still perhaps sometimes its dissalowed | 16:45 |
| racarr__ | im not sure | 16:45 |
| racarr__ | i.e. things like can phone apps open on the external display | 16:46 |
| alf_ | racarr__: another point is that if output_id is a guarantee you can cater for both 1. clients that really need to be placed in that id otherwise they don't work properly (XMir) 2. clients that would like to be placed in that output id, but it's not critical (they can try with output_id, fallback to without output_id) | 16:49 |
| alf_ | racarr__: anyway, food for thought :) | 16:49 |
| alf_ | racarr__: enjoy your day an weekend! | 16:49 |
| alf_ | all: ^^ | 16:49 |
| mzanetti | thanks alf_ :) you too | 16:50 |
| racarr__ | alf_: :) Cheers. Happy friday | 16:50 |
| === 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 | ||
| bschaefer | racarr__, hey, was just getting to the doing the SDL2 cursor stuff. 2 have come up that I don't see in mir (not sure if they are really needed anyway): | 21:32 |
| bschaefer | SDL_SYSTEM_CURSOR_NO and SDL_SYSTEM_CURSOR_CROSSHAIR | 21:32 |
| * bschaefer gets the x11 equivalent | 21:32 | |
| bschaefer | XC_pirate and XC_tcross | 21:33 |
| racarr__ | XC_pirate oO | 21:33 |
| racarr__ | ill hvet o look in to that one | 21:33 |
| racarr__ | will add crosshair to the branch though | 21:33 |
| racarr__ | thanks :D | 21:33 |
| bschaefer | racarr__, nice :), thank you! | 21:33 |
| racarr__ | brb though | 21:33 |
| bschaefer | racarr__, yeah the pirate, is just a cross, like on a treasure map | 21:34 |
| bschaefer | err...weird, pirate does not show up like that in xlib manual...weird... | 21:36 |
| bschaefer | strange...: case SDL_SYSTEM_CURSOR_NO: shape = XC_pirate; break; | 21:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!