[02:00] Uuuh, launchpad? Why did you just silently eat my workitems? [02:30] Uuuk, google? Why did you just silently eat my personal account and force me to retry for an hour to prove my identity? [02:34] Seriously though... I have plenty of two-factor mechanisms and instead of asking for them, Google asks me questions that no reasonable person would be able to answer. Like the month I opened my account, or the month/year I first used Calendar. [02:53] Woah. [03:13] RAOF: duflu ...could one of you review/approve https://code.launchpad.net/~mir-team/mir/bump-deb-changelog16-mirserver8/+merge/191548 [03:14] kgunn: Done, but needs a minor fix [03:15] kgunn: Also, I assume we've given up on keeping milestones up to date with each 0.0.N ? [03:16] duflu, kgunn: Do we need dates in the changelog *at all*? [03:16] s/changelog/version/c [03:17] RAOF, kgunn: Yeah if we're bumping the version this much then there's no need for a date in there too [03:17] So long as it *increases* each time [03:18] duflu: robert_ancell used to set milestones...altho, i'm not enlightened as to its usefulness...other than maybe trying to target bugs to be done (e.g. phone-v1-freeze) [03:19] kgunn: I've been maintaining them much of the time, but they're not useful if the milestone moves this often. You need less frequent point releases. [03:19] kgunn: If we're not using them then we should have even just one milestone for the release and target that [03:19] RAOF: duflu ...as to date, dunno, i thot there was some esoteric reason it was needed [03:20] kgunn: I think we're free with version strings. So long as they increase and also end with -NubuntuN. The prefix is our own choice [03:21] ... the prefix being the upstream project version without -NubuntuN [03:23] duflu: so you guys are saying instead of this 0.0.16+13.10.20131011-0ubuntu1....we should just make it 0.0.16-0ubuntu1 [03:23] kgunn: I think so [03:23] Yup. [03:23] robert_ancell: ^ what you say even tho you no workie on mir anymore [03:24] the only reason I was stamping versions was so we could mark bugs as closed against that version [03:24] recently the version is useful for bumping build dependencies [03:24] Although the "16" is meaningless. It would have more meaning if we replaced "16" with "" [03:24] I'd agree with duflu using the bzr revision number is more useful [03:25] and having some sort of major version number for telling the difference between versions in Ubuntu [03:25] Then the "0.0" is a placeholder for real project versioning (in future) [03:26] Yeah, the major.minor needs to change, somehow, for each cycle at least [03:26] duflu: ok...can we go with this for this time, let me coordinate with didrocks tomorrow.....i don't want to switch it up and have a reason for grinding everything to a halt [03:27] Fair point. My experience with versions and didrocks that anything which increases is fine. And anything with meaning is better [03:27] *is that [03:31] Argh. Although in using revision numbers you have to remember *only* the development-branch has useful history now. So it would have to be the revision of development-branch [03:35] And similarly, when branching post-saucy, that has to branch from development-branch. Or else we lose the history. Because lp:mir presently has no useful history [03:46] duflu: now ? https://code.launchpad.net/~mir-team/mir/bump-deb-changelog16-mirserver8/+merge/191548 [03:52] kgunn: Needs fixing still :( [03:56] Really, we're not using milestones and the "16" is meaningless. So we should go to upstream version "0.1" or higher. And let ubuntu saucy versions be "0.1-0ubuntuN". [03:56] or "13.10..." :) [04:17] ok strange...i remerged from trunk, that went fine, dch -i and did all the updates...all seemed fine... [04:18] but now, when i try to push...is says error "These branches have diverged." [04:18] but when i do bzr missing it just shows my one commit... [04:20] and a merge from dev-branch results in "nothing to do" [04:25] Where are you pushing to? [04:34] kgunn: bzr info to see where you're pushing to. Verify it's your own and not a shared branch. Then explicitly: bzr push --overwrite lp:~kgunn/mir/somewhere [04:41] duflu: ok...now? [04:46] kgunn: All approved. But then again... I'm not sure if and where we actually broke the server ABI :) [04:46] ... hence it might not have needed incremening [04:46] +t [08:15] duflu, hey! [08:16] duflu, got an opinion on bug 1240841 ? [08:16] bug 1240841 in mir (Ubuntu) "[Mir]In-App scrolling is lagging much" [High,New] https://launchpad.net/bugs/1240841 [08:16] om26er: Hi [08:16] * duflu looks [08:16] om26er, which image? [08:16] om26er, maguro? [08:16] tvoss, 100 mako [08:17] om26er, was it present yesterday? [08:17] tvoss, yes it was [08:17] om26er: Probably not Mir at least. Since native Mir demo clients are perfectly smooth [08:17] But maybe... [08:18] om26er, can you please verify with a less complex client than the browser? [08:18] tvoss, ok, let me try the contacts app [08:19] om26er, ideally, something without too much interaction with the underlying system would be helpful [08:19] om26er, to isolate variables [08:25] That's fun. The Mir branches appear to have had Compiz tags imported into them at some point. How useless. Now deleting them [08:27] tvoss, its visible in address-book as well [08:27] with only 38 contacts in the list [08:28] om26er: On startup too (not many surfaces running in the background)? [08:29] just rebooted. lets see [08:29] om26er: P.S. occlusion optimizations just landed, but don't do anything on mako because --> bug 1240833 [08:29] bug 1240833 in Mir "[feature] Expose at least one non-alpha pixel format for Nexus 4" [Medium,Triaged] https://launchpad.net/bugs/1240833 [08:30] duflu, will it help on nexus 7 ? [08:30] * ogra_ sees it on maguro with the browser and all webapps (though i was blaming the browser initially) [08:30] om26er: Haven't looked yet [08:30] Yeah it seems the browser is naturally slower than other apps anyway [08:31] (lagging and horrible jumpiness when scrolling that it) [08:31] It has a lot to do [08:31] well it didnt do that a week ago or so [08:31] duflu, facebook.com or omgubuntu are really smooth in the browser under Mir. there are other sites that can be slow but these 2 are super smooth [08:31] and indeed i dont see that on mako [08:31] *under SF [08:32] om26er, ogra_, Yeah I think we know our Android rendering is sub-optimal. I don't know what is planned to fix there next. Best ask kdub. [08:32] duflu, just rebooted. visible right after phone starts in contacts app [08:32] om26er, just augment the bug with your findings. Ideally add a video, we will look at it [08:33] duflu, well, maguro has other more low level probs too with Mir ... like exposing a uevent for *each* vsync, seems that doesnt happen on SF [08:33] ogra_: Sounds bad. But I'm no Android expert [08:33] yeah [08:33] ogra_, do we have a bug report for that? [08:34] tvoss, yes, pitti is just working with om26er on one of the fallout bugs in #ubuntu-touch [08:35] (one is that udevd eats constantly 10%+ on maguro, the other is that upstart picks up these events and collects ram like crazy) [08:35] tvoss, we dont really have a bug against Mir for it, but i think somewhere in Mir lies the root of this [08:36] seems SF somehow tells the driver to stop the event spam (probably through a special arch specific switch) [08:36] ogra_, digging [08:36] tvoss, ok. will do === pete-woods is now known as pete-woods-brb [09:07] om26er, did you upload the video, yet? [09:08] tvoss, i was helping pitti with some udev debugging [09:08] om26er, ack [09:08] tvoss, will upload in a few minutes [09:25] duflu, so who is going to work on bug 1240833 ? [09:25] bug 1240833 in Mir "[feature] Expose at least one non-alpha pixel format for Nexus 4" [Medium,Triaged] https://launchpad.net/bugs/1240833 [09:25] Kevin ? [09:26] om26er: Don't know. But it's next cycle :( [09:27] duflu, next cycle starts in a few days ;) [09:27] well actually tomorrow :p [09:27] om26er: Hah. Yeah fair point. Still don't know. It's a simple concept, but potentially tricky to implement === pete-woods-brb is now known as pete-woods [10:08] tvoss, I don't think video camera are able to capture the lag. I have been trying to record a few videos but none seems to show the problem. perhaps I need a better camera [10:08] om26er, ack [10:24] om26er: what's the issue I have a pretty good camera I can setup [10:25] davmor2, on Mir open contacts app with ~50 contacts, try flick from bottom towards top and see if the scrolling lags. try the same on SF. make a video for both [10:26] its even more visible in the webbrowser.. in sites like omgubuntu or facebook [10:26] om26er: I was going to say open planet.ubuntu.com and you get it [10:26] yeah [10:28] tvoss: ^ this is what I said yesterday, If you open planet.ubuntu.com on a maguro because of the length of the site page you can really see the glitchy effect on mir. Not so much lag for me more that is seems to bounce forever and a day [10:28] davmor2, again, maguro is not really the reference here, but I will look at it as soon as I have some time on my hands [10:29] davmor2, confirm this bug 1240841 [10:29] bug 1240841 in mir (Ubuntu) "[Mir]In-App scrolling is lagging much" [High,New] https://launchpad.net/bugs/1240841 [10:29] davmor2, until then, please make sure that we have bugs logged with as much information as possible [10:29] I see that on mako Sir! [10:30] om26er, sure. One other thing: *much* is not really helpful, either we have hard numbers to quantify the slowdown, or it lags. I would rather model qualitative attributes in the bug importance [10:30] davmor2, om26er that being said: bug reports with attached videos or as usual, detailed steps to reproduce would help the most [10:31] ok, we'll improve the title and attach a video if I get my hands on a better camera [10:32] tvoss: I can video the glitch effect I'll add it to the bug, I'll give you a ping once it is done [10:33] davmor2, thx [10:33] om26er, thx [10:33] tvoss, i find it funny that maguro isnt really the reference anymore since we were told we need to focus exactly on this device class [10:33] instead of the beefy arch [10:34] (though that seems to have shifted a little) [10:34] ogra_, fair point, and we will get to optimizing for it, too. However, the PowerVR SGX 540 is *known* to be full of issues, and we don't have drivers with proper hardware compositor support for it [10:34] ogra_, that's the main reason it does not benefit as much of the performance improvements [10:35] yeah, i understand whats the issue indeed [10:35] everything powervr has issues :P [10:35] * ogra_ fights with PVR since nearly 4 years already :) [10:35] mlankhorst, but there are particular bad chips in that series ;) [10:35] maguro is just a different pandaboard ;) [10:36] mlankhorst, ogra_ specifically, touching the fb stalls rendering pipelines and rendering contexts in wild and wonderful ways [10:36] ogra_, that's one of the reasons just catting the fb can lead to "interesting" behavior on maguro [10:37] ogra_, but yes, I'm talking in technical terms here. In general I do agree that we should not only consider super-phones [10:40] theyshould be second focus instead [10:52] tvoss: video added to bug [10:52] davmor2, +1, thx [10:52] om26er: can you confirm that is what you see too [10:54] tvoss: is that alright for you? [10:57] davmor2, yup, helps a lot, thx [10:59] tvoss: same thing happens on contacts as with the slow scroll on the browser page you get that bouncy glitchy effect [10:59] davmor2, ack [11:07] tvoss: the only really odd thing if you do the same scroll in unity8 itself you don't get the glitch it's nice and smooth :) [11:08] davmor2, try opeing three apps and scroll in unity then ;) [11:08] davmor2, that's indeed interesting [11:08] om26er, please add that information to the bug report [11:08] davmor2, yeah, I can confirm your video [11:08] tvoss, ok [11:09] om26er: I've confirmed the bug then now I know it is the same thing :) [11:11] davmor2, btw opening omgubuntu.co.uk is also an easy way to reproduce that bug. since that a mobile optimized app [11:11] om26er, tvoss: I'm assuming that the slow scroll in unity8 with apps open is mostly just down to lack of memory so it's possibly hitting the swap [11:11] davmor2, might well be. However, we have optimization potential in Mir, too [11:11] davmor2, memory is not much of a problem on mako. its because the apps that are running in the background are still being rendered by Mir [11:11] davmor2, bug 1227739 [11:11] bug 1227739 in unity-mir "Mir continues to render background application surfaces even when they're not visible" [High,Triaged] https://launchpad.net/bugs/1227739 [11:12] om26er, only for a certain amount of time, after that, the processes are sigstopped [11:12] om26er: right yeah I see it when you open an app and you get that initial stall sometimes and another app appears till the new one is fully loaded === alan_g is now known as alan_g|lunch [12:40] Hey folks [12:41] wanted to ask, is there some kind of xvfb for mir? some kind of fake mir backend in memory [12:41] no specific GPU connected [12:43] lool: no, we do have a dummy display backend in the tests (no drawing done at all) [12:43] lool: why do you need the memory backend? [12:45] lool: also see https://bugs.launchpad.net/mir/+bug/1118903 [12:45] Ubuntu bug 1118903 in Mir "[feature] Mir lacks a software rendering backend" [High,Triaged] [12:46] alf_: something inbetween emulator virtual machine, and real hardware basically [12:47] alf_: I think this is indeed related; thanks for the pointer [12:48] alf_: I guess there is probably a fake fb driver we could use with this support for fbdev [12:48] I'll check with kgunn how far this is in the mir roadmap [12:48] (with other work such as performance work upcoming) [12:57] lool: why the query ? e.g. what's your proposed need ? [13:02] kgunn: I'm chatting with vila on evolutions of CI stuff, and this came up as one of the things that might help running some of the tests on vms [13:02] kgunn: So was just tring to get status [13:03] kgunn: maybe we will need this sooner rather than later, depends how far this is === alan_g|lunch is now known as alan_g [13:03] lool: ok, right now its nowhere (...unless duflu has been sneaky and spent time on it) [13:04] kgunn: Ok; thanks [13:04] lool: but thanks for this...i will [13:04] make sure to create a bp for some general mir testability items (this is 1 of handful) [13:04] lool: don't the VMs we have support KMS/DRM? [13:05] alf_: true...but, isn't the fb is just a phoney...its really a sw fb that gets redirected to a window right? [13:05] alf_: oh i get your point [13:06] alf_: you might use a sw buffer as fb, but that doesn't mean there is no fb [13:06] oops, meant gpu... [13:06] you might use a sw buffer as fb, but that doesn't mean there is no gpu === pete-woods is now known as pete-woods-brb [13:13] alf_: I'm not sure; I think where there are cases where we dont want this relayed to real hardware, but rather have fake fbs [13:14] lool: do you mean the final display, or the rendering? [13:16] alf_: I guess it depends; on one side we want to exercize Mir itself, on the other side sometimes we just want a solid hardware independent output for higher level tests which are not dependent on GPU specific behaviors [13:16] Perhaps something we might want to do for instance is simulating cloning or extending of displays, or rotating the screen [13:17] or different DPIs [13:17] lool: (if it's just for the final display, we could just draw to an off-screen buffer instead of the real framebuffer) [13:17] lool, so you want a vesa backend? [13:17] lool: so ideally you want a pure software pipeline, e.g. what the bug describes [13:18] lool: GPU not involved in neither display nor rendering [13:18] alf_: Yes, in regular memory buffers is what I had in mind rather than real framebuffer [13:18] much like Xvfb [13:18] tvoss: vesa still goes to hardware via bios? [13:18] alf_: yes pure software [13:18] alf_: exactly [13:19] lool: the rendering part may be a bit tricky, but we could probably just use mesa software rendering for this [13:22] lool: btw, I am not sure that xvfb doesn't use the GPU at all, I think it does so for rendering [13:22] lool: perhaps you just want mir in an X window? :) [13:27] alf_: Actually I care to be able to say "Run these commands that would usually output things to a real screen on a fake screen and let me be able to poke at it" [13:27] alf_: typically, take screenshots, get events about what's going on, influence it [13:27] alf_: e.g. did the display output get "turned off" [13:28] lool, so you want a state-observable mock? I think that's best done in the project-internal tests [13:28] alf_: the main use case is running tests in a reproducible manner and simulating / listening to events; e.g. I can run a "rotate unity8" test on intel or nvidia hardware without testing the intel and nvidia specific behaviors, and then do integration testing on real hardware [13:29] tvoss: but right now when we're actually displaying something it goes to real hardware and might behave differently on this or that hardware [13:29] also, hardware sucks [13:29] if you see what I mean [13:29] we'll always need testing on real GPUs [13:30] but if we could run most of the pre-integration test steps in vms / reproducible + controlled environments, that would be more reliable, scalable [13:30] lool, sure, I'm not argueing against your point, only saying that I think what you want is a mockable and obversable backend, as independent of HW as possible [13:30] lool, what are preintegration tests from your pov? [13:30] tvoss: Ah Mir backend, yes [13:30] tvoss: typically testsuites of our components [13:31] one class is unity8 itself, another class is anything running in unity8 [13:32] but in all cases, we're rarely writing GPU specific code and we could run all tests first on a virtual backend, then on a GPU in the last integration steps [13:32] as in-process? [13:32] hmm not sure [13:32] lool, sure, we would need graphics drivers for the vm's then [13:32] Frankly, I dont fully grasp how the technical implementation would look like yet :-) [13:33] but in the end, I feel I shoudl be able to land an unity8 change by running the tests on a reproducible / fast / scalable environment before I even try it on a real GPU [13:33] with more tooling too [13:33] like, rotating the screen [13:34] lool, so what we would need are graphics drivers for the virtual machines we want to consider [13:34] lool, those drivers typically allow for injecting events like "rotate screen", too [13:36] tvoss: hmmm [13:36] tvoss: virtual machine we are working on [13:36] goldfish [13:36] but it has GL passthrough [13:36] so it's not really hardware independnet [13:36] also, vms are a bit heavy [13:37] when you compare to Xvfb [13:37] lool, xvfb is not hardware independent either [13:37] is it not? [13:37] how so? [13:38] I thought it was creating a fake in memory surface; that it worked without a hardware GPU [13:38] well, it depends [13:40] however, I do not see the advantage of a "pure" software solution in small-scale integration testing. What we have right now is a way to run Mir without real-hw backend in integratoin and acceptance testing scenarios. Unity (or unity-mir) could use that knob, too [13:40] tvoss: can we take screenshots from it? [13:41] I guess we could live without screenshots [13:41] lool, nope, it's state observable though [13:41] lool, that's what we use to mock out things for our CI runs [13:41] maybe fake non-rendering backend + goldfish are enough to cover our needs [13:41] the xvfb like solutoin would be a bit in between I guess [13:44] where's the fake non-rendering backend? I looked into mir/src/server/graphics/ but I'm not sure I can tell how it's named [13:46] lool, searching [13:48] lool: tvoss: there no dedicated "null" backend at the moment, it's just dummy classes inside our test framework (e.g. see in tests/mir_test_framework/testing_server_options.cpp) [13:50] ok [14:36] alan_g: alf_ anyone?....https://code.launchpad.net/~mir-team/mir/development-branch/+merge/191652 [14:37] kgunn: looking [14:38] alan_g: is this going into a phone release? [14:38] kgunn: ^^ [14:38] alf_: alan_g nope, won't make phone release [14:38] * alan_g thought so [14:39] kgunn: so, when are we going to be working directly on trunk again? [14:41] alf_: i spoke to didrocks about it, and seems the api control we have in place is working good... [14:41] alf_: so until we get our api distilled down [14:41] alf_: we'll have to stay on the dev branch [14:42] :/ [14:42] alf_: what's the complaint besides speed (of which...i am probably 1/2 that problem :) === pete-woods-brb is now known as pete-woods [14:45] kgunn: the problem is tracking the source of problems - think about "bisecting" trunk changes [14:45] alan_g: yeah...true [14:46] racarr: can you resume the api distillation activity ?? ^ this will help us return to trunk === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g|tea [14:47] alan_g|tea: that was a quick lunch ;) [14:47] kgunn: I think our API will begin to stabilize only after the scenegraph/model rework [14:49] alf_: that makes a lot of sense....so really, should we just forego the distillation process with what we have today & prioritize the scenegraph work ? [14:49] alf_: altho...doing some gross distillation wouldn't hurt [14:49] we could bump api/abi slightly less [14:50] today i see a header in include/server....by technical rights...i need to bump (even tho i know the likelihood is really low) [14:51] i suppose tackling scenegraph will depend on greyback's availability ....and i know he may be sidelined for about 3 weeks doing the right-edge navigation proto [14:51] greyback: could someone else do the proto ? [14:51] albert maybe ? === alan_g|tea is now known as alan_g [14:55] kgunn: I think that the upcoming changes will drastically alter what we expose to the shell, so much of the distillation work will be wasted. We also need to decide what privatization scheme we are going to use. [14:55] ^ +1 [14:56] alf_: "which scheme"....can you elaborate ? i'm kind of simple minded...i was thinking you got abunch of headers wit pv func's and some needed enums/structs in them [14:57] kgunn: I am referring to the discussion in the the "privatize" MP series email thread [14:57] btw, gonna miss stand up..i have to sit in for olli at some meeting [14:58] alf_: ah...again, am i missing something ? but isn't it a rather simple argument to conclude which directories (feel free to educate me) [14:58] * kgunn realizes there were some responses to my mail...i meant to go back and read :) === dandrader_ is now known as dandrader|afk [15:12] an accidental "make -j44" brought my machine to its knees [15:16] kgunn: fastest way to do the prototype is probably to use the app-screenshot hack we're using for app switching. Disadvantage of that is previews will not be live. But that task will require the screenshot-save-to-disk work we need anyway [15:17] kgunn: yes someone else could certainly take that on [15:18] kgunn: that prototype could be educated to use live previews when available, as the scenegraph task progresses a bit [15:19] kgunn: I need to write up a doc with what scenegraph works I think needs to be done, and what I think Mir might need. I need to spend time understanding how the two can work together tho [15:19] * greyback quite needy at the moment :) [15:22] I'll also need a volunteer from the Mir team who is happy to discuss the Mir-side compositor with me, to explain hardware compositing drawbacks to me, and so I can bounce ideas off === dandrader|afk is now known as dandrader [15:26] greyback, i might be able to help there [15:29] kdub: great, thanks! Prepare for a barrage of idiotic questions and sky-high ideas :D [15:29] :D [15:33] greyback: 'make -j' is also fun :) [15:34] alf_: that it is, but for some reason my Ctrl+C reflex kicks in for that immediately.. :) [15:51] greyback: was busy, and thanks for the responses....great minds think alike....i wanted to ask you to write up some thots....maybe you and kdub (and whomever else) could spend some quality time early next week on it [15:52] kgunn: sure === jfunk is now known as jfunk-afk [16:28] kdub: as a first question, I'd like to learn more about what various hardware compositors can do, just to get a grip on the basics. Would you know of any docs that I could start out on? [16:29] docs, not really [16:30] kdub: even an API of some hardware compositor would give me something. I've found a little on the hardware compositor in the raspberry pi, but mot much [16:30] oh, let me point to the api [16:31] greyback, https://android.googlesource.com/platform/hardware/libhardware/+/android-4.3.1_r1/include/hardware/hwcomposer.h [16:32] kdub: are there similar for nvidia/intel/amd chips? Or is it quite chip specific? [16:33] the whirlwind tour is that you can set various transforms you want to do in composition (basic ones) certain alpha modes, 90-degree rotation, cropping, blits, scaling [16:33] then you ask the hardware, and it tells you 'i can do that' or 'i can't' [16:33] if the hardware can't do it, you have to do that in opengl [16:33] greyback, only talking about android at the moment [16:34] kdub: sure, I'm just thinking about desktop further down the road [16:35] right, with desktop... i think? there's just the cursor that's an overlay [16:35] alf_, is that right, or wrong? :) [16:36] kdub: KMS has the concept of planes (=hardware overlay), but we are not using them at the moment, not even sure how well they are actually supported by the drivers [16:37] oh yeah... i don't hear about them very often, i'd guess the support is hit-or-miss [16:38] so sounds like there's little to no hardware compositing abilities on desktop chips [16:39] i guess.... i mean, there are some different tricks we might want to try [16:39] like, composition happens on the 2nd gpu core (for laptops with an integrated and discrete core) [16:39] cool [16:47] * greyback eod === dandrader is now known as dandrader|lunch [17:03] are there any known issues with mir and android hwc11 (whatever that is)? mir 0.14 used to work after some patching, mir 0.15 crashes in hwcomposer.so after a call from mir in commit_frame() in HWC11Device. Now I'm wondering if the special qcom/display for my phone is broken, or if there's something wrong with mir 0.15 and "hwc11" :) [17:04] uhoh [17:04] nexus 4? [17:04] nope [17:04] HTC Desire Z [17:05] nexus4 uses that hwc11 code, too? then it must be something in the hwcomposer code for my phone I guess... [17:05] w-flo, haven't tried it... but i am doing improvements around that area currently [17:06] i'd expect them to be different [17:06] but is there a backtrace or something? might be a difficult issue to debug w/o a device though [17:08] kdub, http://pastebin.ubuntu.com/6252062/ is the backtrace. The code for libhwcomposer is not the same as in ubuntu/cyanogenmod, so no need to fix anything :) [17:09] w-flo, still would be good to fix... maybe i'll have a branch or two to try over the next week (or two :) ) [17:09] i'll keep you posted === alan_g is now known as alan_g|EOD [17:11] kdub, well, don't waste your time with it. might be a bug in the inofficial cyanogenmod port for the device, this is the repo: https://github.com/Andromadus/android_hardware_qcom_display/blob/cm10.1/libhwcomposer/hwc.cpp [17:11] anyway, thanks a lot kdub, I'll let you know if I get it to work somehow :) [17:39] kdub, hey there :) happy release day [17:39] happy release day tvoss :D [17:41] * kdub start refactoring [17:41] kdub, thanks :) so I commented on the uevent spam bug [17:41] kdub, seems like we miss a call to the android poewr HAL that is a no-op on mako, but should help on maguro [17:41] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1234743/comments/37 [17:41] Ubuntu bug 1234743 in systemd (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [High,Fix committed] [17:42] ah, hmm [17:43] okay, i guess we should add that hal to mir [17:45] we can add that to a bp somewhere [17:47] kdub, yup :) kgunn, can you help here? [17:47] not sure which bp is approprate [18:01] alan_g|EOD: dang...i did not realize you were unavailable...but the sprint timing was kind of tied to strehl's team as well [18:01] alan_g|EOD: that ended up being a really good week for his team too === dandrader|lunch is now known as dandrader [18:21] Lonnnn....don? [18:21] I'm glad we are getting an architecture sprint even if it's going to be cold [18:22] could be worse ... [18:22] oslo in january for example [18:25] alan_g|EOD: i'm gonna poke strehel and see if we could change to that nov 18-22 week...but i'm doubting it [18:36] kgunn: *deep breath and exhale* I guess I should go back to ABI now? [18:38] racarr: so alf_ and i discussed earlier....he was suggesting that changes may come wrt api/abi from scenegraph as well ...he was thinking drastic [18:39] racarr: question is how long that may take, and even if that's the case i was wondering...isn't some [18:39] kgunn: kind of coarse api distillation still useful ? (e.g. at least limit the number of headers out there in public) [18:39] hmm [18:40] yes that's true. wrt scenegraph [18:40] kgunn: Ok I guess, so let's actually split the issue in to two [18:40] racarr: in other words, alf_ was sort of questioning whether its worth distilling the api right now priori to that [18:40] 1. ABI is hard to maintain. 2. API is hard to maintain [18:40] racarr: whereas i was thinking...some effort would be good [18:40] racarr: yep [18:41] the ABI is hard to maintain because we have unity8 using concrete classes, and the sheer number of things we expose (which could be internal) [18:41] the API is hard to maintain, because of it's shape, i.e. the way we require unity8 to implement many many interfaces [18:43] hmm [18:43] alf may be right depending on when we really [18:43] crack down on the scene graph [18:46] racarr: right, i'd like to dive in and try to make headway asap, i think greyback is going to spend some time working with kudb and you to put toghether a vision of what really needs to get done to incorporate qtscenegraph [18:46] ok yeah my thoughts kind of trailed off this way... [18:46] we really need to think about that [18:46] I think maybe [18:47] I need to do a deeper dive in to Qt/QML [18:47] racarr: if you have a little patience, I'll write up a doc explaining the internal workings of the Qt SG [18:48] as that's pretty important for you guys to have a decent understanding of, before we get anywhere [18:48] Ok. [18:48] ug...i everytime i start thinking about it then i think...oh crap, we're gonna need parent-child relations, modality....calgon take me away [18:49] washing machines live longer with..calgon. *bing* [18:49] Now I remember why I don't have a TV [18:49] I feel like I need to understand the QML side more perhaps though... [18:49] because I still don't understand the objective outside of [18:49] tautologically, i.e. "use the QT scene graph" [18:50] * kgunn now on a mission to over-use the word tautologically [18:50] racarr: the benefit for us is to be able to position/size and apply transformations/rotations to Mir's surfaces using QML's syntax [18:51] racarr: that then means we can easily animate too [18:51] racarr: so ideally a mir surface will be a Surface{} type, with properties like a Rectangle{} [18:51] greyback: This is what I don't understand though [18:52] can't a surface be a Surface{} type and have properties like [18:52] width and height and support transformations and such [18:52] and even be a QQuickItem (we reach the boundaries of me knowing what I am talking about) [18:52] for simple properties yes [18:52] and does Qt "scene graph" even have to be [18:52] part of that? [18:53] but transformations and clipping can depend on their parent's transformations & clipping [18:53] racarr: i think part of the point is....something on the qt/qml side will need that just for the qml portion to "talk" in those terms [18:54] before it "knows" about mir [18:54] greyback: That's true [18:54] Isn't it kind of a small number of things though? [18:54] racarr: so what I need to determine is if I can calculate the total transformation [18:55] and clipping [18:55] it could be, but during a complex animation like the proposed right-edge swipe to show all windows animation, it could also be non-trivial [18:55] ? [18:55] I lost a thread [18:56] hmm, yes I mean there can be a lot of stuff going on [18:56] but it's a quite simple language of stuff [18:56] there are items that can be rendered, they have transformations, clips, shaders, a few visual properties (width, height, opacity, position, etc...) [18:57] we can also write shaders in qml to appy to elements, but yeah, that's a good chunk of the list [18:58] My thought is that improving the mir data model to support the needed things (like parent child relationships with cumulative transformations) [18:58] and then binding that out to QML [18:58] is going to be much easier and more fruitful than trying to change the mir data model to be the Qt scene graph [18:58] + the whole rendering set of questions [18:58] That's not what I am asking for [18:59]