| Sarvatt | RAOF: also laptop only | 00:17 |
|---|---|---|
| RAOF | Sarvatt: Doesn't appear to be explicitly laptop-only? | 00:21 |
| RAOF | Or, rather, there doesn't seem to be any reason external displays couldn't implement the same thing. | 00:21 |
| Sarvatt | http://techreport.com/news/25878/nvidia-responds-to-amd-free-sync-demo | 00:22 |
| Sarvatt | it'd need a new scaler in the monitor which is what gsync is | 00:22 |
| * RAOF is not entirely sure why external displays have scalers in them anyway. | 00:25 | |
| RAOF | So that could be pretty simply solved :P | 00:26 |
| RAOF | New question: why does Intel allocate the root window differently, in a way that fails, when I pass -rootless? To the gdbatron! | 00:29 |
| === d-snp_ is now known as d-snp | ||
| === jono is now known as Guest35005 | ||
| RAOF | Oh, right. | 01:47 |
| RAOF | Because it turns out that Intel doesn't allocate 0x0 pixmaps in VRAM. | 01:47 |
| RAOF | Who knew?! | 01:47 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === duflu_ is now known as duflu | ||
| RAOF | Dear X damage: WTF? | 05:41 |
| duflu | RAOF: Inaccurate damage reports? | 05:45 |
| duflu | Racey? | 05:45 |
| RAOF | Curiously offset. | 05:45 |
| duflu | Oh, fun | 05:45 |
| RAOF | Apparrently by screen_x, screen_y. | 05:45 |
| RAOF | So the damage region comes out as (-230, ...) → (214, ...) | 05:46 |
| duflu | RAOF: Cos Mir has your screens at different locations to where X thinks? :) | 05:46 |
| RAOF | No; apparently because COMPOSITE interacts strangely with damage. | 05:49 |
| duflu | I do recall thinking I had Compiz damage handling theoretically water tight, and then seeing bugs on random occasions | 06:02 |
| RAOF | Well, that would have been asynchronous. | 06:05 |
| RAOF | Making everything significantly more difficult. | 06:05 |
| duflu | Yes, being outside the server did pose the biggest hurdles | 06:19 |
| duflu | But my Ubuntu desktop doesn't look /too/ broken right now :) | 06:20 |
| RAOF | Hm. Am I using a version of Mir that's unable to service requests from two windows at the same time? | 06:23 |
| RAOF | Grr. Is it just me, or is the msg-processor-report roughly useless? | 06:29 |
| * duflu hasn't used it | 06:35 | |
| RAOF | Bah! It *is* Mir failing to send me buffers again. | 06:45 |
| RAOF | I mean, I'm also doing things wrong, but Mir is definitely doing them wrong as well. Bah. | 06:48 |
| didrocks | RAOF: shared guilt? :) | 06:53 |
| didrocks | hey RAOF ;) | 06:53 |
| RAOF | didrocks: Yo! | 06:53 |
| RAOF | Well, I'm merely crashing the X server when I try and start xterm. Mir is failing to let me draw anything! | 06:53 |
| didrocks | ah, annoying right :) | 06:54 |
| duflu | Dear gcc, You still suck at C++ error messages | 07:59 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === om26er is now known as om26erafk | ||
| janimo | is this spec uptodate? https://wiki.ubuntu.com/Mir/Spec | 10:24 |
| janimo | I see it links to QMir in LP which is marked as deprecated https://launchpad.net/qmir | 10:25 |
| alan_g | janimo: I'm not sure what's happening with qmir - sorry. I know kgunn was checking our docs were current recently he may know more. (But is on Texas time) | 10:44 |
| janimo | alan_g, thanks. I am trying to learn more about mir/xmir/unity8 and try as much of it as possible out on a regular x86 desktop | 10:45 |
| janimo | the unity compositor/xmir part seems to be ok so far (as others have found) on integrated intel GPUs | 10:46 |
| alan_g | janimo: AFAIK unity8 uses unity-mir for Qt bindings | 10:46 |
| janimo | alan_g, seeing whether I can run unity8 was the next step :) | 10:46 |
| anpok | and qt itself uses platform api | 10:47 |
| anpok | qt-ubuntu that is | 10:48 |
| janimo | I just saw an old (May 2013) video with Unity8 running on a laptop, and was wondering whether that is still possible or it was mostly amockup that has been abandoned | 10:49 |
| alan_g | Right. I guess that platform api is preferred over qmir. I'll ask kgunn to confirm before changing the Wiki. | 10:50 |
| alan_g | janimo: you're probably better asking on #ubuntu-unity. But my understanding is that it should be possible to get it to work (but it won't, for example, adapt properly to the screen size.) | 10:52 |
| janimo | alan_g, just basic working UI without sensor support or other niceties would be enough for now, I'll ask there thanks | 10:53 |
| === chihchun is now known as chihchun_afk | ||
| alf__ | janimo: The high level picture is unity8 -> qt -> qt-ubuntu -> platform-api -> mir, and also unity8 -> unity-mir -> mir | 11:36 |
| alf__ | greyback: ^^ please correct me if I am wrong | 11:36 |
| greyback | alf__: correct | 11:37 |
| janimo | alf__, the former for Android the latter for desktop? | 11:37 |
| alf__ | janimo: no, both for both | 11:38 |
| janimo | alf__, which package provides qt_ubuntu ? | 11:39 |
| janimo | the latter sequence is not using qt at all? I am not sure what the two separate path are then (apps vs shell?) | 11:39 |
| greyback | janimo: qtubuntu-android I think | 11:40 |
| janimo | greyback, does it need some more work for desktop or is it misnamed (android) | 11:41 |
| greyback | janimo: the second path exists because unity8 is a mir server. That code path starts up Mir, and exports mir info to unity8 (via unity-mir) allowing unity8 to read window lists and change window placement/management | 11:41 |
| greyback | janimo: but unity8 also wants to draw a shell, the dash, launcher, etc. So for that, unity8 also acts just like any other mir client - that's the 1st code path | 11:43 |
| greyback | janimo: largely misnamed. It works on desktop - only annoyance is it depends on libhybris which does misconfigure your desktop. I think a patch just landed to qtubuntu to fix that, so there will be a "qtubuntu-desktop" package soon | 11:45 |
| janimo | greyback, by mir at the end of both code paths do we mean the unity-system-compositor ? | 11:45 |
| janimo | unclear at first site which of those are libraires/daemons or even protocols :) | 11:46 |
| greyback | janimo: no, unity8 is an instance of a mir server. It is meant to run with user permissions, only when user logs into their account. U-S-C is another Mir instance, which runs asap at startup, as root user, and is resposible for the login greeter, startup animations and user switching | 11:47 |
| janimo | since I understood mir is two libraries (server and client) to build higher level components from, it confuses me when I see a role attributed to Mir | 11:47 |
| alf__ | janimo: for these paths s/mir/libmirserver/ | 11:48 |
| janimo | ack | 11:48 |
| greyback | mir supports nested servers, so unity8 mir server will be a client of the USC mir server | 11:48 |
| janimo | and xmir is only a transitional step, but otherwise it won't be needed on unity8 desktop? | 11:49 |
| greyback | yes - though will be needed for compatibility for exotic toolkits which do not have native support for mir, only X | 11:51 |
| alf__ | janimo: also note that xmir is moving towards rootless support (being able to run x apps as windows in unity8) instead of the current state which is running a whole X session under mir. | 11:59 |
| janimo | alf__, I noticed that. I first ran xmir today, and mostly read docs so far | 12:00 |
| janimo | I am more interested in running unity8/mir without the android bits and using mesa, rather than desktop use cases/convergence | 12:00 |
| janimo | so tablet like use case but on the free stack | 12:01 |
| janimo | this is a subset of the full converge work AFAIK | 12:01 |
| ogra_ | note that the nested U-S.C and Mir stuff will land on the phone next week (or so... still waiting for a hybris patch to land it) | 12:02 |
| alf__ | alan_g: anpok: Do you have any (links to) notes from our discussion about hardware layer and related APIs? I was looking at lp:~kdub/mir/db-optimize but I get the feeling that we discussed something slightly different in terms of API (execute-around-method?), but perhaps that was at a higher level? | 12:03 |
| alan_g | alf__: someone took photos but I've not got a link | 12:04 |
| alf__ | alan_g: I think it was kdub :) | 12:05 |
| === alan_g is now known as alan_g|walk | ||
| anpok | alf__: we discussed various variants | 12:26 |
| anpok | to which one did we settle? | 12:26 |
| alf__ | anpok: that's what I don't remember :) | 12:28 |
| anpok | alf__: there was the topic of locking planes between the start of drawing and the final post | 12:28 |
| anpok | i.e. to cover things like, somebody plugs in a monitor and the scan out engine has not enough overlays/planes left .. | 12:28 |
| === om26erafk is now known as om26er | ||
| anpok | (provided thats possible at all) | 12:32 |
| anpok | i wonder if the interface shouldnt be just: draw(list<buffers_with_transformation>) . | 12:33 |
| === alan_g|walk is now known as alan_g | ||
| alan_g | alf__: anpok we settled on Mir being told "draw these" - no holding locks across interactions | 12:40 |
| anpok | so it would fallback on its own when necessary | 12:41 |
| alan_g | "fallback" being gl compositing? Yes | 12:43 |
| alf__ | alan_g: anpok: What triggered my concerns was that lp:~kdub/mir/db-optimize introduces the optimize() call which means that we may need to keep state between optimize() and post(). I think I remember some related discussion, but it could be that the discussions were for a higher level, or that my memory is failing me. | 12:44 |
| anpok | is display_buffer the interface level | 12:44 |
| anpok | yes | 12:44 |
| anpok | is that the interface level were that would happen or is there a more higher level interface the shell would ues.. | 12:45 |
| anpok | it is now in display_buffer::optimize | 12:45 |
| alan_g | I don't believe we have a migration path thought out - this is still a couple of items down the backlog. But surely "optimize" and "post" are both part of the "draw these" processing. | 12:53 |
| === chihchun_afk is now known as chihchun | ||
| === alan_g is now known as alan_g|lunch | ||
| anpok | looking at the interfaces there again, i think display_info should be the place to add draw_these | 13:04 |
| === chihchun is now known as chihchun_afk | ||
| anpok | alf__: will make another MP - I would then also eradicate the k-constants. if there is no futher objection | 13:41 |
| alf__ | anpok: sure | 13:42 |
| anpok | I was reluctant because I found two forms of constants.. with the normal variable nameing style, and ALL_CAPS | 13:42 |
| === alan_g|lunch is now known as alan_g | ||
| davmor2 | just had my first lockup on maguro since the new mir landed so I don't know what it changed but it isn't dying anywhere near as often on maguro now well done team :) | 14:09 |
| dandrader | alf__, hey, got some spare time to help a mostly clueless guy with "OpenGL in Qt vs EGL in Mir" issues (on the "qml as mir compositor" task)? | 14:12 |
| dandrader | my qml compositor is notified about the creation of a client surface. so I create the corresponding qt scene graph and qml item for it, to that is gets displayed on the qml scene | 14:14 |
| alf__ | dandrader: sure | 14:14 |
| alan_g | anpok: ALL_CAPS should be reserved for preprocessing macros | 14:14 |
| dandrader | but when I call bind_to_texture | 14:14 |
| anpok | alan_g: i agree | 14:14 |
| anpok | will include that way then .. | 14:14 |
| dandrader | the texture displaying the client surface is there being shown and updating nicely on the qml scene | 14:14 |
| dandrader | but all other gl textures used by Qt get borked | 14:15 |
| dandrader | the one used to hold fonts is blanked | 14:15 |
| dandrader | and the other used to hold an image starts showing the contents of that client mir surface as well | 14:15 |
| anpok | is that GL vs GLESv2? | 14:16 |
| dandrader | alf__, I could make a video if that would help understanding the situation | 14:17 |
| alf__ | dandrader: no need, do you have some code I can read/try out? | 14:18 |
| dandrader | alf__, I do, but is not so convenient as you need to build and install a couple of repos (a qpa, a specific mir version, install qt 5.2..) | 14:19 |
| dandrader | ah, and a specific platform-api as well | 14:19 |
| dandrader | alf__, want to try it still? :) | 14:19 |
| alf__ | dandrader: I would at least like to just quickly check what it is doing :) | 14:21 |
| alf__ | dandrader: so perhaps not run it yet | 14:21 |
| dandrader | alf__, 1- so, install qt 5.2 from that "canonical edgers" qpa, 2- that mir lp:~unity-team/mir/mir-for-qpamirserver, 3- that platform-api lp:~dandrader/platform-api/set_window_dimensions and 4- that qpa lp:~unity-team/mir/mir-for-qpamirserver | 14:27 |
| dandrader | alf__, sorry, the qpa is this one: lp:~unity-team/+junk/qpa-mirserver | 14:28 |
| dandrader | alf__, then follow the instructions in the README in this qpa-mirserver on how to run the demo shell and client | 14:29 |
| alf__ | dandrader: ok, I will start by just reading the code and see if I actually built this :) | 14:29 |
| dandrader | alf__, ah, and that's on a nexus 10 | 14:30 |
| alf__ | dandrader: btw, how does your work overlap with what greyback is doing? | 14:31 |
| dandrader | alf__, its the same code base | 14:32 |
| dandrader | alf__, I'm just trying to help him out while he's busy with other work (e.g. side stage, etc) | 14:32 |
| alf__ | dandrader: ok, mir::graphics::Buffer::bind_to_texture() needs an existing texture to bind the contents of the buffer to, i.e. it doesn't create a texture itself. | 14:36 |
| alf__ | dandrader: my guess is that in MirBufferSGTexture you need to create a texture (whose id you can then return in textureId()) and bind to that | 14:40 |
| alf__ | dandrader: so, more or less: glGenTexture() once, and glBindTexture(), Buffer::bind_to_texture()] in MirBufferSGTexture::bind() | 14:41 |
| alf__ | dandrader: (unless qt provides a better way to deal with raw gl objects) | 14:42 |
| alf__ | dandrader: see src/server/compositor/gl_renderer.cpp:199 | 14:43 |
| dandrader | alf__, excelent. makes sense. thanks, I will try it! For me the interaction between EGL and the current OpenGL context in Qt is a really gray area | 14:45 |
| dandrader | alf__, so glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, image) acts on the GL_TEXTURE_2D of the currently active texture unit in the current Openg GL context. is that it? | 14:47 |
| greyback | alf__: aaahhh, dammit that makes sense | 14:48 |
| * greyback kicks himself hard | 14:48 | |
| alf__ | dandrader: yes, on the target the currently active texture unit (i.e. what was last bound with glBindTexture() on that unit) | 14:50 |
| alf__ | dandrader: don't forget to set attributes of the texture as in gl_renderer.cpp | 14:51 |
| dandrader | alf__, ok, thanks! | 14:51 |
| alf__ | dandrader: hmm, although I see some qt calls in MirBufferSGTexture::MirBufferSGTexture that indicate that perhaps qt can do that for you, provided it somehow gets the texture id from you? | 14:53 |
| dandrader | alf__, from my current understanding I think qt expects a QSGTexture (which MirBufferSGTexture extends) to do the texture creation itself. although it might have some kind convenience wrapper, which use should be optional | 14:55 |
| alf__ | dandrader: I am wondering whether the setFiltering(...) ... updateBindOptions() etc calls in the constructor will have any effect, since the texture is not bound yet at that point... | 15:05 |
| dandrader | alf__, AFAIU, they just fill up the internal variables of QSGTexture | 15:08 |
| dandrader | like in a simple POD struct | 15:08 |
| dandrader | alf__, so that the scene graph might query them later one | 15:09 |
| dandrader | s/one/on | 15:09 |
| alf__ | dandrader: right, but I guess that updateBindOptions() actually applies these values, which will need a bound texture? | 15:10 |
| * dandrader checks | 15:10 | |
| dandrader | alf__, you're right | 15:11 |
| dandrader | alf__, thanks for pointing that out! | 15:11 |
| alf__ | dandrader: np | 15:12 |
| ogra_ | mterry, FYI, maguro tested and running fine with nested mode, now we just need to get ricmm_ to commit that hybris fix for grouper | 15:24 |
| mterry | ogra_, awesome. I was able to revive my grouper device from what I thought was certain death, so I can test that when it's available | 15:25 |
| * mterry gets excited for nested mode to land | 15:25 | |
| ogra_ | good, i can test too ... we just need to clone ricmm_ somehow ... he is swamped i think | 15:26 |
| ogra_ | or get asac to announce that we drop grouper :P | 15:26 |
| ogra_ | mterry, bah, spoke to soon, seems i cant wake it up from suspend | 15:28 |
| mterry | ogra_, oh no | 15:28 |
| * ogra_ reboots | 15:29 | |
| ogra_ | hmm, now it wakes up but takes nearly 10sec to do so after pressing the button | 15:31 |
| dandrader | alf__, problem solved! thanks a lot!!! | 15:31 |
| dandrader | greyback, \o/ | 15:31 |
| ogra_ | ... and works immediately on all subsequent presses | 15:31 |
| ogra_ | this is weird | 15:31 |
| greyback | dandrader: woo! thanks alf__ !! | 15:31 |
| alf__ | dandrader: greyback: great! | 15:33 |
| alan_g | alf__: got time to comment on https://code.launchpad.net/~alan-griffiths/mir/expose-rpc-infrastructure/+merge/200879? | 15:34 |
| alf__ | alan_g: sure, will look in 5' | 15:35 |
| ogra_ | mterry, hmm, looking with dbus-monitor it seems like the display stays off until there is dbus feedback from NM o_O ... | 15:39 |
| ogra_ | i reliably see it turning on if the NM response to the resume shows up | 15:40 |
| mterry | ogra_, well this branch does move the dbus service that powerd talks to from unity8 to unity-system-compositor... | 15:40 |
| * ogra_ wonders how that can be connected | 15:40 | |
| ogra_ | mterry, well, it looks like the screen only turns on when indicator-network activation happens | 15:42 |
| ogra_ | which is pretty strange | 15:42 |
| mterry | let me see if I see anything similar on manta | 15:43 |
| ogra_ | might be a coincidence, but it is pretty reproducable | 15:43 |
| ogra_ | (running dbus-monitor as the phablet user indeed) | 15:43 |
| === alan_g is now known as alan_g|tea | ||
| mterry | ogra_, I don't see similar behavior on mako or manta | 15:47 |
| ogra_ | this is good ... | 15:47 |
| ogra_ | but on maguro it will bite us in the tests | 15:47 |
| mterry | yup | 15:47 |
| mterry | :( | 15:47 |
| ogra_ | (since they fail if unlocking doesnt happen in time) | 15:47 |
| ogra_ | we had such a thing before (i guess davmor2 remembers) ... but it was fixed inbetween | 15:48 |
| * ogra_ tries to find the old bug | 15:48 | |
| mterry | kdub, are you still well versed in nesting mode concerns? We're seeing a weird behavior on maguro where the screen doesn't wake up in a timely fashion ^ | 15:48 |
| ogra_ | bug 1255045 | 15:49 |
| ubot5 | bug 1255045 in unity-mir (Ubuntu) "screen does not turn on on maguro when pressing the power button" [High,Fix released] https://launchpad.net/bugs/1255045 | 15:49 |
| davmor2 | ogra_: if you drop grouper and maguro what the hell do I test on | 15:50 |
| ogra_ | davmor2, the new flo and mako your manager has sent you before we dropped them ;) | 15:50 |
| davmor2 | ogra_: but these are both mine that I bought to play with Ubuntu on :'( | 15:51 |
| === dandrader is now known as dandrader|afk | ||
| ogra_ | mterry, so it seems this patch from duflu fixed it http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/154 ... i wonder if u-s-c needs a similar patch if the screen is now handled through it | 15:52 |
| ogra_ | davmor2, so you can still do community testing with them | 15:52 |
| davmor2 | ogra_: When! :D | 15:52 |
| mterry | ogra_, yup. That patch didn't make it to u-s-c | 15:54 |
| * mterry whips up a branch | 15:54 | |
| ogra_ | awesome ! | 15:55 |
| ogra_ | that was quick :) | 15:55 |
| davmor2 | ogra_: what is usc to you? It is Ubuntu Software Center to me :) | 15:57 |
| ogra_ | not in this channel ;) | 15:57 |
| ogra_ | unity-system-compositor | 15:57 |
| davmor2 | ah | 15:57 |
| ogra_ | everywhere else it is ubuntu-software-center ;) | 15:57 |
| === alan_g|tea is now known as alan_g | ||
| davmor2 | you can understand my confusion now though right we really need to start thinking more about initials and if the already exist :D | 15:58 |
| mterry | ogra_, do you mind giving lp:~mterry/unity-system-compositor/dbus-screen-fix a test? I'll test on my other devices to confirm no regressions | 16:02 |
| janimo | kgunn, hi, which are the new mir integration tests in trusty-proposed? What package? | 16:05 |
| ogra_ | mterry, will do will take a bit (meeting run for the next 2h now and i have no active arm build env atm) | 16:05 |
| mterry | ogra_, OK, will mark it for merge review so jenkins makes a deb | 16:05 |
| ogra_ | ++ | 16:05 |
| kgunn | janimo: hey!...yeah...yesterday they were in the devel-proposed image | 16:05 |
| janimo | kgunn, I have 121 installe don the n4 | 16:05 |
| kgunn | janimo: to double check apt-cache policy libmirserver* if you have libmirserver12 installed tests should be there | 16:06 |
| kgunn | janimo: well...actually | 16:06 |
| kgunn | janimo: you'll need to apt-get install mir-test-tools | 16:06 |
| janimo | mir-test-tools itself is not, indeed | 16:06 |
| janimo | kgunn, any chance of adding it by default in the image? The use case is network not being available while doing graphics bringup and testing is | 16:07 |
| mterry | ogra_, hopefully when you're ready, https://code.launchpad.net/~mterry/unity-system-compositor/dbus-screen-fix/+merge/201211 will have debs | 16:07 |
| ogra_ | perfect ! | 16:08 |
| janimo | kgunn, not sure whose call is adding packages to the build. ogra? | 16:08 |
| === dandrader|afk is now known as dandrader | ||
| ogra_ | janimo, i just add them on request to the seeds (if they actually need seeding, ususally deps just pull things in) | 16:08 |
| janimo | ogra_, well I can request adding mir-test-tools but someone else needs to approve such requests I guess | 16:09 |
| janimo | and ask for a reasone (which I provided above for this particular request) | 16:09 |
| ogra_ | kgunn, do they install any upstart job or anything that would make a binary start etc ? | 16:09 |
| ogra_ | or would thesy just add some extra binaries that arent used by anything | 16:09 |
| janimo | ogra_, well they have 5 deps (lttng, libumockdev, liburcu1) so may not be very straighforward from seedin PoV | 16:10 |
| janimo | ogra_, but other than that they are a couple of binaries to test Mir client and server | 16:11 |
| janimo | ogra_, but it is those deps that make it desirable by default in the image, to avoid installing many debs by hand | 16:13 |
| ogra_ | janimo, hmm, not sure what the mock pieces might do | 16:14 |
| janimo | especially when the image being tested is no longer the very latest and there are newer versions of libmirserver and libmirclient | 16:14 |
| ogra_ | was long as system behavior doesnt change due to a seed change i'm all fine | 16:14 |
| ogra_ | read: someone needs to a) run the whole testsuite with them installed and make sure nothing fails | 16:15 |
| janimo | ogra_, I'll do that and let you know | 16:15 |
| ogra_ | b) give me an MP against the ubuntu-touch seed branch | 16:15 |
| ogra_ | (and c) some manual smoketesting would be nice but not mandatory) | 16:15 |
| janimo | ogra_, well the mir tests set up fake DRM devices or various other udev driven environment bits | 16:16 |
| janimo | hence umockdev - | 16:16 |
| ogra_ | right | 16:16 |
| * janimo has just grepped the sources | 16:16 | |
| ogra_ | as long as they only do that when invoked by a test and not in the general system thats fine | 16:16 |
| ogra_ | if they modify (install udev rules) the system in a permanent way we cant just ship it | 16:17 |
| ogra_ | janimo, given pitti is the umockdev upstream, he can probably shed some light on if it makes sense to ship that stuff by default | 16:17 |
| ogra_ | he should know the impact | 16:18 |
| janimo | ogra_, it's only libumockdev that is depended upon , not the umockdev binary | 16:20 |
| * janimo wonders whether a custom build channel devel-devel would make sense | 16:21 | |
| janimo | devel version of ubuntu with development/testing related packages added in the image | 16:21 |
| janimo | targetting bringup and porting work mostly | 16:22 |
| janimo | or even automated hw test setups | 16:22 |
| ogra_ | janimo, well, i would expect a bringup to be done on a rw image in any case | 16:25 |
| ogra_ | so the channels wouldnt really help here | 16:26 |
| mterry | ogra_, hrm. With my patch, u-s-c crashes with the "could not activate surface with eglMakeCurrent" error | 16:26 |
| ogra_ | mterry, i guess we need duflu ... he wrote the original | 16:26 |
| mterry | kdub, you around? | 16:28 |
| kdub | mterry, otp | 16:30 |
| mterry | kdub, ok, no worries. when you're done, I'd like some talk-through help | 16:31 |
| kgunn | janimo: sorry...i am otp to...lost context...you ok? or got other questions ? | 16:35 |
| kdub | mterry, ok, done with the call, whats up? | 16:36 |
| kgunn | mterry: that looks like the annoying "unity8 took long to shut down..and powerd switched blank on..now mir can't get screen" | 16:36 |
| kgunn | mterry: if you do "powerd-cli display on bright" from root on device | 16:36 |
| mterry | kdub, so. For nested mode, I've moved the dbus interface that powerd talks to from unity-mir to unity-system-compositor | 16:36 |
| kgunn | it should hold the display on for testing... | 16:36 |
| kgunn | obviously....if its not just testing....then yeah, we have a problem | 16:37 |
| mterry | kgunn, yeah not just for testing :( | 16:37 |
| mterry | kdub, but a fix went in in the meantime to fix a screen blanking issue on maguro. I've ported that patch over to u-s-c too, but now I get an error "could not activate surface with eglMakeCurrent". Here's my branch: https://code.launchpad.net/~mterry/unity-system-compositor/dbus-screen-fix/+merge/201211 | 16:37 |
| janimo | kgunn, I am ok, just wanted to know what your team thinks of adding mir-test-tools to the default images | 16:37 |
| mterry | kdub, now... can starting a compositor twice be bad? Should I be guarding those calls to start/stop? | 16:37 |
| kgunn | janimo: i'm fine with that idea...kdub ? you ok if mir-test-tools shows up in images ? | 16:38 |
| kdub | kgunn, sure, works for me | 16:38 |
| kgunn | mterry: kdub ( ricmm_ & greyback to a degree)....i think we need to have a sequence diagram of screen blanking... | 16:39 |
| kdub | mterry, with the way mir code is now, start() shouldn't be called twice, i can patch that though | 16:39 |
| kdub | kgunn, i agree | 16:39 |
| kgunn | we keep suffering either bugs in the product...or annoyances in testing... | 16:39 |
| kgunn | kdub: i know you're busy on hwc stuff.... | 16:40 |
| mterry | kdub, I'm not certain I'm calling it twice right now... But it just seemed possible | 16:40 |
| mterry | kdub, there doesn't seem to be a call to see 'isStarted' or something to even guard the call | 16:40 |
| mterry | kdub, if I did call it twice, would that explain the crash I'm seeing? | 16:40 |
| kdub | i think it could, but i have to poke around to be sure | 16:41 |
| mterry | kdub, OK. I will also test on my end with my own guard variable | 16:41 |
| kdub | i'll fix it in mir, shouldn't take too long | 16:42 |
| kdub | the call to blank/unblank though is guarded against double on's | 16:43 |
| mterry | Guh! Now I can't reproduce | 16:48 |
| kdub | now that you added the guard? | 16:49 |
| mterry | ogra_, ^ can't reproduce anymore, so I'd still like to see your testing results when you can get to them. No rush | 16:49 |
| mterry | kdub, no, just at all | 16:49 |
| mterry | I reproduced it several times in a row... Now nothing | 16:50 |
| ogra_ | it seems unreliable ... even on my maguro i have it sometimes react immediately (most of the time it takes >10sec to wake up though) | 16:50 |
| mterry | I meant the u-s-c crash, but yeah, these powerd interactions seem less than predictable | 16:51 |
| ogra_ | oh, ok | 16:51 |
| mterry | I haven't been able to reproduce the screen wake up problem at all. Might just be a maguro issue | 16:52 |
| ogra_ | yeah, like the old one was | 16:52 |
| alan_g | kdub: do you still dislike "namespace google { namespace protobuf { class RpcChannel; } }"? | 16:53 |
| mterry | debs are in the merge for ya, btw | 16:53 |
| alan_g | alf__: anpok opinions on "namespace google { namespace protobuf { class RpcChannel; } }" as a single line? | 16:54 |
| kdub | i don't mind it in general, but the rest of the code puts something like that on 7 lines | 16:57 |
| alf__ | alan_g: I am ok with one level of "namespace X { class Yy }", but with more I think the class name is somewhat lost in the text | 16:59 |
| alf__ | alan_g: e.g., I would be more OK with http://paste.ubuntu.com/6727615/ if we want to keep it short | 17:01 |
| === dandrader is now known as dandrader|lunch | ||
| janimo | ogra_, better than I thought, all the deps of mir-test-tools are already in the image (they were not on my desktop only) | 17:08 |
| ogra_ | janimo, ah, perfect ... | 17:09 |
| janimo | ogra_, where is the bzr branch you need a MR agains for adding mir-test-tools ? | 17:11 |
| alan_g | alf__: sorry, got distracted. I don't think we have a consensus format. | 17:22 |
| janimo | ogra_, https://code.launchpad.net/~jani/ubuntu-seeds/ubuntu-touch.trusty-mir-test-tools/+merge/201236 | 17:25 |
| ogra_ | janimo, perfect | 17:26 |
| kgunn | janimo: i saw your mail...about the failing tests....did you stop unity8 before running ? | 17:32 |
| kgunn | kdub: janimo should stop unity8 correct ?? ^ | 17:32 |
| kdub | yes | 17:33 |
| kgunn | at least i did stop unity8....and integration, acceptance tests pass 100% | 17:33 |
| kdub | although segfaults shouldnt be happening | 17:33 |
| kgunn | unit-test fails...only 1 after many...its the | 17:33 |
| janimo | kgunn, I did not stop it :) | 17:34 |
| janimo | kgunn, well then the tests are great, since the majority passed even with unity8 running | 17:34 |
| kgunn | janimo: ok...hopefully you'll get even better results when you try with untiy8 stoped | 17:34 |
| janimo | kgunn, how is that doen again? kill the process or some upstart command? | 17:35 |
| janimo | I keep forgetting even though I had stopped unity8 in the past IIRC | 17:35 |
| alan_g | janimo: sudo -u phablet -i stop unity8 | 17:36 |
| kdub | janimo, sent a mail, but last I remember, mir_stress should be run against a demo server | 17:37 |
| kgunn | janimo: right...running as "phablet" just "stop unity8" | 17:38 |
| kgunn | janimo: also...as kdub says....really for the case of this testing...it should be unit, integration & acceptance | 17:39 |
| janimo | I used su - phablet and that did not find stop. I need to remember to stick to sudo -i -H -u phablet | 17:39 |
| kgunn | janimo: i'm gonna update https://docs.google.com/a/canonical.com/document/d/1oxXDxehRQ35rYRwkuBCy1ZNmB_IBpg5UhE3jvNHEk_0/edit# | 17:45 |
| kgunn | with the unity8 stop | 17:45 |
| janimo | kgunn, ok. I just sent a new email | 17:47 |
| kgunn | janimo: thanks.. | 17:50 |
| ogra_ | janimo, never use su :) | 17:54 |
| === alan_g is now known as alan_g|EOW | ||
| ogra_ | (gets you a totally different env than sudo) | 17:54 |
| janimo | ogra_, yes I remember the thread on the mailing list a few months ago, but it seemed to end inconclusively | 17:55 |
| janimo | I had used su - so far because it is shorter :) | 17:55 |
| ogra_ | we use sudo -u phablet -i everywhere | 17:55 |
| janimo | ogra_, I will too from now on :) | 17:55 |
| ogra_ | yeah :) | 17:55 |
| ogra_ | janimo, meta uploaded btw | 17:55 |
| janimo | ogra_, thanks | 17:57 |
| === dandrader|lunch is now known as dandrader | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| mterry | Does mirserver initialize the display to on or off on startup? (by itself, not worrying about powerd right now) | 20:35 |
| * mterry is trying to wade through the code to determine, but perhaps someone knows off the top of their head | 20:35 | |
| anpok | mterry: i dont think so, it only interferes with hwc and framebuffer device | 20:52 |
| mterry | anpok, so it leaves it uninitialized until powerd asks the compositor to turn it on/off? | 20:52 |
| mterry | anpok, mirserver deals with screen when that happens via Display::configure() | 20:53 |
| mterry | I'd assumed it would do something on startup too | 20:53 |
| kdub | mterry, it does set the screen to unblanked on start | 20:55 |
| mterry | kdub, OK, cool. Where? | 20:55 |
| anpok | HWCCommondevice::turn_screen_on .. | 20:57 |
| kdub | http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platform/graphics/android/hwc_common_device.cpp#L58 | 20:57 |
| anpok | but I thought that would not turn the display on/off | 20:57 |
| kdub | anpok, those hal functions should blank or unblank the fb device | 20:58 |
| kdub | mterry, is that what you meant, or did you mean something else? | 20:59 |
| mterry | kdub, I believe that's what I wanted, yeah | 21:00 |
| kdub | cool... that constructor should get hit when the_display() is called the first time (not for nested / offscreen of course) | 21:01 |
| mterry | kdub, hmm | 21:09 |
| mterry | kdub, testing restarting unity8 with the screen off doesn't turn screen on | 21:10 |
| kdub | restarting how | 21:11 |
| kdub | and in what powerd state? | 21:11 |
| mterry | kdub, um | 21:13 |
| mterry | kdub, I had pressed power button so screen was off | 21:14 |
| mterry | kdub, then I did a "sudo -u phablet -i restart unity8" | 21:14 |
| kdub | right, so the power button allows the system to enter 'powerd inactive' | 21:15 |
| kdub | my understanding is that everyone could assume that things were on to start with... although hopefully the discussion about those power interactions clarifies the situation | 21:16 |
| mterry | kdub, sure. I'm just trying to document the current situation. And if mirserver is turning display on on startup, I'd expect a unity8 restart to turn display on | 21:16 |
| kdub | right, it should | 21:17 |
| mterry | hmm | 21:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!