| RAOF | racarr: Your mesa fails to build against trunk; but for an obvious reason that I'll just fix up. | 00:07 |
|---|---|---|
| racarr | RAOF: thanks...sorry I have mild | 00:12 |
| racarr | branches inside branches schizophrenia the last 2 weeks | 00:12 |
| racarr | *motions to chalkboard filled with diagrams* | 00:13 |
| racarr | It's all wheels inside wheels...ive seen it....*twitch* | 00:13 |
| RAOF | racarr: Good, that (finally) works. Thanks! | 00:25 |
| * RAOF has a pleasing, but somewhat banded, plasma flying across his display. | 00:25 | |
| * kdub noticed the bandedness too | 00:31 | |
| RAOF | My guess is that it's not using a full 8-bit colour range, but whatever. | 00:33 |
| racarr | RAOF: If you merge receive-input-in-client you can quit the plasma with the q key! | 00:56 |
| racarr | its a revolution in user interaction | 00:56 |
| racarr | ;) | 00:56 |
| racarr | thanks for testing and fixing :) | 00:56 |
| RAOF | Should land in the PPA next time jenkins scans the branches. | 00:58 |
| RAOF | racarr: Got any idea how you'll handle keymaps? :) | 01:01 |
| RAOF | racarr: Do we have to poll() every 10ms for input? | 01:14 |
| * duflu hopes that's a joke | 01:16 | |
| * duflu afk | 01:16 | |
| racarr | RAOF: No there should be a comment there... | 01:16 |
| racarr | maybe I didn't push everything yet | 01:16 |
| racarr | there just needs to be a way to interrupt it so we can use a longer poll time without making shutdown slow (or the test times become huge) | 01:17 |
| racarr | i.e. a wake fd | 01:17 |
| racarr | it might that a droidinput::Looper should be used but | 01:17 |
| racarr | need to sync up with Alan on that in the morning... | 01:17 |
| RAOF | If you expected there to be a comment about the poll(), then you haven't pushed everything :) | 01:17 |
| racarr | RAOF: As for keymaps, currently it is using the android keymap files+format | 01:18 |
| racarr | though only Generic is available :) | 01:18 |
| racarr | I think we will replace it | 01:18 |
| racarr | with libxkb | 01:18 |
| racarr | its pretty well abstracted, in that its just part of the InputReaderPolicy | 01:18 |
| racarr | pushed more changes :) but probably just containing that comment that I just explained | 01:18 |
| robert_ancell | RAOF, I'm thinking that that Mir on X wont be ready by 13.05. Does that sounds right to you (you have a bp item though eleni is working on it right?)? | 02:57 |
| RAOF | robert_ancell: Correct, eleni is working on it. | 02:59 |
| RAOF | I think it could be ready for 13.05 if it's a priority. | 02:59 |
| robert_ancell | RAOF, I'll reassign the item then | 02:59 |
| robert_ancell | It's a very nice to have, but not essential | 03:00 |
| robert_ancell | RAOF, there are two items right, SDL on Mir then X on SDL on Mir right? | 03:01 |
| RAOF | No, just Mir on SDL. | 03:01 |
| * robert_ancell gets confused with order | 03:02 | |
| robert_ancell | yep, that sounds more like it | 03:02 |
| robert_ancell | RAOF, so we already have SDL on X, so mir on sdl = mir on X? | 03:02 |
| RAOF | Correct. | 03:02 |
| robert_ancell | and that was easier than mir on X? | 03:02 |
| RAOF | Eleni's just using SDL as the toolkit for Mir-on-X | 03:02 |
| duflu | It should be equally easy to make Mir on native X after that. The boiler-plate for an X Window and GLX setup isn't that big. | 03:03 |
| duflu | smspillaz: Bored with uni already? | 03:11 |
| tvoss | RAOF, ping | 06:12 |
| RAOF | tvoss: Yo! | 06:12 |
| tvoss | RAOF, ninjaaron asked about libxkb yesterday, too. Will ping him today, he seemed to know a lot about it | 06:14 |
| tvoss | RAOF, perhaps we can get some help | 06:14 |
| RAOF | tvoss: I presume everyone's referring to libxkbcommon? | 06:14 |
| RAOF | Which we should totally use. | 06:14 |
| tvoss | RAOF, yup :) libxkbcommon it is | 06:15 |
| * tvoss is too lazy to type common, no tab completion :) | 06:15 | |
| RAOF | Grr, GMock. | 06:24 |
| tvoss | RAOF, what did you do? can I help? :) | 06:25 |
| RAOF | Verifying that a destructor is called is unnecessarily annoying. | 06:25 |
| RAOF | Or: verifying that a destructor is called in a couple of tests, and not caring in most of them, is unnecessarily annoying. | 06:26 |
| tvoss | RAOF, okay | 06:26 |
| tvoss | RAOF, an existing test? | 06:26 |
| RAOF | tvoss: Cleaning up in https://code.launchpad.net/~raof/mir/buffer-age-misc-cleanups/+merge/155164 | 06:27 |
| tvoss | RAOF, looking | 06:29 |
| duflu | Hmm, I hope we don't end up with XKB (extension) semantics in using libxbkcommon. That was a major problem for Compiz and not something I'd like to see happen in Mir | 06:32 |
| tvoss | duflu, the general idea is that we reuse the existing keymapping solution without pulling in all of the atom handling | 06:33 |
| RAOF | duflu: I don't believe it mandates xkb | 06:33 |
| * RAOF -> baby | 06:34 | |
| duflu | tvoss: Twas only the grab behaviour that was wrong I think. And we're trying to avoid that right now AFAIK | 06:34 |
| tvoss | duflu, yup | 06:34 |
| * duflu wonders how many times the words "Android" and "#include <X11/" need to appear in the Mir source before it's "too much" | 06:38 | |
| duflu | tvoss: Can you point me to the design principle/reasoning/rationale for separating the protobuf from protobuf.wire? | 06:55 |
| duflu | or /pattern | 06:56 |
| tvoss | duflu, not sure what you mean? | 06:56 |
| duflu | tvoss: There are two layers of protocol. There must be a good reason why it's done that way | 06:56 |
| tvoss | duflu, from what I see on trunk, the wire protocol deals with the actual rpc, while the protobuf definition defines the actual types and services that we expose | 06:59 |
| RAOF | duflu: AFAIK "#include <X11/" is nowhere in the Mir source? | 06:59 |
| duflu | tvoss: Yeah I can see that. But I don't yet understand why we need to abstract an abstraction (wrap protobuf in protobuf). I need to understand more of the "why" | 07:00 |
| duflu | RAOF: Not yet, but potentially when we use libxkbcommon :) | 07:00 |
| duflu | -need + want | 07:00 |
| tvoss | duflu, can you check with alan_g please? I remember there was a reason ... but I'm otp right now :) | 07:01 |
| duflu | Kay | 07:01 |
| RAOF | duflu: There's no X11/ in libxkbcommon :) | 07:06 |
| duflu | Whee, small win | 07:10 |
| * duflu thinks this looks like a hack: /usr/include/xkbcommon/xkbcommon.h | 07:17 | |
| duflu | One designed for Weston? | 07:17 |
| tvoss | duflu, hack in what respect? | 07:20 |
| duflu | tvoss: The name "xkb..." and yet it has no dependency on *XKB* stuff under X11/. Seems a bit backwards. Thought that could be resolved simply with better naming | 07:21 |
| tvoss | duflu, that's a good point actually. While reading through the library I though about a name along the lines of libkeymap :) | 07:22 |
| RAOF | Wooo! | 08:13 |
| RAOF | I win the “work around annoying bits of gmock” award. | 08:13 |
| tvoss | RAOF, \o/ | 08:36 |
| === alan_g is now known as alan_g|afk | ||
| === AlanChicken is now known as AlanBell | ||
| === alan_g|afk is now known as alan_g | ||
| duflu | Argh. I hate it when Europe wakes up. No offence :) | 09:17 |
| smspillaz | RAOF: the re-entrancy rule strikes again ? | 11:24 |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === cjohnston_ is now known as cjohnston | ||
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| === Saviq_ is now known as Saviq | ||
| === alf___ is now known as alf_ | ||
| kdub | morning | 15:05 |
| tvoss | kdub, good morning :) | 15:06 |
| UbuPhillup | hi | 15:07 |
| kgunn | kdub: ping | 15:14 |
| racarr_ | Morning | 15:15 |
| tvoss | racarr_, good morning :) | 15:17 |
| kdub | kgunn, pong | 15:20 |
| alan_g | racarr_: Morning. Looking into the Looper thing. Is definitely a difference in behaviour, not worked out why yet. | 15:27 |
| racarr_ | alan_g: Thanks :) | 15:27 |
| racarr_ | I am wondering, how it was supposed to work as it stands, as it seems like the deadline timer is unused? | 15:27 |
| racarr_ | (Wondering if there is some bit of boost asio I do not understand) | 15:28 |
| alan_g | racarr_: is all asio magic to me - tvoss seems to understand (or have a bit more experience of) this stuff | 15:29 |
| tvoss | alan_g, racarr_ can you point me to the bit that is not working? | 15:29 |
| alan_g | tvoss: the bit racarr_ is referring to is Looper::pollOnce(int timeoutMillis) with timeoutMillis > 0 | 15:31 |
| racarr_ | tvoss: It works with the android::Looper implementation but not with our boost::asio based implementation :) | 15:32 |
| racarr_ | it's all described in here https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 | 15:32 |
| racarr_ | "Currently this is failing to work with MIR_INPUT_USE_ANDROID_TYPES=false ...." | 15:32 |
| tvoss | alan_g, racarr_ looking ... | 15:32 |
| racarr_ | three items I could take up | 15:52 |
| tvoss | racarr_, on the Looper issue | 15:53 |
| racarr_ | 1. SW cursor (seems hard to land)/pointer input 2. Back to inprocess EGL 3. Clean up qtubuntu mir branch | 15:53 |
| racarr_ | tvoss: Oh?! | 15:53 |
| tvoss | racarr_, at your items: I would focus on inprocess EGL | 15:54 |
| racarr_ | Ok. makes sense | 15:56 |
| racarr_ | actually depending on how it is structured that might all live in Qt ubuntu now that prepare-for-inprocess-egl has landed | 15:57 |
| tvoss | racarr_, what's the magic cmake option to enable compiling the Looper relying on boost? | 15:59 |
| === jono is now known as Guest461 | ||
| racarr_ | tvoss: MIR_INPUT_USE_ANDROID_TYPES=false | 15:59 |
| racarr_ | which is the default | 15:59 |
| racarr_ | should use the looper coming from 3rd-party/android-deps/bla/bla (with the boost implementation in header file) | 16:00 |
| tvoss | racarr_, ack | 16:00 |
| * alf_ is starting to get really tired of gcc ICEs | 16:13 | |
| racarr_ | alf_: I know what you mean... | 16:13 |
| tvoss | racarr_, can you give http://pastebin.ubuntu.com/5649723/ | 16:13 |
| tvoss | a spin? | 16:13 |
| racarr_ | alf_: At some point last week I wrote like 900 lines of new code...then -> ICE....I wanted to cry! | 16:14 |
| racarr_ | alf_: SOme bug report implied it may be fixed upstream I am thinking of building my own G++ | 16:14 |
| racarr_ | tvoss: Trying :) | 16:16 |
| tvoss | racarr_, cool | 16:16 |
| racarr_ | tvoss: alan_g: It's strange...changes to Looper.h wont actually trigger | 16:16 |
| alf_ | racarr_: my current methodology is to build with clang, so I can get an idea of what the problem is | 16:16 |
| racarr_ | recompile of android-input | 16:16 |
| racarr_ | always have to make clean | 16:16 |
| racarr_ | alf_: Ah...that's a better idea than crying | 16:16 |
| alf_ | racarr_: :) | 16:17 |
| alan_g | racarr_: that's because CMake's dependency tracing doesn't track #include MACRO | 16:17 |
| racarr_ | tvoss: Still the same. | 16:17 |
| racarr_ | alan_g: ah.... | 16:17 |
| alan_g | Just delete a few files in 3rd_party/... | 16:18 |
| tvoss | racarr_, then I need to look a bit deeper | 16:18 |
| === mmrazik is now known as mmrazik|otp | ||
| racarr_ | tvoss: googling around people kind of implied | 16:18 |
| racarr_ | the only way to do this with asio is in the timer callback | 16:19 |
| racarr_ | you have to cancel the work. | 16:19 |
| racarr_ | then there is going about resetting the io service and | 16:19 |
| racarr_ | readding the async_read...and I dunno | 16:19 |
| racarr_ | not sure asio is the right fit here | 16:19 |
| racarr_ | tvoss: A thought..."woken" needs to be reset right | 16:21 |
| racarr_ | i.e. around l585 if (woken.load()) | 16:21 |
| alan_g | racarr_: it doesn't seem at all easy. Am proposing a fix branch | 16:23 |
| kdub | alf_, could you give another look? https://code.launchpad.net/~mir-team/mir/consolidate-crossbuild-scripts/+merge/154762 | 16:23 |
| racarr_ | it doesn't help though | 16:23 |
| alf_ | kdub: sure | 16:23 |
| racarr_ | alan_g: Yeah...it's really complex to how it should be :/ | 16:23 |
| racarr_ | I think run_one should take a timeout ;) | 16:23 |
| alan_g | racarr_: Agreed | 16:24 |
| alan_g | racarr_: https://code.launchpad.net/~alan-griffiths/mir/receive-input-in-client-patch/+merge/155549 | 16:25 |
| alf_ | kdub: @l.78, the line is not wrapped. Other than that looks good. | 16:26 |
| racarr_ | alan_g: It looks like there is some confusion in this branch? extra changes etc | 16:27 |
| alan_g | Bugger - that has some trunc changes tpp | 16:27 |
| alan_g | Bugger - that has some trunc changes too | 16:27 |
| racarr_ | :) | 16:27 |
| kdub | alf_, sorry, got lost in some merges... fixed now | 16:28 |
| alf_ | kdub: also, is lp:~kdub/mir/ndk-rewrite the best place to get information from for creating a chroot, or is lp:mir enough now? | 16:29 |
| kdub | alf_, after that branch, just lp:mir | 16:30 |
| kdub | i'll delete that branch, and send out a mail on the mailing list | 16:30 |
| alf_ | kdub: so, we should update at l.65 ? | 16:30 |
| kdub | alf_, yes :/ i corrected that, but that got lost in my merge mixup too | 16:31 |
| kdub | fixed | 16:31 |
| alan_g | racarr_: I hope that fixes it | 16:32 |
| alan_g | (At least it looks like I intended) | 16:34 |
| racarr_ | alan_g: Oh good idea at line 310 | 16:34 |
| racarr_ | (test name change) | 16:34 |
| alan_g | racarr_: np | 16:35 |
| alf_ | kdub: thanks, approved | 16:35 |
| racarr_ | testing now | 16:35 |
| racarr_ | alan_g: All works | 16:36 |
| racarr_ | going to merge your branch in to mine and push | 16:37 |
| racarr_ | alan_g: tvoss: Thanks both :) | 16:37 |
| === mmrazik|otp is now known as mmrazik | ||
| racarr_ | I wonder if the InputReceiverThread on the client side should be/use an android::Looper | 16:39 |
| alan_g | racarr_: hopefully we'll soon be confident to delete the ANDROID_TYPES=on option (and the code to support it) | 16:39 |
| racarr_ | Mm | 16:39 |
| racarr_ | Currently it is using a little mini select loop but it needs optimization (diff l598) | 16:39 |
| === alan_g is now known as alan_g|afk | ||
| racarr_ | *really happy to finally being close to landing an end to end test for input* | 16:49 |
| racarr_ | it's easy to move fast there now :) | 16:50 |
| tvoss | racarr_, yup, great work :) | 16:50 |
| racarr_ | aww merge conflicts | 16:50 |
| racarr_ | tvoss: Oh while you are around i wanted to ask you...was trying to find a good input demo | 16:51 |
| racarr_ | but nothing qwidget based works on qtubuntu for me | 16:51 |
| racarr_ | expected/known? | 16:51 |
| racarr_ | (Not many QML demos that work with no cursor ;)) | 16:51 |
| tvoss | racarr_, mostly known I would say. I would think that the qml examples should work, though | 16:51 |
| racarr_ | at least precanned ones in /opt/qt5/examples | 16:52 |
| racarr_ | yeah | 16:52 |
| racarr_ | there is just only one that will accept keyboard input before mouse input | 16:52 |
| racarr_ | and it makes a pretty lame video XD (qtdeclarative/quick/keynavigation) | 16:52 |
| tvoss | racarr_, ack, @cursor: is there a way to get a cursor rendering easily? IIRC you can provide the InputReader with a cursor handler | 16:53 |
| racarr_ | tvoss: We have a cursor handler in trunk | 16:53 |
| tvoss | racarr_, is that one actually rendering? | 16:53 |
| racarr_ | and InputManager takes a CursorListener object, which would be the place to put a renderer | 16:53 |
| racarr_ | but the CursorListener is null atm | 16:53 |
| racarr_ | not sure how to render it | 16:54 |
| racarr_ | at least in a way that will land :) | 16:54 |
| tvoss | racarr_, yeah, so let's postpone a cool video until we have a way to expose the hw cursor, if that's fine with you | 16:55 |
| racarr_ | Yeah :) | 16:56 |
| racarr_ | I amw ondering if I should try and work on that now...I dunno its probably not that difficult I just can't figure out the interfaces in mir... | 16:56 |
| === alan_g|afk is now known as alan_g | ||
| racarr_ | the thing is the cursor listener shouldn't speak directly to the compositor or if it does | 16:58 |
| racarr_ | that's a pretty big change! | 16:58 |
| racarr_ | because it makes lines that cross surface stack where there were none | 16:58 |
| tvoss | racarr_, hw cursor support is more likely to end up somehwere in graphics | 16:58 |
| racarr_ | but surface stack isn't really prepared to | 16:58 |
| racarr_ | represent a cursor | 16:58 |
| tvoss | racarr_, yup | 16:58 |
| tvoss | racarr_, so focus on in_process_egl | 16:59 |
| racarr_ | ok | 17:00 |
| racarr_ | tvoss: The way I was handling that in the iteration-1 branch was | 17:00 |
| racarr_ | using almost unmodified qtubuntu backend, and ubuntu_platform_api backed by libmirserver | 17:01 |
| racarr_ | does that still make sense? I am not sure exactly what the status of ubuntu_* API is | 17:01 |
| racarr_ | I have this thought that we don't really need "qmir" just qtubuntu, a nd ubuntu-application-api-mirclient and ubuntu-application-api-mirserver | 17:02 |
| tvoss | racarr_, that's a difficult one. Need to give it some thought | 17:04 |
| racarr_ | tvoss: ok | 17:05 |
| racarr_ | tvoss: It's a convenient way to proceed ;) that ends with little code duplication | 17:05 |
| racarr_ | but I am not entirely sure it makes sense | 17:05 |
| racarr_ | i.e. why is the launcher an indirect consumer of ubuntu-application-api | 17:06 |
| racarr_ | seems weird. | 17:07 |
| racarr_ | ill delay it a day and at least get the inserver EGL display and a demo inprocess app proposed today :) | 17:10 |
| === racarr_ is now known as racarr | ||
| tvoss | racarr, that sounds like a good idea :) | 17:10 |
| alf_ | status: working on compositing-on-demand, reviewing, fighting with gcc ICEs | 17:26 |
| racarr | it's a shame too that its not easy to downgrade to 4.6 now because of the override use (which I quite like actually) | 17:27 |
| racarr | its just like it's some sort of cruel joke being played on us XD | 17:27 |
| racarr | hmm issues with the new test_client_mir_surface tests when merging trunk in to receive-input | 17:44 |
| alf_ | racarr: alan_g: Do we need SurfaceStack::raise_to_top()? No one is using it, and it has memory problems (it uses a potentially invalidated iterator). | 17:53 |
| alan_g | alf_: dead code? Delete it! | 17:54 |
| === Cheery_ is now known as Cheery | ||
| racarr | alf_: Apparently not! | 17:58 |
| racarr | I think it was used in an early version of sessions/ in copenhagen ;) | 17:58 |
| racarr | then we decided restacking the surfaces was silly when all we need is visibility | 17:59 |
| alf_ | racarr: alan_g: preparing an MP | 17:59 |
| racarr | obviously we will need something like it one day. but lets just drop it and | 17:59 |
| racarr | readd it working correctly when we do :) | 17:59 |
| racarr | hmm | 18:00 |
| racarr | where does the server MesaNativeDisplay implementation go :) | 18:00 |
| racarr | mir::graphics::EGL::? | 18:01 |
| === alan_g is now known as alan_g|EOD | ||
| kgunn | racarr: ping | 18:41 |
| kgunn | alf_: hey, can you change https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 to have the drafter set to mir-team ? | 18:49 |
| racarr | kgunn: Pongalong! | 18:51 |
| racarr | I think I need to make | 19:43 |
| racarr | mir::DisplayServer mockable but its not clear what the interface is | 19:43 |
| racarr | the EGLNativeDisplay constructor (well or more likely factory function) | 19:44 |
| racarr | wants to take mir::DisplayServer I think | 19:45 |
| racarr | becuase the thing is, think of the code paths in unity. Unity starts up, initializes a server configuration, and then calls off to mir::run_mir(Configuration) | 19:46 |
| racarr | at which point control goes to Mir | 19:46 |
| racarr | but unity needs a time to start, threads | 19:46 |
| racarr | and get some reference to the display server instance (after it is prepared) | 19:47 |
| racarr | so I think we need some callback, the display server instance invokes inbetween starting and entering the main loop | 19:47 |
| racarr | to give unity a time to say, start a thread which creates a surface and starts rendering. | 19:48 |
| racarr | even simpler just imagine we are talking about a simple EGL demo app instead of unity. What does it need? It needs the display to get the platform package to initialize the egl context, and it needs a surface controller | 19:49 |
| racarr | to create a surface. | 19:49 |
| racarr | so it seems like maybe mir::DisplayServer should provide these | 19:50 |
| racarr | through a...<NAME GOES HERE> interface | 19:50 |
| racarr | first thought is mir::ServerInstance but actually this interface | 19:51 |
| racarr | doesn't need start/stop like mir::DisplayServer does (and you would guess a ServerInstance would) | 19:52 |
| racarr | so maybe it's more like mir::ServerComponents is the interface with (.shell_surface_controller(), .display(), etc...) | 19:52 |
| racarr | and mir::DisplayServer implements | 19:52 |
| racarr | or maybe mir::ServerInstance is the concrete implementation containing start/stop and the .display(), etc... | 19:53 |
| racarr | and mir::DisplayServer becomes the interface with just | 19:53 |
| racarr | the component access | 19:53 |
| racarr | I think that makes sense. a mir::DisplayServer has a bunch of components that make up the interface mir::* exposes to the shell. a server instance is a display server with API for execution | 19:55 |
| racarr | *shrug* | 19:56 |
| racarr | Sorry sounds kind of pedantic but I think it's important to think about this interface because we need to make sure Unity and Mir are cleanly mockable from eachother. | 19:56 |
| kgunn | kdub: quick one i think | 19:58 |
| kgunn | what exactly did "display integration" mean ?...i mean you already go hwc vsync working for nexus4 (not nec'lly landed...but) | 19:59 |
| racarr | Lunch! | 20:00 |
| === racarr is now known as racarr|lunch | ||
| kdub | kgunn, making sure that all the pieces fit together (integration test) | 20:00 |
| kgunn | kdub: thanks...it was marked as todo...but i suppose that will hinge on some mp's to say done... | 20:01 |
| === racarr|lunch is now known as racarr | ||
| kgunn | robert_ancell: would you mind making mir-team drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-nexus4 | 21:04 |
| robert_ancell | kgunn, done | 21:04 |
| kgunn | thank you! | 21:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!