| RAOF | Huh. Do we really not have a server report that includes the message IDs? | 03:13 |
|---|---|---|
| === Saviq is now known as Saviq|QtCS | ||
| alf_ | alan_g: anpok_: Do you prefer manually merging branches until the clang issue is fixed, or do you want to force g++-4.8? I prefer (1) if we can get a reasonable ETA on the fix (a couple of days max). | 10:26 |
| alan_g | alf_: I (mildly) prefer disabling the clang build | 10:27 |
| alf_ | alan_g: even better, too bad we can't just do it ourselves :/ | 10:29 |
| alf_ | alan_g: anpok_: From what I understand from ubuntu-ci-eng discussions, the gcc-4.9 update has been reverted | 10:54 |
| alan_g | alf_: shall I kick off an affected build to see what happens? | 10:54 |
| * alan_g has a link handy | 10:55 | |
| alf_ | alan_g: sure | 10:55 |
| alan_g | done - should know in 20min | 10:55 |
| alf_ | alan_g: anpok_: to be exact, the update making gcc-4.9 the default has been reverted, gcc-4.9 packages are still there | 10:56 |
| alan_g | (Unless it fails faster) | 10:56 |
| alf_ | alan_g: which MP did you trigger? | 10:58 |
| alan_g | alf_: Just http://s-jenkins.ubuntu-ci:8080/job/mir-clang-utopic-amd64-build/531/console | 10:58 |
| alf_ | alan_g: the CI environment is still broken... | 11:02 |
| alan_g | /o\ | 11:03 |
| * alan_g starts to think fondly of a former "life" where he "owned" the CI environment | 11:04 | |
| alan_g | alf_: I (mildly) prefer disabling the clang build - I wonder if fginther is about yet | 11:05 |
| alf_ | fginther: ^^ | 11:06 |
| === pete-woods is now known as pete-woods-lunch | ||
| anpok_ | hm isnt there a way to override the clangs header picking behavior | 11:22 |
| anpok_ | -the | 11:22 |
| anpok_ | maybe we can force clang to pick the 4.8 folder | 11:22 |
| alan_g | anpok_: maybe - but how much time should go on that? | 11:28 |
| anpok_ | we would have to add -I /usr/include/c++/4.8 --gcc-toolchain=/usr/lib/gcc/`uname -m`/4.8 to the clang command line - provided that 4.8 is still available on the ci builder | 11:36 |
| anpok_ | +-linux-gnu | 11:37 |
| === ara is now known as Guest77001 | ||
| anpok_ | hm the clang packages from llvm.org dont have that issue anymore | 11:43 |
| alf_ | anpok_: This has been fixed in the debian packages, but they haven't been pulled in the ubuntu archive yet | 11:43 |
| === alan_g is now known as alan_g|lunch | ||
| === pete-woods-lunch is now known as pete-woods | ||
| fginther | alan_g|lunch, alf_, morning | 13:06 |
| alf_ | fginther: Hi! Due to recent clang breakage, all our CI jobs are failing. I think that things have been fixed in the archive (by making g++-4.8 the default again, instead of 4.9), but the CI environment is still broken. | 13:08 |
| alf_ | fginther: We would like to either fix/update the CI environment (preferred), or if this is not feasible for the near future then temporarily disable the clang jobs for mir-ci and autolanding | 13:10 |
| fginther | alf_, I'll have to see what's required to fix it. After a skim of the latest logs, I have no idea what's broken to know what to fix. | 13:17 |
| === alan_g|lunch is now known as alan_g | ||
| alf_ | fginther: How is the build environment for CI updated? We need to ensure we have the latest package versions from archive (in particular for the package gcc-defaults) | 13:20 |
| alf_ | fginther: (source package 'gcc-defaults') | 13:20 |
| fginther | alf_, they are pbuilder chroots updated with 'pbuilder update' | 13:28 |
| alf_ | fginther: ok, I think that just updating the chroots should be enough to fix this | 13:29 |
| fginther | alf_, ack, I'll kick of an update now | 13:29 |
| alf_ | fginther: thanks | 13:29 |
| alf_ | fginther: please let us know when it is done, so we can trigger a couple of builds to see if the clang ci jobs are fixed | 13:30 |
| fginther | alf_, the update is complete and there appears to be a build in progress | 15:03 |
| alan_g | fginther: which failed: CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message): | 15:05 |
| alan_g | The C++ compiler "/usr/bin/clang++" is not able to compile a simple test | 15:05 |
| alf_ | fginther: alan_g: I have triggered a new one, now that we are sure that the update is done | 15:05 |
| alan_g | alf_: fginther that failed too | 15:19 |
| fginther | :-( | 15:27 |
| fginther | alan_g, alf_, I manually check to see what gcc packages are in that chroot, maybe that got dropped somehow when the archive changed the default | 15:28 |
| === Saviq|QtCS is now known as Saviq | ||
| fginther | alan_g, alf_, the chroot has both gcc-4.8 and gcc-4.9, the gcc package version is 4:4.9.0-3ubuntu5. gcc -v reports "gcc version 4.8.3 (Ubuntu 4.8.3-3ubuntu1)" | 15:45 |
| kgunn | seb128: hey there, so AlbertA has some changes coming wrt screen blanking...which will also likely be a proxy for screen brightness as well...would you be the person to | 15:49 |
| kgunn | talk to about having settings properly pick up | 15:50 |
| kgunn | any brightness settings ? | 15:50 |
| seb128 | kgunn, hey, setting got transferred to bfiller's team, jgdx would probably be the right person to talk to | 15:51 |
| kgunn | seb128: thanks! | 15:51 |
| seb128 | kgunn, but iirc we only use the powerd dbus interface there, so there might be nothing to change on the settings side | 15:51 |
| seb128 | kgunn, yw | 15:51 |
| kgunn | AlbertA: jgdx is in #ubuntu-touch | 15:52 |
| AlbertA | thanks | 15:53 |
| seb128 | #ubuntu-touch is the right channel to use anyway | 15:53 |
| seb128 | Laney, I and some other probably still know that code better, the project just got moved | 15:53 |
| seb128 | so we can also reply/comment on the channel | 15:53 |
| alf_ | fginther: alan_g: trying a chroot locally to try to figure out wth is going on | 15:55 |
| kdub_ | AlbertA, are those screen-blanking changes mir-level or powerd? | 15:59 |
| AlbertA | kdub_: USC and powerd | 15:59 |
| AlbertA | USC will now handle inactivity tracking, which makes it have to handle brightness (dim, bright, off) | 16:00 |
| kdub_ | AlbertA, cool, makes sense | 16:00 |
| AlbertA | this is to avoid having powerd also instantiate an android input parser thread | 16:00 |
| AlbertA | and because USC handles display power state changes it just makes more sense for it to be there | 16:00 |
| === bschaefer_ is now known as bschaefer | ||
| alf_ | fginther: alan_g: Can't reproduce problem locally with utopic chroot. | 16:09 |
| alf_ | fginther: alan_g: Is it possible to recreate the chroot from scratch instead of updating it? | 16:09 |
| fginther | alf_, can you do a "dpkg --list|grep gcc"? | 16:09 |
| fginther | alf_, this is what I have: http://paste.ubuntu.com/7634385/ | 16:10 |
| fginther | alf_, it should be possible to recreate | 16:10 |
| alf_ | fginther: http://paste.ubuntu.com/7634390/ (see also stdc++ libs) | 16:11 |
| alf_ | fginther: can you also paste your stdc++ libs? | 16:11 |
| fginther | alf_, http://paste.ubuntu.com/7634395/ | 16:12 |
| alf_ | fginther: kinnara has a fuller gcc 4.9 installation than my chroot. Perhaps the updates don't work so well if you already have 4.9... | 16:14 |
| alf_ | fginther: I would propose either a clean chroot, or perhaps trying to remove the 4.9 packages manually | 16:15 |
| alf_ | fginther: (clean chroot seems safer) | 16:15 |
| fginther | alf_, I'll work on recreating the chroot toady | 16:22 |
| alf_ | fginther: thanks | 16:22 |
| * kdub_ renames surfaceflinger spaghettiflinger | 16:22 | |
| DonkeyHotei | [Wed 2014-06-11 07:35:19 AM PDT] <alf_> DonkeyHotei: We are working on using software GL rendering through Mesa/llvmpipe if no HW accel is available | 16:30 |
| DonkeyHotei | [Wed 2014-06-11 07:36:47 AM PDT] <DonkeyHotei> alf_: how soon? | 16:30 |
| alf_ | DonkeyHotei: 'anpok_' is working on it, so he is better suited to answer the question | 16:31 |
| alf_ | anpok_: ^^ | 16:31 |
| * kdub_ is interested in how that will look in the code too | 16:33 | |
| kdub_ | and also if android can make use of it | 16:34 |
| === alan_g is now known as alan_g|EOD | ||
| anpok_ | DonkeyHotei: next task | 17:12 |
| anpok_ | i think we cannot do much about unity8 using glesv2 | 17:13 |
| anpok_ | DonkeyHotei: resurrected old hardware today.. will see why egl fails to come up there | 17:14 |
| kdub_ | anpok_, with that llvm stuff, are you intending it to be a different platform? a feature of the mesa platform? | 17:34 |
| === jono is now known as Guest93557 | ||
| AlbertA | gaah...deadlock when using surface observer... | 18:39 |
| AlbertA | since my observer tries to change focus | 18:39 |
| anpok_ | kdub_: llvm on dri would be mesa platform.. | 18:49 |
| anpok_ | i mean we could/should also have gbm + pixman | 18:49 |
| anpok_ | that would be a new platform | 18:49 |
| anpok_ | AlbertA: it happened sooner than I thought | 18:52 |
| AlbertA | anpok_: yeah this is for USC where it likes to raise the session only after receiving the first frame | 18:53 |
| AlbertA | anpok_: also I would like do deregister the observer at that time too...but not possible either :) | 18:54 |
| * AlbertA notes its time to remove unlock the guard before executing observer callbacks | 18:54 | |
| * AlbertA time to unlock the guard rather | 18:55 | |
| fginther | alf_, looks like the rebuild chroot is working: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-utopic-amd64-build/541/console | 18:55 |
| racarr_ | Spinning my head in circles on cursor in renderable list lol | 19:28 |
| racarr_ | There are at least 3 main approaches I could think of | 19:29 |
| racarr_ | 1. Cursor specially built in to surface stack. Requires some renderable generalization and renaming surface stack/perhaps changing some API | 19:29 |
| racarr_ | kind of unsatisfying but maybe a good first step | 19:29 |
| racarr_ | 2. Expand scene type functionality of surface stack slightly, i.e. add_renderable instead of add_surface. so surface stack is renamed to um | 19:30 |
| racarr_ | Scene or Renderables or something | 19:30 |
| racarr_ | and the API has to be futzed around all over | 19:30 |
| racarr_ | 3. Use view-adapter style pattern | 19:31 |
| racarr_ | where something inbetween the surface stack and the compositor | 19:31 |
| racarr_ | presents a modified renderable list. | 19:31 |
| racarr_ | adding the cursor on top | 19:32 |
| racarr_ | I tried thinking through tests too...but I mean the main sort of acceptance tests for what I am trying to do is that there is some sort of small buffer at the top of the renderlist that moves with the pointer. | 19:33 |
| racarr_ | so its satisfied by all 3 approaches fine. | 19:33 |
| racarr_ | 1 is... | 19:34 |
| racarr_ | at best a first step, but might be the best choice because it accomplishes the goal, improves things (grows renderable interface) | 19:35 |
| racarr_ | but then, you need different casing in surface stack for touch spot visualization if you take that approach....and that obviously seems pretty bad | 19:35 |
| racarr_ | so probably no 1. | 19:35 |
| racarr_ | 2. Seems good, but im a little literally unclear on exactly how the interfaces should shape up because it has to touch all the factories a little, etc...and there are no clear tests to guide it...but maybe I can think through it more | 19:36 |
| racarr_ | 3. Has a certain charm lol...in that it solves the | 19:36 |
| racarr_ | cursor/touch visualization/overlay problem perfectly and also grows | 19:37 |
| racarr_ | the renderable interface | 19:37 |
| racarr_ | but also clearly... | 19:37 |
| racarr_ | taking an approach of continuing to append view adapters | 19:37 |
| racarr_ | between surface stack and compositor | 19:37 |
| kdub_ | my 2 cents are that the cursor should come along with the generate_renderable_list() function | 19:38 |
| racarr_ | wouldn't work/would become very messy (interdependent) | 19:38 |
| racarr_ | kdub_: :D Yes I agree lol...im just not sure how. | 19:38 |
| kdub_ | and, on the basic level, it is a renderable of sorts, that is, the concrete cursor class would inherit from renderable | 19:38 |
| racarr_ | Yes | 19:38 |
| kdub_ | and the display buffers sort out the hardware cursor abilities | 19:38 |
| anpok | i would prefer 2. | 19:38 |
| racarr_ | so my main divide is is this cursor renderable. 1. Something built in to the scene. 2. Something added to the scene by some sort of controller or 3. Something appended to the scene by some sort of compositor | 19:39 |
| racarr_ | anpok: Yeah...my intuition is that is also best...im just not exactly sure what the new surface stack should look like | 19:40 |
| kdub_ | I don't mind the concrete SurfaceStack impl gaining specific cursor knowledge | 19:41 |
| racarr_ | / how exactly renderable/surface/input target interact | 19:41 |
| racarr_ | kdub_: I was thinking too its not so awful for cursor right, because its just one thing on the top | 19:41 |
| kdub_ | what's not so awful? | 19:42 |
| racarr_ | but then, touch spot visualization is kind of seperate in that there are any number and they | 19:42 |
| racarr_ | vanish or dissapear | 19:42 |
| racarr_ | kdub_: SurfaceStack impl gaining cursor knowledge | 19:42 |
| racarr_ | but if SurfaceStack impl has to know about cursors, and touch spots... | 19:42 |
| racarr_ | it kind of seems | 19:42 |
| racarr_ | like too much | 19:42 |
| kdub_ | eh, you can have a cursor object as a member that takes care of the hairy details | 19:43 |
| racarr_ | hmm maybe. | 19:43 |
| kdub_ | as for the touchspot visualization, you just insert the cursor renderable multiple times with different coordinates for each | 19:44 |
| kdub_ | and like, that way, you have the cursor image be part of the stack | 19:44 |
| kdub_ | and future fancy stuff like MSwindows trailing cursor effect be a matter of the compositor's view state | 19:45 |
| racarr_ | haha fancy stuff | 19:45 |
| kdub_ | heh, well more realistically, like say the cursor is a waiting cursor and has to rotate | 19:46 |
| racarr_ | we already support trailing cursor in glamor | 19:46 |
| racarr_ | haha yes. sure. there are definitely things | 19:46 |
| kdub_ | and iirc, the current client-backed renderable inherits from a touch-targetable interface | 19:47 |
| kdub_ | and the cursor-backed renderable would not | 19:47 |
| kdub_ | so, solves that other problem | 19:47 |
| racarr_ | the thing is if all renderables dont | 19:47 |
| racarr_ | inherit from input target | 19:47 |
| racarr_ | but surface stack stores | 19:47 |
| racarr_ | renderables | 19:47 |
| racarr_ | then you at least need a cast to implement InputTargets::for_each | 19:48 |
| racarr_ | so it doesnt seem quite right | 19:48 |
| kdub_ | if we have internally a list of cursors and a list of clients | 19:48 |
| kdub_ | the for_each can iterate over the clients, which inherit from the right interface for that | 19:49 |
| racarr_ | oh yes, if we keep cursors really entirely seperate | 19:49 |
| anpok | as soon as you add more than just images that refer to surfaces to your scene you need some sort of runtime type information | 19:49 |
| kdub_ | and the stack grows in smartness to interleave the cursors with the clients | 19:49 |
| kdub_ | with the 1st step being 'cursors always on top' (pretty simple) | 19:49 |
| kdub_ | anpok, no, why | 19:50 |
| kdub_ | or maybe | 19:50 |
| kdub_ | who needs that information | 19:50 |
| anpok | when you traferse the scene you might ignore certain elements - i.e. for touch dispatch you would ignore the cursor objects | 19:51 |
| racarr_ | anpok: Well thats the thing in approach 1 though right | 19:51 |
| racarr_ | cursor is just totally seperate | 19:51 |
| kdub_ | sure, thats why you have cursors in one list and clients in the other internally | 19:51 |
| kdub_ | and generate_renderables_list can weave the two together, as both types implement mg::Renderable | 19:51 |
| racarr_ | but, I mean it seems like eventually... | 19:52 |
| racarr_ | we want to support inserting other kinds of renderables in | 19:52 |
| racarr_ | the scene right? | 19:52 |
| anpok | *traverse | 19:52 |
| racarr_ | I mean...I would be happy for example if decorations were in the scene | 19:53 |
| anpok | kdub_: in that case ok .. | 19:53 |
| racarr_ | and all sorts of various effects from various shells | 19:53 |
| racarr_ | could be in the scene | 19:53 |
| racarr_ | shadows could be in the scene perhaps | 19:53 |
| racarr_ | etc | 19:53 |
| anpok | camera configuration | 19:53 |
| racarr_ | camera configuration | 19:53 |
| racarr_ | yes | 19:53 |
| kdub_ | racarr_, decorations, sure | 19:53 |
| racarr_ | so I wonder if taking this approach is actively making things | 19:53 |
| racarr_ | worse | 19:53 |
| racarr_ | so I should just bite the bullet and make surface stack | 19:53 |
| kdub_ | animations are compositor-driven more than scene driven though | 19:53 |
| racarr_ | RenderablesTree (new name) | 19:54 |
| racarr_ | (err by new name, I mean thats not a final name lol) | 19:54 |
| racarr_ | and work in terms of add/remove renderable, etc | 19:54 |
| kdub_ | it was originally just std::list<mg::Renderables> | 19:54 |
| racarr_ | kdub_: Yes lots of animations maybe... I mean effects like | 19:54 |
| kdub_ | sorry, std::list<std::shared_ptr<mg::Renderables>> | 19:54 |
| racarr_ | say unity glass layers (like unity 7 alt tab switcher) | 19:54 |
| kdub_ | RenderableList is just a typedef | 19:54 |
| kdub_ | but sure, the compositor just wants something that can be traversed for rendering | 19:56 |
| kdub_ | tree or list, /me doesn't mind | 19:56 |
| racarr_ | mm | 19:56 |
| racarr_ | in this case, I'm worried about | 19:56 |
| racarr_ | the other side of the API | 19:56 |
| anpok | the actual renderer that draws to one output only needs that list | 19:56 |
| racarr_ | i.e. for adding/removing to it/arranging it, etc. | 19:57 |
| racarr_ | i.e. if cursor controller is going to be adding and arranging cursor renderables in RenderTree, it probably needs something | 19:57 |
| anpok | and information about how to set up the projection matrix.. resolution.. | 19:57 |
| racarr_ | better than depth id ;) | 19:57 |
| racarr_ | among other things | 19:57 |
| kdub_ | no no | 19:57 |
| kdub_ | projection matrix is a view | 19:57 |
| anpok | it should not care about the rest of the scene.. | 19:57 |
| kdub_ | like, the compositor can have its own state | 19:58 |
| anpok | ah ok maybe that part could also benefit from being able to interpret a tree | 19:59 |
| anpok | maybe it depends on what a renderable could be | 19:59 |
| anpok | kdub_: I dont think so.. | 19:59 |
| kdub_ | the tree is just a z-ordering | 19:59 |
| kdub_ | and, i'm talking in the short-medium term here | 20:00 |
| kdub_ | the compositor has to feed back to the stack for certain bits of information, like alf_'s visibility stuff | 20:02 |
| racarr_ | well. I think for cursor I am going to try and get something going with some cursor knowledge built in to surface stack, because this allows me to grow the renderable interface some without worrying too much about other stuff | 20:02 |
| kdub_ | cool | 20:03 |
| kdub_ | although I just got renderable cleaned up! :) | 20:03 |
| racarr_ | and then after, make an attempt to pull the specifics out of the stack to do touch spots | 20:03 |
| racarr_ | but give up if ends up being too confusing, because cursor specialization in the stack impl isnt so bad | 20:03 |
| racarr_ | kdub_: Haha. | 20:04 |
| racarr_ | THE WHEEL IS TURNING | 20:04 |
| anpok | kdub_: that was just the preparation work to make it dirty again | 20:04 |
| kdub_ | haha, hope not! | 20:08 |
| racarr_ | haha | 20:11 |
| anpok | hm intersting intel needs a reboot with the hdmi cable pluggin to be able to send audio through hdmi | 20:11 |
| racarr_ | Luckily we dont yet have a "dirty renderable" | 20:11 |
| racarr_ | concept | 20:11 |
| anpok | *plugged in | 20:11 |
| anpok | racarr_: hehe | 20:11 |
| racarr_ | and that sounds...non surprising lol | 20:11 |
| racarr_ | intel audio...connection stuff is totally messedup, i.e. switching between line in and mic when line in is plugged in, switching dual-function jacks between input/output | 20:12 |
| anpok | sounds like intel wifi | 20:13 |
| racarr_ | lol | 20:13 |
| anpok | only works when power management is turned off | 20:13 |
| racarr_ | intel graphics though does a great job satisfying my need of drawing 20 quads in 16ms | 20:13 |
| anpok | amazing what open source drivers can do to a buy decision.. | 20:14 |
| anpok | ..with all that quirks I would have never bought that laptop | 20:15 |
| racarr_ | my nexus 4 battery life | 20:16 |
| racarr_ | seems to have dropped to roughly...um | 20:16 |
| racarr_ | like if I leave it unplugged for an hour it goes dead | 20:16 |
| racarr_ | kind of situation | 20:16 |
| racarr_ | maybe thats exaggerating | 20:17 |
| racarr_ | I can't really tell | 20:17 |
| racarr_ | but its gotten really bad | 20:17 |
| anpok | i switched from webos to ubuntu phone last week | 20:17 |
| anpok | for that reason actually .. battery becoming really awkward | 20:17 |
| racarr_ | hahahaha | 20:17 |
| racarr_ | anpok: Congratulations on being the first person | 20:17 |
| racarr_ | to use that sentence | 20:17 |
| anpok | now I wonder what it would take (apart from ordering a replacement batery) to get ubuntu phone running on the pre3 | 20:18 |
| anpok | i miss the keyboard | 20:19 |
| racarr_ | kind of a small screen for unity | 20:19 |
| anpok | yeah means less overdraw | 20:19 |
| racarr_ | :) | 20:20 |
| racarr_ | I suspect we may all have shiny new phones before too long anyway | 20:20 |
| kgunn | AlbertA: didn't you or someone fix the "last frame doesn't render" bug? | 21:09 |
| AlbertA | kgunn: yes | 21:10 |
| kgunn | thot so... | 21:10 |
| AlbertA | kgunn: reappeared? | 21:10 |
| kgunn | nope...just need to go kill some fud | 21:10 |
| kgunn | did it make the 020 cut off ? | 21:10 |
| AlbertA | let me see | 21:10 |
| kgunn | racarr_: o/ feels like forever since i said hi | 21:11 |
| AlbertA | kgunn: yes it did | 21:11 |
| kgunn | so hi! | 21:11 |
| kgunn | AlbertA: thanks | 21:11 |
| racarr_ | kgunn: Hi! | 21:18 |
| racarr_ | How was your trip? I remember you went to colorado but cant remember exactly why | 21:18 |
| kgunn | racarr_: yeah thanks for asking | 21:18 |
| kgunn | racarr_: it was nice | 21:18 |
| kgunn | racarr_: pot tourism | 21:19 |
| racarr_ | hahaha of course. | 21:19 |
| kgunn | racarr_: j/k :) my bro in law lives ther | 21:19 |
| camako | nice cover :-) | 21:19 |
| racarr_ | Right mine too ;) | 21:19 |
| kgunn | did some hiking...which was needed for all the food/beer calories consumed | 21:19 |
| racarr_ | aha sounds pleasant | 21:19 |
| racarr_ | ive been craving some nature lately | 21:19 |
| racarr_ | have to find a way to escape the city this weekend | 21:20 |
| kgunn | racarr_: did a 6mi/3000 ft elevation incr hike...and it rained on us the entire 2nd half down the mountain...that was fun | 21:20 |
| kgunn | little chilly | 21:20 |
| racarr_ | haha...cest la vie. | 21:22 |
| kgunn | ....aaaaandddd reboot | 21:32 |
| racarr_ | https://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/540/console | 22:19 |
| racarr_ | :/ | 22:19 |
| racarr_ | The C++ compiler "/usr/bin/clang++" is not able to compile a simple test The C++ compiler "/usr/bin/clang++" is not able to compile a simple test | 22:19 |
| racarr_ | thats a shame | 22:19 |
| kgunn | racarr_: hey, have you played with performanceOverlay ? wondering if there's a way to dump to a file | 22:28 |
| kgunn | http://developer.ubuntu.com/api/qml/sdk-14.10/Ubuntu.PerformanceMetrics.PerformanceOverlay/ | 22:29 |
| kgunn | for the curious, only works on apps (not shell) set the PERFORMANCE_OVERLAY variable, reboot, tap 4 times on the app screen | 22:30 |
| racarr_ | kgunn: I dunno sorry. | 22:44 |
| racarr_ | quick scan of the code makes it look unlikely (dumping to file) | 22:45 |
| kgunn | racarr_: yeah no biggie | 22:47 |
| === robert_ancell_ is now known as robert_ancell | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!