[00:27] <racarr> kdub: Oh no XD
[00:27] <racarr> well you can launch them but not from unity
[00:28] <RAOF> How about switching?
[00:28] <RAOF> ☺
[00:28] <racarr> RAOF: God you guys are so demanding
[00:28] <racarr> how much does a shell really have to do!?!?!?!
[00:29] <racarr> its coming together though :)
[00:40] <kdub> still cool :)
[00:41] <kdub> hey RAOF, i built my own mesa driver
[00:41] <kdub> but get this error:
[00:41] <kdub> [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] <RAOF> kdub: Your EGL platform detection isn't working; it's falling back to X11 and failing.
[00:46] <RAOF> What's your mesa driver for?
[00:47] <kdub> an i965 card
[00:47] <kdub> does "EGL_PLATFORM=mir" work?
[00:48] <racarr> 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] <racarr> so I'm rebooting to OSX
[00:48] <racarr> Bye!
[00:48] <racarr> :p
[01:16] <RAOF> kdub: That should work, I think.
[01:16] <RAOF> kdub: As long as you actually built the mir platform; you need to explicitly enable it.
[01:17] <RAOF> 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] <RAOF> Is what I use; you probably want to replace the --with-gallium-drivers bit to --with-gallium-drivers=
[02:04] <RAOF> It's remarkable how quickly you learn to ignore the huge stomping orange arrow on your screen.
[02:11] <duflu> Luckily it is moveable :)
[02:33] <RAOF> duflu: Not once XMir starts :)
[03:18] <duflu> robert_ancell: Umm saucy just builds mir without modification. There are lots of notes/warnings to fix but no errors.
[03:18] <robert_ancell> duflu, all the tests pass?
[03:18] <duflu> Yep
[03:18] <robert_ancell> Did it build with -DNDEBUG?
[03:19] <duflu> Doesn't appear so
[03:20] <robert_ancell> duflu, did you run cmake from scratch?
[03:20] <duflu> I ran it per usual. What's "from scratch"?
[03:20] <robert_ancell> duflu, i.e. cleared out existing build
[03:21] <duflu> robert_ancell: Yes it's a fresh machine
[03:21] <duflu> from scratch
[03:21] <robert_ancell> and definitely gcc 4.8?
[03:21] <duflu> Yep
[03:21] <robert_ancell> weird
[03:21] <duflu> gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1)
[03:21] <duflu> Perhaps gcc got updated to fix spurious errors recently
[03:42] <RAOF> Clearly not, because mir just failed to build in the PPA again.
[04:47] <RAOF> Huh.
[04:47] <RAOF> I wonder how that builds on raring?
[04:47] <RAOF> std::cerr should not be defined in <fstream>
[05:07] <tvoss> RAOF, ping
[05:07] <RAOF> tvoss: Pong.
[05:09] <tvoss> RAOF, good morning :) how is it going?
[05:09] <RAOF> Fine!
[05:09] <RAOF> 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] <tvoss> \o/
[05:10] <tvoss> RAOF, did you see the mail I forwarded you? :)
[05:10] <tvoss> olli, good morning :)
[05:11] <olli> good morning gentlemen
[05:11] <RAOF> tvoss: The sabdfl experiences with unity-system-compositor + XMir?
[05:11] <tvoss> RAOF, yup
[05:11] <olli> RAOF, that was good :)
[05:11] <tvoss> RAOF, I think he ran without hw accel: <sabdfl> saucy!
 OpenGL vendor string: VMware, Inc.
 OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 256 bits)
 OpenGL version string: 2.1 Mesa 9.2.0-devel
 OpenGL shading language version string: 1.30
 OpenGL extensions:
[05:11] <RAOF> Hm.
[05:12] <olli> gm morphis
[05:12] <RAOF> In my experience that happens when lightdm fails to set up the drm permissions properly.
[05:12] <tvoss> RAOF, yup
[05:13] <RAOF> 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] <tvoss> RAOF, sabdfl sent me his Xorg.log, just forwarded it to you
[05:15] <RAOF> Hm. That doesn't seem to be an xmir session.
[05:15] <tvoss> RAOF, yup, that's what I was thinking, too :)
[05:31] <duflu> RAOF: So you really think a mir_set_cursor_image() is the right solution to use hardware cursors with xmir?
[05:31] <duflu> I can't think of a better one. And general cursor management/theming should be kept out of the server
[05:32] <RAOF> 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] <duflu> 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] <duflu> RAOF: Or should the cursor be a surface to take advantage of IPC?... :)
[05:36] <duflu> Hmm, actually I'm not sure that's useful. Certainly more complex
[05:36] <tvoss> RAOF, duflu why don't we enumerate different cursor types for a first cut, and make it more configurable in the future?
[05:37] <duflu> tvoss: Not even types. Just leave it up to the toolkit to upload an image when it wants a different one
[05:37] <duflu> I thought
[05:38] <duflu> Hmm, though that makes resizing cursor management different when building a shell
[05:38] <duflu> -different + difficult
[05:38] <tvoss> duflu, right, it exposes a lot of internals to the client
[05:38] <RAOF> The other option would be to treat the hw cursor as an overlay.
[05:38] <tvoss> 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] <RAOF> 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] <duflu> Although if the shell is an internal client then the mir_set_cursor_image() works still
[05:39] <tvoss> RAOF, ack, fully understood
[05:39] <tvoss> duflu, exactly
[05:40] <duflu> I'm trying to avoid (1) having an enum of cursor types and (2) managing them in the server
[05:41] <tvoss> duflu, I guess I would like to understand why you want to avoid an enum. Got a use-case/example for me?
[05:41] <duflu> Not that I'm working on cursors at all right now
[05:41] <duflu> tvoss: It's about limiting the functionality and responsibility of the server
[05:41] <duflu> A shell will need "types" but the core server library not
[05:42] <duflu> A touch shell for example won't need anything. Depends on the shell.
[05:42] <tvoss> duflu, fair point, but what is exposed to the client?
[05:42] <RAOF> If we knew how we were handling overlays, this *could* be done with overlay surfaces.
[05:43] <duflu> 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] <tvoss> duflu, but how do you prevent a client from setting an arbitrary cursor image?
[05:44] <tvoss> duflu, that will break consistency, wouldn't it?
[05:44] <duflu> tvoss: You don't. Clients are always allowed to, and some really need it
[05:44] <duflu> Some apps will break otherwise
[05:44] <RAOF> You don't, but it can only control its cursor image while said cursor image is over one of its surfaces.
[05:44] <RAOF> (Or is otherwise owned by said surface, such as in a drag and drop operation)
[05:45] <duflu> RAOF: Yeah then you end up with the ugly situation that X has where the arrow is different depending on the window :(
[05:45] <tvoss> duflu, RAOF exactly, that's what I'm afraid of
[05:46] <RAOF> I'm not sure that's avoidable.
[05:46] <duflu> OK. I guess the client API is already gathering very specific enums (e.g. surface type/state) already. Why now cursors too
[05:46] <duflu> -now +not
[05:47] <tvoss> 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] <RAOF> 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] <RAOF> Also, games.
[05:48] <tvoss> RAOF, fair point
[05:48] <duflu> Games tend to use their own texturing for cursors. Not hardware or display server cursors
[05:48] <tvoss> RAOF, is there value in only allowing set_cursor_image for fullscreen surfaces?
[05:49] <RAOF> duflu: You've not noticed the “Use hardware cursor” option that many games have?
[05:49] <duflu> No
[05:49] <RAOF> In my experience it's quite common.
[05:50] <RAOF> I'm pretty sure Mass Effect had it, I seem to recall XCom having it, Civ 5 having it, …
[05:51] <duflu> Oh I totally agree you need to be able to set an arbitrary custom cursor for some apps anyway
[05:54] <RAOF> tvoss: re: fullscreen surfaces only - I don't know.
[05:55] <RAOF> 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] <RAOF> 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] <RAOF> Grr.
[06:06] <RAOF> Why do we build with -NDEBUG?
[06:08] <duflu> RAOF: I have a fix
[06:08] <duflu> Just proposing now
[06:09] <RAOF> duflu: For the whole shebang, or jsut teh NDEBUG bit?
[06:10] <duflu> RAOF: For everything.
[06:10] <RAOF> Hurray.
[06:10] <RAOF> Allow me to approve that post-haste.
[06:10] <duflu> Though now I notice that the debuilt tests are failing. Don't fail otherwise on saucy :/
[06:12] <duflu> RAOF: Not just proposing yet :/
[06:12] <RAOF> Well, that'll give me time to handle the mesa sru for mlankhorst then :)
[06:59] <duflu> RAOF: Sorry. Something so simple should not have taken so long... https://code.launchpad.net/~vanvugt/mir/saucy-build/+merge/169108
[07:10] <racarr> Just to make sure everyone not on mir list knows
[07:10] <racarr> will be out in the morning at the dentist :)
[07:10] <racarr> :( really
[07:11] <alf_> racarr: enjoy :P
[07:11] <didrocks> alf_: you will eat some candies, thinking about him?
[07:13] <alf_> didrocks: :)
[07:14] <RAOF> Chocolate!
[07:14] <RAOF> 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] <racarr> I guess I'm kind of surprised that it's not eating input
[07:15] <racarr> we still have to disable control sequences
[07:15] <racarr> maybe the unity-system-compositor configuration
[07:15] <racarr> removes input?
[07:17] <racarr> it doesn't
[07:17] <racarr> look like it ;) um
[07:18] <racarr> not sure on the top of my head
[07:25] <RAOF> racarr: Ta :)
[07:25] <RAOF> 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] <tvoss> alf_, ping
[07:46] <alf_> tvoss: pong
[08:03] <tvoss> robert_ancell, ping
[08:03] <robert_ancell> tvoss, hello
[08:15] <robert_ancell> yay, I can do a full dist-upgrade now without it trying to remove everything :)
[08:22] <tvoss> robert_ancell, \o/
[08:23] <robert_ancell> RAOF, damn, when did mesa become such a massive package?
[08:23] <robert_ancell> 49.4M!
[08:28] <RAOF> 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] <alan_g> robert_ancell: Sorry, I just realized that we have a meeting just when I've a physio booked.
[08:33] <robert_ancell> alan_g, can you do it now?
[08:33] <alan_g> robert_ancell: yes
[09:17] <robert_ancell> tvoss, I can confirm you do get a big ugly orange cursor :)
[09:18] <robert_ancell> tvoss, did it work for you?
[09:18] <tvoss> robert_ancell, now: yes, but it hang on boot an hour ago
[09:18] <tvoss> robert_ancell, argh
[09:19] <robert_ancell> 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] <robert_ancell> (upstart changes)
[09:20] <robert_ancell> and Mir+Plymouth don't play so well together as X+Plymouth (which already isn't very well)
[09:20] <tvoss> robert_ancell, so we should pull them over then
[09:22] <robert_ancell> tvoss, the changes are 1.6.0-0ubuntu2.1 if you want to test
[09:22] <robert_ancell> I'm making a lightdm release tomorrow, was planning on syncing all the packaging then
[09:22] <tvoss> robert_ancell, great, thank you. Can you drop a mail to mir-devel once done?
[09:23] <robert_ancell> tvoss, about what?
[09:23] <tvoss> robert_ancell, when you synced the packages
[09:24] <robert_ancell> that doesn't sound like a particularly interesting post...
[09:26] <robert_ancell> bye all
[10:50] <alan_g> alf_: fix-1189443 had merge conflicts when you approved. (I've just pushed resolution)
[10:52] <alf_> alan_g: ok
[11:25] <alf_> 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] <alan_g> alf_: I'd be happy with that too. (And also, separately, with you suggestion of a MIR_ASSERT)
[11:27] <alan_g> "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] <alan_g> alf_: care to recheck fix-1189443?
[11:31] <alf_> alan_g: sure
[11:32] <alan_g> alf_: do you think the team needs a discussion on precondition checking on mir-devel?
[11:37] <alan_g> 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] <alf_> 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] <alan_g> 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] <tvoss> alan_g, enlighten me please :)
[11:44]  * alan_g wonders "hacking" or "coding guidelines"
[11:44] <alan_g> tvoss: about writing tests for the reporting of precondition violations
[11:44] <alf_> alan_g: ok, if you suspect there may be disagreement, the ML sounds like a good place to start
[11:45] <alan_g> tvoss: see discussion on https://code.launchpad.net/~vanvugt/mir/saucy-build/+merge/169108
[11:48] <hikiko> alan_g, that's what I am doing now
[11:49] <hikiko> cross compiling and fixing
[11:49] <alan_g> hikiko: I hope you don't feel I'm nagging. ;)
[11:49] <alf_> 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] <hikiko> 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] <tvoss> alan_g, ENOCONTEXT :)
[11:50] <tvoss> alan_g, gimme a few
[11:51] <alan_g> tvoss: it is not an important use of your time
[11:51] <tvoss> alan_g, okay, cool :) from a quick glance: I'm as convinced as alf :)
[11:51] <alan_g> (just satisfying your curiosity)
[12:55] <gotwig> :(
[12:55] <gotwig> When are packages coming for unity next + mir
[13:01] <tvoss> greyback, can you give gotwig some eta for unity next + mir packages?
[13:02] <greyback> tvoss, gotwig: give me 2 hours to build them and verify them
[13:02] <tvoss> greyback, \o/
[13:02]  * tvoss wants to buy beers for greyback
[13:02] <gotwig> alcohol free beers ;D
[13:03] <gotwig> I am just too stupid to compile all dat unity greatness *.*
[13:03] <gotwig> I finished it, but when I start it via ./run (in X session) I cant use any apps. What am I missing?
[13:03] <greyback> gotwig: ah, so you got shell working?
[13:03] <gotwig> 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] <gotwig> greyback, yeah, but no apps?
[13:04] <gotwig> greyback, and also it didnt work with mir, for me
[13:04] <gotwig> It said it cant load "ubuntu"
[13:04] <greyback> gotwig: we've not got the apps working with shell yet
[13:04] <greyback> there's a bit more to do there
[13:04] <gotwig> than I manually changed it to "ubuntumir" in the run file, but it didnt work either
[13:05] <greyback> lemme see, things changed on Tuesday and I'm not up to speed
[13:05] <gotwig> greyback, what do you mean? I cant use Unity Next apps in Mir?
[13:05] <gotwig> I got segmentation fault
[13:05] <gotwig> as the error
[13:05] <greyback> gotwig: not yet. Unity shell and Mir need more development to support applications and window management of those apps
[13:06] <greyback> gotwig: we've got work yet to do.
[13:06] <gotwig> greyback, so the dude on youtube is a liar ;X?
[13:07] <greyback> gotwig: what was the link again? Let me check it
[13:07] <gotwig> https://www.youtube.com/watch?v=E9AzRxsnfTE
[13:08] <gotwig> oh, there are no apps ;D just screenshots I  guess?
[13:09] <greyback> 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] <greyback> gotwig: exactly
[13:09] <greyback> gotwig: proper app support is coming, but will be a few weeks before all the bits & pieces connect
[13:10] <gotwig> ok ;X
[13:10] <gotwig> which advantages has using Mir right now for me as a developer...
[13:10] <greyback> gotwig: sorry for the confusion, I totally see where you're coming from
[13:10] <gotwig> how native are X applications going to feel?
[13:11] <gotwig> They cant fit in the new UI :X
[13:11] <greyback> 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] <gotwig> "without X bindings"
[13:11] <tvoss> 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] <tvoss> 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] <gotwig> but GTK is so primitive, when you compare it to QT :/
[13:12] <tvoss> gotwig, then why not learn qt?
[13:12] <gotwig> C++ .. ouch
[13:12] <gotwig> its so different
[13:13] <tvoss> gotwig, why not do qml then?
[13:13] <tvoss> gotwig, easy to get started with
[13:14] <tvoss> gotwig, and learning c++ is always a good idea :)
[13:16] <tvoss> alf_, can you point me to the adjusted x driver branches?
[13:22] <alan_g> learning c++ is a lifetime journey
[13:24] <alf_> tvoss: https://code.launchpad.net/~mir-team/*
[13:35] <tvoss> alan_g, agreed, but every journey has a start
[14:36] <racarr> Good morning! (for 10 minutes before I go to the dentist)
[14:45] <alan_g> Keep smiling
[15:02] <smspillaz> ahah, dentists
[15:03] <ogra_> yeah, racarr gets all the fun ... mean ...
[15:05] <smspillaz> 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] <smspillaz> it was a bit surreal
[15:32] <gotwig> I broke my 13.10 :/
[15:52] <kdub> 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
[15:54] <alan_g> 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] <kdub> 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] <kdub> as I've begun to think of it :)
[15:56] <alan_g> \o/ (someone else thinks there's a problem there.)
[15:57] <alan_g> kdub: we should hatch a strategy for draining the swamp. Not sure "putting an interface around" is the right answer though.
[15:58] <kdub> yeah, i'm just trying to find a way to drive the interfaces in the tests
[15:58] <kdub> and they're not very mockable without interfaces
[16:00] <alan_g> I share your pain
[16:03] <alan_g> 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] <kdub> well, i think that the inheritance from both Renderable and SurfaceTarget might need re-evaluation
[16:06] <alan_g> Oh?
[16:06] <kdub> 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] <kdub> 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] <kdub> and the input needs access to that same state, as well as some input objects
[16:07] <kdub> but we use multiple inheritance to jam all that together into ms::Surface
[16:08] <alan_g> Do you have something against multiple inheritance?!
[16:09] <kdub> not generally :)
[16:10] <alan_g> We have an object that is useful to the graphics (implements Renderable) and input (implements SurfaceTarget). Why is that not reasonable?
[16:10] <alan_g> Where does "jamming" come into it?
[16:10] <alan_g> (Not saying you're wrong - just want to understand)
[16:12] <kdub> 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] <kdub> then that object would be analogous to  msh::Surface in our current code
[16:13] <alan_g> "state" being?
[16:14] <kdub> "this surface's place in the world", position, size, transformation, etc
[16:17] <alan_g> So, ms::Surface is that object, that Renderable is (graphics, state) and SurfaceTarget is (input, state)?
[16:18] <kdub> right
[16:18] <kdub> and then we could present just the state to the shell interfaces
[16:19] <kdub> (which don't exist, but the shell probably needs a MVC-like view of the surfaces)
[16:19] <kdub> racarr^^
[16:19] <kdub> oh, he's at the dentist
[16:20] <alan_g> kdub: OK, that would be a new SurfaceMark2 interface in ms
[16:20]  * alan_g hopes that name isn't taken seriously
[16:22] <kdub> alan_g, right. that concern about a view of the 'state' for the shell's purposes just comes from
[16:23] <kdub> 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] <alan_g> I'm happy with that idea.
[16:25] <alan_g> That was the extent of your changes to ms::Surface? What about the mess^b msh::Surface?
[16:56] <racarr> Back!
[16:57] <kdub> alan_g, sorry, got distracted
[16:58] <alan_g> kdub: np - I'm about to leave anyway. racarr can take over discussion of msh::Surface
[17:01] <racarr> *blank*
[17:03] <alan_g> racarr: kdub has decided to start draining the "msh::Surface" swamp
[17:03] <alan_g> racarr: kdub has decided to start draining the "msh::Surface swamp"
[17:13] <kdub> just start thinking about it :)
[19:45] <kdub> yay, my mesa improvements work... now to figure out how to show raof on github
[22:13] <racarr> kdub: Sorry I dropped out of our conversation earlier...I got distracted by the stuff I am doing with input acceptance tests
[22:13] <racarr> 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] <kdub> np, i got distracted cleaning up mesa's mir platform :)
[22:18] <racarr> its a party all around XD
[22:55] <kdub> RAOF, ping
[22:57] <RAOF> kdub: Yo.
[22:58] <RAOF> Mesa? Woot!
[22:58] <kdub> RAOF, i made the egl dri2 driver upstreamable while adding swapinterval0 hooks
[22:58] <kdub> well, hopefully more upstreamable
[22:58] <kdub> i submitted a pull-request on github with the cleanup
[22:58] <RAOF> Less /* do stuff */? ☺
[22:58] <RAOF> Hurray!
[22:59] <kdub> basically, we now have a native type for egl displays and surfaces
[22:59] <kdub> and i removed 'mir_client_library.h" from the platform_mir.c
[23:00] <kdub> it pairs with lp:~kdub/mir/gbm-cleanup
[23:00] <kdub> so hopefully we can get those both reviewed and land them at the same time
[23:00] <kdub> maybe monday :)
[23:31] <nall> could this be why I'm getting an error "Can't create a surface"
[23:32] <nall> "Can't initialize EGL" ?
[23:33] <nall> 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] <RAOF> nall: That's what happens when the call to create a surface fails.
[23:43] <RAOF> 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] <nall> 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] <nall> 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] <RAOF> nall: Oh, cool.