| racarr | One option is that advance_buffer becomes an error instead of blocking while display is off | 00:00 |
|---|---|---|
| racarr | but this is really just shoving the problem to the client | 00:00 |
| kdub | racarr, we say that the advance buffer could block | 00:01 |
| kdub | so if the client wants to blank/unblank then, it seems the client is the only one that can sort that out | 00:01 |
| racarr | kdub: Yes. its generally ok, but here is the specific problem | 00:01 |
| racarr | its the blocking on the server side, | 00:01 |
| racarr | i.e. you call, display off, then call advance buffer | 00:01 |
| racarr | your server side socket session is blocked there | 00:02 |
| racarr | so you can never turn display back on | 00:02 |
| racarr | because all messages are processed in order | 00:02 |
| racarr | one solution would be to seperate messages in to channels, and read them as fast as we can and ensure messages are executed in order per channel | 00:02 |
| racarr | i.e. the surface channel, and so you can't execute a resize message while you are executing a swap buffers message | 00:02 |
| racarr | but the display channel, you can turn off the display while your surface is being resized | 00:03 |
| kdub | seems complicated | 00:03 |
| racarr | that's kind of invasive though | 00:03 |
| racarr | yeah | 00:03 |
| kdub | why not just have an error be returned | 00:03 |
| kdub | if the client tries to swapbuffers while they've paused? | 00:03 |
| kdub | well, actually, i take that back | 00:04 |
| racarr | thats what I was saying, is one option | 00:04 |
| racarr | but ideally I think, swap buffers really would just block | 00:05 |
| racarr | but assuming you are doing it asynchronously you should be able to go on to do | 00:05 |
| racarr | other things like reconfigure the displays | 00:05 |
| robert_ancell | RAOF, hey, been thinking we can abuse the application lifecycle API for XMir input dropping instead of focus - it will probably work better. racarr confirmed the API is there (mir_connection_set_lifecycle_event_callback) | 00:06 |
| robert_ancell | RAOF, since it's per connection it should be more clear than focus | 00:06 |
| racarr | kdub: toyds would never have this problem | 00:07 |
| kdub | i was just thinking about toyds yesterday | 00:07 |
| racarr | :D | 00:07 |
| robert_ancell | thomi, also, is Jenkins locked up? https://code.launchpad.net/~robert-ancell/lightdm/coverity-fixes/+merge/184043 | 00:09 |
| racarr | maybe the different message channels aren't that hard | 00:09 |
| racarr | instead of waiting for the session mediator to process messages before starting the next async read | 00:09 |
| racarr | you read them as fast as you can | 00:09 |
| racarr | then the session mediator has locks i.e. | 00:10 |
| racarr | surface_channel_mutex, display_channel_mutex | 00:10 |
| racarr | to ensure you only process one message from each channel | 00:10 |
| racarr | except it doesnt work because how do you know that in between reading a message from the socket and invoking the session mediator that your thread wont yield to another thread which will process a message ahead of you that should have been behind | 00:11 |
| RAOF | robert_ancell: Oooh, yes! | 00:13 |
| robert_ancell | RAOF, at the moment it doesn't handshake, but I suspect that will have to come at some time | 00:13 |
| RAOF | We might as well get the handshake in sooner rather than later. | 00:14 |
| duflu | RAOF: Can you please sanity check these comments?... https://bugs.freedesktop.org/show_bug.cgi?id=68969 | 01:48 |
| ubot5 | Freedesktop bug 68969 in Driver/intel "xf86-video-intel 2.99.901 + XMir + multimonitors = all displays black" [Normal,Resolved: notourbug] | 01:49 |
| RAOF | duflu: Hm. | 02:22 |
| duflu | robert_ancell: I just noticed why so many bug reports lack logs... | 02:24 |
| duflu | UnitySystemCompositorLog: Error: [Errno 13] Permission denied: '/var/log/lightdm/unity-system-compositor.log' | 02:24 |
| duflu | LightDMLog: Error: [Errno 13] Permission denied: '/var/log/lightdm/lightdm.log' | 02:24 |
| robert_ancell | duflu, huh, I thought apport collected them as root | 02:25 |
| robert_ancell | duflu, do you have an example bug report with that error? | 02:51 |
| duflu | robert_ancell: https://bugs.launchpad.net/bugs/1215053 | 02:54 |
| ubot5 | Launchpad bug 1208250 in Mir "duplicate for #1215053 Graphic corruption on Intel Mobile Corp Mobile 4 chipsets" [Critical,Incomplete] | 02:54 |
| === chihchun_afk is now known as chihchun | ||
| robert_ancell | duflu, https://code.launchpad.net/~robert-ancell/unity-system-compositor/apport-root-files/+merge/184224 | 03:09 |
| tvoss_ | good morning :) | 05:14 |
| alf_ | RAOF: I have been trying to add eglCreateImageKHR support for gbm_bo to platform_mir, but I get some erratic behavior with this failing either during image creation or rendering in intel_do_flush_locked. It seems there may be some race/timing related issue going on... any ideas or known caveats about CreateImage implementations? | 05:17 |
| RAOF | alf_: Sorry, I've got no ideas. | 05:27 |
| alf_ | RAOF: np, thanks | 05:27 |
| RAOF | Although most drivers are not themselves threaded, so if gbm_bo import happens on a Mir callback that might be wrong. | 05:28 |
| duflu | RAOF: Some trivial patches for you: https://bugs.launchpad.net/xmir/+patches | 05:43 |
| RAOF | Ta. | 05:43 |
| duflu | I wish, less trivial fixes :{ | 05:44 |
| RAOF | ...oh. | 06:05 |
| RAOF | Is *that* it? | 06:05 |
| RAOF | Hm, no, that *shouldn't be it… | 06:06 |
| RAOF | Oh, yes it is. | 06:08 |
| RAOF | duflu: We really need to tell clients when they're bypassed. | 06:08 |
| duflu | RAOF: That's quite counter-intuitive for me, but yeah, sure. | 06:09 |
| duflu | RAOF: More reasons why? Other than intel DDX internal reasons? | 06:10 |
| RAOF | Radeon DDX internal reasons, too. | 06:10 |
| duflu | Joy | 06:10 |
| RAOF | I'm pretty sure that's why radeon is corrupting with bypass (for some people) | 06:10 |
| RAOF | And the (for some people) is really (for some resolutions), because scanout buffers are aligned differently. | 06:11 |
| mlankhorst | ;p | 06:11 |
| mlankhorst | <<< | 06:11 |
| duflu | RAOF: In that case we need to flag scanout buffers, and not necessarily when they're also bypassed | 06:11 |
| RAOF | mlankhorst: nvidia always seems to have the most forgiving hardware, but does nouveau lay out scanout buffers subtly differently in ways the kernel doesn't necessarily expose? | 06:12 |
| RAOF | duflu: Yes | 06:12 |
| mlankhorst | erm not at all, just needs to be allocated contiguously | 06:12 |
| mlankhorst | but I've even added kernel checks for that recently | 06:12 |
| duflu | RAOF: Can you please make sure the bug carries the conversation?... bug 1218815 | 06:13 |
| ubot5 | bug 1218815 in xserver-xorg-video-ati (Ubuntu) "[radeon] Graphic glitches and screen corruption (vertical lines) on XMir surfaces only" [Critical,Triaged] https://launchpad.net/bugs/1218815 | 06:13 |
| mlankhorst | failing to allocate contiguously will only result in some very obvious scanout corruption though ;P | 06:14 |
| duflu | RAOF: Umm, actually, no. We don't need a scanout flag. We just need to report stride/pitch/whatever *accurately* :) | 06:14 |
| mlankhorst | duflu: but you can abuse the fact that if you know the dimensions, radeon calculates everything in libdrm so you will get the same answer | 06:17 |
| duflu | Argh, intel why can't you treat NullRegion as empty? :P | 06:18 |
| RAOF | mlankhorst: Actually, you won't; the RADEON_SURF_SCANOUT flag looks like it'll change the surface layout. | 06:19 |
| RAOF | mlankhorst: Although in ways that I've not fully traced. | 06:21 |
| alf_ | mlankhorst: I have been trying to add eglCreateImageKHR support for gbm_bo to platform_mir, but I get some erratic behavior with this failing either during image creation or rendering in intel_do_flush_locked. It seems there may be some race/timing related issue going on... any ideas or known caveats about CreateImage implementations? It seems like the gem object created by gbm somehow gets lost and can't be found (e.g. I sometimes get ENOENT e | 06:30 |
| alf_ | mlankhorst: could this be related to how gbm creates the gem object, loading the dri driver on its own? | 06:33 |
| mlankhorst | alf_: you might want to try against drm-next kernel, it has a bunch of fixes, and your wall of text got truncated at ENOENT | 06:33 |
| alf_ | mlankhorst: ...ENOENT errors from IOCTL_DRM_GEM_FLINK, or later when trying to render) | 06:34 |
| alf_ | mlankhorst: is there an easy way (e.g. a package) to get the kernel? | 06:34 |
| mlankhorst | we have a bunch of pre-built ones | 06:35 |
| mlankhorst | tjaalton: ^ | 06:35 |
| RAOF | In the kernel "PPA", right? | 06:35 |
| mlankhorst | no idea, i only know we do :P | 06:36 |
| RAOF | alf_: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/ | 06:36 |
| alf_ | RAOF: great, thanks! | 06:36 |
| * RAOF really needs to fix it so that we don't flink buffers for no good reason | 06:36 | |
| tjaalton | yes, mainline builds rock | 06:37 |
| tjaalton | what doesn't is the amount of work needed to get fixes backported | 06:38 |
| dholbach | good morning | 06:39 |
| alf_ | RAOF: well, the flink I am referring to is just part of an experiment to figure out why gbm object get lost, do we still have flinks elsewhere? | 06:42 |
| RAOF | alf_: I think we might do, yes. | 06:42 |
| duflu | RAOF: What is this exactly?... xmir->driver->BufferAvailableForWindow | 06:48 |
| RAOF | duflu: A callback we call when swap_buffers has returned, so there's a new buffer available. | 06:49 |
| duflu | RAOF: Yeah I figured that out. But am confused because it means we only schedule new redraws if one happened recently. How do you go from idle to redraw then? | 06:50 |
| RAOF | duflu: Due to my mismemory of the X main loop, it's kinda superfluous, because we only get our events processed when going idle anyway, and the DDX calls xmir_for_each_dirty_window() | 06:50 |
| duflu | Cool. | 06:50 |
| RAOF | duflu: Ah; the BlockHandler gets called before the X main loop goes into select() | 06:50 |
| duflu | ??? | 06:51 |
| duflu | What _is_ the BlockHandler? Looks important :) | 06:51 |
| RAOF | It's the server's “I'm about to go into select(), anything you need to do before I block for an indeterminate period?” | 06:51 |
| RAOF | callback. | 06:51 |
| RAOF | (One of the things you can do is tell it not to block for an indeterminate period ☺) | 06:52 |
| duflu | RAOF: Right. So that could go deep sleep and not be woken till damage arrives? | 06:53 |
| * duflu checks the intel code again | 06:53 | |
| RAOF | Nothing in the X server does anything between the block handlers being called and select() returning because some external event has happened. | 06:54 |
| RAOF | Whereupon the X server will call any of the WakeUpHandlers associated with fds that select says have had something interesting happen to them. | 06:54 |
| RAOF | Then X will handle any client requests on its socket. | 06:54 |
| RAOF | Then X will call the BlockHandlers again, then X will sleep in select() until… | 06:55 |
| duflu | RAOF: X is all very clever with its single threaded design, but not always intuitive. I usually end up appreciating the approach... eventually | 06:57 |
| RAOF | duflu: It's not totally dissimilar to glib's main loop handling, either. | 06:58 |
| RAOF | But much, much less visible. | 06:58 |
| duflu | RAOF: OK, so do we really still need and want all of sna_accel_block_handler when XMir is running? I'm not convinced it's additional, but likely should replace some of that | 06:59 |
| RAOF | I don't think we need all of it, but I don't think it does anything that will actually *break* anything. | 07:01 |
| RAOF | Some of what it does would appear to be mandatory, like actually submitting rendering commands for everything but the XMir→Mir copy. | 07:02 |
| duflu | I thought we did that in XMir. | 07:03 |
| * duflu hacks the DDX to be convinced | 07:03 | |
| duflu | If only the upstream branch *worked* I would be working with that. | 07:03 |
| RAOF | Time for me to see why it doesn't. | 07:11 |
| duflu | RAOF: It works if you have only one output... | 07:12 |
| RAOF | Then it's time to see what xmir_resize does that ickle hates! | 07:12 |
| duflu | RAOF: FYI, commenting out sna_accel_block_handler, XMir still works :) | 07:15 |
| RAOF | Colour me surprised. | 07:16 |
| duflu | RAOF: So unless there's something important there, maybe we should try to skip as much as possible? | 07:16 |
| RAOF | It looks to me like there's important stuff there. | 07:17 |
| * RAOF wonders where else calls kgem_retire and _kgem_submit. | 07:17 | |
| duflu | RAOF: The submit is in +sna_xmir_copy_to_mir | 07:18 |
| RAOF | No, that's kgem_submit_bo, which is different. | 07:18 |
| RAOF | ... no it isn't? | 07:19 |
| RAOF | Ah. _kgem_submit vs kgem_submit. Of course! | 07:19 |
| RAOF | duflu: I suspect that you'll find that XMir will eventually fail to work when you comment out sna_accel_block_handler | 07:23 |
| duflu | RAOF: Fair point | 07:24 |
| Mirv | I just experienced what apport tracked to bug #1220073 after 4h usage. it resulted in Xmir seemingly non-functional but VT1 functional | 07:55 |
| ubot5 | bug 1220073 in xserver-xorg-video-intel (Ubuntu) "[snb mesa] GPU lockup IPEHR: 0x79050005 IPEHR: 0x0b140001" [Undecided,Confirmed] https://launchpad.net/bugs/1220073 | 07:55 |
| duflu | Mirv: Well, the maintainer clearly knows about the bug already. Not sure what you can do | 07:57 |
| duflu | Mirv: BTW, when logging bugs, please remember to set a task for the Mir project. Most of the team doesn't monitor the Ubuntu tasks | 08:02 |
| Mirv | duflu: yeah I noted that you want those in the upstream project | 08:03 |
| Mirv | let's see if that gpu hang happens again, it's been a bit of time since the last one | 08:03 |
| Mirv | generally it's nice now, the only real workaround I currently need is to boot without the external monitor attached | 08:04 |
| MKCoin | Will editing the keyboard be substantially different in Mir, or will it be similar to/the same as Xmodmap? | 08:09 |
| duflu | MKCoin: It's pure X, unchanged. X is still handling all input even under XMir for now | 08:21 |
| duflu | alf_: Have you worked with xf86-video-intel before? | 08:39 |
| MKCoin | I see, thanks. | 08:41 |
| MKCoin | First thing after I do after an install is customize my keyboard, glad to know that will be unchanged :D | 08:42 |
| === hikiko is now known as hikiko|lunch | ||
| === hikiko|lunch is now known as hikiko | ||
| kgunn | alf_: got your feet on the ground again yet ? | 13:44 |
| === pete-woods is now known as pete-woods-lunch | ||
| alf_ | kgunn: I actually have my feet deep in the mud... trying to implement eglCreateImageKHR for EGL platform mir (needed by nested mir), but I am getting strange issues | 13:46 |
| kgunn | alf_: mmm....like ?....i vaguely remember some weirdness around the gl binding call to the egl surface | 13:50 |
| kgunn | alf_: gotta branch ? | 13:52 |
| alf_ | kgunn: it's a combo of the platform_mir eglCreateImageKHR implementation in mesa, and a hacked version of Alan's nested-mir spike. I will push my versions, along with an explanatory email later today. | 13:54 |
| kgunn | alf_: cool... | 13:55 |
| === pete-woods-lunch is now known as pete-woods | ||
| pete-woods | ssweeny: hi, sorry for the delayed response | 15:10 |
| pete-woods | whoops, wrong channel | 15:10 |
| === chihchun is now known as chihchun_afk | ||
| === tkamppeter_ is now known as tkamppeter | ||
| tehrain | in case anyone didn't know, the latest daily build is a real bitch to install on VMware due to graphical corruption | 15:43 |
| xtriz | from the next release ubuntu will start shipping with Mir, so will that create probs with some applications ? | 15:57 |
| tehrain | it's creating huge problems for me right now | 15:58 |
| xtriz | that's sad to hear :( | 15:58 |
| tehrain | and this is with just the stock software | 15:58 |
| xtriz | Mir would be default with the next release ? | 15:58 |
| tehrain | yes | 15:58 |
| tehrain | it doesn't seem to like changing screen resolution | 15:59 |
| tehrain | the installation is also really fucked up on VMware at least | 15:59 |
| tehrain | I had to alt+drag the window | 15:59 |
| xtriz | i tried but i terribly failed too. | 15:59 |
| xtriz | on the next release can't we use the xorg server instead of Mir ? | 16:00 |
| tehrain | nope | 16:00 |
| tehrain | not unless you install binary nvidia or amd drivers | 16:00 |
| tehrain | and in 14.04 there will be no option to use X | 16:00 |
| tehrain | of course, you could also go upstream and use debian instead... ;p | 16:01 |
| xtriz | then most of the applications also must not work properly on it correct ? | 16:01 |
| tehrain | at this point they're running inside of an X server that runs on top of Mir | 16:01 |
| tehrain | so most applications should work similarly | 16:01 |
| xtriz | tehrain, and what about xfce and other DE will they work ? because i am using xfce side by side with unity. | 16:02 |
| tehrain | I haven't tried, but in theory it should work | 16:02 |
| tehrain | but expect serious problems | 16:03 |
| xtriz | is their any special advantage of using Mir ? | 16:03 |
| tehrain | not really ;p | 16:03 |
| xtriz | yeah i suspect that , there must be a whole lot of probs :( | 16:03 |
| xtriz | than why are they taking up Mir...!! :P bad decision . | 16:03 |
| tehrain | obviously they smoke some really good weed | 16:03 |
| tehrain | I mean.. at least wait until the software is ready to make it default! | 16:04 |
| tehrain | I have to support this professionally | 16:04 |
| xtriz | support ? | 16:04 |
| tehrain | we use Ubuntu at this company | 16:04 |
| xtriz | like it's difficult for all the open source software to make Mir compatible. | 16:04 |
| xtriz | ok :) | 16:05 |
| tehrain | yeah, and as an open source developer I'm not going to jump through hoops to make stuff work for a single distro | 16:05 |
| xtriz | correct :D | 16:06 |
| tehrain | it should be up to the Ubuntu devs to make Mir work with the existing software and adhere to existing standards, imo | 16:06 |
| xtriz | absolutely otherwise all will leave ubuntu ... | 16:06 |
| tehrain | on my VM I'm seeing stars right now ;p | 16:06 |
| tehrain | they change color if anything else on the screen moves | 16:06 |
| xtriz | tehrain, what should i do if i don't want mir to be default on my system from the next release ? | 16:07 |
| tehrain | if you have an nvidia or amd graphics card, install the proprietary drivers | 16:07 |
| tehrain | then you'll go back to using straight X | 16:07 |
| xtriz | that's that simple ? | 16:17 |
| xtriz | nothing else i need to do ? | 16:17 |
| === alan_g is now known as alan_g|EOD | ||
| xtriz | \as mir will introduced that other DE like cinnamon and xfce will not work right ? | 18:18 |
| kdub | xmir supports other x-based environments | 18:20 |
| xtriz | kdub, that's great if it supports and everything works well. | 18:22 |
| xtriz | xmir is a compatible layer right ? | 18:22 |
| kdub | no | 18:23 |
| xtriz | ok | 18:23 |
| xtriz | where i can learn more about mir ? | 18:23 |
| kdub | its the xserver that the desktop environment uses | 18:23 |
| xtriz | kdub, is their any special advantage of using mir ? | 18:23 |
| kdub | xtriz, sure! | 18:24 |
| xtriz | like what are they ? i am getting more interested in Mir now...after reading couple of articles. | 18:24 |
| kdub | xtriz, for one, you can have smooth transitions between opengl clients | 18:24 |
| xtriz | but can't get exact benefits of using Mir. | 18:24 |
| xtriz | kdub, ok | 18:25 |
| xtriz | kdub, are you a mir developer ? | 18:26 |
| kdub | xtriz, another one is that the state of the desktop is centralized and can be better tracked | 18:26 |
| kdub | yep | 18:26 |
| xtriz | great :) | 18:26 |
| kdub | xtriz, so for instance, if we want to have a client, and map it to a sphere shape, and have the clicks follow the client's mapping to the sphere, we could do something like that | 18:27 |
| kdub | there's no plans to do that at the moment :) but thats the sort of flexibility we're shooting for | 18:27 |
| xtriz | that's interesting.. so this sounds something more better. | 18:28 |
| xtriz | kdub, for example i am using any open source application will that work fine ? or they have to be made compatible to work with Mir. | 18:30 |
| xtriz | kdub, if i want to get involve into Mir from where should i start. | 18:30 |
| kdub | most applications that rely on qt or gtk won't notice a difference | 18:30 |
| kdub | because we just rewrite some of the backend for qt/gtk/etc and the applications won't have to change | 18:30 |
| xtriz | ok | 18:31 |
| kdub | xtriz, if you want to help out, that would be great! a good start is to just get it running | 18:31 |
| xtriz | ok , so downloading the beta build of 13.10 | 18:32 |
| kdub | xtriz, how are you interested in helping? really, once you get it going, the 'most fun' would just be to play with our example programs probably | 18:33 |
| tehrain | kdub, are you aware of any issues with Mir specific to VMware? | 18:35 |
| xtriz | ok :) | 18:35 |
| xtriz | i would help to fix some bugs or recompile app with GTK / QT necessary flag support. | 18:36 |
| kdub | tehrain, no, unaware... we could note in a bug report I suppose | 18:36 |
| kdub | tehrain, might get better results if you use software rendering in vmware | 18:37 |
| tehrain | the largest issue I've seen is during the installation phase of the latest daily Ubuntu snapshots, where a black/grey menubar repeats itself for half of the screen | 18:38 |
| tehrain | that might be VMware specific though, not sure if it happens on other video drivers | 18:39 |
| tehrain | and if you change resolution, there is a lot of graphical corruption | 18:39 |
| tehrain | and I am using software rendering | 18:39 |
| bschaefer | tehrain, I got that the other day...its not a VM problem | 18:39 |
| xtriz | right now i am using cinnamon 1.8 so after the upgrade to 13.10 i can successfully use it ? | 18:46 |
| xtriz | or some changes are necessary to be made ? | 18:46 |
| xtriz | like compiling packages with mir support ? | 18:46 |
| tehrain | only the toolkit needs to have support for Mir I believe | 18:47 |
| xtriz | ok | 18:52 |
| xtriz | all the packages would need to recompiled to support mir correct ? if this happens then those distro which depends on ubuntu will be in prob ? | 19:08 |
| xtriz | am i correct ? | 19:08 |
| xtriz | any expert opinion | 19:11 |
| kdub | no, just the toolkit packages | 19:12 |
| xtriz | kdub, can i pm you ? | 19:20 |
| xtriz | would all the packages made in ubuntu will be compatible to those distro which do not support mir ? or they will package stuff specifically optimized for mir ? | 19:34 |
| kdub | xtriz, a gui application linked to a toolkit will need no repackaging | 19:39 |
| xtriz | kdub, ok :) | 19:43 |
| kdub | xtriz, really, the goal is so most people don't have to worry about it | 19:44 |
| xtriz | kdub, thats great | 19:45 |
| xtriz | if everything integrates well with Mir then Mir will be really successfully across the board. | 19:49 |
| racarr | cd | 22:22 |
| racarr | ok I think I decided how to do the focus refactoring to get rid of the race | 22:26 |
| racarr | DefaultFocusMechanism::set_focus_to changes its argument from session->surface | 22:27 |
| racarr | and rather than like, session manager calls focus_mechanism->set_focus_to(session) | 22:27 |
| racarr | then the focus_mechanism queries the default_surface | 22:27 |
| racarr | instead, the session manager calls like | 22:27 |
| racarr | session->take_focus(focus_mechanism) | 22:27 |
| racarr | and the session gets its own default surface while holding its internal lock | 22:27 |
| kdub | whats the race? | 22:28 |
| racarr | kdub: You call session->default_surface and get std::shared_ptr<msh::Surface>, and or you were holding std::weak_ptr<msh::Surface> to the last focused surface and just locked it (so you can send it unfocused) | 22:29 |
| racarr | but then you yield, the surface is destroyed from another thread (say the client disconnects) | 22:29 |
| racarr | and you call surface->anything throwing an exception | 22:29 |
| racarr | because you aren't actually keeping the underlying surface alive | 22:31 |
| racarr | of course, everything could be modified to handle the exceptions properly but that seems dangerously like using exceptions for synchronization XD | 22:31 |
| racarr | It's what session-transactions was aimed to fix but that required a recursive mutex. | 22:32 |
| racarr | perhaps even just msh::Session should be std::lockable | 22:32 |
| racarr | eh | 22:34 |
| racarr | needs a recurisve mutex | 22:34 |
| racarr | or a verbose API | 22:34 |
| racarr | bler myt focus mechanism inverting solution makes it difficult to deliver unfocused notifications | 22:36 |
| racarr | its possible to make it like DefaultFocusMechanism::set_focus_to(std::shared_ptr<shell::Surface> const& new_Focus, std::function<void()> callback_to_be_invoked_when_surface_is_unfocused_that_has_reponsibility_for_delivering_the_unfocus_configure_event) | 22:38 |
| racarr | but you still need a recursive mutex because the lambda comes from the session and needs to lock the surfaces, but set_focus_to is called by the session as well | 22:39 |
| racarr | its recursive all the way down | 22:39 |
| racarr | A whole new tree of ideas! | 23:11 |
| racarr | maybe the session doesnt call surface->destroy and just relys on the ~msh::Surface to do that so then | 23:11 |
| racarr | keeping around a shared_ptr to a surface becomes safe | 23:11 |
| racarr | this may be a useful property in general, i.e. just bnecause the client closed the surface doesn't mean the shell is totally done (perhaps we want to do an animation( | 23:11 |
| racarr | lol so in the end the solution is three lines | 23:26 |
| racarr | ok im pretty happy about that :) | 23:32 |
| bschaefer | if anyone can reproduce, seems pretty bad (though it only happens when existing from an egl app): https://bugs.launchpad.net/mir/+bug/1221974 | 23:50 |
| ubot5 | Launchpad bug 1221974 in Mir "eglTerminate double free or corruption using mir" [Undecided,New] | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!