| racarr | Nothing quite seems to destroy my focus like a cyclic dependency | 00:08 |
|---|---|---|
| racarr | problem... | 00:09 |
| racarr | when thinking in circles becomes shockingly literal :( | 00:09 |
| racarr | I guess the gmail migration worked because I just started getting work emails on my phone | 02:11 |
| racarr | *gulp* | 02:11 |
| kgunn | racarr: dont work all night 8am call w greyback | 03:19 |
| hikiko | /j #eclipse | 07:35 |
| hikiko | sorry :p | 07:35 |
| === alan_g|life is now known as alan_g | ||
| alf__ | alan_g: @fix-bug-1108715, I propose that we sent an email to the list to alert people about the name change (I have been bitten by this in the past) | 08:37 |
| alan_g | alf__: good idea. | 08:37 |
| alan_g | "the list" == mir-devel? | 08:38 |
| alf__ | alan_g: that would be my choice | 08:38 |
| alan_g | alf__: looks like jenkins is going to avoid confusion - it is flaky again. :( | 08:45 |
| alan_g | alf__: did you see the email? (I thought I'd opted out of gmail, but I've not seen any email since the migration.) | 09:18 |
| alf__ | alan_g: Yes (the fix-bug-1108715 email). I opted out, too. | 09:19 |
| alan_g | alf__: I guess opting out worked for you. My account was migrated anyway. | 09:37 |
| alan_g | alf__: there a couple of racarr's MPs that (to me) look fit to land - do you want to check them first? | 09:50 |
| alf__ | alan_g: I will take a quick look. If everything is ok I will top approve. | 09:51 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| alf__ | hikiko: basically you will build an SDL client platform and an (unused for now) GBM client platform | 10:51 |
| alf__ | hikiko: oops, you will build an SDL *server* platform | 10:52 |
| hikiko | yes that's what O a, doing | 10:52 |
| hikiko | I am* | 10:52 |
| hikiko | and it works | 10:52 |
| hikiko | the prob is | 10:52 |
| hikiko | in the client | 10:52 |
| hikiko | where I have to do the same | 10:52 |
| hikiko | and I wonder | 10:52 |
| hikiko | if I have to implement an sdl_client_platform | 10:52 |
| hikiko | and use the gbm for buffers | 10:52 |
| hikiko | as I do in the server | 10:53 |
| hikiko | or | 10:53 |
| hikiko | use the gbm as it is | 10:53 |
| hikiko | (add the sdl platform only in CMakeLists as you suggested) | 10:53 |
| hikiko | I think I ll try first what you suggest | 10:53 |
| hikiko | which is the simplest | 10:53 |
| hikiko | and if it doesn't work i will do a dummy implementation | 10:54 |
| hikiko | just to have the client compiling without the vt complains :) | 10:54 |
| alf__ | hikiko: It's possible that you will be able to just use the gbm platform, but that's for the future. For now just try to compile the gbm client platform (check libraries/includes). | 10:55 |
| alf__ | hikiko: Can you pastebin the build errors you are getting? | 10:55 |
| hikiko | if i don't change anything at the client | 10:56 |
| hikiko | i don't get any build errors | 10:56 |
| hikiko | but I have runtime errors | 10:56 |
| hikiko | wait a moment because now I have changed the branch | 10:57 |
| === mmrazik is now known as mmrazik|lunch | ||
| hikiko | alf__, I'll try what you said and if I get any build errors I will paste you the output I ll ping you later :) | 11:01 |
| alf__ | hikiko: sure, thanks | 11:06 |
| alf__ | hikiko: also ensure that you are using the right (the ones you build in the tree) render_to_fb and libmirserver, and not the ones in the system path e.g. /usr/(local/)... | 11:08 |
| alf__ | hikiko: if it is a runtime error you are getting, it maybe that you are using a libmirserver that still uses a gbm server platform | 11:09 |
| hikiko | yes, that's what I told you that was happening initially, I was using the gbm_platform when I compiled the gbm client library, | 11:11 |
| hikiko | I implemented an sdl dummy client platform | 11:12 |
| hikiko | because there's a function that returns | 11:12 |
| hikiko | which platform to use | 11:12 |
| hikiko | anyway, let me try and I ll come back to you later | 11:13 |
| alf__ | hikiko: There may be a misunderstanding here. The client platform shouldn't be a problem at runtime in any case (libmirclient is not used by render_to_fb). I am saying that you should check that at runtime you are using a *libmirserver.so* built with the right *server* platform (i.e. the one you built in your sdl tree) | 11:20 |
| hikiko | oh | 11:21 |
| hikiko | I see | 11:21 |
| hikiko | hmmm and if not then how can i change this? | 11:21 |
| === pete-woods is now known as pete-woods-lunch | ||
| === pete-woods-lunch is now known as pete-woods | ||
| === alan_g is now known as alan_g|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === alan_g|lunch is now known as alan_g | ||
| alf__ | status: Investigated stress test crash, proposed fix+test MP | 13:08 |
| racarr | Morning | 14:49 |
| alan_g | Afternoon | 14:49 |
| === alan_g is now known as alan_g|tea | ||
| racarr | kgunn: I there a hangout? | 15:06 |
| racarr | I joined the one in the calendar but no one is there | 15:06 |
| kgunn | https://plus.google.com/hangouts/_/e1a9426c9efc173c7ab60b17323aafbf56b9ae06 | 15:06 |
| kgunn | kdub: ^ | 15:06 |
| === mmrazik is now known as mmrazik|afk | ||
| racarr | alan_g|tea: Have a few minutes? | 15:19 |
| === alan_g|tea is now known as alan_g | ||
| alan_g | racarr: sure. What's up? | 15:20 |
| racarr | alan_g: I have been working on this branch... | 15:21 |
| racarr | step 1. Move input fds to ms::Surfaces, refactor a bunch of the input classes in this process. | 15:22 |
| racarr | 2. Port InputDispatcher to use an InputTargetEnumerator (rather than this setInputWindows stuff copying the stack) | 15:23 |
| racarr | I guess, the thought is. It's a huge branch, and I feel like you will end up reviewing it since you have seen the most of the input stuff | 15:23 |
| racarr | do you want one giant diff or should I split it in to sequenced branches, even if they don't necesarily make sense by themselves (like there is no acceptance test motivating 1) | 15:24 |
| alan_g | I guess the two steps are likely easier follow. | 15:25 |
| racarr | ok | 15:26 |
| racarr | alan_g: | 15:28 |
| racarr | Want to talk about options too? | 15:28 |
| alan_g | racarr: real options? http://www.infoq.com/articles/real-options-enhance-agility | 15:30 |
| racarr | alan_g: Let me learn :p just a sec | 15:34 |
| alan_g | racarr: sorry, didn't mean to distract you. What do you want to talk about? | 15:34 |
| racarr | alan_g: Haha no, interesting. In the language of that article I would call what I am talking about settings | 15:35 |
| racarr | or something instead | 15:35 |
| racarr | alan_g: There are lots of little input setting, like | 15:35 |
| racarr | various mouse acceleration coeffecients, key repeat rate, | 15:36 |
| racarr | key layout, etc | 15:36 |
| racarr | that I want to expose. But I don't want | 15:36 |
| racarr | well. I think they will be a lot of noise in default_server_configuration.cpp | 15:36 |
| racarr | and it doesn't really seem like they belong in --help | 15:37 |
| racarr | so I am trying to figure out how to add some hierarchy to the option system | 15:37 |
| alan_g | racarr: It's been a while since I looked at the boost.Options docs. I don't remember much hierarchy | 15:38 |
| racarr | alan_g: There isn't any really | 15:39 |
| alan_g | racarr: do you need them on the command-line or would having them only in env or config file be OK? | 15:39 |
| racarr | alan_g: I think env and config file only is perhaps preferable | 15:40 |
| racarr | so I thought of trying to use another instance of program options | 15:40 |
| alan_g | racarr: that's supported by the boost stuff (but we don't use it yet) | 15:40 |
| racarr | but there is lots of coupling with DefaultServerConfiguration | 15:40 |
| racarr | alan_g: Well the thing is I don't want to shove them all in the main | 15:40 |
| racarr | options lists. | 15:40 |
| racarr | because right now, say maybe there are 5 or 6 of them | 15:41 |
| racarr | but I think it could quickly get out of control | 15:41 |
| alan_g | so you think it is time to do something cleverer? | 15:42 |
| racarr | I think so? | 15:43 |
| alan_g | Well the "simplest thing that might work" is just to add them to what we have. We can rework after. | 15:43 |
| racarr | maybe its not, maybe its enough to have like, mir::DefaultServerConfiguration::the_input_options, that calls something like mi::create_options and then uses the same parse enviroment as in DefaultServerConfiguration | 15:43 |
| racarr | Mm. That's true | 15:44 |
| racarr | maybe I should just do that | 15:44 |
| racarr | the only two I really care about is key repeat and pointer acceleration | 15:44 |
| alan_g | racarr: you can also do stuff like --input-params key-repeat=2,pointer-acceleration=100,... | 15:46 |
| * kdub likes that a bit better than secret config files | 15:47 | |
| racarr | hmm | 15:49 |
| racarr | Seems like it's time to write a scheme interpreter | 15:49 |
| racarr | --input-params (defun key-repeat-function keycode.... | 15:50 |
| racarr | :p | 15:50 |
| racarr | hmm that is kind of nice. | 15:50 |
| racarr | your suggestion not the scheme | 15:50 |
| alan_g | racarr: I don't see 5 or 6 more command line parameters as a problem | 15:50 |
| racarr | Ok :) | 15:50 |
| kdub | i don't mind that either | 15:50 |
| alan_g | kdub is in a good mood today. | 15:52 |
| kdub | very agreeable :) | 15:52 |
| racarr | XD | 15:53 |
| * kdub goes to work on client swapinterval0 | 17:03 | |
| === alan_g is now known as alan_g|life | ||
| racarr | so um | 17:42 |
| racarr | should new files | 17:42 |
| racarr | in 3rd_party/android-input (this question is already sounding incorrect...) | 17:42 |
| racarr | use mir style or android style? | 17:42 |
| kdub | i'd guess android, but then again | 17:47 |
| kdub | we've effectively forked it, so if we're transitioning everything gradually to mir style then... | 17:48 |
| racarr | the thing is this is a new interface to be | 17:48 |
| racarr | implemented by something in mir::input | 17:48 |
| racarr | so if I use the style it's forEach instead of for_each lol | 17:48 |
| racarr | kdub: Yeah that's kind of what I was thinking | 17:49 |
| tvoss | racarr, +1 on mir style | 18:02 |
| racarr | class SurfaceStack : public compositor::Renderables, public input::InputTargets | 18:04 |
| racarr | the tldr version of mir | 18:04 |
| racarr | XD | 18:04 |
| racarr | tvoss: Android license or GPL/LGPL? | 18:13 |
| racarr | I think android license...? | 18:14 |
| racarr | its not particularly important because it's an interface with one method, but I guess we will have to answer this at some point | 18:14 |
| kdub | i thought apache on most of it | 18:17 |
| racarr | mm but for new files | 18:18 |
| tvoss | racarr, ack, make it LGPL I would think ... but will check back on that | 18:18 |
| racarr | apache or | 18:18 |
| racarr | LGPL | 18:18 |
| tvoss | hmmm | 18:22 |
| racarr | It's a little hard to answer I think because | 18:22 |
| racarr | adding new files to 3rd_party/something | 18:22 |
| racarr | is a bit of a contradiction | 18:23 |
| tvoss | racarr, exactly | 18:23 |
| racarr | It would be good to talk about the long term trajectory for the input stack | 18:25 |
| racarr | removing setInputWindows (and then perhaps InputWindowHandle) in this way | 18:25 |
| racarr | it's easier to start sucking the large android side components | 18:26 |
| racarr | in to smaller mir side components | 18:26 |
| racarr | i.e. in this case, the InputDispatcher had a hidden responsibility (track and enumerate the list of input targets), so this gets sucked over to mir side. Next perhaps, you move over another responsibility (select target from list of targets) and farm this out to the shell | 18:27 |
| racarr | I don't know if this is what we want to do, or if we want to keep it in it's little bubble | 18:28 |
| racarr | and over what timescales, etc. | 18:28 |
| kdub | racarr, maybe we should set up a meeting to talk about it... i'm sure a lot of people would be interested | 18:30 |
| racarr | kdub: Hmm sounds like a good idea. | 18:30 |
| thomi | morning | 19:08 |
| kgunn | thomi! | 19:09 |
| thomi | o/ | 19:09 |
| thomi | what's up in your kneck of the woods kgunn? | 19:10 |
| kgunn | success building phablet from scratch (which i'm sure is nothing to most people) | 19:11 |
| kgunn | thomi: btw, have you heard from robert A ? | 19:11 |
| thomi | kgunn: nope, what would I be hearing from him about? | 19:12 |
| kgunn | thomi: baby | 19:12 |
| thomi | ahhh, no | 19:12 |
| thomi | I haven't heard anything, sorry :) | 19:12 |
| kgunn | hope all is ok | 19:12 |
| kgunn | alf had a fix for stress test | 19:12 |
| thomi | sweet - any idea if it landed? | 19:12 |
| kgunn | i think he had you on for review :) | 19:13 |
| thomi | ahh sweet | 19:13 |
| kgunn | https://code.launchpad.net/~afrantzis/mir/fix-stress-test-crash-1183327 | 19:13 |
| thomi | I'll take a look | 19:13 |
| racarr | lunch time! | 19:16 |
| === racarr is now known as racarr|lunch | ||
| === mmrazik|afk is now known as mmrazik | ||
| === racarr|lunch is now known as racarr | ||
| kgunn | racarr: kdub ...i think i just merged the upstream hybris changes for n7, built an image & its actually working! | 20:11 |
| kgunn | hell might have frozen over...need to check :) | 20:11 |
| kgunn | kdub: before i proceed further are the instructions for android mir still good? | 20:14 |
| kdub | kgunn, should be :) | 20:14 |
| kdub | i might give it a try too | 20:14 |
| kdub | not really sure of the hwc situation on that device | 20:14 |
| kgunn | mmm, well, its a ics based device | 20:15 |
| kgunn | but ics was first rev...and jb definitely cleaned up some "back doors" | 20:15 |
| kdub | either way, back-up gpu composition (hwc-less fallback) worked fine when i tried it in... febuary? | 20:16 |
| kgunn | kdub: to be sure i half way understood it :_ | 20:16 |
| kgunn | :) | 20:16 |
| kgunn | was the "nvidia_hack" | 20:16 |
| kgunn | the thing that you were toggling ? | 20:16 |
| kdub | kgunn, no | 20:17 |
| kgunn | hmmm | 20:17 |
| kdub | kgunn, its a bit deceptive... things will work until you try to have ipc clients | 20:18 |
| kgunn | ah | 20:18 |
| kgunn | so best test, load mir and see | 20:18 |
| kdub | yeah | 20:18 |
| === francisco is now known as Guest84395 | ||
| racarr | I couldnt make in process | 20:55 |
| racarr | clients work | 20:55 |
| racarr | on 7 that is | 20:56 |
| bschaefer | Hmm getting a pure function call when trying to release the mir connection? Stacktrace: http://paste.ubuntu.com/5695233/ | 22:12 |
| bschaefer | and code doing the releasing...: http://paste.ubuntu.com/5695235/ | 22:12 |
| kgunn | kdub: wrt instructions...the cross-compile says to add ppa to get armhf....but those all fail | 22:30 |
| kgunn | kdub: ...and i already have a build branch of the image i'm running | 22:30 |
| kgunn | kdub: ring any bell? | 22:31 |
| kgunn | e.g. are you still relying on that package pull...or are you using armhf libs some other way | 22:32 |
| kdub | kgunn, still relying on the package pull | 22:51 |
| kdub | kgunn, you can cross compile normally from within a chroot | 22:51 |
| kdub | the cross compile script is just the sane way for a development work-cycle | 22:51 |
| kgunn | kdub: right...looking now | 22:51 |
| kgunn | kdub: but what's weird...if you go here http://us.archive.ubuntu.com/ubuntu/dists/quantal/universe/ | 22:52 |
| kgunn | there's no armhf...not sure how that's working for you | 22:53 |
| kdub | we're on raring | 22:54 |
| kdub | saucy probably works too | 22:54 |
| kdub | kgunn, are you trying to cross compile, or compile within a chroot? | 22:54 |
| kgunn | yeah...sorry i was poking around | 22:54 |
| kgunn | cross compile | 22:54 |
| kgunn | i know we're on raring, i was poking around to see if they had been there on quantal or something | 22:55 |
| kgunn | ......arg....nvmd, found 'em | 22:55 |
| kdub | cool | 23:02 |
| kdub | hmm, cant ping launchpad | 23:05 |
| racarr | Whee. RUN ] TestClientInput.multiple_clients_receive_motion_inside_windows | 23:06 |
| racarr | [ OK ] TestClientInput.multiple_clients_receive_motion_inside_windows (18 ms) | 23:06 |
| racarr | and they dn't talk back about it either :D | 23:06 |
| racarr | ugh | 23:12 |
| racarr | there is a race condition in the acceptance test (or perhaps in the actual code XD) | 23:12 |
| racarr | sometimes the hover exit event (this test drags the mouse over the boundary between two surfaces) | 23:13 |
| racarr | doesn't get emitted | 23:13 |
| kgunn | kdub: i feel stupid...i was confused b/c by output failures coming from regular repo's.... | 23:19 |
| kgunn | since you add armhf to dpkg config | 23:20 |
| kgunn | it looks for them too there i guess.... | 23:20 |
| kgunn | but it found the ports just fine | 23:20 |
| kdub | kgunn, cool :) | 23:20 |
| kgunn | kdub: check my head tho....so i was going to take the hybris i built & plop it into the dir where mir is looking (replacing whatever i just downloaded) | 23:22 |
| kgunn | in theory should work right? | 23:22 |
| kdub | kgunn, at link time on the host, as long as they have the same symbols, it doesn't matter | 23:22 |
| kdub | at runtime, the right library has to be installed into the linker search path | 23:23 |
| kdub | so short answer... yes :) | 23:23 |
| kgunn | :) right but i might not need to | 23:23 |
| kgunn | i get it | 23:23 |
| === jono is now known as Guest71790 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!