[00:00] <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:01] <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:02] <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:03] <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:04] <kdub> well, actually, i take that back
[00:04] <racarr> thats what I was saying, is one option
[00:05] <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:06] <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:07] <racarr> kdub: toyds would never have this problem
[00:07] <kdub> i was just thinking about toyds yesterday
[00:07] <racarr> :D
[00:09] <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:10] <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:11] <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:13] <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:14] <RAOF> We might as well get the handshake in sooner rather than later.
[01:48] <duflu> RAOF: Can you please sanity check these comments?... https://bugs.freedesktop.org/show_bug.cgi?id=68969
[02:22] <RAOF> duflu: Hm.
[02:24] <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:25] <robert_ancell> duflu, huh, I thought apport collected them as root
[02:51] <robert_ancell> duflu, do you have an example bug report with that error?
[02:54] <duflu> robert_ancell: https://bugs.launchpad.net/bugs/1215053
[03:09] <robert_ancell> duflu, https://code.launchpad.net/~robert-ancell/unity-system-compositor/apport-root-files/+merge/184224
[05:14] <tvoss_> good morning :)
[05:17] <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:27] <RAOF> alf_: Sorry, I've got no ideas.
[05:27] <alf_> RAOF: np, thanks
[05:28] <RAOF> Although most drivers are not themselves threaded, so if gbm_bo import happens on a Mir callback that might be wrong.
[05:43] <duflu> RAOF: Some trivial patches for you: https://bugs.launchpad.net/xmir/+patches
[05:43] <RAOF> Ta.
[05:44] <duflu> I wish, less trivial fixes :{
[06:05] <RAOF> ...oh.
[06:05] <RAOF> Is *that* it?
[06:06] <RAOF> Hm, no, that *shouldn't be it…
[06:08] <RAOF> Oh, yes it is.
[06:08] <RAOF> duflu: We really need to tell clients when they're bypassed.
[06:09] <duflu> RAOF: That's quite counter-intuitive for me, but yeah, sure.
[06:10] <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:11] <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:12] <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:13] <duflu> RAOF: Can you please make sure the bug carries the conversation?... bug 1218815
[06:14] <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:17] <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:18] <duflu> Argh, intel why can't you treat NullRegion as empty? :P
[06:19] <RAOF> mlankhorst: Actually, you won't; the RADEON_SURF_SCANOUT flag looks like it'll change the surface layout.
[06:21] <RAOF> mlankhorst: Although in ways that I've not fully traced.
[06:30] <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:33] <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:34] <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:35] <mlankhorst> we have a bunch of pre-built ones
[06:35] <mlankhorst> tjaalton: ^
[06:35] <RAOF> In the kernel "PPA", right?
[06:36] <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:37] <tjaalton> yes, mainline builds rock
[06:38] <tjaalton> what doesn't is the amount of work needed to get fixes backported
[06:39] <dholbach> good morning
[06:42] <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:48] <duflu> RAOF: What is this exactly?... xmir->driver->BufferAvailableForWindow
[06:49] <RAOF> duflu: A callback we call when swap_buffers has returned, so there's a new buffer available.
[06:50] <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:51] <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:52] <RAOF> (One of the things you can do is tell it not to block for an indeterminate period ☺)
[06:53] <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:54] <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:55] <RAOF> Then X will call the BlockHandlers again, then X will sleep in select() until…
[06:57] <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:58] <RAOF> duflu: It's not totally dissimilar to glib's main loop handling, either.
[06:58] <RAOF> But much, much less visible.
[06:59] <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
[07:01] <RAOF> I don't think we need all of it, but I don't think it does anything that will actually *break* anything.
[07:02] <RAOF> Some of what it does would appear to be mandatory, like actually submitting rendering commands for everything but the XMir→Mir copy.
[07:03] <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:11] <RAOF> Time for me to see why it doesn't.
[07:12] <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:15] <duflu> RAOF: FYI, commenting out sna_accel_block_handler, XMir still works :)
[07:16] <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:17] <RAOF> It looks to me like there's important stuff there.
[07:17]  * RAOF wonders where else calls kgem_retire and _kgem_submit.
[07:18] <duflu> RAOF: The submit is in +sna_xmir_copy_to_mir
[07:18] <RAOF> No, that's kgem_submit_bo, which is different.
[07:19] <RAOF> ... no it isn't?
[07:19] <RAOF> Ah. _kgem_submit vs kgem_submit. Of course!
[07:23] <RAOF> duflu: I suspect that you'll find that XMir will eventually fail to work when you comment out sna_accel_block_handler
[07:24] <duflu> RAOF: Fair point
[07:55] <Mirv> I just experienced what apport tracked to bug #1220073 after 4h usage. it resulted in Xmir seemingly non-functional but VT1 functional
[07:57] <duflu> Mirv: Well, the maintainer clearly knows about the bug already. Not sure what you can do
[08:02] <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:03] <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:04] <Mirv> generally it's nice now, the only real workaround I currently need is to boot without the external monitor attached
[08:09] <MKCoin> Will editing the keyboard be substantially different in Mir, or will it be similar to/the same as Xmodmap?
[08:21] <duflu> MKCoin: It's pure X, unchanged. X is still handling all input even under XMir for now
[08:39] <duflu> alf_: Have you worked with xf86-video-intel before?
[08:41] <MKCoin> I see, thanks.
[08:42] <MKCoin> First thing after I do after an install is customize my keyboard, glad to know that will be unchanged :D
[13:44] <kgunn> alf_: got your feet on the ground again yet ?
[13:46] <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:50] <kgunn> alf_: mmm....like ?....i vaguely remember some weirdness around the gl binding call to the egl surface
[13:52] <kgunn> alf_: gotta branch ?
[13:54] <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:55] <kgunn> alf_: cool...
[15:10] <pete-woods> ssweeny: hi, sorry for the delayed response
[15:10] <pete-woods> whoops, wrong channel
[15:43] <tehrain> in case anyone didn't know, the latest daily build is a real bitch to install on VMware due to graphical corruption
[15:57] <xtriz> from the next release ubuntu will start shipping with Mir, so will that create probs with some applications ?
[15:58] <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:59] <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.
[16:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:17] <xtriz> that's that simple ?
[16:17] <xtriz> nothing else i need to do ?
[18:18] <xtriz> \as mir will introduced that other DE like cinnamon and xfce will not work right ?
[18:20] <kdub> xmir supports other x-based environments
[18:22] <xtriz> kdub, that's great if it supports and everything works well.
[18:22] <xtriz> xmir is a compatible layer right ?
[18:23] <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:24] <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:25] <xtriz> kdub, ok
[18:26] <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:27] <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:28] <xtriz> that's interesting.. so this sounds something more better.
[18:30] <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:31] <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:32] <xtriz> ok , so downloading the beta build of 13.10
[18:33] <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:35] <tehrain> kdub, are you aware of any issues with Mir specific to VMware?
[18:35] <xtriz> ok :)
[18:36] <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:37] <kdub> tehrain, might get better results if you use software rendering in vmware
[18:38] <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:39] <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:46] <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:47] <tehrain> only the toolkit needs to have support for Mir I believe
[18:52] <xtriz> ok
[19:08] <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:11] <xtriz> any expert opinion
[19:12] <kdub>   no, just the toolkit packages
[19:20] <xtriz> kdub, can i pm you ?
[19:34] <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:39] <kdub> xtriz, a gui application linked to a toolkit will need no repackaging
[19:43] <xtriz> kdub, ok :)
[19:44] <kdub> xtriz, really, the goal is so most people don't have to worry about it
[19:45] <xtriz> kdub, thats great
[19:49] <xtriz> if everything integrates well with Mir then Mir will be really successfully across the board.
[22:22] <racarr> cd
[22:26] <racarr> ok I think I decided how to do the focus refactoring to get rid of the race
[22:27] <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:28] <kdub> whats the race?
[22:29] <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:31] <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:32] <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:34] <racarr> eh
[22:34] <racarr> needs a recurisve mutex
[22:34] <racarr> or a verbose API
[22:36] <racarr> bler myt focus mechanism inverting solution makes it difficult to deliver unfocused notifications
[22:38] <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:39] <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
[23:11] <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:26] <racarr> lol so in the end the solution is three lines
[23:32] <racarr> ok im pretty happy about that :)
[23:50] <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