| === chihchun_afk is now known as chihchun | ||
| duflu_ | RAOF: Bug 1253507 is now on trusty too :( | 03:04 |
|---|---|---|
| ubot5 | bug 1253507 in Mir "The following tests FAILED: 134 - unit-tests.UdevWrapperTest.* (OTHER_FAULT)" [Critical,Triaged] https://launchpad.net/bugs/1253507 | 03:04 |
| === duflu_ is now known as duflu | ||
| RAOF | duflu: You can't run the unit-tests bare. | 03:47 |
| duflu | RAOF: Yes you can. Always have. How else do you run a specific test you're working on? Or under valgrind? | 03:47 |
| RAOF | duflu: If you don't want to run ‘make test’, you'll need to run “umockdev-run bin/unit-tests” | 03:48 |
| RAOF | Or export LD_PRELOAD, of course. | 03:48 |
| duflu | RAOF: We need to fix that then. All the tests binaries need to be self-contained | 03:48 |
| RAOF | This has been - or *should* have been - the case for some time. We've had umockdev tests in tree for ages. | 03:49 |
| duflu | Hmm. Although I see the problem :S | 03:49 |
| duflu | RAOF: Perhaps make the tests smarter so they don't try stuff that will fail if the environment is wrong | 03:49 |
| RAOF | I could do that, yes. | 03:50 |
| duflu | Because tests "expected to fail" is just going to trip people up, repeatedly | 03:50 |
| RAOF | They're not expected to fail; they're expected to succeed, and do in the correct environment. | 03:52 |
| RAOF | Hm. Looks like you can't programatically skip gtest tests. | 03:52 |
| racarr | Wow I just heard that all australlians that develop an opinion on https://code.launchpad.net/~robertcarr/mir/consolidate-default-shell-part-1/+merge/195870 get a cookie at the sprint | 03:53 |
| racarr | Everyone is talking about it. | 03:54 |
| sarnold | oh man wish I could a cookie. but I'm not australian :( | 03:54 |
| racarr | Yeahhhh...sorry | 03:54 |
| racarr | I don't make the rules | 03:54 |
| sarnold | rules are important. but I bet there's some lucky australian who'll get a cookie! | 03:55 |
| racarr | and just maybe his wildest IPC fantasies will come true. | 03:56 |
| racarr | Good afternoon RAOF :p | 03:56 |
| RAOF | racarr: :) | 03:56 |
| duflu | racarr: Can't eat cookies :S | 03:57 |
| racarr | duflu: Hmm I don't know what your IPC fantasies are either. | 03:58 |
| RAOF | racarr: The description makes sense to me; bonus points are available for proceedurally generating the DefaultShell, of course :) | 04:01 |
| RAOF | racarr: I'll form a more informed opinion over time :) | 04:02 |
| RAOF | duflu: Would you accept tests that fail with a more-correct error message when the environment is wrong? | 04:03 |
| duflu | RAOF: Not really. It would be a significant loss to not be able to run "unit-tests" any more. But if you can do an error message then you can if(){} around the failing tests too. Although instructing gtest to disable them would be nicer | 04:13 |
| RAOF | duflu: You *can* still run unit-tests. | 04:14 |
| RAOF | You just need to run “umockdev-run bin/unit-tests” | 04:14 |
| RAOF | Unless you restrict the tests you run to tests which don't need umockdev, in which case you should still be able to run unadorned bin/unit-tests | 04:15 |
| duflu | RAOF: There are solutions out there. I'm really just asking that it not be me who implements one because I'm the only person who cares right now | 04:24 |
| RAOF | duflu: I'm just trying to get a sense of what parameters you think a solution must have. | 04:28 |
| RAOF | Hm. I wonder if we could just link the unittests to the umockdev SO rather than libudev... | 04:29 |
| duflu | Sounds like another option. | 04:32 |
| duflu | And so is lunch... | 04:32 |
| racarr | RAOF: I think any discussionsabout the IPC,etc will have to wait for the sprint so in the mean time I am just trying to change the way we think about "shell" | 04:38 |
| RAOF | racarr: Oh, yeah. Absolutely. | 04:39 |
| === chihchun is now known as chihchun_afk | ||
| RAOF | duflu: https://code.launchpad.net/~raof/mir/fix-1253876/+merge/196222 is first part of fix. | 04:51 |
| RAOF | duflu: GAH! Does lp-propose not work? I ran bzr lp-propose lp:~mir-team/mir/development-branch, which should target the right thing? | 05:40 |
| duflu | RAOF: Apparently not (?!) | 05:40 |
| === chihchun_afk is now known as chihchun | ||
| * RAOF should really learn more OpenGL | 05:54 | |
| duflu | RAOF: It's actually much more fun leanring OpenGL than ES :P | 06:00 |
| duflu | *learning | 06:00 |
| RAOF | More fixed function, less shaders for everything? :) | 06:00 |
| duflu | RAOF: Yes... as in OpenGL complements your C algorithm. You just write C and emit vertices etc when it suits you | 06:01 |
| duflu | Also there's much less setup and voodoo that ES necessitates with shaders | 06:02 |
| duflu | Whoever designed GL was clever. Whoever designed ES was so desperate to solve hardware-specific performance issues that they forgot to keep the awesomeness of GL | 06:03 |
| duflu | Umm, I mean OpenGL. Technically "GL" is an SGI thing that predates it | 06:04 |
| alf_ | Why is cmake so stupid? It's building the executable before a library that the executable depends on! https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/258/console | 09:32 |
| * duflu reconsiders the wisdom of the past few days work. Maybe it's the wrong approach. | 10:03 | |
| duflu | And now I have to host dinner :S | 10:04 |
| alan_g | alf_: Can you confirm that I've not missed something? The call to frame_posted() would work just as well after secure_client_buffer() wouldn't it? | 11:42 |
| alf_ | alan_g: looking | 11:44 |
| alf_ | alan_g: From what I can see it shouldn't make any difference. | 11:46 |
| alf_ | alan_g: Are you seeing anything strange? | 11:46 |
| alan_g | alf_: thanks | 11:46 |
| alan_g | No, just wanted to shuffle stuff and wanted to double check | 11:47 |
| alf_ | alan_g: hmm, on second though, it will change the timings a bit, since we won't necessarilly recomposite until after the client has got its buffer (will may block for a bit) | 11:49 |
| alf_ | thought | 11:49 |
| alf_ | will->which | 11:49 |
| alf_ | alan_g: thinking whether this could actually block the system completely | 11:52 |
| alan_g | alf_: it does change ordering slightly, but I *can't see* that it can cause blocking. | 11:52 |
| alf_ | alan_g: (after some thought) yes, it seems it would be ok | 12:10 |
| greyback | alan_g: alf_: hi folks, can you remind me of something: when using run_mir(config, clientInit) - is Mir server ready to accept incoming connections when clientInit is called? Or it only works as clientInit is an internal client, and so I must use the ServerStatusListener for when external clients can reliably connect? | 12:11 |
| alf_ | greyback: you need to use ServerStatusListener | 12:12 |
| greyback | alf_: ok | 12:12 |
| alan_g | greyback: Mir is initialized, but run() hasn't been called | 12:12 |
| greyback | alan_g: alf_: thanks! | 12:13 |
| * alan_g wonders whether to build on start-cleanup-of-ownership-of-client-buffers when it has a "Disapprove" vote | 12:19 | |
| === chihchun is now known as chihchun_afk | ||
| greyback | alan_g: +1 on SIGSTOP being a strange choice. Made it particularly annoying to test, run it and it stopped itself | 13:05 |
| === greyback is now known as greyback|lunch | ||
| kgunn | alan_g: alf_ i'm gonna eat bkfst real quick...but this morning, i suppose its time to queue up dev-branch merge to trunk ?? just checking make sure there's nothing to wait on ... | 14:14 |
| alan_g | kgunn: nothing essential. Anything "in flight" is a nice to have though. ;) | 14:15 |
| alf_ | kgunn: nothing special on my side... shmem buffers are getting close, but are not urgent | 14:15 |
| dandrader | what's the easiest way for unity8-mir to grab a screen shot (ie. which mirserver API it should use)? | 14:16 |
| alf_ | dandrader: I would say override the renderer, and read from the framebuffer (glReadPixels) after rendering is done | 14:18 |
| alf_ | dandrader: override => decorate | 14:19 |
| dandrader | alf_, ok. thanks. should I lock any resource explicitly or will it just work? | 14:20 |
| alf_ | dandrader: no, during rendering the renderer is in complete control of the framebuffer (well, the back buffer to be exact, since we are double buffering) | 14:21 |
| dandrader | ok | 14:21 |
| alf_ | dandrader: hmm, actually now that I think about it this won't work with the current compositor structure | 14:22 |
| dandrader | alf_, oh, what should I do then? | 14:23 |
| alf_ | dandrader: you could implement/override the overlay renderer, which is called after all normal rendering is done and do glReadPixels from there | 14:24 |
| alf_ | dandrader: but I am not sure what the future holds for the overlay renderer, it seems it's not needed in general | 14:25 |
| === pete-woods is now known as pete-woods|late- | ||
| === pete-woods|late- is now known as pete-woods|lunch | ||
| === dandrader is now known as dandrader|lunch | ||
| === greyback|lunch is now known as greyback | ||
| kgunn | alan_g: alf_ ...was just about to do the version update...noticed this https://code.launchpad.net/~vanvugt/mir/version-0.1.2/+merge/196050 | 15:20 |
| kgunn | mind approving ? | 15:21 |
| alan_g | kgunn: no objection | 15:21 |
| kgunn | or...guess i can...sorry to bother.. | 15:22 |
| kgunn | was thinking something else.... | 15:22 |
| alan_g | There are worse wastes of time | 15:23 |
| kgunn | he just confused me with the todo in changelog...but i totally get it now....epiphany | 15:24 |
| ricmm | dandrader|lunch: ping | 15:36 |
| ricmm | racarr: ping | 15:36 |
| === alan_g is now known as alan_g|tea | ||
| === pete-woods|lunch is now known as pete-woods | ||
| === dandrader|lunch is now known as dandrader | ||
| dandrader | ricmm, pong | 15:40 |
| ricmm | dandrader: I see you as the author of http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1193#3rd_party/android-input/android/frameworks/base/services/input/InputReader.cpp | 15:41 |
| ricmm | racarr and duflu as reviewers | 15:42 |
| ricmm | that branch breaks input on all devices after 16 touches on the screen | 15:42 |
| dandrader | ricmm, you need newest qtubuntu | 15:42 |
| ricmm | sure it could be patched in qtubuntu | 15:42 |
| ricmm | but is there a reason for the count not to reset? | 15:42 |
| ricmm | why not hold an internal count for your tracking purposes, instead of changing the android API | 15:43 |
| ricmm | just trying to understand the reason of the pointer id increasing across gesture boundaries | 15:44 |
| dandrader | ricmm, "Have touch ids remain valid for some time after its touches have physically ended, so one can still refer to a touch that has already ended." | 15:45 |
| dandrader | ricmm, and qtubuntu was making wrong assumptions about touch id values | 15:45 |
| ricmm | in what way? | 15:45 |
| dandrader | ricmm, check the patch there | 15:46 |
| dandrader | ricmm, is has an explanation | 15:46 |
| dandrader | ricmm, besides, we forked android-input code so that we could modify it to fit our needs | 15:46 |
| ricmm | thats not an explanation, thats you saying you are changing the android API | 15:46 |
| ricmm | but sure | 15:46 |
| ricmm | does this qtubuntu change work with the SF plugin? | 15:46 |
| dandrader | ricmm, yes | 15:47 |
| ricmm | alright | 15:47 |
| === alan_g|tea is now known as alan_g | ||
| ricmm | dandrader: for my own awareness, what are they being used for after the touch ends? | 15:52 |
| dandrader | a tap near the edge of a screen | 15:52 |
| dandrader | ricmm, the edge gesture recognition won't know it's not an edge gesture until the touch has already ended | 15:53 |
| dandrader | ricmm, and so it has to reject a touch after its end | 15:54 |
| ricmm | got it | 15:54 |
| greyback | anyone around be able to tell me is mir::graphics::Buffer::id() simply the gl texture id? | 17:11 |
| alan_g | greyback: It used to be a generated number - I doubt it changed | 17:12 |
| greyback | alan_g: ok, thanks | 17:13 |
| kgunn | alan_g: good togo | 17:19 |
| alan_g | kgunn: I assume that means "Approve"? ;) | 17:20 |
| kgunn | alan_g: yep...i can do that too | 17:21 |
| kgunn | uno momento | 17:21 |
| alan_g | kgunn: just vote (no need to top-approve yet) | 17:21 |
| === dandrader is now known as dandrader|afk | ||
| kdub | alan_g, with the surface/scene cleanup, have you given any thought yet to ms::SurfaceStack? | 17:48 |
| kdub | i'm trying to come up with a good interface for overlays, and if SurfaceStack is changing, I might hit conflicts | 17:49 |
| alan_g | kdub: only to the extent that the interfaces it needs to support are getting clearer | 17:49 |
| alan_g | kdub: I'm fiddling with client buffers for the next couple of days | 17:50 |
| kdub | ah, okay | 17:51 |
| kdub | the system of filters and iterating over the stack seems pretty okay for the purposes of sorting out overlays | 17:52 |
| alan_g | kdub: maybe but it is wrong beyond that | 17:53 |
| alan_g | let me sketch why... | 17:54 |
| alan_g | we should only be locking the stuff composited by the current compositing pass (think multiple concurrent monitors and hidden surfaces) | 17:55 |
| alan_g | So there ought to be a filter pass that selects what will be composited and leaves it locked | 17:55 |
| alan_g | And then a compositing pass over the locked stuff | 17:56 |
| alan_g | And we should get rid of the lock()/unlock() of everything | 17:57 |
| alan_g | So if there's any of that which fits well with your needs... | 17:57 |
| kdub | yes, that makes sense | 17:58 |
| kdub | so the first filter would trim away surfaces that we know won't appear on the screen, and secures them for render | 17:59 |
| kdub | and then the 'overlay filter' would go through and sort out which of those need GL composition | 17:59 |
| kdub | and then we would do a composition pass, (GL + overlay), and then post | 17:59 |
| kdub | okay, sounds good | 18:00 |
| greyback | fuck yeah, I finally have Qt SG compositing Mir surfaces | 18:00 |
| alan_g | kdub: yes. I've not thought through all the details. (Was chatting to duflu about it a couple of weeks back) | 18:01 |
| alan_g | greyback: sounds interesting | 18:01 |
| kdub | i think too that the bypass logic should be buried deeper than the compositor | 18:01 |
| kdub | all the compositor needs to know for bypass AND overlays is which layers need GL composition | 18:02 |
| === dandrader|afk is now known as dandrader | ||
| kdub | in the bypass case, no gl composition at all, in the overlay case, some gl composition | 18:02 |
| alan_g | kdub: I have the feeling that it becomes a special case of ... yeah exactly | 18:02 |
| alan_g | bypass is really just using any suitable surface as the fb | 18:05 |
| kdub | cool, sounds like we're on the same page | 18:05 |
| kdub | and then though, the hardware cursor becomes an overlay that gbm can do | 18:05 |
| kdub | and mc:: doesn't know 'this is the cursor' | 18:05 |
| alan_g | I hadn't though that through, but it sounds plausible | 18:06 |
| kdub | yeah | 18:07 |
| kdub | i get an hour of overlap with duflu, will chat with him about it on monday | 18:07 |
| kdub | since its already tomorrow in australia | 18:08 |
| alan_g | ack | 18:08 |
| alan_g | It is already weekend here. ;) | 18:08 |
| === alan_g is now known as alan_g|EOW | ||
| kdub | i know, every friday, i'm like 'i'm the last one that gets a weekend :(' | 18:08 |
| kdub | but every sunday, i'm like 'i'm the last one still on the weekend :)' | 18:08 |
| kdub | racarr can probably relate | 18:09 |
| Kaleo | greyback, well done! | 18:09 |
| alan_g|EOW | But the last to get up on a Monday morning | 18:09 |
| greyback | Kaleo: ta | 18:09 |
| kdub | greyback, with the gnex or nexus4? | 18:10 |
| alan_g|EOW | greyback: I'll be very interested in how and any issues you ran into. (But not until next week) | 18:10 |
| greyback | kdub: working on nexus4, framerate bad, but same with mir_demo_server_shell, so think it a problem | 18:10 |
| greyback | alan_g|EOW: a few things I had to hack into Mir, but not much to get it working | 18:11 |
| alan_g|EOW | Bye all! Have a good one. | 18:11 |
| kdub | greyback, ah, okay... i don't really know why you're seeing that | 18:11 |
| greyback | kdub: yep, weird alright | 18:12 |
| kdub | greyback, but i was spiking on overlays | 18:12 |
| greyback | kdub: as I said in the mail, I'm not asking for help, was just an FYI | 18:13 |
| kdub | greyback, right | 18:13 |
| greyback | it's just weird tho :) | 18:13 |
| kdub | greyback, so does that use mir's ms::SurfaceStack? or does it do something else | 18:14 |
| kdub | really, I think we can boil the communication we need with the GL compositor down to | 18:16 |
| greyback | kdub: it doesn't rely on SurfaceStack - but this is just iteration 1. I get the surfaces from the SessionListener events | 18:16 |
| kdub | greyback, ah, okay | 18:16 |
| greyback | kdub: this is an early prototype, so that's not a permanent decision or anything. Was just most convenient | 18:18 |
| kdub | greyback, right | 18:18 |
| kdub | greyback, i think as long as qt's renderer can skip some surfaces, we can work bypass and overlays into the render pass | 18:19 |
| greyback | kdub: when a surface is created by Mir, I wrap it with a QQuickItem (so that it can be used in QML). That QQuickItem then can specify the texture to be used in the scenegraph engine | 18:19 |
| kdub | without the compositor having to know about bypass or overlays | 18:19 |
| greyback | +1 that's my thinking too | 18:19 |
| greyback | and not hard to do | 18:19 |
| kdub | okay, cool | 18:19 |
| greyback | what I think will be most tricky is deciding /when/ can use bypass/overlays | 18:20 |
| kdub | greyback, right, but as long as mir can understand the intended composition | 18:20 |
| kdub | it can decide, based on the hardware, and the platform, what would be best | 18:21 |
| greyback | right | 18:21 |
| mhall119 | hey guys, I know there's a screenshot script for some of the nexus devices running Mir, but are there plans to build in a more reliable way of getting screenshots and screenrecordings from Mir? | 18:41 |
| dandrader | mhall119, well, I just started on a task for providing a way for autopilot to get screenshots | 18:44 |
| dandrader | mhall119, something along the lines of unity8 exposing a d-bus method to be called for that. | 18:45 |
| mhall119 | could that be extended to do recordings too? | 18:46 |
| sarnold | .. or vnc? | 18:46 |
| dandrader | mhall119, the task is about just screenshots. Which is what autopilot folks are asking for | 18:47 |
| mhall119 | does it return the screenshot over dbus, or just trigger it with dbus and then access it via the filesystem (or some other method)? | 18:49 |
| dandrader | mhall119, I think it will just a filename will be exchanged... | 18:49 |
| mhall119 | ok, so in theory it could do something similar for video | 18:50 |
| dandrader | mhall119, I don't know. I have absolutely no experience with screencasts | 18:51 |
| mhall119 | ok | 18:52 |
| dandrader | eow | 18:54 |
| kgunn | alf_: you still on ? | 18:56 |
| kgunn | kdub: or racarr could one of you sanity review https://code.launchpad.net/~mir-team/mir/v0.1.2/+merge/196359 | 18:57 |
| mhall119 | kgunn: being able to record an app in-use on a device with Mir is something app developers are going to want, what do I need to do to get this on your radar/roadmap? | 18:57 |
| kdub | okay | 18:57 |
| kdub | kgunn, what do you mean by sanity review? :) | 18:57 |
| kgunn | kdub: meaning...review and approve...it should just be dev going to trunk | 18:58 |
| kgunn | kdub: so mainly the debian bits | 18:58 |
| kgunn | version | 18:58 |
| kgunn | s | 18:58 |
| kdub | okay | 18:58 |
| kgunn | mhall119: well...its interesting | 18:58 |
| kgunn | mhall119: trouble is | 18:58 |
| kgunn | mhall119: we don't want to just let apps read from the fb | 18:58 |
| kgunn | its kinda anti-security | 18:58 |
| kgunn | an app could certainly read from its own back buffer before it gets composited | 18:59 |
| sarnold | kgunn: users are going to want vnc or nx or something similar | 19:01 |
| kgunn | sarnold: mhall119 please bring up monday when tvoss is back..i'm well aware but we need something that's cohesive with our security story...and things like "my random remote desktop app" just might not work..we might have to have a signing process or something.... | 19:04 |
| kgunn | mdeslaur: ^ thots ? | 19:04 |
| kgunn | bbiab | 19:04 |
| mdeslaur | capturing a video or a screenshot is definitely a privileged operation | 19:05 |
| mdeslaur | we want to make sure that the user is able to control that, not confined applications | 19:06 |
| mdeslaur | having it live in unity is the right place | 19:06 |
| mdeslaur | and we can enforce both access to the dbus call to trigger it, and to the file storage location once it's written out | 19:06 |
| sarnold | heh, I _do_ want to confine the vncd .. :) | 19:07 |
| mdeslaur | sarnold: yes, the design should allow for trusted apps, such as a vnc daemon, or an alternative keyboard | 19:08 |
| mdeslaur | by "confined applications", I meant "arbitrary untrusted confined application" | 19:08 |
| sarnold | okay, good :) | 19:08 |
| mdeslaur | ie: not stuff from the app store | 19:09 |
| mhall119 | kgunn: will so | 19:19 |
| mhall119 | kgunn: my assumption is that an app would need permission to request a screen recording, or use the content hub to request it without app permissions, then it will be given access to read from a local socket or something | 19:20 |
| mhall119 | or what mdeslaur said, if I had bothered to finish reading the scrollback before commenting :) | 19:20 |
| mhall119 | but yes, no arbitrary access to the FB | 19:21 |
| ricmm | rafalm_: ping | 20:46 |
| ricmm | crap, wrong person | 20:46 |
| ricmm | racarr: ping | 20:46 |
| racarr | ricmm: Pong | 20:58 |
| ricmm | racarr: is the msh::Session for the server expected to be null? | 21:00 |
| ricmm | you set it to null when creating the surface for the shell in papi | 21:00 |
| ricmm | just wondering if thats expected | 21:00 |
| racarr | Yes. | 21:00 |
| ricmm | ok | 21:00 |
| racarr | though maybe its an abuse of API so its possible not everyone knew about this | 21:00 |
| racarr | and some code might expect it | 21:00 |
| ricmm | I wrote some code expecting it and it blew up in my face | 21:01 |
| ricmm | but I went around it | 21:01 |
| ricmm | heh | 21:01 |
| racarr | Thanks for bringing that up actually its a good point to consider in the shell refactoring thread | 21:03 |
| racarr | its weird that a session is the sort of the only way to create a fully functioning surface but the shell doesn't have one | 21:03 |
| ricmm | yup | 21:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!