| racarr | kdub: Oh no XD | 00:27 |
|---|---|---|
| racarr | well you can launch them but not from unity | 00:27 |
| 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:28 |
| racarr | its coming together though :) | 00:29 |
| kdub | still cool :) | 00:40 |
| 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:41 |
| RAOF | kdub: Your EGL platform detection isn't working; it's falling back to X11 and failing. | 00:42 |
| RAOF | What's your mesa driver for? | 00:46 |
| kdub | an i965 card | 00:47 |
| kdub | does "EGL_PLATFORM=mir" work? | 00:47 |
| 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 | 00:48 |
| 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:16 |
| 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= | 01:17 |
| RAOF | It's remarkable how quickly you learn to ignore the huge stomping orange arrow on your screen. | 02:04 |
| duflu | Luckily it is moveable :) | 02:11 |
| RAOF | duflu: Not once XMir starts :) | 02:33 |
| 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:18 |
| duflu | Doesn't appear so | 03:19 |
| 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:20 |
| 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:21 |
| RAOF | Clearly not, because mir just failed to build in the PPA again. | 03:42 |
| RAOF | Huh. | 04:47 |
| RAOF | I wonder how that builds on raring? | 04:47 |
| RAOF | std::cerr should not be defined in <fstream> | 04:47 |
| tvoss | RAOF, ping | 05:07 |
| RAOF | tvoss: Pong. | 05:07 |
| 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:09 |
| tvoss | \o/ | 05:10 |
| tvoss | RAOF, did you see the mail I forwarded you? :) | 05:10 |
| tvoss | olli, good morning :) | 05:10 |
| 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! | 05:11 |
| tvoss | <sabdfl> OpenGL vendor string: VMware, Inc. | 05:11 |
| tvoss | <sabdfl> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.2, 256 bits) | 05:11 |
| tvoss | <sabdfl> OpenGL version string: 2.1 Mesa 9.2.0-devel | 05:11 |
| tvoss | <sabdfl> OpenGL shading language version string: 1.30 | 05:11 |
| tvoss | <sabdfl> OpenGL extensions: | 05:11 |
| RAOF | Hm. | 05:11 |
| 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:12 |
| 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:13 |
| tvoss | RAOF, sabdfl sent me his Xorg.log, just forwarded it to you | 05:14 |
| RAOF | Hm. That doesn't seem to be an xmir session. | 05:15 |
| tvoss | RAOF, yup, that's what I was thinking, too :) | 05:15 |
| 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:31 |
| 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:32 |
| 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:33 |
| duflu | RAOF: Or should the cursor be a surface to take advantage of IPC?... :) | 05:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| duflu | I'm trying to avoid (1) having an enum of cursor types and (2) managing them in the server | 05:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| RAOF | I'm pretty sure Mass Effect had it, I seem to recall XCom having it, Civ 5 having it, … | 05:50 |
| duflu | Oh I totally agree you need to be able to set an arbitrary custom cursor for some apps anyway | 05:51 |
| RAOF | tvoss: re: fullscreen surfaces only - I don't know. | 05:54 |
| 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:55 |
| 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’ | 05:56 |
| RAOF | Grr. | 06:06 |
| RAOF | Why do we build with -NDEBUG? | 06:06 |
| duflu | RAOF: I have a fix | 06:08 |
| duflu | Just proposing now | 06:08 |
| RAOF | duflu: For the whole shebang, or jsut teh NDEBUG bit? | 06:09 |
| 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:10 |
| duflu | RAOF: Not just proposing yet :/ | 06:12 |
| RAOF | Well, that'll give me time to handle the mesa sru for mlankhorst then :) | 06:12 |
| duflu | RAOF: Sorry. Something so simple should not have taken so long... https://code.launchpad.net/~vanvugt/mir/saucy-build/+merge/169108 | 06:59 |
| 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:10 |
| alf_ | racarr: enjoy :P | 07:11 |
| didrocks | alf_: you will eat some candies, thinking about him? | 07:11 |
| alf_ | didrocks: :) | 07:13 |
| 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:14 |
| 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:15 |
| racarr | it doesn't | 07:17 |
| racarr | look like it ;) um | 07:17 |
| racarr | not sure on the top of my head | 07:18 |
| 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:25 |
| * RAOF goes baby-feeding. | 07:26 | |
| tvoss | alf_, ping | 07:45 |
| alf_ | tvoss: pong | 07:46 |
| tvoss | robert_ancell, ping | 08:03 |
| robert_ancell | tvoss, hello | 08:03 |
| robert_ancell | yay, I can do a full dist-upgrade now without it trying to remove everything :) | 08:15 |
| tvoss | robert_ancell, \o/ | 08:22 |
| robert_ancell | RAOF, damn, when did mesa become such a massive package? | 08:23 |
| robert_ancell | 49.4M! | 08:23 |
| 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:28 |
| 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 | 08:33 |
| === alan_g is now known as alan_g|physio | ||
| robert_ancell | tvoss, I can confirm you do get a big ugly orange cursor :) | 09:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:22 |
| robert_ancell | tvoss, about what? | 09:23 |
| tvoss | robert_ancell, when you synced the packages | 09:23 |
| robert_ancell | that doesn't sound like a particularly interesting post... | 09:24 |
| robert_ancell | bye all | 09:26 |
| === alan_g|physio is now known as alan_g | ||
| === mmrazik is now known as mmrazik|lunch | ||
| alan_g | alf_: fix-1189443 had merge conflicts when you approved. (I've just pushed resolution) | 10:50 |
| alf_ | alan_g: ok | 10:52 |
| === mmrazik|lunch is now known as mmrazik | ||
| 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:25 |
| alan_g | alf_: I'd be happy with that too. (And also, separately, with you suggestion of a MIR_ASSERT) | 11:26 |
| alan_g | "It is your problem if you pass me nullptr - don't rely on ME to check it!" | 11:27 |
| * alan_g remembers days of getting bug reports "this one's yours - it is asserting in your code..." | 11:29 | |
| alan_g | alf_: care to recheck fix-1189443? | 11:30 |
| alf_ | alan_g: sure | 11:31 |
| alan_g | alf_: do you think the team needs a discussion on precondition checking on mir-devel? | 11:32 |
| 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:37 |
| 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:40 |
| 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:43 |
| 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:44 |
| alan_g | tvoss: see discussion on https://code.launchpad.net/~vanvugt/mir/saucy-build/+merge/169108 | 11:45 |
| hikiko | alan_g, that's what I am doing now | 11:48 |
| 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:49 |
| * 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:50 |
| 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) | 11:51 |
| === pete-woods is now known as pete-woods-lunch | ||
| === alan_g is now known as alan_g|lunch | ||
| gotwig | :( | 12:55 |
| gotwig | When are packages coming for unity next + mir | 12:55 |
| tvoss | greyback, can you give gotwig some eta for unity next + mir packages? | 13:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| greyback | gotwig: we've got work yet to do. | 13:06 |
| gotwig | greyback, so the dude on youtube is a liar ;X? | 13:06 |
| greyback | gotwig: what was the link again? Let me check it | 13:07 |
| gotwig | https://www.youtube.com/watch?v=E9AzRxsnfTE | 13:07 |
| gotwig | oh, there are no apps ;D just screenshots I guess? | 13:08 |
| 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:09 |
| 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 |
| === alan_g|lunch is now known as alan_g | ||
| gotwig | how native are X applications going to feel? | 13:10 |
| 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:11 |
| 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:12 |
| tvoss | gotwig, why not do qml then? | 13:13 |
| tvoss | gotwig, easy to get started with | 13:13 |
| tvoss | gotwig, and learning c++ is always a good idea :) | 13:14 |
| tvoss | alf_, can you point me to the adjusted x driver branches? | 13:16 |
| alan_g | learning c++ is a lifetime journey | 13:22 |
| alf_ | tvoss: https://code.launchpad.net/~mir-team/* | 13:24 |
| tvoss | alan_g, agreed, but every journey has a start | 13:35 |
| racarr | Good morning! (for 10 minutes before I go to the dentist) | 14:36 |
| alan_g | Keep smiling | 14:45 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| smspillaz | ahah, dentists | 15:02 |
| ogra_ | yeah, racarr gets all the fun ... mean ... | 15:03 |
| 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:05 |
| gotwig | I broke my 13.10 :/ | 15:32 |
| 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:52 |
| === mmrazik is now known as mmrazik|afk | ||
| alan_g | kdub: ms::Surface really ought to be a private implementation class - not an interface | 15:54 |
| * 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:55 |
| alan_g | \o/ (someone else thinks there's a problem there.) | 15:56 |
| alan_g | kdub: we should hatch a strategy for draining the swamp. Not sure "putting an interface around" is the right answer though. | 15:57 |
| 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 | 15:58 |
| alan_g | I share your pain | 16:00 |
| 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:03 |
| kdub | well, i think that the inheritance from both Renderable and SurfaceTarget might need re-evaluation | 16:05 |
| 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:06 |
| 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:07 |
| alan_g | Do you have something against multiple inheritance?! | 16:08 |
| kdub | not generally :) | 16:09 |
| 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:10 |
| 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:12 |
| kdub | then that object would be analogous to msh::Surface in our current code | 16:13 |
| alan_g | "state" being? | 16:13 |
| kdub | "this surface's place in the world", position, size, transformation, etc | 16:14 |
| alan_g | So, ms::Surface is that object, that Renderable is (graphics, state) and SurfaceTarget is (input, state)? | 16:17 |
| kdub | right | 16:18 |
| kdub | and then we could present just the state to the shell interfaces | 16:18 |
| 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:19 |
| 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:20 | |
| kdub | alan_g, right. that concern about a view of the 'state' for the shell's purposes just comes from | 16:22 |
| 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:23 |
| alan_g | That was the extent of your changes to ms::Surface? What about the mess^b msh::Surface? | 16:25 |
| racarr | Back! | 16:56 |
| kdub | alan_g, sorry, got distracted | 16:57 |
| alan_g | kdub: np - I'm about to leave anyway. racarr can take over discussion of msh::Surface | 16:58 |
| racarr | *blank* | 17:01 |
| 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:03 |
| === alan_g is now known as alan_g|life | ||
| kdub | just start thinking about it :) | 17:13 |
| kdub | yay, my mesa improvements work... now to figure out how to show raof on github | 19:45 |
| 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:13 |
| kdub | np, i got distracted cleaning up mesa's mir platform :) | 22:16 |
| racarr | its a party all around XD | 22:18 |
| kdub | RAOF, ping | 22:55 |
| RAOF | kdub: Yo. | 22:57 |
| 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:58 |
| 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 | 22:59 |
| 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:00 |
| nall | could this be why I'm getting an error "Can't create a surface" | 23:31 |
| nall | "Can't initialize EGL" ? | 23:32 |
| 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:33 |
| RAOF | nall: That's what happens when the call to create a surface fails. | 23:42 |
| 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:43 |
| 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:51 |
| 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:56 |
| RAOF | nall: Oh, cool. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!