| kode54 | heh, running mir as system compositor with X seems to be broken at the moment, at least with nouveau | 02:55 |
|---|---|---|
| === mhall119|away is now known as mhall119 | ||
| === IReboot is now known as 6JTAAJO6W | ||
| thomi | robert_ancell: ping? | 04:20 |
| robert_ancell | thomi, hello | 04:20 |
| thomi | robert_ancell: this may be a stupid question, but... in a mir (X-less) world, where is the keyboard keymap configured? | 04:20 |
| robert_ancell | thomi, I'm not sure | 04:21 |
| robert_ancell | thomi, racarr was looking into that I think | 04:21 |
| thomi | I guess racarr would know, but I suppose it's still the weekend for him | 04:21 |
| thomi | I'll grab him tomorrow, thanks | 04:21 |
| mlankhorst | kode54: worksforme, anything in dmesg? | 05:42 |
| RAOF | alf__: Good morning! | 06:40 |
| alf__ | RAOF: Good morning! | 06:40 |
| alf__ | RAOF: or rather, good afternoon | 06:40 |
| RAOF | :) | 06:40 |
| tvoss | Good morning :) | 06:47 |
| alf__ | tvoss: good morning! | 06:51 |
| tvoss | alf__, hey, how are you? | 06:51 |
| alf__ | tvoss: great, you? | 06:52 |
| tvoss | alf__, likewise :) | 06:53 |
| tvoss | RAOF, ping | 08:53 |
| RAOF | tvoss: Pong, but about to extract Zoë from the bath. | 08:53 |
| tvoss | RAOF, ack, no rush | 08:56 |
| tvoss | RAOF, could you ping me if you find 5 minutes today? | 08:56 |
| RAOF | tvoss: Sure. Probably after putting Zoë to sleep. | 09:03 |
| tvoss | RAOF, sure | 09:05 |
| tvoss | greyback, ping | 09:07 |
| greyback | tvoss: pong | 09:07 |
| RAOF | tvoss: Yo. | 10:04 |
| === olli__ is now known as olli | ||
| === yofel_ is now known as yofel | ||
| === Cimi_ is now known as Cimi | ||
| === alan_g is now known as alan_g|lunch | ||
| === greyback is now known as greyback|lunch | ||
| === pete-woods1 is now known as pete-woods | ||
| === mlankhor1t is now known as mlankhorst | ||
| === seb128_ is now known as seb128 | ||
| === marlinc_ is now known as Marlinc | ||
| === mmrazik is now known as mmrazik|afk | ||
| === alan_g_ is now known as alan_g | ||
| === greyback|lunch is now known as greyback | ||
| === mmrazik|afk is now known as mmrazik | ||
| hikiko_ | alf___, ping | 13:14 |
| * alf___ wonders how he ended up with so many undescores | 13:15 | |
| alf___ | hikiko_: hi | 13:15 |
| hikiko_ | hi :) | 13:15 |
| === alf___ is now known as alf__ | ||
| hikiko_ | I was looking at your gbm_display.cpp | 13:16 |
| hikiko_ | the configure function | 13:16 |
| hikiko_ | I didn't understand everything to be honest :) | 13:19 |
| hikiko_ | you create the display buffer isn't it? which is the gbm buffer that will fill the EGLImage later? | 13:20 |
| alf__ | hikiko_: the configure() method is an early version of what will become the mechanism to handle multiple displays in the future. Right now it just produces the same output on all displays (possibly cropped on some of them). | 13:21 |
| hikiko_ | and what are the kms outputs? | 13:22 |
| alf__ | hikiko_: (For SDL I don't think you will need any of this.) | 13:22 |
| hikiko_ | yes that's what I thought too but I guess I need the code that creates the gbm buffer? | 13:23 |
| hikiko_ | or maybe not | 13:23 |
| hikiko_ | ah I can do what kevin did in the android platform using a gbm buffer instead of an android one probably | 13:24 |
| alf__ | hikiko_: KMSOutput wraps an "output" (i.e. an attached screen) as defined by DRM/KMS, it is an internal abstraction which you don't need in SDL | 13:25 |
| alf__ | hikiko_: There is the notion of DisplayBuffer, which is a framebuffer which is meant to provide the contents for one or more outputs. On Android, which currently supports one output, the AndroidDisplay class is also a (implements the) DisplayBuffer interface | 13:27 |
| alf__ | hikiko_: gbm uses separate objects to provide DisplayBuffers | 13:28 |
| hikiko_ | so, I can implement display and display buffer in SDLDisplay as kevin did and leave the configure etc parts :) | 13:29 |
| hikiko_ | cool! :D | 13:29 |
| hikiko_ | thank you alf__ :) | 13:29 |
| alf__ | hikiko_: The display side of SDL is completely independent of GBM (and Android, of course). There is probably no code you can sanely share between these display backends. | 13:30 |
| hikiko_ | what i did so far was to use the gbm helper and gbm buffer allocator as it is | 13:30 |
| hikiko_ | initialize the context using sdl, and now I am looking what I need from the egl part (I didn't use the egl helper yet because I am looking at android impl to see if I can modify this version to use my sdl context :) | 13:32 |
| hikiko_ | but I guess it should work | 13:33 |
| alf__ | hikiko_: ok, for the display you shouldn't need to mess with GBM at all. Suggestion: as a first step create only the SDLDisplay(Buffer) and make sure that you can run examples/render_to_fb. | 13:34 |
| alf__ | hikiko_: then implement/reuse the buffer allocator and ensure that render_surfaces run | 13:35 |
| alf__ | s | 13:35 |
| hikiko_ | ok, but for the step 2, do I have to implement a buffer allocator? can't I use the gbm one as it is? | 13:37 |
| hikiko_ | ah no, it's not platform independent | 13:37 |
| hikiko_ | it has a private shared ptr to gbm platform | 13:38 |
| hikiko_ | ok | 13:38 |
| hikiko_ | I start step one :) thank you :) | 13:38 |
| alf__ | hikiko_: for step two, the dependency of GBMBufferAllocator on gbm platform is not a real one... we actually only need the gbm device pointer (which in theory the SDL platform could provide too). RAOF will need to make this change in order to split display/buffer_allocator anyway (but I am not sure how the split is progressing). | 13:45 |
| alf__ | hikiko_: but one step at a time! | 13:45 |
| === mmrazik is now known as 18WADHGI8 | ||
| === francisco is now known as Guest50946 | ||
| kdub | morning, today getting started on a bit of performance investigation | 15:02 |
| alan_g | Afternoon | 15:05 |
| kdub | hello alf__, are you back? | 15:10 |
| alf__ | kdub: Hello! Yes, I am back. | 15:22 |
| kdub | yay, welcome back | 15:23 |
| === pete-woods1 is now known as pete-woods | ||
| greyback | kdub: hey, I'm still struggling with a segv in integrating unity & mir | 15:28 |
| greyback | kdub: mind if I borrow you for a while? | 15:28 |
| kdub | greyback, sure (have a meeting in 30 though) | 15:30 |
| greyback | kdub: ok, well I'll be EODing soon, so let me put instructions in a mail, and hopefully you'll be able to repro my issue | 15:30 |
| racarr_ | arsenm:/win goto 10 | 15:30 |
| racarr_ | Err...wow | 15:30 |
| racarr_ | on another note | 15:30 |
| racarr_ | good morning! | 15:30 |
| tvoss | kgunn, ping | 15:31 |
| kgunn | pong | 15:31 |
| kgunn | tvoss: pong | 15:32 |
| === mhall119_ is now known as mhall119 | ||
| racarr_ | Someone gave me an extra monitor yesterday for my new place annnnd... | 15:53 |
| racarr_ | turning it on causes unity to segfault :( | 15:53 |
| racarr_ | greyback: Got your email...not sure of the top of my head hopefully will come up with an idea soon | 15:54 |
| racarr_ | I will be going through all this again today too... | 15:54 |
| racarr_ | took a week off so its kind of hard to remember anything :) | 15:54 |
| greyback | racarr_: no worries, I'm just glad you're around so I can ask dumb questions :) | 15:54 |
| racarr_ | greyback: electric-fence | 16:02 |
| racarr_ | libefence.so is the preload | 16:02 |
| === racarr_ is now known as racarr | ||
| === mmrazik is now known as mmrazik|afk | ||
| kode54 | mlankhorst: that depends on whether unity-system-compositor is a required package | 16:30 |
| kode54 | I had to modify the control in that package because it required an older version of libmirserver0 | 16:31 |
| === jdstrand_ is now known as jdstrand | ||
| mlankhorst | come again? | 16:32 |
| mlankhorst | oh nm | 16:33 |
| kode54 | unity-system-compositor : Depends: libmirserver0 (= 0.0.2bzr676raring0) but 0.0.2bzr678raring0 is to be installed | 16:33 |
| mlankhorst | yeah good enough reason for nouveau not to work :) | 16:34 |
| kode54 | ahahaa | 16:34 |
| kode54 | not nouveau then | 16:34 |
| kode54 | I managed to install that package from source, but it still doesn't work | 16:34 |
| kode54 | there's also a "mir" package, don't know if I need that one | 16:35 |
| kode54 | it fails to install because it depends on libmirserver0 0.0.2bzr643raring0 | 16:36 |
| kode54 | the source package for the same thing is 0.0.2bzr678raring0 | 16:36 |
| mlankhorst | well, is there anything in dmesg? | 16:37 |
| mlankhorst | soomething like failed to validate yadda yadda | 16:38 |
| racarr_ | Thanks for chatting all :) was useful to get things loaded back in my head | 17:01 |
| kode54 | nothing about failed to validate | 17:03 |
| kode54 | there is a notice that VBIOS is valid | 17:04 |
| kode54 | and a pile of ACPI notices with Namespace lookup failure attached to them | 17:04 |
| === alan_g is now known as alan_g|life | ||
| racarr_ | If we have some data | 17:19 |
| racarr_ | that we model by some function like cpu_usage(timepoint) | 17:20 |
| racarr_ | it's interesting to see | 17:20 |
| racarr_ | integral from start of frame to end of frame | 17:20 |
| racarr_ | of the derivative of cpu_usage | 17:20 |
| racarr_ | which gives us some idea of the | 17:20 |
| racarr_ | right this number will be high if | 17:20 |
| racarr_ | we have many wakeups spread in to seperate peaks of usage | 17:21 |
| racarr_ | vs low if we have a single peak of usage in the frame | 17:21 |
| tvoss | racarr_, we can do that post-mortem with lttng easily | 17:21 |
| racarr_ | Mm. | 17:21 |
| racarr_ | I am just saying it's a good number to look at | 17:21 |
| racarr_ | we were just talking about good numbers to measure and track on a hangout :) | 17:22 |
| tvoss | racarr_, ah :) | 17:22 |
| tvoss | racarr_, did you fix greyback's problems, yet? | 17:23 |
| racarr_ | not yet. we had a shell sync up, then talked about inprocess EGL then talked about performance | 17:23 |
| racarr_ | and now I am going through what greyback did to start to reproduce it | 17:23 |
| racarr_ | I have a pretty strong suspiscion | 17:23 |
| racarr_ | of what it i | 17:23 |
| racarr_ | s | 17:24 |
| racarr_ | :) | 17:24 |
| racarr_ | I think it's just API changes between android inprocess EGL and GBM inprocess EGL | 17:24 |
| racarr_ | masked by a reinterpret_cast | 17:24 |
| racarr_ | so I think the solution is really | 17:24 |
| racarr_ | get all these branches landed with an integration test | 17:25 |
| racarr_ | tvoss: Did you say riccm was looking after platform-api now? | 17:26 |
| tvoss | racarr_, yup | 17:27 |
| === marlinc_ is now known as Marlinc | ||
| tvoss | racarr_, who is working on the integration test stuff? is that you? | 17:27 |
| racarr_ | tvoss: Not really. I'll harass thomi though and work with him | 17:29 |
| tvoss | racarr_, thomi? | 17:29 |
| racarr_ | my immediate task is to make qt-mir-inserver and qt-mir-outofserver co installable, clean up more of the shared code, and make the platform-api and qtubuntu mergeable | 17:29 |
| === Quintasan_ is now known as Quintasan | ||
| racarr_ | tvoss: He is our QA friend. | 17:30 |
| tvoss | racarr_, sounds good :) | 17:32 |
| racarr_ | tvoss: Basically what I want to get in place is some sort of automatic test that runs a Qt app against a real mir binary | 17:32 |
| racarr_ | and a mir binary with an inprocess Qt app | 17:32 |
| tvoss | racarr_, sounds sane | 17:33 |
| racarr_ | and just verifies that it appears to work :) | 17:33 |
| racarr_ | there is a deeper and missing level of testing needed | 17:33 |
| racarr_ | i.e. the event translation from application API -> Qt | 17:33 |
| racarr_ | is quite complex. | 17:33 |
| racarr_ | and not really covered atm | 17:33 |
| racarr_ | YAY multimonitor | 17:42 |
| racarr_ | not in mir ;) I just mean on my desk. | 17:43 |
| racarr_ | ok now platform-api :) | 17:43 |
| smag | Is anyone aware if someone is working on X11 for Ubuntu-touch? | 17:51 |
| kdub | smag, there's xmir | 17:51 |
| kdub | probably about the closest thing at the moment | 17:51 |
| smag | ok, I'll check it out | 17:53 |
| racarr_ | Hmm | 17:53 |
| racarr_ | nvm :) | 17:54 |
| === bschaefer_ is now known as bschaefer | ||
| === yofel_ is now known as yofel | ||
| racarr_ | </lunch> | 20:04 |
| racarr_ | Hit the point in merging platform-api mirserver and mirclient branches and cleaning up where I need to pick things out from input-conglomeration ;) so working on that | 20:19 |
| kgunn | racarr_: :) | 20:42 |
| kgunn | racarr_: did gerry ever ping back w electric fence results on the segfault? | 20:43 |
| racarr_ | kgunn: No but upon inspection I know exactly what it is | 20:43 |
| racarr_ | well | 20:43 |
| racarr_ | thought | 20:43 |
| racarr_ | reflection | 20:43 |
| racarr_ | something-ion | 20:43 |
| racarr_ | just platform-api-mirserver need to be updated to the new inprocess API | 20:44 |
| racarr_ | to use the internal client helper to get the native window type | 20:44 |
| racarr_ | rather than just cast the mir::frontend::Surface (works on GBM, not on android) | 20:44 |
| racarr_ | :) | 20:44 |
| kgunn | racarr_: sweet | 20:44 |
| racarr_ | im merging platform-api-mirserver and platform-api-mirclient in to one great branch now and extracting the dependencies that I had left around and proposing those for merge | 20:44 |
| racarr_ | then syncing up with riccm to figure out how to land it all | 20:45 |
| racarr_ | so hopefully should unblock shell tomorrow | 20:45 |
| kgunn | racarr_: seriously...that will be so awesome | 20:45 |
| racarr_ | Speaking of dependencies I need to land...;) | 20:45 |
| racarr_ | kdub: /+who else is alive? https://code.launchpad.net/~robertcarr/mir/enable-and-demonstrate-inprocess-input/+merge/163615 | 20:45 |
| racarr_ | When you have time | 20:46 |
| racarr_ | (simple) | 20:46 |
| kdub | racarr_, sure | 20:46 |
| racarr_ | 90% cmake ;) | 20:46 |
| kdub | i was wondering what was happening today... | 21:35 |
| thechef | If I had an application which wants to repeat the behaviour of Mir in order to act as a display manager for its sub applications (e.g. I want to fire up konversation in the Gordon Freemans Office in Half-Life 3). Is Mir capable of supporting this situation well, or will it fail compared to wayland, because it doesn't strictly follow the unix rules where one tool does one job, while Mir does 2 by including server side buffer allocation? | 21:42 |
| thomi | hey racarr_ | 21:45 |
| racarr_ | Hi thomi :) | 21:45 |
| thomi | racarr_: you were looking for me earlier? | 21:45 |
| kdub | thechef, it wouldnt be doing 2 jobs any more than any other display server does | 21:46 |
| racarr_ | thomi: Yes. I wanted to ask you about sort of cross bit integration tets for qt+mir | 21:46 |
| racarr_ | but I am getting ready to walk to a coffee shop in like 10 minutes then context switch time (from platform-api) | 21:47 |
| racarr_ | so lets sync up then? | 21:47 |
| racarr_ | thechef: The scenario you describe is rather similar to mirs primary use case ;) | 21:47 |
| racarr_ | where the session compositor mir (Unity) runs as an embedded display server | 21:47 |
| racarr_ | in the system compositor mir | 21:47 |
| thomi | racarr_: sure | 21:47 |
| racarr_ | which has non user things like login screen, etc. | 21:48 |
| thomi | BTW people, I have a suspicion that the packages in mir-team/staging are causing my desktop raring machine to not start Unity. | 21:48 |
| thomi | haven't confirmed that yet though, but it's the most likely candidate | 21:48 |
| racarr_ | hmm | 21:49 |
| racarr_ | im having weird unity issues too lately but unrelated | 21:49 |
| racarr_ | just added that ppa on this system today | 21:49 |
| racarr_ | though I guess I had most of the things from it... | 21:49 |
| racarr_ | unity will fail to start because dbus is completely screwed and then I have to reboot (haven't managed to unscrew dbus so far) | 21:50 |
| thechef | racarr_: and which instance of mir handles which buffers? | 21:50 |
| racarr_ | the system mir allocates buffers from the gpu and hands them out to the session mirs, and it's normal clients (i.e. lightdm) | 21:51 |
| racarr_ | the session mir hands out buffers from the system mir | 21:52 |
| racarr_ | i.e. the same way that mir can use gbm or android gralloc as a buffer source mir will use mir as a buffer source | 21:53 |
| racarr_ | but I mean, if half life 3 wants to let you run konversation, it links against libmirserver | 21:54 |
| racarr_ | subclasses the renderer, with something that renders to some FBO like it wants rather than the framebuffer | 21:55 |
| racarr_ | and acts like a normal mir, konversation talks to it, asks for some buffers, it asks the session mir (that the app/game is running inside of) for some buffers, so on (ignoring optimizations...lots of subcases) | 21:55 |
| racarr_ | not something we have thought about a lot (besides the session/system compositor case) | 21:56 |
| racarr_ | but it's certainly doable. | 21:56 |
| thechef | okay, thanks. Good to know. | 21:56 |
| racarr_ | :) np | 21:56 |
| racarr_ | I think more so than buffer "allocation" it's interesting to think about buffer distribution and ownership | 21:57 |
| racarr_ | and the theory behind server side allocation is just that they are a shared centralized resource, and the display server will be in the best position to make decisions about distribution and ownership i.e. who gets what buffers when | 21:58 |
| racarr_ | as it has the most info | 21:58 |
| racarr_ | this way, rather than doing two jobs, mirs job is "Provide clients with a stream of buffers" | 21:58 |
| racarr_ | aha sorry...I seem to enjoy typing today ;) new office so im a little overexcited. | 21:59 |
| thechef | It's seems to be some sort of a Zaunpfahl-Problem whether you choose to do server side or client side allocation. But what I find weird is the handing over of single frames, because sometimes the display server is going to know really bad WHEN an application should receive the buffer. Assume you want freshest frames. The client is better able than the server to estimate (e.g. according to the content of it's GL frustum) rendering time | 22:02 |
| thechef | and to decide when it should start drawing. | 22:02 |
| racarr_ | greyback: Around? (This is super late for you isn't it?) | 22:22 |
| greyback | racarr_: just about to go to bed, but go on | 22:23 |
| racarr_ | greyback: Oh no worries then. Was just going to say think the issue is fixed in ~robertcarr/platform-api/mir but haven't gotten to test it yet (still reconstructing qtubuntu and getting things out of input-conglomeration) | 22:23 |
| racarr_ | it was just, on gbm, the EGLNativeWindowType is the msh::Surface but on the new android stuff | 22:24 |
| racarr_ | you have to use this factory helper thing to contruct it | 22:24 |
| racarr_ | so ubuntu_application_ui_get_egl_native_window had to be updated | 22:24 |
| racarr_ | maybe it was another segfault but that would definitely segfault shortly after creating the surface :) | 22:24 |
| greyback | ok cool, that's somewhere for me to start tomorrow | 22:26 |
| greyback | racarr_: appreciated, thanks! :) | 22:26 |
| racarr_ | sleep well :) | 22:27 |
| racarr_ | will have an email for you with updated (slightly simplified so far ;)) branches | 22:27 |
| greyback | racarr_: and good night to you too | 22:27 |
| racarr_ | kdub: Hey on the subject of mir::client::input | 22:38 |
| racarr_ | I don't want to put it in to just mir::input because it's all about receiving | 22:38 |
| racarr_ | but mir::client is misleading... | 22:38 |
| racarr_ | so what about...mir::input::receiver | 22:38 |
| racarr_ | ? | 22:38 |
| kdub | yeah... i think we were on to something today when we said we need another word other than client | 22:39 |
| kdub | racarr_, i think that is better | 22:39 |
| racarr_ | yes. I agree it's a hard lingual problem though XD | 22:40 |
| racarr_ | on the input side it's easier | 22:40 |
| racarr_ | because it's all about being a receiver | 22:40 |
| racarr_ | but in general its not so clear | 22:40 |
| racarr_ | Patron | 22:40 |
| racarr_ | XD | 22:40 |
| racarr_ | mir::graphics::Platform::create_internal_patron | 22:41 |
| racarr_ | ...maybe not | 22:41 |
| racarr_ | It's not a consumer | 22:43 |
| racarr_ | We could call it a customer and then we can have business logic | 22:43 |
| kdub | hah, mir::graphics::Platform::synergize | 22:44 |
| racarr_ | of course, that just composes the Patron and the Business Logic | 22:45 |
| === racarr_ is now known as racarr | ||
| racarr | I think this word has the potential to be misleading because 95% of the time in our domain it refers to a human consumer of software | 22:46 |
| racarr | but really what we mean by client | 22:46 |
| racarr | is user | 22:46 |
| racarr | or maybe we want client and the problem is that we have a "client" library | 22:46 |
| racarr | as opposed to a.......*spins hand* | 22:48 |
| racarr | I dunno "application" library | 22:48 |
| racarr | the root of these confusing names, is libmirclient implies that | 22:48 |
| racarr | "Hey this is the library for mir clients" | 22:49 |
| racarr | likewise with the mir::client:: namespace | 22:49 |
| racarr | this is the namespace for mir client machinery | 22:49 |
| racarr | so this inprocess client conflicts | 22:49 |
| racarr | so mir::client::* and libmirclient might be too generally named | 22:50 |
| racarr | so libmirapplication becomes the library toolkits link against, the exiting client library machinery moves to mir::application | 22:51 |
| racarr | mir::client::application? | 22:51 |
| racarr | and common stuff (like input machinery, EGL bits(??), types, etc) | 22:52 |
| racarr | can live in mir::client:: | 22:52 |
| racarr | *shrug* | 22:52 |
| racarr | ... | 22:54 |
| racarr | uhoh | 22:54 |
| racarr | namespace mir = mir::input::receiver | 22:54 |
| kdub | heh, mirec? | 23:03 |
| racarr | kdub: I don't know maybe this is a sign that mir is misnamed | 23:13 |
| racarr | it needs salting to prevent collision, i.e. mirzzz773# | 23:14 |
| racarr | :p sorry...bored renaming things and waiting for compiles | 23:14 |
| kdub | racarr, with the "internal clients", "inprocess egl", i think the term 'client' can be reserved for the normal ipc, non priveleged client | 23:20 |
| kdub | lots of good synonyms for client to choose from, for the 'inprocess/internal' things though | 23:21 |
| kdub | http://thesaurus.com/browse/client | 23:21 |
| kdub | lackey, minion, parasite, vassal,... | 23:22 |
| kdub | ShellSidekick | 23:22 |
| racarr | Ahahaha vassal | 23:22 |
| racarr | mir::graphics::Vassal | 23:22 |
| racarr | kdub: Pushed updates to enable-and-demonstrate-inprocess-input | 23:23 |
| racarr | with the input::receiver namespace anddddddddd | 23:23 |
| racarr | removed the reinterpret cats | 23:23 |
| racarr | casts... | 23:23 |
| racarr | Good morning! | 23:25 |
| kdub | racarr, i think this one is ok without the renames (we can address that later) | 23:25 |
| kdub | racarr, what about line 200 'todo: does this belong?' | 23:25 |
| racarr | kdub: Mm, well at least for now it isn't using | 23:25 |
| racarr | ::client anymore | 23:25 |
| racarr | um | 23:25 |
| racarr | Oh | 23:26 |
| racarr | I put that there so we would think about exposing it because I just did it really quickly in oakland... | 23:26 |
| racarr | tbh I'm not sure why I was concerned about it, I think it was just a general I don't want to think about this right now | 23:26 |
| racarr | are you concerned? XD | 23:27 |
| kdub | well, it doesn't seem 'wrong' that it would be exposed | 23:27 |
| kdub | just trying to avoid confusing comments | 23:27 |
| kdub | but other than that, it looks ok | 23:27 |
| racarr | ok just removed the comment | 23:28 |
| racarr | sorry, normally grep for TODOs... | 23:28 |
| racarr | there are lots in all the code from oakland, haha, basically everytime a question crossed my head that didn't block running unity I was like | 23:28 |
| racarr | ok record it in a TODO | 23:29 |
| racarr | r654 | 23:29 |
| kdub | racarr, +1ed, once jenkins scans it | 23:30 |
| racarr | Thanks :) | 23:30 |
| racarr | Looking at some ot her stuff in input-conglomeration | 23:30 |
| racarr | now that unity is so close to running in a sane way | 23:30 |
| racarr | it doesn't seem worth landing the software cursor in demo shell | 23:31 |
| thomi | RAOF: got a second? | 23:38 |
| thomi | whenever I have the mir-team staging PPA enabled, unity3d won't start and spits out X errors - I wonder if you have any idea what's going on? http://paste.ubuntu.com/5662858/ | 23:39 |
| thomi | "Error: GL_ARB_vertex_buffer_object not supported" sounds bad | 23:39 |
| thomi | it seems like whatever is in the ppa causes the DRI driver to not load :( | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!