| robert_ancell | RAOF, did you have any luck with xmir working? | 02:17 |
|---|---|---|
| RAOF | robert_ancell: I believe it should now; let me check again. | 02:17 |
| RAOF | Unless launchpad has *once again* foiled me. | 02:22 |
| robert_ancell | RAOF, the package did update for me, but still fails to connect to mir | 02:24 |
| RAOF | Ok launchpad. Let's see what you've got for me... | 02:25 |
| duflu | One _million_ bugs (pinky to mouth) | 02:27 |
| robert_ancell | thomi, was CI supposed to work for lp:lightdm/1.6? | 02:44 |
| robert_ancell | (two MPs, no checking done) | 02:45 |
| racarr | I think | 02:45 |
| racarr | I might try and port kmscon | 02:45 |
| racarr | it seems surprisingly hard | 02:46 |
| thomi | robert_ancell: no, I thought we decided that it wasn't worth it - but I can add it to the "things to do in Oakland for mir people" list, if you like :) | 02:46 |
| robert_ancell | thomi, it's nice to have, but not a high priority | 02:48 |
| thomi | yeah that's what I figured | 02:49 |
| racarr | I just want to point out https://code.launchpad.net/~robertcarr/platform-api/mirclient/+merge/160217 to the southern hemisphere :) | 02:54 |
| RAOF | racarr: Port kmscon? Why? | 02:56 |
| duflu | Why not port anything you can? :) | 02:56 |
| racarr | RAOF: I just want a working terminal emulator | 02:56 |
| racarr | kterm isn't qt5 | 02:57 |
| racarr | this qml terminal emulator seems quirky | 02:57 |
| RAOF | Does kmscon have all the various affordances we expect in a decent terminal emulator? Unicode? Colour? | 02:58 |
| * RAOF goes to see why the new new build of xf86-video-intel doesn't XMir properly | 02:59 | |
| racarr | it seems to | 03:03 |
| RAOF | Grr. Who changed the libmirclient API? :) | 03:05 |
| racarr | who didn't! | 03:19 |
| RAOF | Me~! | 03:24 |
| robert_ancell | RAOF, any idea on XMir? So you also don't have XMir working on -intel? | 04:30 |
| RAOF | robert_ancell: So, cascade of failures. | 04:45 |
| RAOF | robert_ancell: The autobuilt xf86-video-intel defaulted to the SNA acceleration architecture, which I haven't yet patched for XMir. | 04:47 |
| RAOF | Once I'd fought launchpad to get a build that defaults to UXA, someone had gone and remove mir_surface_create() from libmirclient, so XMir now doesn't work. | 04:47 |
| === rsalveti_ is now known as rsalveti | ||
| RAOF | Both of these should now be fixed, and you're waiting for 1.13.3-0ubuntu6+xmir2 to appear in the PPA. | 04:48 |
| RAOF | URGH | 04:48 |
| robert_ancell | RAOF, ok, cool | 04:48 |
| RAOF | thomi: Hey, while you're at it, could you get the tests to spin up an XMir server? :) | 04:49 |
| thomi | RAOF: send me an email with the details and I'll look into it at oakland... or bug me about it in oakland :) | 04:49 |
| RAOF | Most assuredly! | 04:50 |
| robert_ancell | thomi, is there a convention for raising QA issues? Should we open bugs on LP projects and assign them to you? | 04:51 |
| thomi | robert_ancell: it rather depends on the issue. There's no project that deals with infrastructure issues, for example | 04:51 |
| thomi | and (thankfully) I'm not having to teach you guys how to write unit tests, so I've not had to actually touch the mir codebase yet | 04:52 |
| thomi | I guess if we think we need a process to stop things getting forgotten about we should figure out what the best approach is | 04:52 |
| thomi | my problem right now is that my time is split between mir and autopilot, and autopilot is consuming close to 90% of my waking hours | 04:53 |
| robert_ancell | thomi, you can we awake for 190% of the time right? | 04:53 |
| thomi | I tried that once, it did not go well | 04:54 |
| robert_ancell | :) | 04:54 |
| RAOF | Ok ladies and gentlemen: A brief bit of client architecture handwaving. | 05:14 |
| RAOF | I'd like to implement n-buffering so that I can implement eglSwapInterval(0) so that the benchmarks we run can be minimally useful. | 05:14 |
| RAOF | There are two broad approaches here - the client always has exactly one buffer, or the compositor always has exactly one buffer. | 05:15 |
| RAOF | In the former you give out multiple buffers to the client library, and the client library is responsible for handling "do I block" and "what is the next buffer to draw to". | 05:17 |
| RAOF | In the latter the server only ever hands out one buffer to the client library at a time, the client library always blocks on IPC, and the server is responsible for "what is the next buffer to draw to" | 05:18 |
| RAOF | The former will have less IPC overhead, and will result in higher benchmark numbers, but the IPC overhead won't be significant for non-benchmark clients anyway. | 05:22 |
| RAOF | You know what? email. | 05:23 |
| robert_ancell | RAOF, yeah, email works for big stuff :) | 05:25 |
| tvoss | RAOF, ping | 05:42 |
| RAOF | tvoss: Pongity pong. | 05:42 |
| robert_ancell | RAOF, well, X doesn't quit anymore. But it does sit at 100% CPU and never generates a ready signal | 05:47 |
| robert_ancell | RAOF, short ML post from you... | 05:48 |
| RAOF | The rest is coming soon. | 05:48 |
| RAOF | robert_ancell: That's odd. Mine got all the way to showing the root weave and not responding to input because I didn't run it as root. | 05:48 |
| RAOF | robert_ancell: To be clear - you get as far as the root weave, yes? | 05:49 |
| robert_ancell | RAOF, no, black screen | 05:50 |
| robert_ancell | RAOF, doesn't appear to be anything exciting in the X log http://paste.ubuntu.com/5594738/ | 05:50 |
| robert_ancell | RAOF, lightdm log, though also shows nothing except for it waiting for the ready signal http://paste.ubuntu.com/5594740/ | 05:51 |
| robert_ancell | but perhaps the command line flags passed to it might indicate something | 05:51 |
| RAOF | Hm. | 05:53 |
| RAOF | Let me see about this locally. | 05:54 |
| RAOF | robert_ancell: Everything works fine here. | 05:58 |
| robert_ancell | RAOF, :( | 05:58 |
| robert_ancell | How are you launching it? | 05:59 |
| RAOF | Xorg :7 -mir 5 -retro -verbose 7 | 05:59 |
| RAOF | Oooh! *That's* why VT switching sometimes takes minutes! | 06:00 |
| RAOF | xf86-video-ati is totally freaked out that I've turned off the radeon on this laptop. | 06:00 |
| mlankhorst | oooh I'm freaked outttt where is my card? where is my card? | 06:01 |
| RAOF | Actually, it looks like it's also confusing radeon.ko, which is being amazed that it can't execute the ATOM BIOS. | 06:02 |
| mlankhorst | how does it even find a valid bios, then? | 06:04 |
| RAOF | Presumably it's cached the bios from boot? | 06:04 |
| RAOF | The card was on at boot, and got switcheroo'd off. | 06:05 |
| mlankhorst | ah | 06:05 |
| robert_ancell | RAOF, ok, will look into that tomorrow | 06:05 |
| robert_ancell | bye all | 06:05 |
| mlankhorst | bb | 06:05 |
| RAOF | robert_ancell: 'night! | 06:05 |
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| kdub | hello, status, mp-ed hwc 1.0 support, working on display logging today | 15:03 |
| alan_g | hello, status, getting laptop in sync with current dev environment | 15:13 |
| kdub | quiet day on the channel | 16:05 |
| alan_g | kdub:I'm here if you need to talk | 16:06 |
| kdub | lol | 16:08 |
| racarr | morning | 16:20 |
| alan_g | afternoon | 16:20 |
| racarr | alan_g: Do you have any idea with demo-shell? | 16:33 |
| racarr | I dont have any besides using a weak_ptr somewhere but I don'tknow where is appropriate | 16:33 |
| alan_g | racarr: I've not been thinking about it today (got distracted elsewhere) | 16:34 |
| racarr | Maybe EventFilterChain holds weak references | 16:34 |
| racarr | to each EventFilter | 16:34 |
| alan_g | racarr: since demo-shell tends to kill leave me with a blank screen I can't get out of I've been disinclined to play | 16:36 |
| racarr | compared to regular mir binary? | 16:36 |
| racarr | vince vt changes things are weird | 16:36 |
| racarr | I have to kill it, then switch to X | 16:37 |
| racarr | to get a screen back | 16:37 |
| alan_g | racarr: I can do that with mir, but not with demo-shell | 16:37 |
| racarr | uhoh | 16:37 |
| racarr | oh | 16:37 |
| racarr | well I just fixed the crash properly | 16:37 |
| racarr | yesterday | 16:37 |
| alan_g | racarr: I gather you agree about the "owner loop"? Or have I missed something? | 16:40 |
| racarr | yes | 16:40 |
| racarr | im just anxious to push things a long | 16:41 |
| racarr | but I don't know how to fix it | 16:41 |
| racarr | besides with a weak_ptr | 16:41 |
| racarr | We are going to have these everywhere | 16:42 |
| racarr | unless we introduce a new pattern | 16:42 |
| alan_g | racarr: weak (or dumb) pointers can certainly break the loop | 16:42 |
| racarr | i.e. the compositing strategy draws a software cursor so it becomes the cursor listener and needs to notify the compositor ofdamage | 16:42 |
| racarr | alan_g: Yeahhh everything still goes in a circle though ;) | 16:43 |
| racarr | I wish there were something better | 16:43 |
| alan_g | there are solutions - e.g. a "RegisterMe" member variable that registers a callback in the constructor and deregisters in the destructor. | 16:44 |
| alan_g | (The registered back-pointer can be a raw pointer, as its guaranteed to point to a live object) | 16:45 |
| alan_g | The thing is that smart_ptr is being used in places where ownership isn't involved. | 16:46 |
| alan_g | But my head isn't yet clear on where the fixes are needed | 16:46 |
| racarr | Most ui frameworks would use | 16:47 |
| racarr | a signalling pattern to break this | 16:48 |
| racarr | i.e. rather than ApplicationSwitcher becoming the EventFilter, application switcher | 16:48 |
| racarr | is allowed to see the KeybindingEventFilter | 16:48 |
| racarr | and registers a callback or whatever | 16:48 |
| racarr | the EventFilter keeps with weak reference, or the signal is expected to be disconnected on shutdown | 16:49 |
| alan_g | If it's blocking you then using weak pointers in EventFilters ought to be enough for now | 16:52 |
| racarr | alan_g: I will propose I think. the thing is it's blocking software cursor | 16:52 |
| racarr | which has the same problem | 16:52 |
| racarr | and over andover | 16:52 |
| racarr | (propose with weak ptrs that is) | 16:53 |
| racarr | you all are in for some excellent weather next week if things continue :) | 16:57 |
| alan_g | Where we are working? Or out of the window? | 16:59 |
| racarr | alan_g: ...hmm good point | 16:59 |
| racarr | though when the day ends at 6 | 17:00 |
| racarr | still an hour and a half of time to have a beer in the sunshine! | 17:00 |
| alan_g | We'll need to find a good beer location | 17:01 |
| racarr | Hehe one night you should come to city beer, which is a store/pub type thing in San Francisco (close to a bart though, about 25 minute travel from hotel) | 17:02 |
| racarr | that is all local beers from the bay area | 17:02 |
| racarr | nearly 100 I would say | 17:02 |
| racarr | *embarassingly excited to be the local at conference for once* | 17:04 |
| racarr | hehe | 17:04 |
| alan_g | You'll be writing the guidebook then? | 17:04 |
| alan_g | Anyway, I've had enough for the day. I'll start looking into managing back pointers tomorrow. (And finish getting laptop to behave.) | 17:06 |
| === alan_g is now known as alan_g|sun | ||
| racarr | alan_g|sun: I'm working on it, it's called "The Great American Novel: A software engineers guide to life in San Francisco" ;) | 17:12 |
| racarr | not really i'd read that though | 17:12 |
| racarr | enjoy :) tty tomorrow | 17:12 |
| === mmrazik is now known as mmrazik|afk | ||
| bschaefer | racarr, hello! Is this what you had in mind when moving some enums over to the mir_toolkit/event.h? | 17:37 |
| bschaefer | http://paste.ubuntu.com/5596121/ | 17:37 |
| bschaefer | which then makes this easier: http://paste.ubuntu.com/5596127/ | 17:39 |
| racarr | bschaefer: https://code.launchpad.net/~robertcarr/mir/add-event-action-defines/+merge/160224 | 17:51 |
| racarr | ;) | 17:51 |
| racarr | so yes! | 17:51 |
| bschaefer | haha | 17:51 |
| bschaefer | well awesome, beat me to it! | 17:51 |
| bschaefer | racarr, did you want to type def them? Though it shouldn't be needed... | 17:52 |
| bschaefer | racarr, nevermind, I see you've commented on that part :) | 17:53 |
| racarr | bschaefer: We also need the modifiers | 17:57 |
| racarr | but in adding them would like to add something using them | 17:58 |
| racarr | so either demo shell after it lands (alt tab instead of tab) or | 17:58 |
| racarr | maybe just tests that | 17:58 |
| racarr | KEY_SHIFT comes out as mir_meta_flag_shift or hwatever its called | 17:58 |
| bschaefer | right, tests for thest shouldn't be to bad if you can mock motion events and tests they line up with the correct enum (for a unit test) | 17:58 |
| bschaefer | racarr, also, what about button state? | 17:59 |
| * bschaefer also wonders if the input platform is subject to change from android | 18:01 | |
| racarr | bschaefer: button state too I guess | 18:04 |
| racarr | hypothetically | 18:05 |
| racarr | but | 18:05 |
| bschaefer | racarr, well I suppose a lot of this can be talked about next week, but im more concerned about a changing input platform :( | 18:05 |
| racarr | more likely is the increasingly forked | 18:05 |
| racarr | droidinput loses the android name | 18:05 |
| racarr | well | 18:05 |
| racarr | its unlikely right! The abstraction exists | 18:05 |
| racarr | but more as a consequence of writing testable well isolated object oriented code | 18:06 |
| racarr | than an intention to replace the input backend | 18:06 |
| racarr | but eventually once all the flags are in place, etc. and everything is defined ina mir_ namespace | 18:06 |
| racarr | that hides all the ANDROID* and android* and integer guessing stuff | 18:06 |
| racarr | you could swap it out! | 18:06 |
| bschaefer | oo yeah, I was just wonder about the enum ordering if the input is different as we can't control how they order their actions :) | 18:07 |
| bschaefer | or I suppose if its forked we can :) | 18:07 |
| bschaefer | right, and changing the enums (onces they are in place) will make that easy | 18:07 |
| racarr | well if you are integrating any input stack you control in to the mir server you can have it emit events over the wire that look like MirEvent in terms of enums, etc | 18:08 |
| racarr | and the worst case is some kind of marshalling, i.e. conversion | 18:08 |
| bschaefer | right, I was thinking of sort of mapping to ensure a mir_motion_action_down is always 0 | 18:08 |
| bschaefer | for the action, but that can be done under the hood for the event.action I suppose (if it ever gets to that point) | 18:08 |
| racarr | Yeah | 18:09 |
| bschaefer | well that answers my question thanks :) | 18:09 |
| racarr | Too much sun? | 18:17 |
| racarr | I think the EventFilterChain holding each filter by weak reference is satisfactory in that case and actually | 18:20 |
| racarr | the software cursor case I was giving was something entirely different | 18:20 |
| racarr | it's already strange that the software cursor renderer has to subclass the compositing strategy | 18:20 |
| racarr | i.e. reimplement all the drawing | 18:21 |
| racarr | just to draw an overlay | 18:21 |
| racarr | so there should be like | 18:21 |
| racarr | the_overlay_renderer() which is passed a change_callback like | 18:21 |
| racarr | the_renderables() | 18:21 |
| racarr | are | 18:21 |
| racarr | *babbles* | 18:22 |
| === kdub is now known as kdub^lunch | ||
| === kdub^lunch is now known as kdub | ||
| racarr | kdub: https://code.launchpad.net/~robertcarr/mir/weakify-event-filters/+merge/160497 is aimed at the circular dependency | 20:47 |
| racarr | indemo shell | 20:47 |
| kdub | cool, will look it over soon | 20:53 |
| racarr | Thanks :) | 20:56 |
| racarr | now to untangle the software cursor one. I think I can do something more satisfactory than just a weak_ptr here with some work on the rendering interfaces | 20:56 |
| racarr | Morning robert_ancell :) | 21:02 |
| bschaefer | racarr, an interesting bug im getting up a mouse released events. That button state is == 0 :(, no matter which key is being released | 21:06 |
| bschaefer | a log: http://paste.ubuntu.com/5596683/ | 21:06 |
| bschaefer | racarr, if you can point me close to some of the mir code I can dig through it :) | 21:07 |
| robert_ancell | racarr, hello | 21:15 |
| racarr | Hi :) | 21:15 |
| racarr | bschaefer: Hmm | 21:16 |
| racarr | I'm not sure exactly where the culprit is! I mean one way to start is to write | 21:16 |
| racarr | a failing integration test with the fixtures in tests/integration-tests/input/android/test_android_input_manager | 21:17 |
| racarr | using the event_filter, rather than an actual server with clients | 21:17 |
| bschaefer | racarr, cool, Ill look into getting a failing test | 21:17 |
| racarr | you use the fake event hub to | 21:17 |
| racarr | synthesize events | 21:17 |
| bschaefer | yeah, I saw some fake MouseDown tests, but none for Up | 21:17 |
| racarr | TEST_F(AndroidInputManagerAndEventFilterDispatcherSetup, manager_dispatches_button_events_to_filter) | 21:17 |
| racarr | does the kind of thing you need | 21:18 |
| bschaefer | sweet, thanks! | 21:18 |
| racarr | but maybe write a new test rather than just expand it :) | 21:18 |
| racarr | feel free to bug me about the APIs, etc :) | 21:18 |
| bschaefer | alright :) | 21:18 |
| bschaefer | racarr, I might have done the test a bit wrong, but it shows the button state always being zero:http://paste.ubuntu.com/5596922/ | 22:43 |
| bschaefer | http://paste.ubuntu.com/5596922/ | 22:44 |
| === Quintasan_ is now known as Quintasan | ||
| racarr | bschaefer: Yay! tests. Ok. Give me just 20-30 minutes to wrap something up and I will | 22:53 |
| racarr | investigate | 22:53 |
| bschaefer | racarr, alright, thanks! | 22:53 |
| racarr | robert_ancell: The overlay renderer is for the software cursor. | 23:38 |
| racarr | it could be a surface but I think it is less conceptually clear as it introduces a lot of | 23:38 |
| racarr | other stuff, i.e. it has to be kept on top (double triple on top) | 23:38 |
| racarr | and the way surfaces are rendered has to change | 23:38 |
| robert_ancell | racarr, yeah, was just wondering if there were strong reasons like the hardware needs to know the difference | 23:39 |
| * kdub has thought about overlays too | 23:39 | |
| robert_ancell | Also wasn't sure if you might need more than one overlay and then it becomes better to use surfaces with an overlay flag | 23:39 |
| racarr | Hmm no no strong reasons like hardware in this case. | 23:40 |
| racarr | I think if you want more than one "overlay" | 23:40 |
| racarr | you implement that in your overlay renderer | 23:40 |
| racarr | the idea is just this is a point for a shell to render, after mir has finished rendering the entire surface stack | 23:42 |
| racarr | I think this is almost definitely how you want to do things like debugging visualizations | 23:42 |
| racarr | with software cursor I considered another approach too... | 23:43 |
| racarr | the shell could implement the_renderables, to contain a surfacestack, andfor_each first does for_each on the surfacestack then emits a renderable for the cursor | 23:43 |
| racarr | but the renderable interface | 23:43 |
| racarr | isn't really prepared to draw anything besides | 23:43 |
| racarr | a surface... | 23:43 |
| racarr | mostly due to the way textures are managed. | 23:44 |
| kdub | racarr, with the overlay manager | 23:54 |
| kdub | how do we coordinate the overlay with the surface stack? | 23:54 |
| kdub | i guess i'm thinking in the more complex world of using the hwc with multiple layers to do overlays | 23:55 |
| racarr | kdub: I don't know yet | 23:59 |
| racarr | I would guess those are in the surface stack and maybe not "overlays" in this sense ovf overlay | 23:59 |
| racarr | right like, a video overlay isnt an overlay in this sense of overlay | 23:59 |
| kdub | yes, and that's sort of what i'm thinking about | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!