| duflu | RAOF: Surprisingly, and ignoring the tearing, I could actually *feel* the desktop was more responsive with the PPA intel driver. I suspect that would mostly be due to double vs triple buffering... | 01:23 |
|---|---|---|
| RAOF | Plausibly. | 01:23 |
| duflu | I always thought it was imperceptible before now | 01:24 |
| RAOF | We're ridiculously sensitive to latency, sometimes. | 01:25 |
| thomi | robert_ancell: did you get anywhere with that MP? I fixed the failing CI :-/ | 01:32 |
| robert_ancell | thomi, what's the link? | 01:32 |
| robert_ancell | thomi, 'add-mir-stress'? | 01:33 |
| === kode54_ is now known as kode54 | ||
| robert_ancell | thomi, did the client API not get fixed for leaking descriptors yet? | 01:35 |
| thomi | robert_ancell: https://code.launchpad.net/~thomir/mir/add-mir-stress/+merge/167661 | 01:37 |
| thomi | robert_ancell: it was fixed, but then it broke again | 01:37 |
| thomi | robert_ancell: so I want to get this as part of a CI run, to apply some pressure to not have it break again in the future | 01:38 |
| robert_ancell | yep | 01:38 |
| thomi | sorry for the delay - I did a dist upgrade and now saucy unity crashes every time I click anywhere in firefox :-/) | 01:38 |
| robert_ancell | unity in saucy also went super-unstable when switching to saucy | 01:40 |
| thomi | robert_ancell: thanks for the review. I like your package name better, so I'll chaneg it & then hit the button | 01:45 |
| === harrow` is now known as harrow | ||
| robert_ancell | thomi, with one last merge I think the lightdm tests (i.e. make check) should finally run on a server - what do we do to enable them in Jenkins? | 05:08 |
| thomi | robert_ancell: just make them run as part of the package build | 05:29 |
| thomi | something about roverriding dh_auto_test ? | 05:29 |
| thomi | override_dh_auto_test: | 05:30 |
| thomi | in debian/rules | 05:30 |
| thomi | to run your tests | 05:30 |
| thomi | and done! | 05:30 |
| robert_ancell | thomi, oh duh. Cheers! | 06:52 |
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| === mmrazik is now known as mmrazik|ofp | ||
| alf_ | RAOF: hi | 08:44 |
| === mmrazik|ofp is now known as mmrazik | ||
| robert_ancell | pete-woods, hey, did the LightDM test changes make sense? Do you want to have a call? | 09:12 |
| pete-woods | robert_ancell: I really appreciate you putting the effort in to help me here! | 09:12 |
| pete-woods | I was expecting you to be in bed around now, though! | 09:12 |
| pete-woods | I was going to stay up late tonight | 09:13 |
| robert_ancell | pete-woods, I stay up late on Thursdays otherwise I never have overlap with you guys over that side | 09:13 |
| robert_ancell | pete-woods, I'd be interested if there will be possible at some point to remove the mock service code in test-runner.c and replace it with dbusmock. At the time dbusmock didn't exist but I really needed it then | 09:14 |
| pete-woods | robert_ancell: could you give me a short while to read the changes - I've not looked at them yet | 09:14 |
| robert_ancell | np | 09:14 |
| pete-woods | yeah, dbusmock is awesome | 09:14 |
| robert_ancell | I'll be here another 15 mins | 09:14 |
| pete-woods | okay | 09:14 |
| pete-woods | speed code read! | 09:14 |
| pete-woods | okay, cool, that looks like a nice start | 09:19 |
| robert_ancell | pete-woods, yeah, I hope that shows enough to plug in the other tests | 09:20 |
| pete-woods | robert_ancell: if we want to change the users, what do you think we should do there? | 09:21 |
| pete-woods | re-write the whole passwd file, etc | 09:21 |
| pete-woods | ? | 09:21 |
| pete-woods | should the code there be extracted into a new method that blats the passwd file and corresponding extended user info file? | 09:22 |
| robert_ancell | pete-woods, I'm not sure the case your talking about - you mean having users A B C then replacing them all with D E F? | 09:22 |
| pete-woods | so say a user's name changes, or language, or anything like that | 09:22 |
| pete-woods | robert_ancell: ^ | 09:22 |
| robert_ancell | pete-woods, I'd say add a method to test-runner.c to that can modify user information and yeah, replace the passwd file if necessary and update the accounts service API | 09:23 |
| pete-woods | robert_ancell, okay cool, I'll have a look at doing that | 09:24 |
| pete-woods | as long as you're happy with that sort of change | 09:24 |
| pete-woods | I'm really nervous about disrupting as critical a project as LightDM | 09:24 |
| pete-woods | I don't want 3 million angry geeks ranting at me! | 09:25 |
| robert_ancell | :) That's what the tests are for! | 09:25 |
| pete-woods | but it's the tests I'm screwing with! | 09:25 |
| robert_ancell | yeah, you can do fairly radical things with the test-runner because it's only the tests that trigger that that will be affected | 09:25 |
| robert_ancell | I'll push that MP - I was just keeping it open so you'd notice it | 09:26 |
| pete-woods | okay fair enough, if you're happy with me messing with that, I'll re-do the changes | 09:26 |
| pete-woods | *tests | 09:26 |
| robert_ancell | sorry about that - it's always a pain to have to redo | 09:27 |
| pete-woods | robert_ancell: there is one thing your runner doesn't catch that I'd like it to | 09:27 |
| pete-woods | so the way I structure my dbus tests I make sure you create, destroy, create the service under test multiple times in a single process | 09:27 |
| pete-woods | that way DBus gets upset at you if you don't clean up after youself | 09:27 |
| robert_ancell | i.e. restart accounts service? | 09:27 |
| pete-woods | as in repeat the lifecycle of liblightdm's UsersList object | 09:28 |
| pete-woods | when it is destroyed it doesn't let go of it's reference to the display proxy | 09:29 |
| pete-woods | liblightdm-gobject/user.c | 09:29 |
| pete-woods | g_clear_object(&priv->display_manager_proxy); | 09:29 |
| pete-woods | inside the finalize method | 09:29 |
| robert_ancell | pete-woods, oh, that would be done inside the greeter - i.e. new/unref it a whole lot of times | 09:30 |
| robert_ancell | or create/destroy the greeter object? | 09:30 |
| pete-woods | the actual user list object | 09:30 |
| pete-woods | that's what I was adding the tests for | 09:30 |
| robert_ancell | do you think they'll work well if you make a method in the greeter that does that? | 09:31 |
| pete-woods | what I'm getting at is that I think that the way the tests are run, it'd be nice if they lived inside a single process | 09:31 |
| pete-woods | as that exacerbates resource problems | 09:32 |
| robert_ancell | Yeah, that's the down-side of the current method | 09:32 |
| pete-woods | but, I think it could be changed without affecting your test scripts | 09:33 |
| pete-woods | it'd just be the test framework that would change | 09:33 |
| robert_ancell | The thing is, that liblightdm shouldn't work at all really unless it is set up inside the LightDM environment - so the fact you can use the UserList is a bit of a fluke | 09:33 |
| robert_ancell | In general it requires the connection to the daemon which is harder to mock | 09:34 |
| pete-woods | totally fair | 09:34 |
| pete-woods | I just think that you could do all the set-up and destruction without spawning lots of separate instances | 09:34 |
| pete-woods | it's always amazing how many things you catch when you force all the tests to run in the same env | 09:35 |
| pete-woods | you see how leaky things are (especially with resources) | 09:35 |
| pete-woods | either way, we can at least fix the bug, even if we don't have a regression test | 09:35 |
| robert_ancell | pete-woods, do you mean lightdm_greeter_new multiple times for example? | 09:35 |
| robert_ancell | (from the same process) | 09:36 |
| duflu | ping alan_g | 09:36 |
| pete-woods | robert_ancell, that would probably do it | 09:36 |
| alan_g | duflu: morning | 09:36 |
| duflu | alan_g: Evening | 09:36 |
| duflu | alan_g: What kind of "using directive" did you mean here: https://code.launchpad.net/~vanvugt/mir/move/+merge/162487/comments/358815 | 09:37 |
| duflu | ? | 09:37 |
| pete-woods | robert_ancell: I guess what I mean is do something like call test-runner with a list of all the test scripts, then it would run each of them in the same process | 09:37 |
| pete-woods | including all the setup and tear down | 09:37 |
| robert_ancell | pete-woods, oh, I understand | 09:37 |
| robert_ancell | pete-woods, yeah, the best you can get is to make a test that does 100 iterations etc | 09:37 |
| * alan_g looks | 09:37 | |
| robert_ancell | the downside is it's very hard to link up valgrind etc and analyse the greeter that was run | 09:38 |
| pete-woods | robert_ancell: if you ran each of them under a g_test instance you could even get a nice report about which of them failed | 09:38 |
| robert_ancell | and you get coverage analysis | 09:38 |
| alan_g | duflu: "using DefaultServerConfiguration::set_session_manager;" | 09:38 |
| pete-woods | true! | 09:38 |
| robert_ancell | pete-woods, I'm open to improved tests, I'm just worried about two similar but different test frameworks to support | 09:39 |
| pete-woods | robert_ancell: I totally understand, I'm saying we could improve the existing tests here | 09:39 |
| robert_ancell | I think if we could get dbusmock into the existing tests or share some code it would probably work. But it would be quite some work | 09:39 |
| robert_ancell | pete-woods, please do! :) | 09:39 |
| pete-woods | yes! | 09:39 |
| pete-woods | I don't really have time to go crazy, though | 09:40 |
| pete-woods | damn full-time job ;) | 09:40 |
| robert_ancell | pete-woods, you don't need to sleep right? | 09:40 |
| pete-woods | robert_ancell: I think some people at canonical don't seem to sleep | 09:40 |
| robert_ancell | that's been my assumption | 09:40 |
| duflu | alan_g: Maybe I'm rusty, but I don't see what that solves. It's WindowManager::set_session_manager that is introduced | 09:42 |
| alan_g | duflu: then I probably meant something I didn't say... | 09:44 |
| duflu | alan_g: OK forget about it for now. I'll ask for clarification later when I repropose | 09:44 |
| alan_g | duflu: https://code.launchpad.net/~vanvugt/mir/move/+merge/162487/comments/358816 | 09:44 |
| duflu | alan_g: Yeah that change at "195" doesn't exist any more. Someone else already committed the same thing on trunk :) | 09:45 |
| * alan_g forgets about it (for now) | 09:46 | |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === seb128_ is now known as seb128 | ||
| === alan_g is now known as alan_g|lunch | ||
| hikiko | question: how do you: start the mir server, run a mir client and stop it from a tty? (atm i kill it with ssh :P) | 12:17 |
| hikiko | +is it possible to run mir on a vm? | 12:17 |
| alan_g|lunch | hikiko: http://unity.ubuntu.com/mir/using_mir_on_pc.html | 12:30 |
| hikiko | i tried this alan_g|lunch but I couldn't switch to other terminals or start the client | 12:30 |
| hikiko | and I had to kill it through ssh | 12:31 |
| hikiko | hmm sorry I wasn't root but still when I run the mir demo client I get seg fault | 12:33 |
| === greyback is now known as greyback|food | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | hikiko: are you running trunk? | 12:55 |
| alan_g | and is it the client or server that segfaults? | 12:55 |
| hikiko | alan_g, it was the client, now it's ok, I had a 2nd server running in the background that's why | 13:05 |
| hikiko | sorry | 13:05 |
| alan_g | hikiko: so you're OK now? | 13:05 |
| hikiko | yes | 13:05 |
| alan_g | cool | 13:05 |
| hikiko | everything working fine | 13:05 |
| === greyback|food is now known as greyback | ||
| === seb128_ is now known as seb128 | ||
| alan_g | alf__: hikiko - I'm currently blocked on CB, is there anything I can lend a hand with? | 14:24 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| alf__ | alan_g: is there something we can do to unblock you? | 14:34 |
| alan_g | alf__: kdub_ is having a look. So probably best not to disrupt what you're doing. | 14:35 |
| === alan_g is now known as alan_g|afk | ||
| hikiko | alan_g, sorry I just saw it | 14:35 |
| hikiko | what is the cb? | 14:35 |
| === alan_g|afk is now known as alan_g|tea | ||
| alf__ | hikiko: composition bypass | 14:36 |
| hikiko | sorry if I sound too naive but what is the composition bypass? | 14:36 |
| alf__ | hikiko: it's when a client renders directly to the framebuffer instead of a normal surface | 14:38 |
| alf__ | hikiko: usual scenario for this is when a game goes fullscreen | 14:39 |
| hikiko | so you have to make active the framebuffer (set colorbuffer etc) and then bind? | 14:40 |
| hikiko | hmmm | 14:40 |
| hikiko | well I don't know well the mir codebase but you mean when for example you go to the system compositor, you create a texture with width/height the virtual screen height and you redirect all your rendering to the texture and then you fill the compositors bo with that texture and you render? | 14:41 |
| === alan_g|tea is now known as alan_g | ||
| hikiko | (i should put some commas on that :p) i hope yuo make sense | 14:42 |
| hikiko | i mean is that a framebuffer? a full screen texture? | 14:43 |
| hikiko | or you refer to something else? | 14:43 |
| hikiko | eg the linux fb0 device or sth else | 14:43 |
| alf__ | hikiko: framebuffer= the block of graphics memory that gets display on the screen by the graphics card | 14:43 |
| hikiko | ok so you don't refer to the FBO in GLES | 14:44 |
| alan_g | hikiko: on android I'm trying to pass out the framebuffer to the client. (But when the client calls eglSwapBuffer the buffer isn't returned to the server.) | 14:44 |
| alf__ | hikiko: what we want is for clients to be able to render directly to screen, instead of on a surface which we then render/composite onto the screen | 14:46 |
| hikiko | so you need to have a shared framebuffer | 14:46 |
| hikiko | and the client to have the full control there | 14:46 |
| hikiko | isn't it? | 14:46 |
| hikiko | I mean the client to have the ability to render directly to the fb | 14:47 |
| alan_g | yes | 14:47 |
| hikiko | and you provide a callback to the client for rendering for example? | 14:47 |
| hikiko | like those in the client library? | 14:48 |
| alan_g | The client renders to the frambuffer, calls next_buffer and the server swaps the FB to the display. (In theory) | 14:49 |
| hikiko | alan_g, is it possible that your framebuffer is empty because you already sent it to the gpu with some make current in the wrong place ? (I guess no but I just say the most obvious mistake I can think of) | 14:49 |
| alan_g | hikiko: when the client calls eglSwapBuffers I expect a call to next_buffer - but that doesn't happen. kdub_ is most familiar with the android blobs and is looking into it... | 14:51 |
| hikiko | next buffer is a mir client isn't it | 14:52 |
| alan_g | yes | 14:52 |
| hikiko | method* | 14:53 |
| hikiko | then how eglSwapBuffers will call a mir method? | 14:53 |
| alan_g | hikiko: I guess my problem is more interesting than yours? | 14:53 |
| hikiko | lol | 14:54 |
| hikiko | ok I don't comfuse you anymore | 14:54 |
| alan_g | hikiko: I don't mind, but I don't want to divert you from more useful work. | 14:55 |
| alan_g | egl is supplied with a bunch of function pointers. One of which leads to next_buffer | 14:56 |
| alan_g | and if a normal buffer is used next_buffer gets called after rendering. | 14:57 |
| hikiko | I didn't know that egl has callbacks, interesting to know | 14:58 |
| kdub_ | hello, status, starting to dive into comp bypass, shepherding branches and cleanups too | 15:03 |
| alan_g | status: deciding what to do while kdub_ dives into CB | 15:04 |
| * alan_g has discovered that saucy is unstable on his netbook | 15:05 | |
| kdub_ | alan_g, no exciting news so far, going to tinker with some small test programs for a while to explore what's happening | 15:08 |
| alf_ | status: experimenting with various approaches for providing surface snapshots, leaning towards having a separate thread in mir for this purpose | 15:09 |
| alan_g | kdub_: at least I don't feel I missed something obvious. ;) | 15:10 |
| alf_ | status2: (also for snapshots) working on providing BufferSwapper::compositor_peek() | 15:13 |
| kdub_ | alf_, hmm. if the only 'lastposted' buffer is given out to the compositor, how would that work? | 15:14 |
| kdub_ | we could retain the reference to the 'lastposted' buffer in the swappers, and then allow 2 threads to compositor_acquire that buffer | 15:15 |
| alf_ | kdub_: yes, we need to keep information about which buffer the compositor has acquired | 15:17 |
| kdub_ | i've thought recently that compositor_{acquire,release} and client_{acquire, release} would be better if they were consumer_{} and producer_{} | 15:18 |
| alf_ | kdub_: but we need a separate peek() method that doesn't dequeue the buffer. We don't want snapshots to cause the compositor to drop frames. | 15:19 |
| alf_ | kdub_: I like the idea | 15:19 |
| kdub_ | alf_, i'm saying like, if we have a snapshotter and a compositor who both get the same buffer, we would have to wait for them to both release before triggering buffer advancement in the swapper | 15:20 |
| kdub_ | it would be cool even if the separate thread was a SnapshottingCompositionStrategy : public CompositingStrategy, then we could use the gpu to copy the buffer into thumbnail-size resolution and use the gpu's capability to scale the image | 15:22 |
| alf_ | kdub_: sure, but we shouldn't allow the snapshotter to make the compositor miss a buffer. If we just have normal acquire/release, then imagine: snapshotter acquires buffer, is done, releases buffer back to client, compositor acquires the next buffer => frame lost | 15:24 |
| kdub_ | ah, so the essence of the new function is that compositor_acquire would be required to advance the buffer | 15:25 |
| kdub_ | but peek_buffer would not trigger an advance on the return of the buffer it 'peeked at' | 15:25 |
| alf_ | kdub_: right, and of course if a buffer is being peeked at it will not return to the client until it is released by the peeker (is there such a word?) | 15:28 |
| alf_ | kdub_: and the change to producer/consumer make even more sense now that we have another type of consumer (the snapshotter) | 15:30 |
| kdub_ | alf_, right, the generic plan sounds good then :) | 15:32 |
| alan_g | kdub_: alf_ do we actually need to hand out the buffer to the snapshotter? Wouldn't ExecuteAroundMethod be a better idiom? | 15:37 |
| alf_ | alan_g: do you mean something like BufferSwapper::with_compositor_buffer_do(std::function<void(Buffer&)> const&) ? | 15:44 |
| alan_g | alf_: exactly | 15:45 |
| alan_g | if could also do that on the compositor side, then - at least in theory - both the compositor and the snapshotter could access the buffer concurrently. | 15:47 |
| kdub_ | i guess either way, the buffer would be delayed the same potential amount of time | 15:47 |
| alan_g | *if we | 15:47 |
| alf_ | alan_g: At first glance that could work, and I like the idea. Need to think through the locking/delay implications. | 15:47 |
| kdub_ | with peek_buffer() it could be concurrent too though | 15:48 |
| kdub_ | although i like the idea too | 15:48 |
| alan_g | kdub_: I was thinking the the swapper lost the buffer between the calls? | 15:49 |
| kdub_ | right, either way (execute-around or a new method) we'll have to change it so we never loose the reference in the swapper for the compositor buffer | 15:50 |
| kdub_ | lose | 15:50 |
| alf_ | kdub_: So, yeah, perhaps we wouldn't need to lock the entire operation and get the best of both worlds. In particular, perhaps do what would be needed to "peek" the buffer, but don't give it out, process it through the callback. | 15:50 |
| alf_ | but I need to think through the details... | 15:52 |
| kdub_ | sure, i think both would work, and both would have worst case delay of (compositing-time + snapshotting time) | 15:52 |
| kdub_ | but best case delay of max(compositing-time, snapshotting-time) | 15:52 |
| alan_g | agreed | 15:54 |
| racarr | Morning | 15:56 |
| alf_ | kdub_: alan_g: best case delay from the compositor's perspective is 0 (if snapshotting begins and ends while the compositor doesn't need the buffer), worst case is snapshotting time | 15:56 |
| alan_g | Afternoon | 15:56 |
| kdub_ | racarr, you have the mesa 'configure' command handy? my compile can't find a symbol for '_glapi_tls_Dispatch' | 15:57 |
| alf_ | kdub_: do you mean delay as in how much time the buffer is in use? | 15:58 |
| kdub_ | right, how long it is in use as a 'consumer' buffer | 15:58 |
| racarr | kdub_: Uhhhh so I have seen that beore and got it from something weird but the configure command is | 15:59 |
| racarr | ./configure --disable-gallium-egl --enable-gles1 --enable-gles --with-egl-p\ | 15:59 |
| racarr | latforms=x11,drm,mir,wayland --enable-gbm --enable-shared-glapi --with-gallium-\ | 15:59 |
| racarr | drivers=r300,r600 | 15:59 |
| alf_ | kdub_: right, so I guess that's delay from the client's perspective | 15:59 |
| alan_g | alf_: snapshotting shouldn't need to delay compositing (they should both treat the buffer as immutable) | 16:00 |
| alf_ | alan_g: kdub_: yes you are absolutely right, probably time to end my day :) | 16:00 |
| kdub_ | racarr, thanks | 16:03 |
| === mmrazik is now known as mmrazik|afk | ||
| === kdub_ is now known as kdub | ||
| kdub | with swapper-swapper, i can't decide if having an empty swapper and filling it later with buffers (such as adopt_buffer(mc::Buffer)) is 2 step initialization or not :) | 16:21 |
| alan_g | Is it a precondition of using it that it is filled? | 16:23 |
| kdub | in swapper-swapper's current state, i decided that it was, hence, i bundle the factory function and send it down via function interface | 16:26 |
| alf_ | kdub: alan_g: right now compositor_acquire() assumes that it always has a buffer | 16:26 |
| kdub | right, so i guess it is | 16:26 |
| kdub | maybe the solution is to have the SwapperMaster have the SwapperFactory, and it can alloc the new swapper | 16:27 |
| alf_ | all: Have a great rest of day. Talk to you tomorrow! | 16:27 |
| kdub | instead of having BufferBundle kick a lambda down to indicate a change | 16:27 |
| racarr | alf_: Bye | 16:27 |
| kdub | you too alf_ | 16:27 |
| alan_g | Bye alf_ | 16:27 |
| * alan_g sees a fight coming: ~robertcarr/mir/display-sizes-are-unsigned vs ~vanvugt/mir/move | 16:51 | |
| racarr | what | 16:57 |
| racarr | oh | 16:58 |
| racarr | I see | 16:58 |
| racarr | haha | 16:58 |
| alan_g | Goodbye all - have a good one! | 16:58 |
| === alan_g is now known as alan_g|life | ||
| racarr | See you! | 16:59 |
| racarr | New platform-api branch is done except for some packaging bits that Gerry is going to help me with at ~robertcarr/platform-api/mir2 | 18:01 |
| racarr | moving on to qtubuntu now which should just be small things. Hopefully have things unity8 running on platform-api-v2/mir tomorrow | 18:01 |
| kdub | racarr, very cool | 18:33 |
| kdub | racarr, if you have time, could you look over swapper-swapper? many eyes make for better thread code :) | 18:33 |
| racarr | kdub: Ok I will try. I know I said I would a few days ago then i got distracted by the stress test thread code XD | 18:40 |
| racarr | I think I can do it after lunch though, before moving on to qtubuntu | 18:40 |
| racarr | also by the end of lunch hopefully they will be done turning the concrete on the road in to | 18:41 |
| racarr | powdered concrete | 18:41 |
| racarr | and I might be able to focus long enough to do a review XD | 18:41 |
| kdub | racarr, thanks :) threading code reviews are funnier than the straightforward ones | 18:42 |
| kdub | because the reviews process ends with ' well, can't find anything wrong', instead of 'looks good to me' ;) | 18:43 |
| racarr | kdub: But what about the mathematical proof of the display server | 18:44 |
| racarr | Lunch! back soon | 18:49 |
| === mmrazik|afk is now known as mmrazik | ||
| kdub | i've worked out this fun way of bouncing c++ compile errors between clang and gcc to get the quickest reading on the problem for every situation | 19:37 |
| racarr | Annnd back | 19:44 |
| racarr | kdub: ? | 19:44 |
| racarr | or do you just mean you go back and forth betwween them | 19:45 |
| racarr | because that's what I do XD | 19:45 |
| kdub | we just need a 3rd or 4th compiler toolchain, then we'd be really quick at diagnosing google mock explosions ;) | 19:49 |
| racarr | kdub: Ok going to review swapper swapper now | 19:59 |
| racarr | kdub: I think alan's last comment about bundling up was about | 20:16 |
| racarr | the signature appearing so frequently it should be a composite type (vector reference bufers, size_t) | 20:16 |
| racarr | I'm not sure, I was just thinking it's hard or me to understand size_t& original_size in end_responsibility | 20:17 |
| racarr | but I am not very far yet :) | 20:17 |
| kdub | the difference there is that during a switch, the number of buffers the dying swapper is responsible for can be different than the number of buffers the dying swapper is curerntly in possession of | 20:18 |
| racarr | Mm | 20:26 |
| racarr | ok I think I understand what is supposed to happen/the overall control flow now | 20:26 |
| racarr | kdub: I also don't understand why BufferSwapperMaster extends BufferSwapper | 20:28 |
| racarr | but that's ok for now I gues | 20:28 |
| kdub | the SwapperSwitcher has to redirect returning buffers from the swapper that was destroyed to the new swapper | 20:31 |
| kdub | really, I expect BufferSwapperMaster and BufferBundle to merge | 20:31 |
| racarr | mm, so SwapperSwitcher implement BufferSwapperMaster and BufferSwapper | 20:31 |
| racarr | but they are two interfaces? | 20:32 |
| kdub | no, i think of it as a BufferSwapperMaster is a BufferSwapper that can also change between algorithms | 20:32 |
| racarr | Mm | 20:34 |
| racarr | kdub: Ok I think the locking makes sense. The one thing I am hung up on now | 20:35 |
| racarr | is why the exception for control flow in SwapperSwitcher. | 20:35 |
| racarr | Can't it be anticipated that | 20:36 |
| racarr | swapper->client_acuire will throw forced_completion | 20:36 |
| racarr | by updating some member variable in change_swapper | 20:37 |
| kdub | no, because the client could have entered its wait long before the command to change the swapper comes in | 20:37 |
| racarr | Mm right... | 20:39 |
| racarr | kdub: Hmm, so | 20:39 |
| racarr | is it so/is it a problem | 20:39 |
| racarr | that, say 2 clients are waiting, and the swapper changes | 20:39 |
| racarr | they are no longer guaranteed to get buffers in the order | 20:40 |
| racarr | they requested them | 20:40 |
| kdub | hmm, thinking | 20:40 |
| racarr | right, because they are woken up at the same time after blocking when they handle the forced completion exception, then it's a race to call client acquire the second time | 20:41 |
| kdub | well, as it is now, the client only has one buffer at a time | 20:41 |
| racarr | der! | 20:42 |
| kdub | and it would be a race in BufferSwapperMulti as well, so I don't think its a problem | 20:42 |
| racarr | Sorry, silly questions, it's just not very well loaded in my head | 20:42 |
| racarr | mm | 20:42 |
| kdub | racarr, np, they're good questions to think about | 20:43 |
| racarr | kdub: Is SwatcherSwitcher::end_responsibility a real TODO? | 20:44 |
| racarr | what should it do... | 20:44 |
| racarr | Swapper* XD | 20:45 |
| racarr | SwatcherSwitcher might be a nice color management object though | 20:45 |
| kdub | racarr, it is, technically, it should return the bu ffers to whoever owned it... i'd expect that as I do another pass on the interface (and the BufferBundle interface) that function would go away | 20:45 |
| racarr | Mm makes sense. | 20:50 |
| racarr | tests make sense :) cool test for RWLock | 20:50 |
| racarr | kdub: I am a little suspiscious of | 20:51 |
| racarr | test_swapping_swappers | 20:51 |
| racarr | .cpp | 20:51 |
| racarr | because you can comment out the implementation of change_swapper and it still passes ;) | 20:51 |
| racarr | but I can understand how it's useful as a stress integration test... | 20:52 |
| racarr | um | 20:52 |
| racarr | I don't know it might be nice if there were a different filename like stress_test_swapping_swappers so people like me don't look for how it tests swapping swappers | 20:53 |
| racarr | but that's not a huge problem either and the test names clear it up really | 20:53 |
| racarr | kdub: Ok! LGTM | 20:55 |
| racarr | I didn't really go through for whitespace/style because I guess Alan/Alexandros did | 20:56 |
| kdub | racarr, well, if you comment out change_swapper, it is just tests that the swappers in normal conditions work ok. the change_swapper() is the essential part | 20:56 |
| racarr | but am pretty convinced on the logic | 20:56 |
| kdub | racarr, thanks! | 20:56 |
| racarr | kdub: Right, but I mean the test file name implies | 20:56 |
| racarr | that it tests, the swapper changing functionality works | 20:56 |
| racarr | whereas in fact even if it doesn't, the test can still work. | 20:56 |
| kdub | the subtle ways that test failed when I first wrote it were things like, it would hang, or the buffer's references would be lost | 20:57 |
| kdub | so its one of those 'don't hang, don't lose the buffers' sort of tests :) | 20:58 |
| kdub | thanks again though! | 20:59 |
| racarr | no worries! It was interesting | 21:00 |
| bregma | racarr, I understand you can point me at android input drivers for the desktop? | 21:50 |
| racarr | bregma: Maybe! | 22:16 |
| racarr | Can you clarify what you are looking for / expecting, because there aren't userspace drivers for specific input devices like in X11 | 22:16 |
| bregma | racarr, I'm looking for what needs to happen to get Unity8 on the desktop, I understood there was an android-based layer on top of evdev available? | 22:28 |
| racarr | bregma: Yes. | 22:32 |
| racarr | I think nothing special needs to happen (beyond everything else) we have it going on the desktop, it delivers events to Qt, etc. | 22:33 |
| racarr | til: If you want to include symbols in your shared library from a static library and don't reference them internally you need to use -Wl,--whole-archive before your library, but then you also need to use -Wl,--no-whole-archive after your library | 22:36 |
| racarr | because G++ appends its own libraries to the end of your list | 22:36 |
| racarr | Whee, qtubuntu builds again | 22:41 |
| racarr | bregma: Sorry I was pretty distracted XD um | 22:41 |
| racarr | so yeah it's a layer on top of evdev that was originally android code | 22:41 |
| racarr | though we've pulled out all the android dependencies, etc... | 22:42 |
| racarr | and replaced some bits, for example we use xkbcommon for keymapping, etc. | 22:42 |
| racarr | So it should be well suited for the desktop and we are matching it up with Qt, etc. | 22:42 |
| racarr | one thing that is perhaps, a bit of an open question (at least not entirely closed to me, maybe someone knows the answer) | 22:43 |
| racarr | is where/how we will do things that happen in X11 drivers for the desktop, that are of interest | 22:43 |
| racarr | i.e. things like two finger scroll on synaptics | 22:43 |
| racarr | etc | 22:43 |
| kdub | haha, happened across some old mir prototyping code that had a todo in the gl renderer 'todo: replace with nux' | 23:20 |
| racarr | kdub: The normal spelling is 'QML' | 23:26 |
| racarr | XD. Nux is still in RoughArchitecture.png too | 23:26 |
| kdub | haha, yeah | 23:31 |
| kdub | once i cross compiled nux for android, using the android ndk | 23:31 |
| kdub | that was a painful week :) | 23:31 |
| racarr | Mm I bet | 23:51 |
| racarr | just tested and ironed out a few errors and now ran some QML apps on top of platform-api-v2/mir | 23:52 |
| racarr | now I just need to fix key mapping again (mostly deleting the correct code now that we do xkbcommon) | 23:52 |
| racarr | andddddddddd | 23:52 |
| racarr | then something I suppose ;) | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!