[00:27] kdub: Oh no XD [00:27] well you can launch them but not from unity [00:28] How about switching? [00:28] ☺ [00:28] RAOF: God you guys are so demanding [00:28] how much does a shell really have to do!?!?!?! [00:29] its coming together though :) [00:40] still cool :) [00:41] hey RAOF, i built my own mesa driver [00:41] but get this error: [00:41] [172730.125463] mir_demo_server[23263]: segfault at 0 ip b6b6b53a sp bf834e1c error 4 in libX11-xcb.so.1.0.0[b6b6b000+1000] [00:42] kdub: Your EGL platform detection isn't working; it's falling back to X11 and failing. [00:46] What's your mesa driver for? [00:47] an i965 card [00:47] does "EGL_PLATFORM=mir" work? [00:48] I really want to watch a live stream of a concert and try as I might I cant get flash sound working XD [00:48] so I'm rebooting to OSX [00:48] Bye! [00:48] :p [01:16] kdub: That should work, I think. [01:16] kdub: As long as you actually built the mir platform; you need to explicitly enable it. [01:17] kdub: PKG_CONFIG_PATH=$HOME/.local/lib/pkgconfig ./autogen.sh --prefix=$HOME/.local/ --enable-gles1 --enable-gles2 --with-dri-drivers=i965 --with-gallium-drivers=i915,nouveau,r300,r600,freedreno,svga,swrast --enable-shared-glapi --enable-glx-tls --with-egl-platforms=mir,drm,x11 --enable-texture-float --enable-gbm --enable-openvg --enable-gallium-egl --enable-gallium-gbm [01:17] Is what I use; you probably want to replace the --with-gallium-drivers bit to --with-gallium-drivers= [02:04] It's remarkable how quickly you learn to ignore the huge stomping orange arrow on your screen. [02:11] Luckily it is moveable :) [02:33] duflu: Not once XMir starts :) [03:18] robert_ancell: Umm saucy just builds mir without modification. There are lots of notes/warnings to fix but no errors. [03:18] duflu, all the tests pass? [03:18] Yep [03:18] Did it build with -DNDEBUG? [03:19] Doesn't appear so [03:20] duflu, did you run cmake from scratch? [03:20] I ran it per usual. What's "from scratch"? [03:20] duflu, i.e. cleared out existing build [03:21] robert_ancell: Yes it's a fresh machine [03:21] from scratch [03:21] and definitely gcc 4.8? [03:21] Yep [03:21] weird [03:21] gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1) [03:21] Perhaps gcc got updated to fix spurious errors recently [03:42] Clearly not, because mir just failed to build in the PPA again. [04:47] Huh. [04:47] I wonder how that builds on raring? [04:47] std::cerr should not be defined in [05:07] RAOF, ping [05:07] tvoss: Pong. [05:09] RAOF, good morning :) how is it going? [05:09] Fine! [05:09] It looks like my trivial patch makes Mir build on saucy again, so I can start getting rid of the ugly orange pointer in unity-system-compositor ☺ [05:10] \o/ [05:10] RAOF, did you see the mail I forwarded you? :) [05:10] olli, good morning :) [05:11] good morning gentlemen [05:11] tvoss: The sabdfl experiences with unity-system-compositor + XMir? [05:11] RAOF, yup [05:11] RAOF, that was good :) [05:11] RAOF, I think he ran without hw accel: saucy! [05:11] OpenGL vendor string: VMware, Inc. [05:11] OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 256 bits) [05:11] OpenGL version string: 2.1 Mesa 9.2.0-devel [05:11] OpenGL shading language version string: 1.30 [05:11] OpenGL extensions: [05:11] Hm. [05:12] gm morphis [05:12] In my experience that happens when lightdm fails to set up the drm permissions properly. [05:12] RAOF, yup [05:13] The output of “LIBGL_DEBUG=verbose glxinfo” is the a diagnostic in that case; it'll generally say "i965: failed to open drm device: EPERM” or words to that effect. [05:14] RAOF, sabdfl sent me his Xorg.log, just forwarded it to you [05:15] Hm. That doesn't seem to be an xmir session. [05:15] RAOF, yup, that's what I was thinking, too :) [05:31] RAOF: So you really think a mir_set_cursor_image() is the right solution to use hardware cursors with xmir? [05:31] I can't think of a better one. And general cursor management/theming should be kept out of the server [05:32] duflu: Well, xmir certainly needs *some* way of setting the cursor image. It doesn't necessarily have to be ‘hand a blob of pixels to Mir’, but that's a reasonably simple first go. [05:33] Yeah. I noticed GBM will fail unless you give it precisely 64x64 but that's a detail that can be hidden behind the API [05:35] RAOF: Or should the cursor be a surface to take advantage of IPC?... :) [05:36] Hmm, actually I'm not sure that's useful. Certainly more complex [05:36] RAOF, duflu why don't we enumerate different cursor types for a first cut, and make it more configurable in the future? [05:37] tvoss: Not even types. Just leave it up to the toolkit to upload an image when it wants a different one [05:37] I thought [05:38] Hmm, though that makes resizing cursor management different when building a shell [05:38] -different + difficult [05:38] duflu, right, it exposes a lot of internals to the client [05:38] The other option would be to treat the hw cursor as an overlay. [05:38] duflu, I think it makes more sense for the shell to decide the actual pixels of the cursor, and the client is able to choose from a pre-defined set [05:39] tvoss: I don't believe that works for XMir; I'm pretty sure some part of the X stack expects to be able to do arbitrary cursors. [05:39] Although if the shell is an internal client then the mir_set_cursor_image() works still [05:39] RAOF, ack, fully understood [05:39] duflu, exactly [05:40] I'm trying to avoid (1) having an enum of cursor types and (2) managing them in the server [05:41] duflu, I guess I would like to understand why you want to avoid an enum. Got a use-case/example for me? [05:41] Not that I'm working on cursors at all right now [05:41] tvoss: It's about limiting the functionality and responsibility of the server [05:41] A shell will need "types" but the core server library not [05:42] A touch shell for example won't need anything. Depends on the shell. [05:42] duflu, fair point, but what is exposed to the client? [05:42] If we knew how we were handling overlays, this *could* be done with overlay surfaces. [05:43] tvoss: There will be a set_cursor_image() type function regardless but I'm trying to avoid the need for a set_cursor_type() in the core client API. It can go elsewhere. [05:44] duflu, but how do you prevent a client from setting an arbitrary cursor image? [05:44] duflu, that will break consistency, wouldn't it? [05:44] tvoss: You don't. Clients are always allowed to, and some really need it [05:44] Some apps will break otherwise [05:44] You don't, but it can only control its cursor image while said cursor image is over one of its surfaces. [05:44] (Or is otherwise owned by said surface, such as in a drag and drop operation) [05:45] RAOF: Yeah then you end up with the ugly situation that X has where the arrow is different depending on the window :( [05:45] duflu, RAOF exactly, that's what I'm afraid of [05:46] I'm not sure that's avoidable. [05:46] OK. I guess the client API is already gathering very specific enums (e.g. surface type/state) already. Why now cursors too [05:46] -now +not [05:47] RAOF, duflu why don't we say enum first, mapping to the generic function, and we will see how far we can get with only an enum exposed to clients? [05:47] Some clients *are* going to want a pixel-perfect representation of their specific cursor (image manipulation programs are particularly fine candidates for this) [05:48] Also, games. [05:48] RAOF, fair point [05:48] Games tend to use their own texturing for cursors. Not hardware or display server cursors [05:48] RAOF, is there value in only allowing set_cursor_image for fullscreen surfaces? [05:49] duflu: You've not noticed the “Use hardware cursor” option that many games have? [05:49] No [05:49] In my experience it's quite common. [05:50] I'm pretty sure Mass Effect had it, I seem to recall XCom having it, Civ 5 having it, … [05:51] Oh I totally agree you need to be able to set an arbitrary custom cursor for some apps anyway [05:54] tvoss: re: fullscreen surfaces only - I don't know. [05:55] tvoss: I'm not sure that the situation we're trying to avoid - randomly different cursor themes for different windows - is best solved by not allowing different cursor themes. [05:56] I don't think it's a significant problem in X anymore. I think the solution is to make it easier to do right thing than the wrong thing, which I think is basiacally equivalent to saying ‘make sure the toolkits do the right thing by default’ [06:06] Grr. [06:06] Why do we build with -NDEBUG? [06:08] RAOF: I have a fix [06:08] Just proposing now [06:09] duflu: For the whole shebang, or jsut teh NDEBUG bit? [06:10] RAOF: For everything. [06:10] Hurray. [06:10] Allow me to approve that post-haste. [06:10] Though now I notice that the debuilt tests are failing. Don't fail otherwise on saucy :/ [06:12] RAOF: Not just proposing yet :/ [06:12] Well, that'll give me time to handle the mesa sru for mlankhorst then :) [06:59] RAOF: Sorry. Something so simple should not have taken so long... https://code.launchpad.net/~vanvugt/mir/saucy-build/+merge/169108 [07:10] Just to make sure everyone not on mir list knows [07:10] will be out in the morning at the dentist :) [07:10] :( really [07:11] racarr: enjoy :P [07:11] alf_: you will eat some candies, thinking about him? [07:13] didrocks: :) [07:14] Chocolate! [07:14] racarr: Oh, iff you're still here - what bit of Mir infrastructure do I need to inject to get unity-system-compositor to eat input? [07:15] I guess I'm kind of surprised that it's not eating input [07:15] we still have to disable control sequences [07:15] maybe the unity-system-compositor configuration [07:15] removes input? [07:17] it doesn't [07:17] look like it ;) um [07:18] not sure on the top of my head [07:25] racarr: Ta :) [07:25] racarr: The other possibility is that it's fixed in a later Mir than has built for saucy :) [07:26] * RAOF goes baby-feeding. [07:45] alf_, ping [07:46] tvoss: pong [08:03] robert_ancell, ping [08:03] tvoss, hello [08:15] yay, I can do a full dist-upgrade now without it trying to remove everything :) [08:22] robert_ancell, \o/ [08:23] RAOF, damn, when did mesa become such a massive package? [08:23] 49.4M! [08:28] robert_ancell: There's a “don't statically link 10MB worth of stuff into every DRI driver” patch that I haven't applied to the PPA packages. That makes it somewhat smaller ;) [08:33] robert_ancell: Sorry, I just realized that we have a meeting just when I've a physio booked. [08:33] alan_g, can you do it now? [08:33] robert_ancell: yes === alan_g is now known as alan_g|physio [09:17] tvoss, I can confirm you do get a big ugly orange cursor :) [09:18] tvoss, did it work for you? [09:18] robert_ancell, now: yes, but it hang on boot an hour ago [09:18] robert_ancell, argh [09:19] tvoss, part of the problem there might be we don't have the more aggressive plymouth changes that went into Ubuntu after we forked the packaging [09:19] (upstart changes) [09:20] and Mir+Plymouth don't play so well together as X+Plymouth (which already isn't very well) [09:20] robert_ancell, so we should pull them over then [09:22] tvoss, the changes are 1.6.0-0ubuntu2.1 if you want to test [09:22] I'm making a lightdm release tomorrow, was planning on syncing all the packaging then [09:22] robert_ancell, great, thank you. Can you drop a mail to mir-devel once done? [09:23] tvoss, about what? [09:23] robert_ancell, when you synced the packages [09:24] that doesn't sound like a particularly interesting post... [09:26] bye all === alan_g|physio is now known as alan_g === mmrazik is now known as mmrazik|lunch [10:50] alf_: fix-1189443 had merge conflicts when you approved. (I've just pushed resolution) [10:52] alan_g: ok === mmrazik|lunch is now known as mmrazik [11:25] alan_g: @saucy-build, what I take from your comment, is that it would be even better for us to remove this test (since it is testing a precondition) [11:26] alf_: I'd be happy with that too. (And also, separately, with you suggestion of a MIR_ASSERT) [11:27] "It is your problem if you pass me nullptr - don't rely on ME to check it!" [11:29] * alan_g remembers days of getting bug reports "this one's yours - it is asserting in your code..." [11:30] alf_: care to recheck fix-1189443? [11:31] alan_g: sure [11:32] alf_: do you think the team needs a discussion on precondition checking on mir-devel? [11:37] hikiko: it looks like it should be quick to fix and land https://code.launchpad.net/~hikiko/mir/mir.dest-tmp/+merge/168934 [11:40] alan_g: Would it be worth to put these guidelines in our hacking guide? If so, we can use that as our starting point for a discussion. Otherwise, mailing list works fine, too. [11:43] alf_: I was wondering how close to agreement we (as a team) are. I know tvoss wasn't in agreement with me when he added the tests. [11:44] alan_g, enlighten me please :) [11:44] * alan_g wonders "hacking" or "coding guidelines" [11:44] tvoss: about writing tests for the reporting of precondition violations [11:44] alan_g: ok, if you suspect there may be disagreement, the ML sounds like a good place to start [11:45] tvoss: see discussion on https://code.launchpad.net/~vanvugt/mir/saucy-build/+merge/169108 [11:48] alan_g, that's what I am doing now [11:49] cross compiling and fixing [11:49] hikiko: I hope you don't feel I'm nagging. ;) [11:49] alan_g: "coding guidelines" is a better match, if we create it we should also move "Error handling strategy" from HACKING [11:50] * alan_g decides to try saucy again [11:50] haha no alan_g :) better to finish with that before I go to something new.. I don't like to see it there either [11:50] alan_g, ENOCONTEXT :) [11:50] alan_g, gimme a few [11:51] tvoss: it is not an important use of your time [11:51] alan_g, okay, cool :) from a quick glance: I'm as convinced as alf :) [11:51] (just satisfying your curiosity) === pete-woods is now known as pete-woods-lunch === alan_g is now known as alan_g|lunch [12:55] :( [12:55] When are packages coming for unity next + mir [13:01] greyback, can you give gotwig some eta for unity next + mir packages? [13:02] tvoss, gotwig: give me 2 hours to build them and verify them [13:02] greyback, \o/ [13:02] * tvoss wants to buy beers for greyback [13:02] alcohol free beers ;D [13:03] I am just too stupid to compile all dat unity greatness *.* [13:03] I finished it, but when I start it via ./run (in X session) I cant use any apps. What am I missing? [13:03] gotwig: ah, so you got shell working? [13:03] greyback, when you are going to release it as a package (and if it works) I am sure OMG! Ubuntu is going to do an article ;) [13:04] greyback, yeah, but no apps? [13:04] greyback, and also it didnt work with mir, for me [13:04] It said it cant load "ubuntu" [13:04] gotwig: we've not got the apps working with shell yet [13:04] there's a bit more to do there [13:04] than I manually changed it to "ubuntumir" in the run file, but it didnt work either [13:05] lemme see, things changed on Tuesday and I'm not up to speed [13:05] greyback, what do you mean? I cant use Unity Next apps in Mir? [13:05] I got segmentation fault [13:05] as the error [13:05] gotwig: not yet. Unity shell and Mir need more development to support applications and window management of those apps [13:06] gotwig: we've got work yet to do. [13:06] greyback, so the dude on youtube is a liar ;X? [13:07] gotwig: what was the link again? Let me check it [13:07] https://www.youtube.com/watch?v=E9AzRxsnfTE [13:08] oh, there are no apps ;D just screenshots I guess? [13:09] gotwig: ah, I see it. In that video, it was running Unity with the fake built-in apps, a feature we only use for testing. [13:09] gotwig: exactly [13:09] gotwig: proper app support is coming, but will be a few weeks before all the bits & pieces connect [13:10] ok ;X [13:10] which advantages has using Mir right now for me as a developer... [13:10] gotwig: sorry for the confusion, I totally see where you're coming from === alan_g|lunch is now known as alan_g [13:10] how native are X applications going to feel? [13:11] They cant fit in the new UI :X [13:11] gotwig: for an app developer point of view, you should not need to care about Mir at all. If you write in Qt, everything will work exactly as they do under X [13:11] "without X bindings" [13:11] gotwig, to pick up from yesterday: if you are doing a gtk app, and someone wires up gtk to Mir, you don't need to worry [13:12] gotwig, even if not, we will have a rootless xserver that is fired up on demand for apps that talk X. But that's not there, yet [13:12] but GTK is so primitive, when you compare it to QT :/ [13:12] gotwig, then why not learn qt? [13:12] C++ .. ouch [13:12] its so different [13:13] gotwig, why not do qml then? [13:13] gotwig, easy to get started with [13:14] gotwig, and learning c++ is always a good idea :) [13:16] alf_, can you point me to the adjusted x driver branches? [13:22] learning c++ is a lifetime journey [13:24] tvoss: https://code.launchpad.net/~mir-team/* [13:35] alan_g, agreed, but every journey has a start [14:36] Good morning! (for 10 minutes before I go to the dentist) [14:45] Keep smiling === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:02] ahah, dentists [15:03] yeah, racarr gets all the fun ... mean ... [15:05] I was in for a bit of a shock the last time I went - everyone at that clinic had quit and all the staff were replaced by people who ... looked like they might also pass as part time models [15:05] it was a bit surreal [15:32] I broke my 13.10 :/ [15:52] with ms::Surface or msh::Surface, would anyone object to putting a pure virtual interface around those classes? they're kinda ballooning as a concrete class === mmrazik is now known as mmrazik|afk [15:54] kdub: ms::Surface really ought to be a private implementation class - not an interface [15:55] * alan_g thinks msh::Surface is a mess and doesn't know what to make of it [15:55] yeah, i guess in carving out a signal path for the swapinterval0 ipc message, i had to cross the "ms/msh::surface swamp" [15:55] as I've begun to think of it :) [15:56] \o/ (someone else thinks there's a problem there.) [15:57] kdub: we should hatch a strategy for draining the swamp. Not sure "putting an interface around" is the right answer though. [15:58] yeah, i'm just trying to find a way to drive the interfaces in the tests [15:58] and they're not very mockable without interfaces [16:00] I share your pain [16:03] kdub: isn't the comment at the top of ms::Surface still true? Because if it is I can't see an interface helping you. [16:05] well, i think that the inheritance from both Renderable and SurfaceTarget might need re-evaluation [16:06] Oh? [16:06] from what I see, we're just doing it because we don't have a 'surface state' object that is useful to both the input and graphics world [16:07] like, the compositor needs a 'surface state' (where is this in the scene graph) as well as some access to the graphics buffer [16:07] and the input needs access to that same state, as well as some input objects [16:07] but we use multiple inheritance to jam all that together into ms::Surface [16:08] Do you have something against multiple inheritance?! [16:09] not generally :) [16:10] We have an object that is useful to the graphics (implements Renderable) and input (implements SurfaceTarget). Why is that not reasonable? [16:10] Where does "jamming" come into it? [16:10] (Not saying you're wrong - just want to understand) [16:12] i was just thinking that if the SurfaceStack held an object that held 3 things (graphics, input, state) and handed out (graphics, state) to the compositor and (input, state) to the input manager [16:13] then that object would be analogous to msh::Surface in our current code [16:13] "state" being? [16:14] "this surface's place in the world", position, size, transformation, etc [16:17] So, ms::Surface is that object, that Renderable is (graphics, state) and SurfaceTarget is (input, state)? [16:18] right [16:18] and then we could present just the state to the shell interfaces [16:19] (which don't exist, but the shell probably needs a MVC-like view of the surfaces) [16:19] racarr^^ [16:19] oh, he's at the dentist [16:20] kdub: OK, that would be a new SurfaceMark2 interface in ms [16:20] * alan_g hopes that name isn't taken seriously [16:22] alan_g, right. that concern about a view of the 'state' for the shell's purposes just comes from [16:23] i don't see how a shell object would access that info currently [16:23] * kdub is really opening up a can of worms today :P [16:23] I'm happy with that idea. [16:25] That was the extent of your changes to ms::Surface? What about the mess^b msh::Surface? [16:56] Back! [16:57] alan_g, sorry, got distracted [16:58] kdub: np - I'm about to leave anyway. racarr can take over discussion of msh::Surface [17:01] *blank* [17:03] racarr: kdub has decided to start draining the "msh::Surface" swamp [17:03] racarr: kdub has decided to start draining the "msh::Surface swamp" === alan_g is now known as alan_g|life [17:13] just start thinking about it :) [19:45] yay, my mesa improvements work... now to figure out how to show raof on github [22:13] kdub: Sorry I dropped out of our conversation earlier...I got distracted by the stuff I am doing with input acceptance tests [22:13] think I just finally got a test fixture I am happy with, at least the first part...trying to make it trivial to write input tests with multiple clients and synthetic input [22:16] np, i got distracted cleaning up mesa's mir platform :) [22:18] its a party all around XD [22:55] RAOF, ping [22:57] kdub: Yo. [22:58] Mesa? Woot! [22:58] RAOF, i made the egl dri2 driver upstreamable while adding swapinterval0 hooks [22:58] well, hopefully more upstreamable [22:58] i submitted a pull-request on github with the cleanup [22:58] Less /* do stuff */? ☺ [22:58] Hurray! [22:59] basically, we now have a native type for egl displays and surfaces [22:59] and i removed 'mir_client_library.h" from the platform_mir.c [23:00] it pairs with lp:~kdub/mir/gbm-cleanup [23:00] so hopefully we can get those both reviewed and land them at the same time [23:00] maybe monday :) [23:31] could this be why I'm getting an error "Can't create a surface" [23:32] "Can't initialize EGL" ? [23:33] It's thrown when calling mir_surface_is_valid which checks the protocol buffer for an error and I'm having trouble figuring out what actually sets this error. [23:42] nall: That's what happens when the call to create a surface fails. [23:43] nall: In the past there was a bug with colour formats that caused that sort of problem. The other option is that you've got a mismatched mesa version, since Mir requires some patches to work. [23:51] The method I used for installation was to install the pre-compiled packages first to ensure I had the right mesa libraries. The I built from source installing with prefix=/usr to overwrite the precompiled mir packages. [23:56] I'm trying to get it to work on VMWare. I'm building from source because I had to add vmwgfx (VMWare's drm driver) to a drivers list to fix a bug when calling drmOpen. On doing that it loads the driver but fails to create the surface. [23:59] nall: Oh, cool.