| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| duflu | Morning didrocks. I just did a project cleanup (with branch from where saucy was released). Any thoughts? https://launchpad.net/mir/+series | 06:12 |
|---|---|---|
| didrocks | duflu: hum, looking good but please don't push anything to saucy release anymore | 06:12 |
| didrocks | duflu: we don't support it for touch-only components | 06:12 |
| didrocks | and good evening ;) | 06:12 |
| duflu | didrocks: I only pushed the changelog, as the tagged version didn't match the ubuntu release. Now it's identical | 06:13 |
| didrocks | duflu: perfect then :) | 06:13 |
| === tvoss|eod is now known as tvoss | ||
| tvoss | katie, on my way | 08:00 |
| katie | tvoss, ok | 08:00 |
| w-flo | kdub, remember my mir crash (Desire Z) from yesterday? I think the problem is on line 89 in https://github.com/Andromadus/android_hardware_qcom_display/blob/cm10.1/libhwcomposer/hwc.cpp , "MAX_DISPLAYS" is (HWC_NUM_DISPLAY_TYPES+1) .. so it's 3, and the display list passed by mir only has length 2. I haven't tested this yet, but something seems to be wrong there. is that a possible mir bug or hwcomposer bug? :) | 10:58 |
| === sil2100_ is now known as sil2100 | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === alan_g is now known as alan_g|lunch | ||
| kgunn | greyback: do you feel the work around scenegraph is something that could be achieved by jan ? | 13:15 |
| greyback | kgunn: until we've fully defined the task, I really can't say for sure. Would estimate by mid-next week be ok? | 13:17 |
| kgunn | greyback: yeah... | 13:17 |
| kgunn | greyback: just trying to line stuff up... | 13:17 |
| === alan_g|lunch is now known as alan_g | ||
| greyback | kgunn: it'll be a good 2 month effort, most likely. Is that enough to help you, then I can be more specific later | 13:19 |
| kgunn | greyback: yeah, looking for gross estimates | 13:20 |
| alan_g | kgunn: reminder: the work around scenegraph is intimately connected to the work around the Mir data model - but they are not the same thing. | 13:20 |
| kgunn | alan_g: is your reminder a warning about knock-on impacts to mir ...and the effort there? or rather one of architectural-vigilance ? | 13:22 |
| alan_g | kgunn: more about ensuring that you don't conflate them in planning workload | 13:23 |
| kgunn | alan_g: meaning we don't really have a "mir data model" at the moment ? :) | 13:24 |
| alan_g | kgunn: meaning our data model is spread across several components and that is causing problems | 13:25 |
| kgunn | alan_g: lol....worse than not having one | 13:26 |
| tvoss | kgunn, what alan_g is saying that we first need to cleanup our internal data model before we can start thinking about punching in the qt scenegraph | 13:26 |
| tvoss | alan_g, correct? | 13:26 |
| kgunn | tvoss: even worse...its not "cleanup"...to me that's extraction-to-create a mir data model | 13:27 |
| alan_g | tvoss: kgunn meaning we need to think about both | 13:27 |
| tvoss | kgunn, well, that's the same to me ... but feel free :) | 13:27 |
| tvoss | alan_g, +1 | 13:27 |
| kgunn | tvoss: sure...i will hair split on that one....cleanup would imply we have some centralized component representation already | 13:28 |
| tvoss | kgunn, well, if you look at the very first architectural diagram, we have ;) | 13:28 |
| kgunn | tvoss: if i look at the code tho ? | 13:29 |
| tvoss | kgunn, obviously not | 13:29 |
| kgunn | ;) | 13:29 |
| kgunn | tvoss: just worried about load...and time to get there | 13:29 |
| tvoss | kgunn, not sure what you mean? this is a must have from my pov | 13:29 |
| kgunn | tvoss: we're in violent agreement.... | 13:30 |
| tvoss | true | 13:30 |
| kgunn | tvoss: i would like to say we could get it preJan...but | 13:30 |
| kgunn | complexity of it will likely push it | 13:31 |
| alan_g | kgunn: The complexity isn't really in the implementation - more in the agreeing of requirements | 13:36 |
| kgunn | alan_g: sure...let's let gerry have a chance to publish his thoughts from investigating & chatting with racarr/kdub a bit more | 13:37 |
| kgunn | then we'll be able to come together to discuss more intelligently | 13:38 |
| alan_g | kgunn: I think we should be first factoring the current data model into a single component. (i.e. moving the misplaced bits from input and shell to surfaces). | 13:47 |
| alan_g | kgunn: second we should be addressing the synchronization issues we have by designing a proper threading strategy in the data model | 13:47 |
| alan_g | kgunn: Only then does it make sense to look into changing the implementation to incorporate the qt scenegraph | 13:49 |
| kgunn | alan_g: hmmm, so you think it would _not_ be premature to refactor the current data-model bits into a single component before hearing greyback 's need/vision ? | 13:50 |
| tvoss | kgunn, ultimately, when we are talking about a centralized component, a scenegraph will be an (admittedly) important implementation detail | 13:52 |
| tvoss | but that's it | 13:52 |
| alan_g | kgunn: unity is only one client of the data model. Input, compositor and shell are also clients. But it is hard to pull out the requirements from input or shell as they implement parts of the de-facto data model | 13:53 |
| kgunn | alan_g: so you see some dup'ing of implementation (at least conceptually) between unity-mir & mir | 13:54 |
| alan_g | kgunn: no. I'm not sure why you say that. | 13:55 |
| kgunn | alan_g: "unity is only one client of the data model." ....& "shell as they implement parts of the de-facto data model" | 13:57 |
| kgunn | alan_g: that's how i was reading that... | 13:57 |
| alan_g | At present we have parts of what should be the data model in surfaces, parts in input, parts in shell and parts in unity8. That is wrong. Implementation that support communal data access should be in surfaces and nowhere else. | 13:59 |
| alan_g | kgunn: clients of the data model do not implement the data model, they use it. | 14:04 |
| greyback | alan_g: I agree that per-surface data should be in one place. I don't see how fixing that blocks the SG task (whatever we decide that to be) | 14:05 |
| greyback | but right now, until we're clear on what the SG task actually is, I don't want to start discussing potential work items | 14:05 |
| alan_g | greyback: I just doubt that deciding how (or whether) to use a SG and how to fix the data model can be done independently. | 14:08 |
| alan_g | And like tvoss says "a scenegraph will be an (admittedly) important implementation detail" | 14:09 |
| greyback | alan_g: ok. While I cannot contribute to the Mir-side discussion, I can discuss my proposal(s) with you, and see what overall is the best solution for both of the projects | 14:11 |
| greyback | but I need to get the proposals clear first | 14:12 |
| === jono is now known as Guest69907 | ||
| alan_g | greyback: for sure. Similarly, cleaning up the existing model will make clear what it is and how it is being (ab)used. | 14:14 |
| greyback | alan_g: most likely yes | 14:16 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| === dandrader is now known as dandrader|lunch | ||
| blead | hello, anyone know where to get the mir multi boot installer for N7 | 16:02 |
| === seb128_ is now known as seb128 | ||
| slangasek | kgunn: hi! so xnox is working on the goldfish emulator bring-up, and he's at the stage now where he needs to get graphics output working... is there somebody who could help him from the Mir side to get this wired up correctly? | 16:41 |
| alf_ | alan_g: @mir_connect_impl shouldn't throw, ok I didn't see try/catch in the impl we use in the tests (tests/mir_test_framework/testing_process_manager.cpp) and thought there wasn't any guarantee. I will fix the test _impl and remove the try/catch from the client library | 16:47 |
| alan_g | alf_: I'm not blocking on it | 16:48 |
| alf_ | alan_g: hmm, now that I check again, mir_default_connection_release doesn't try/catch either. OK, I will leave it for now then, and we can clean up in the future... | 16:50 |
| alan_g | alf_: "it shouldn't throw" unfortunately doesn't mean "it can't" - we should probably abort or something (or at least have the option to) | 16:52 |
| kdub | sometimes, i wish std::shared_ptr was just std::sp | 16:54 |
| alan_g | kdub: "using sp = std::shared_ptr;" | 16:56 |
| kdub | yeah, but not mir style :) | 16:56 |
| alan_g | kdub: put the case for a change in style? | 16:57 |
| kdub | maybe... | 16:58 |
| mlankhorst | please please dont, I only touch mir code when debugging stuff you blame mesa about, and renaming things like that make it harder for me to understand it | 17:01 |
| alan_g | ;) | 17:04 |
| kdub | yeah, probably easier all around not to | 17:06 |
| kdub | i should just rewire F8 to spit out "std::shared_ptr" :) | 17:06 |
| === dandrader|lunch is now known as dandrader | ||
| kgunn | slangasek: just have him ping here...if u.s. time, kdub or racarr | 18:00 |
| slangasek | kgunn: ok - and if he's UK time? :) | 18:00 |
| slangasek | (since he is :) | 18:00 |
| slangasek | xnox: ^^ | 18:00 |
| kgunn | slangasek: then alf_ or alan_g | 18:00 |
| slangasek | ok, perfect - thanks | 18:00 |
| kdub | emulator stuff should find its way into a bp or something | 18:02 |
| kdub | from my perspective, its about the same amount (or more) effort as a new physical device | 18:03 |
| xnox | kdub: was mir ported to each nexus device separately? emulator suppose to behave similarish to android... | 18:15 |
| kdub | it should, but i'm sure there's some kinks to work out | 18:15 |
| xnox | ok. | 18:16 |
| kdub | we're still transitioning to pick up all devices, some don't work just yet | 18:16 |
| kdub | so, from an architectural viewpoint, they should be the same | 18:18 |
| kdub | but i'm sure there will be some bugs that stop it from working at first that we'll have to work through | 18:18 |
| w-flo | kdub, BTW, I've posted a bug + patch for my latest HTC Desire Z issue with mir (we talked about that yesterday): https://bugs.launchpad.net/mir/+bug/1241683 | 18:34 |
| ubot5 | Ubuntu bug 1241683 in Mir "[Desire Z Port] Mir segfault in libhwcomposer.so; display array too short" [Undecided,New] | 18:34 |
| kdub | w-flo, i'll take a look | 18:36 |
| kdub | w-flo, its a hwc bug, iirc | 18:36 |
| kdub | that we patched on the official builds | 18:36 |
| w-flo | kdub, okay, I can change my hwc to handle it. but that same code appears to be on phablet.ubuntu.com | 18:36 |
| w-flo | oh, wait. maybe I've looked in the wrong place then | 18:37 |
| w-flo | http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_qcom_display-caf.git;a=blob;f=libhwcomposer/hwc.cpp;h=75f62b6efd19768bfbddb4162d5f1c7cb952236a;hb=refs/heads/phablet-saucy <-- this looks similar to my and CyanogenMods (possibly buggy) libhwc | 18:38 |
| kdub | w-flo, does it work after the patch? :) | 18:42 |
| kdub | the device on the whole | 18:42 |
| w-flo | uhm.. yeah, with flickering and keyboard not showing up, etc | 18:42 |
| w-flo | it's better, but still not good enough to actually use it | 18:42 |
| kdub | yeah, good to hear though | 18:44 |
| w-flo | It's nice to see mir working on that rather old device, I agree :) | 18:46 |
| kdub | w-flo, trying to find the patch we use in nex4... | 18:54 |
| kdub | w-flo, i'm working on better hwc fencing support at the moment (should help with that flicker on your device) | 18:55 |
| w-flo | I guess I could simply replace that MAX_DISPLAYS with the old HWC_NUM_DISPLAY_TYPES, I just wasn't sure if it's a bug in HWC or actually intended behaviour | 18:55 |
| w-flo | since it seems they changed that for loop recently so it's 3 iterations instead of 2 | 18:56 |
| kdub | i think with this function, its supposed to be sorta like the attributes eglChooseConfig, you have an array terminated by a value | 18:56 |
| kdub | and it looks like qcom just copied the array that surfaceflinger submits and assumes nothing other than SF would ever use the function | 18:57 |
| w-flo | ah, so.. just stop on encountering a NULL pointer | 18:57 |
| w-flo | well, qcom is amazing %) | 18:57 |
| slangasek | kdub: yes, I expect it will be a non-trivial amount of work to get Mir working on goldfish; but this needs to happen ASAP, we are hurting badly by being dependent on hardware for all of our testing. If making it a blueprint is what needs to happen to get this made a priority, then I'm happy to make a blueprint... | 19:22 |
| kdub | kgunn^^ | 19:33 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!