| === Quintasan is now known as 18WAC4VUS | ||
| smspillaz | racarr: good read if you're interested http://googletesting.blogspot.com.au/2013/03/testing-on-toilet-testing-state-vs.html | 03:26 |
|---|---|---|
| ninjaaron | is Mir going to be using libxkbcommon for keyboard input? | 03:35 |
| === RAOF_ is now known as RAOF | ||
| === alan_g is now known as alan_g|afk | ||
| tvoss | alf___, ping | 08:20 |
| * tvoss remembers alf saying that today is a public holiday in Greece | 08:20 | |
| RAOF | Indeed he did. | 08:24 |
| === popey_ is now known as popey | ||
| === alan_g|afk is now known as alan_g | ||
| === mmrazik is now known as mmrazik|lunch | ||
| smspillaz | heh, wayland fork drama | 11:34 |
| alan_g | smspillaz: reference? | 11:35 |
| smspillaz | alan_g: hang on | 11:36 |
| smspillaz | http://lists.freedesktop.org/archives/wayland-devel/2013-March/008131.html | 11:36 |
| alan_g | smspillaz: that's a hard attitude for anyone to engage constructively with | 11:49 |
| smspillaz | alan_g: we will see where it goes - hopefully it will drum up some interesting projects | 11:50 |
| alan_g | mmrazik|lunch: I'm not what's up with this build. But it looks like it is getting glog while failing to get gflags (which glog needs). Can you spot the problem? https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/117/console | 12:31 |
| tvoss | alan_g, you need to adjust the packaging setup in debian/control | 12:39 |
| tvoss | alan_g, and add glog as a build dependency | 12:39 |
| alan_g | tvoss: you mean like: 40+ libgoogle-glog-dev | 12:40 |
| alan_g | ? | 12:41 |
| tvoss | alan_g, yup, but seems like you need to add gflags there, too | 12:42 |
| alan_g | Surely the transitive dependency on gflags should be implicit? | 12:42 |
| * alan_g guesses it can't hurt to try | 12:43 | |
| === mmrazik|lunch is now known as mmrazik | ||
| mmrazik | alan_g: I don't know. I've noticed this failure (all mir failures are going to my INBOX) but I don't know | 12:49 |
| mmrazik | alan_g: maybe kdub can help ? | 12:50 |
| alan_g | mmrazik: I'll ask him when he comes online. | 12:50 |
| === alan_g is now known as alan_g|lunch | ||
| tvoss | lool, bschaefer, seb128 https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en | 13:24 |
| seb128 | tvoss, is that an onair hangout? | 13:25 |
| tvoss | seb128, yup :) | 13:25 |
| seb128 | excellent | 13:25 |
| seb128 | on my way (just grabbing something to drink) | 13:25 |
| bschaefer | tvoss, hello, thanks | 13:26 |
| * bschaefer has no web cam though | 13:26 | |
| tvoss | seb128, bschaefer you guys coming? | 13:29 |
| tvoss | tmoenicke, https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en | 13:29 |
| tvoss | lool, https://blueprints.launchpad.net/ubuntu/+spec/client-input-methods | 13:30 |
| tvoss | lool, https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en | 13:30 |
| lool | coming | 13:31 |
| bschaefer | tvoss, yeah, had to re-install the hangout plugin.... | 13:32 |
| tvoss | bschaefer, ack :) | 13:32 |
| tvoss | kgunn, https://plus.google.com/hangouts/_/cbad7ead46ab1c85a9bc118c525d02dad37e1bc9?authuser=0&hl=en | 13:33 |
| kgunn | coming | 13:34 |
| === alan_g|lunch is now known as alan_g | ||
| tvoss | anyone from the Ubuntu kylin project here? | 13:34 |
| lool | seb128: do you remember who was pushing for the other input stack? | 13:34 |
| seb128 | lool, input? | 13:34 |
| seb128 | like xinput/libinput? | 13:34 |
| seb128 | or ibus/fcitx? | 13:34 |
| lool | seb128: fcitx | 13:35 |
| bschaefer | theres a bunch, gcin, hime, fctix, ibus etc.. | 13:37 |
| GunnarHj | If I understand it correctly, currently a bunch of IM frameworks can be used in Ubuntu. Will MIR restrict the current possibility to choose the framework of your choice? | 13:48 |
| ogra_ | why woudl it do that | 13:49 |
| ogra_ | it might restrict the UI capabilities in the beginning ... but surely not the framework | 13:50 |
| GunnarHj | Ok. | 13:51 |
| GunnarHj | Is any of the frameworks good enough for all the IM dependent languages? | 13:56 |
| happyaron | GunnarHj: almostly, ibus/fcitx can fit for current situations | 13:57 |
| happyaron | csslayer: hi | 13:58 |
| happyaron | seb128 GunnarHj: csslayer is also upstream developer of fcitx (along with Yu) | 13:58 |
| seb128 | csslayer, hey | 13:59 |
| seb128 | happyaron, ok | 13:59 |
| GunnarHj | Hi csslayer | 13:59 |
| csslayer | seb128: happyaron GunnarHj: hi, I may leave for my lab meeting soon, I just login in and look around :) sorry | 14:00 |
| seb128 | csslayer, no problem, thanks for being around | 14:00 |
| GunnarHj | So I take it that we can, if we want, disregard from all the other frameworks that currently is supported by e.g. im-config. | 14:00 |
| seb128 | csslayer, we are trying to figure out what are the main difference between ibus/fcitx | 14:01 |
| seb128 | and what we should review/consider while trying to pick one? | 14:01 |
| csslayer | seb128: from the toolkit level there isn't much difference if you want to make a imf agnostic protocol for mir | 14:02 |
| csslayer | seb128: and even the protocol is quite similiar | 14:02 |
| csslayer | AFAIK ubuntu phone will go with maliit for now, so I think you might want to have some general protocol maybe ? | 14:02 |
| seb128 | on the mir/server side probably | 14:03 |
| seb128 | but there is also the question of configuration | 14:03 |
| seb128 | ui | 14:03 |
| seb128 | like what is our indicator speaking | 14:03 |
| csslayer | that's not a problem of toolkit level, actually anyone can write any ui, there is no much difference between im and other application. | 14:04 |
| bschaefer | also this is a bug report that happened last time we forced IBus in 12.10 for unity: https://bugs.launchpad.net/nux/+bug/983254 | 14:05 |
| ubot5 | Launchpad bug 983254 in Unity "Support input methods beside ibus" [High,Fix committed] | 14:05 |
| csslayer | ah... sorry for my bad behavior one year ago | 14:05 |
| bschaefer | csslayer, I was pointing out that we need to support more then 1 :) | 14:05 |
| seb128 | csslayer, what are the core difference between ibus and fcitx? | 14:06 |
| seb128 | like what would argument would give in favor of picking one instead of the other one? | 14:06 |
| csslayer | seb128: the core difference, from my point of view (and I guess you guys might intereseted in) is the view on what should be handled by imf. | 14:07 |
| seb128 | csslayer, is fcitx handling keyboard layouts like ibus 1.5 is doing? | 14:08 |
| csslayer | seb128: yes, that part is firstly introduced in fcitx 4.2.4 | 14:09 |
| * csslayer is checking the release date of 4.2.4 | 14:09 | |
| csslayer | Jun 3 2012 | 14:09 |
| csslayer | ok let me continue my "differnce part".. | 14:10 |
| csslayer | ibus make everything a engine, each time, every user can only use one engine. | 14:10 |
| csslayer | fcitx also have the concept of engine, but it admits that there are some function doesn't belong to any engine. | 14:10 |
| csslayer | for example: https://www.csslayer.info/wordpress/fcitx-dev/unicode-input-support/ something like this is obviously specific to chinese, english or any other languages. | 14:11 |
| csslayer | and for configuration part you just talked about, fcitx also make it doesn't bind to any toolkit, but just use some file to describe the configuration. | 14:12 |
| csslayer | and those file can be easily exploited by ui. | 14:13 |
| csslayer | though we admits the nature that there are some complex one cannot be handled by this way, so some custom configuration ui part is also introduced in fcitx 4.2.7. | 14:14 |
| racarr | Morning | 14:17 |
| racarr | Got key events working all the way through a QML app over the weekend! | 14:17 |
| alan_g | hello racarr | 14:17 |
| racarr | Hi alan :) | 14:17 |
| smspillaz | morning racarr ! | 14:17 |
| alan_g | racarr: that sounds good. Spike or production ready code? | 14:17 |
| smspillaz | racarr: nice work! | 14:18 |
| racarr | alan_g: 90% production ready | 14:18 |
| lool | 10mn left in meeting | 14:18 |
| seb128 | csslayer, ok ... do you have any data of the number of languages/methods supported by fcitx? | 14:19 |
| racarr | alan_g: I accumulated a few todos in the process (i.e. go back and move this class, improve this test, etc...) | 14:19 |
| racarr | alan_g: Also, it only works with ANDROID_TYPES on | 14:19 |
| racarr | otherwise the android::Looper used by the InputDispather | 14:19 |
| alan_g | racarr: anything I can help with? | 14:19 |
| racarr | never dispatches the input ready callbacks | 14:19 |
| racarr | so it can't read the finished signals from the client | 14:19 |
| alan_g | Hmm, I guess that is my attempted rewrite at fault. | 14:20 |
| racarr | :) I will spend some time debugging it today though, unless you have any ideas to start | 14:20 |
| happyaron | seb128: let me make up a list for you | 14:21 |
| csslayer | seb128: we nearly covered everything that ibus/scim supports. (when I say "nearly" I mean I don't really know if there is some not exists in pop distro's repo) | 14:21 |
| seb128 | happyaron, thanks | 14:21 |
| alan_g | racarr: Nothing specific - was always a risk reworking without proper tests in place | 14:21 |
| happyaron | csslayer: actually everything in debian/ubuntu, all of them (including ibus/scim) are handled by me. | 14:22 |
| seb128 | csslayer, does that include things like cyrillic/russian? | 14:22 |
| alan_g | racarr: I'm happy to look, but would like another hour or two first | 14:22 |
| racarr | alan_g: Ok no hurry. I don't think I am goign to get to propose it this morning anyway | 14:22 |
| racarr | the one thing that will take a little time, is the acceptance test doesn't yet consistently pass | 14:23 |
| racarr | because it needs some interprocess synchronization | 14:23 |
| alan_g | racarr: In that case, drop me some notes at your EOD and I'll look at it when I start tomorrow | 14:23 |
| racarr | so I have to readd that IPCWaitCondition type thing I was doing a whil ago, etc | 14:23 |
| csslayer | seb128: if you take layout part in, then yes, and fcitx's layout is not just layout, such kinds of function can also work for other language https://fcitx-im.org/wiki/File:Fcitx-Keyboard.png if correct dictionary is installed. | 14:23 |
| racarr | alan_g: Perfect. :) | 14:23 |
| csslayer | seb128: I'm not very sure if m17n (fcitx has m17n-lib support) also covers that part, since we also blacklist most of m17n engine since they are deprecated by layout. | 14:25 |
| * alan_g glad he kept the ANDROID_TYPES option for this eventuality | 14:27 | |
| racarr | :) Yes | 14:28 |
| happyaron | seb128: http://paste.ubuntu.com/5646507/ this list may not cover all fcitx supports, but should enough to give an impression. | 14:33 |
| seb128 | happyaron, thanks | 14:33 |
| csslayer | happyaron: keyboard layout is a larger list .. though :) | 14:34 |
| happyaron | csslayer: yes, :) | 14:35 |
| happyaron | keyboard layouts aren't included there | 14:35 |
| GunnarHj | happyaron: Are you aware of any languages that are not sufficiently supported by the fcitx engines? | 14:36 |
| happyaron | GunnarHj: not yet so far, if they are already supported by ibus/scim. | 14:37 |
| GunnarHj | Ok, thanks. | 14:38 |
| happyaron | GunnarHj: but there's room for improvements in detailed user experience, we don't use them day to day and that needs user's feedback. | 14:38 |
| seb128 | tvoss, ^ happyaron and csslayer_ are also good people to ping if you have questions | 14:39 |
| tvoss | seb128, yup, just reading the channel :) | 14:39 |
| seb128 | tvoss, happyaron (co)maintains fcitx (and ibus) in Debian/Ubuntu, csslayer_ is one of fcitx upstreams | 14:40 |
| tvoss | seb128, thank you :) hey happyaron and csslayer_ :) | 14:40 |
| seb128 | yw ;-) | 14:40 |
| happyaron | tvoss: hey, :) | 14:41 |
| csslayer_ | also thank you guys, it's my pleasure :) | 14:41 |
| csslayer_ | just found my boss isn't here today... is the hangout ended?.. | 14:41 |
| tvoss | csslayer_, yup :) | 14:42 |
| csslayer_ | tvoss: ok then :) sorry. | 14:42 |
| === vibhav is now known as barkdog | ||
| csslayer_ | also welcome to #fcitx channel if you guys have further questions about fcitx | 14:44 |
| === [1]Rafal_S57 is now known as Rafal_S57 | ||
| tvoss | csslayer_, great, thank you | 14:47 |
| Rafal_S57 | Hi, quick question. How much will the Mir composer be able to re-use from an existing GPU specific Android hwc implementation? Will there be a lot of work for the GPU manufacturer to ensure that their composition GPU is utilised currectly by Mir? | 14:48 |
| seb128 | csslayer_, happyaron: tvoss updated https://blueprints.launchpad.net/ubuntu/+spec/client-input-methods with the summary of the discussions/things we need to investigate | 14:50 |
| happyaron | seb128 tvoss thanks! | 14:51 |
| tvoss | happyaron, yw | 14:52 |
| alan_g | Rafal_S57: in theory mir should work with existing android implementations. But the mir code isn't yet mature enough to expect this in practice. | 14:56 |
| === barkdog is now known as vibhav | ||
| tvoss | Rafal_S57, you might want to ping kdub with that question, he is working on using the hwc interface | 15:00 |
| tvoss | kdub, you there yet? | 15:00 |
| kdub | morning folks, status, working on that scripting branch, proposed a new type of android display, working on some hwc classes today | 15:01 |
| alan_g | kdub: what's happening with arm/glog? I'm not what's up with this build. But it looks like it is getting glog while failing to get gflags (which glog needs). Can you spot the problem? https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/117/console | 15:02 |
| tvoss | kdub, did you see Rafal_S57's question about the hwc? | 15:04 |
| kdub | alan_g, my plan is for consolidate-crossbuild-scripts to kill ~kdub/mir/ndk-rewrite and to have your glog branch stack on top of it nicely | 15:04 |
| Rafal_S57 | thanks, I'll ping kdub specifically with my questions - Hi kdub | 15:05 |
| kdub | Rafal_S57, yep, i'm working on that today... we do gles composition without hwc at the moment, but we should have hwc/gles composition soon | 15:05 |
| alan_g | kdub: I'll wait patiently then. ;) | 15:06 |
| kdub | alan_g, hopefully not too patiently :) i'll focus on that branch starting now before i hop to the hwc work for today | 15:06 |
| Rafal_S57 | kdub: so in theory, the composition GPU manufacturer will not have to do anything to support Mir, as long as they have Android hwc implemented correctly? (in time, when Mir is matured) | 15:07 |
| kdub | Rafal_S57, yep | 15:08 |
| Rafal_S57 | kdub: ok, sounds good. Do you expect any kind of interaction with the composition GPU manufacturers, or can they "ignore" the Mir work and focus on Android support? | 15:10 |
| racarr | [ RUN ] BespokeDisplayServerTestFixture.clients_receive_input | 15:11 |
| racarr | [ OK ] BespokeDisplayServerTestFixture.clients_receive_input (210 ms) | 15:11 |
| racarr | Wheeeee | 15:11 |
| tvoss | racarr, \o/ | 15:13 |
| kdub | Rafal_S57, can't say what they'll do, but if they ignore us, it won't hurt us | 15:14 |
| tvoss | Rafal_S57, we are certainly happy for any kind of interaction with GPU manufacturers, however, vanilla HWC support is fine with us :) | 15:14 |
| racarr | tvoss: I can make you a video later today :) ... atm my phone is broken and my DSLR is in a room covered in wet paint | 15:16 |
| tvoss | racarr, \o/ | 15:17 |
| tvoss | racarr, what color? | 15:17 |
| Rafal_S57 | kdub, tvoss: I'm currently scoping a support task for a composition GPU manufacturer, as they've asked us to look into what will be required to support Mir. From what you're saying, it seems to me that there is no "must have" support work to be done. Any idea of what kind of "nice-to-have" interaction you'd like? | 15:18 |
| racarr | tvoss: Just a boring grey...we painted the concrete floor on our whole back room :) | 15:18 |
| racarr | it was ...a boring chipping dirty grey before | 15:18 |
| === alan_g is now known as alan_g|tea | ||
| kgunn | racarr: good stuff!! | 15:20 |
| kgunn | racarr: the input work...but the grey paint is cool too :) | 15:22 |
| kdub | Rafal_S57, i'll have to think about it... as far as api support, we're pretty happy with the android hal | 15:24 |
| kgunn | Rafal_S57: my 2 cents...i concur with kdub | 15:25 |
| kgunn | Rafal_S57: as long as you've got gles compliance, we should work | 15:26 |
| kgunn | Rafal_S57: any "goodness" from overlay or "special sauce" should be hidden under hwc | 15:26 |
| kgunn | Rafal_S57: so we plan to work on those interfaces as well | 15:27 |
| racarr | :) thanks | 15:28 |
| kgunn | Rafal_S57: sort of supposing, if you're a gpu ip guy....you've got EGL_image_external (since android sort of mandates it) | 15:28 |
| kgunn | Rafal_S57: do you have some gles vendor extensions in mind ? | 15:29 |
| Rafal_S57 | kgunn: there are some GPU specific optimizations, but they are already hidden inside the hwc. I have to run now (gotta pick up kids) but will join tomorrow. Thanks to all for the answers so far! | 15:32 |
| === alan_g|tea is now known as alan_g | ||
| === mmrazik is now known as mmrazik|otp | ||
| jono | boom: http://www.phoronix.com/scan.php?page=news_item&px=MTMzNDk | 16:08 |
| racarr | jono: http://lists.freedesktop.org/archives/wayland-devel/2013-March/008131.html | 16:09 |
| racarr | jono: Seems familiar ;) | 16:10 |
| jono | indeed | 16:11 |
| jono | can we bring him into Mir to help? | 16:11 |
| ogra_ | unlikely | 16:13 |
| ogra_ | he seems to be very wayland focused | 16:14 |
| racarr | It's more than that the goals are very different | 16:14 |
| racarr | "- A project to learn about compositors and think about new compositing concepts | 16:14 |
| racarr | - A place for the community to openly discuss and contribute to the project | 16:14 |
| ogra_ | he actually wants to work on wayland ... | 16:14 |
| racarr | - A place to create new and exciting desktop effects | 16:14 |
| racarr | - An environment that encourages learning about the Linux Desktop, | 16:14 |
| racarr | programming and wayland/northfield. | 16:15 |
| racarr | - An environment that is less restrictive and encourages uninhibited | 16:15 |
| racarr | i.e. | 16:15 |
| racarr | free-flow thinking | 16:15 |
| racarr | - A project that aims to get as many compiz effects as possible, | 16:15 |
| racarr | not requirements driven | 16:15 |
| racarr | working in a wayland compositor" | 16:15 |
| ogra_ | yeah | 16:15 |
| racarr | which is kind of the opposite of what mir is doing. | 16:15 |
| jono | makes sense | 16:17 |
| alan_g | jono: I don't think he's a good fit | 16:20 |
| ninjaaron | So I asked last night, but I had to go before I saw an answer: is Mir going to use libxkbcommon for keyboard input? | 16:51 |
| racarr | ninjaaron: It's not entirely clear :) | 17:20 |
| racarr | the bits that would be useful to us | 17:20 |
| racarr | are largely the keymap and key character mapping | 17:20 |
| racarr | currently we are using the android keymapper. | 17:20 |
| tvoss | racarr, it used to be the plan :) ninjaaron, any specific reason why you are asking? | 17:20 |
| racarr | tvoss: Yes I was ust getting ready to say | 17:21 |
| racarr | it seems likely it will end up that way though :) | 17:21 |
| tvoss | racarr, sorry :) | 17:21 |
| racarr | an issue we will visit soon once the basics for keyboard input land | 17:21 |
| racarr | tvoss: Hehe no problem. | 17:21 |
| racarr | alan_g: At this point now that we have some stuff under an end to end test do you think it makes sense to start refactoring some interfaces in droid-input, etc... | 17:25 |
| racarr | alan_g: i.e. it would be useful for testing if droidinput::InputChannel were mockable | 17:25 |
| racarr | p.s. have some time to look at the looper thing? | 17:26 |
| alan_g | racarr: assuming that it doesn't conflict with killing USE_ANDROID_TYPES | 17:26 |
| alan_g | racarr: About half an hour - unless I get interrupted | 17:27 |
| alan_g | (which I sort of expect tvoss to do sometime) | 17:27 |
| racarr | ;) ok | 17:27 |
| tvoss | alan_g, please clarify :) | 17:29 |
| alan_g | tvoss: <tvoss> "yup, ....before pulling you onto the hangout" | 17:30 |
| alan_g | racarr: so, can I try to help? Or shall I look in the (UK) morning? | 17:32 |
| racarr | alan_g: well hmm it would be useful if you have time | 17:32 |
| === mmrazik|otp is now known as mmrazik | ||
| racarr | I am not sure that the answer isn't just to use the android implementation here | 17:32 |
| racarr | which just uses epoll which seems like a more clear way to express what this is trying to do | 17:32 |
| racarr | than using async_read from boost::asio | 17:33 |
| racarr | alan_g: The problem as it presents, is the usage of looper by InputDispatcher (see around InputDispatcher.cpp l3132) | 17:34 |
| racarr | handleReceiveCallback never fires | 17:34 |
| racarr | that's as far as I have gotten :) because it works with the android types | 17:35 |
| alan_g | racarr: which executable are you using? | 17:36 |
| racarr | alan_g: acceptance-tests | 17:37 |
| racarr | is that true | 17:37 |
| racarr | no thats not | 17:37 |
| racarr | the actual server binary :) | 17:37 |
| alan_g | lp:~robertcarr/mir/send-clients-input? | 17:39 |
| racarr | alan_g: No. that one landed just a sec. | 17:40 |
| racarr | alan_g: lp:~robertcarr/mir/receive-input-in-client | 17:41 |
| racarr | checking for missing files | 17:41 |
| racarr | how surprising there were missing files ;) pushed a second time | 17:42 |
| ninjaaron | tvoss: re: libxkbcommon: I'm a linguist, and I use a lot of custom keymaps, so I have a lot invested in xkb. | 17:43 |
| ninjaaron | it would be nice not to have to do it over. | 17:43 |
| tvoss | ninjaaron, sure :) I'm close to eod'ing. Would you mind if I ping you tomorrow ~13.00 UTC? | 17:44 |
| ninjaaron | It's a date. | 17:44 |
| tvoss | cool | 17:46 |
| racarr | err...pushed for actual now | 17:47 |
| racarr | I have the most problems with my ssh agent :/ | 17:47 |
| alan_g | racarr: It is building.... But I don't think I can do anything much before EOD | 17:49 |
| racarr | alan_g: No worries :) | 17:49 |
| alan_g | racarr: Oops: ...display_server/receive-input-in-client/examples/eglapp.c:88:49: error: unused parameter ‘surface’ [-Werror=unused-parameter] | 17:50 |
| racarr | it's not really blocking me | 17:50 |
| racarr | alan_g: Yeah I just pushed another revision XD | 17:50 |
| racarr | I committed an inprogress revision to push for you | 17:50 |
| racarr | made the egl app demos quit when you hit q :) | 17:50 |
| alan_g | racarr: I'll pick up in the morning - you can get things tidy first. (and tell me exactly what you run/expect in an email) | 17:51 |
| racarr | alan_g: great thanks! | 17:58 |
| === alan_g is now known as alan_g|life | ||
| racarr | Almost done with self review and cleanup for receive-input-in-clients. Lunch break now though! | 19:01 |
| === racarr is now known as racarr|lunch | ||
| === racarr|lunch is now known as racarr | ||
| racarr | kdub: Shwarma at a picnic table on a grey windy day reminded me of copenhagen :) | 19:27 |
| racarr | remember "the mathematical proof of the display server"? | 19:27 |
| kgunn | racarr: i'm curious...."the mathematical proof of the display server"? | 19:34 |
| kdub | racarr, hah | 19:37 |
| racarr | kdub: Haha, it was just...on the train back to the hotel one night, we were talking...I don't remember exactly how it went, but just about how we expected | 19:49 |
| racarr | things to roll out over the next few months | 19:49 |
| racarr | and you were like "And after that is when we finish the mathematical proof of the display server" | 19:49 |
| racarr | and I found it very funny at the time :) | 19:49 |
| racarr | because I was almost thinking about that somehow aha | 19:50 |
| kdub | racarr, yeah, might have just been the boston public transport | 19:50 |
| racarr | really! | 19:50 |
| racarr | ...maybe | 19:50 |
| kdub | but we were relating how if we were developing aerospace software, we'd have to submit a proof with our changes | 19:51 |
| racarr | aha...yes! | 19:51 |
| racarr | Everytime we drop a frame a plane drops from the sky :( | 19:51 |
| racarr | though who knows I read an article about software at spacex | 19:52 |
| racarr | and they talked about how "They don't have hard real-time requirements" | 19:52 |
| racarr | oO | 19:52 |
| kgunn | racarr: kdub :)) | 19:56 |
| racarr | kgunn: Previous mir sprints involved much more getting stuck on street corners in the suburbs of boston and late nights in copenhagen | 20:03 |
| racarr | than the relatively tame london sprint ;) | 20:03 |
| kdub | except for me... :/ | 20:03 |
| racarr | Mm :( | 20:03 |
| racarr | expanded the client input acceptance test so it reproduces the failure with USE_ANDROID_TYPES=false seen in the server binary | 20:15 |
| racarr | trying to fix it now. | 20:16 |
| Rafal_S57 | hi kgunn, do you have a minute to finish our discussion of hwc support in Mir and GPU vendor interaction? | 21:08 |
| kgunn | Rafal_S57: busy now sorry | 21:27 |
| Rafal_S57 | kgunn: ok, np | 21:28 |
| racarr | intermittent test failure in input acceptance test :( race with the server shutting down before the client handles all the events. difficult to solve without a timeout so going to use an unnamed IPC semaphore. | 21:48 |
| kdub | racarr, in which branch? | 21:56 |
| kgunn | Rafal_S57: i'll be on tomorrow morning US central time...just ping | 22:05 |
| racarr | kdub: ~robertcarr/mir/receive-input-in-client | 22:11 |
| racarr | not proposed yet :) | 22:11 |
| racarr | it turns out there are at least two races... | 22:11 |
| racarr | im currently waiting on the tea kettle, and then going to attempt to deconstruct it carefully | 22:11 |
| racarr | kdub: If you are curious ;) the test is the single acceptance test in acceptance-tests/test_client_input.cpp | 22:14 |
| racarr | -.- I got it to always pass but now its sometimes long running | 22:28 |
| racarr | XD | 22:28 |
| racarr | oh...it was a race between resetting the wait condition and the other thread posting it again XD...b ecause I didn't make reset_and_wait | 22:34 |
| racarr | atomic | 22:34 |
| racarr | wait_and_reset ;) | 22:37 |
| racarr | https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 wheeeee | 23:02 |
| racarr | RAOF: ping? | 23:14 |
| RAOF | racarr: Pong. | 23:22 |
| racarr | RAOF: Wondering what we need to do to land the mesa changes | 23:25 |
| racarr | things are broken in trunk atm for clients that use mir_connection_get_egl_display (rather than cast MirConnection directly) | 23:25 |
| RAOF | Ah, so. Last time I tried to build your mesa changes, they didn't work, so I didn't merge them. | 23:26 |
| RAOF | racarr: Could you point me to the current mesa changes that you expect to work? I'll test and then merge them :) | 23:29 |
| racarr | RAOF: let me figure out how to use git | 23:29 |
| RAOF | Urgh :) | 23:29 |
| racarr | RAOF: http://paste.ubuntu.com/5647997/ | 23:32 |
| racarr | just format-patched from my working branch :) | 23:32 |
| RAOF | And that should work with mir trunk? | 23:34 |
| racarr | RAOF: It should! let me double check I am not branch confused | 23:37 |
| racarr | there have been a lot of branches ;) | 23:38 |
| racarr | RAOF: Yes | 23:38 |
| RAOF | racarr: Sweet, thanks. | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
