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