| === yofel_ is now known as yofel | ||
| robert_ancell | RAOF, did you flash your nexus 4? Any gotchas? | 01:19 |
|---|---|---|
| RAOF | robert_ancell: Yeah, I've flashed my nexus 4. No gotchas that I can remember.e | 01:19 |
| RAOF | Except that you can't keep the screen off but the device on, so it's less interesting as a build box than I hoped :) | 01:20 |
| robert_ancell | RAOF, because it emits too much light? | 01:20 |
| RAOF | robert_ancell: No, not really. It's aesthetically displeasing. | 01:21 |
| RAOF | I could totally use it as a buildbox. | 01:21 |
| * robert_ancell hears the worlds smallest violin | 01:21 | |
| ogra_ | just turn the brightness to 0 | 01:21 |
| ogra_ | there is a sysfs handle for it | 01:21 |
| RAOF | Oh, nifty. | 01:22 |
| ogra_ | (its just linux ;) ) | 01:22 |
| ogra_ | though i wouldnt recommend to build on an eMMC/SD card | 01:23 |
| duflu | I wonder how that compares to using the Nexus 7 as a build box (which I found quite successful) | 01:24 |
| ogra_ | the SoC is definitely a lot more powerful | 01:24 |
| duflu | Though if you can cross compile from a PC, that wins | 01:24 |
| ogra_ | but you dont have USB host mode ... | 01:25 |
| ogra_ | well, for packages that are designed for cross building, thats true | 01:25 |
| RAOF | Sounds like a job for sshfs! | 01:25 |
| duflu | Why do you need USB host mode when you have scp/rsync? :) | 01:25 |
| ogra_ | well, sshfs/rscny over wlan ... | 01:26 |
| ogra_ | could use plain nfs as well, i guess that would be faster ... | 01:26 |
| duflu | Yeah wifi's not much worse than USB 2.0 | 01:26 |
| ogra_ | but if these are the chouces i'd actually take the MMC | 01:26 |
| ogra_ | *choices | 01:26 |
| ogra_ | though stilll, a chromebook is $250 ... and comes with USB 3.0 | 01:27 |
| duflu | Ugg. New keyboard. I'm very slow now. Please be patient. | 01:27 |
| RAOF | Ah, *there* we go - /sys/class/backlight/lm3530/device/lm3630_backlight_on_off | 01:27 |
| ogra_ | if you want a serious device to do native arm builds thats the way to go | 01:27 |
| RAOF | Is building on the MMC likely to kill the flash quickly? | 01:29 |
| ogra_ | nah, i doubt you will manage that in the time you own the phone | 01:30 |
| ogra_ | but its slow I/O | 01:30 |
| * duflu wonders what's wrong with the existing Mir cross-compile script | 01:30 | |
| ogra_ | if your build requires at least some disk I/O it will have quite some impact | 01:31 |
| ogra_ | duflu, in the end it will be packaged and have a bunch of dependencies ... and that means native builds | 01:32 |
| ogra_ | while you build raw upstream code and are sure you have a cross bits in place thats different | 01:32 |
| ogra_ | s/a/all/ | 01:32 |
| ogra_ | cross building packages with a dependency chain is trickier :) | 01:33 |
| TheMuso | RAOF: Do you not have a pandaboard at your disposal? Would that not be a suitable build board? | 02:12 |
| duflu | TheMuso: Pandas are hopelessly slow. Nexus 7 blows it out of the water and supposedly Nexus 4 is similar | 02:15 |
| duflu | ogra_: Thanks you made me realise I can finally buy Chromebooks in Australia. But $349 :P | 02:16 |
| TheMuso | duflu: Rotery disk is better than flash for building no? | 02:26 |
| TheMuso | At least there is that option with panda. | 02:26 |
| TheMuso | But I guess you could use rotery with the Nexus7. | 02:26 |
| TheMuso | duflu: And out re Chromebooks in Australia. | 02:27 |
| TheMuso | s/out/ouch/ | 02:28 |
| duflu | TheMuso: It's true the bottleneck on Nexus 7 is slow flash. But I recall that the panda having only two cores (and slower) was a bigger issue compared to the 4-core Tegra3 | 02:28 |
| TheMuso | Fair enough. | 02:28 |
| TheMuso | I guess we need better dev boards then. :p | 02:32 |
| duflu | Well if ARM servers with far-too-many-cores are now real products then that would be a good build solution, surely... ? | 02:34 |
| duflu | I think it was HP talking about such products in Copenhagen. | 02:34 |
| duflu | www.hp.com/go/moonshot | 02:36 |
| duflu | Of course, that's for Ubuntu builds. Not your desk ;) | 02:46 |
| robert_ancell | RAOF, does installing the PPA mesa hose the phablet UI? | 02:52 |
| RAOF | robert_ancell: I don't see why it would. | 02:52 |
| RAOF | robert_ancell: Does it? :) | 02:52 |
| robert_ancell | RAOF, we'll find out soon... | 02:52 |
| duflu | Surely surface-flinger does not depend on Mesa library paths.... | 02:53 |
| duflu | Or anything "Mesa" | 02:53 |
| RAOF | Also, the PPA mesa shouldn't break anything that depends on Mesa *anyway* | 02:54 |
| duflu | True. My laptop still works with Ubuntu goodness | 02:55 |
| duflu | What's the _eventual_ preference for stride? Should it always represent #bytes or will it become #pixels? | 07:31 |
| duflu | (with respect to MirGraphicsRegion) | 07:32 |
| alf_ | duflu: bytes | 07:35 |
| RAOF | Bytes is probably more useful, yeah. | 07:36 |
| duflu | alf_: Ta. And good morning | 07:36 |
| * alf_ notices that we now have an Android CI job (the buildng part of it, at least) | 07:39 | |
| tvoss | alan_g, ping | 08:39 |
| alan_g | tvoss: ? | 08:39 |
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| === mmrazik is now known as mmrazik|lunch | ||
| alf_ | alan_g: fyi, I am working on changing render-surfaces to use DisplayServer(Configuration) | 11:16 |
| === mmrazik|lunch is now known as mmrazik | ||
| === tvoss is now known as tvoss|lunch | ||
| === tvoss|lunch is now known as tvoss | ||
| alan_g | alf_: Excellent! | 12:53 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| racarr | Mew | 15:27 |
| racarr | Morning :) | 15:27 |
| alf_ | racarr: Hello | 15:28 |
| === rsalveti_ is now known as rsalveti | ||
| === Darxus_ is now known as Darxus | ||
| alan_g | racarr: Hello | 15:50 |
| racarr | alan_g: Hi | 15:50 |
| racarr | alan_g: Btw wanted to ask you...seen any weird segfaults with | 15:54 |
| racarr | droidinput::sp, droidinput::Vector and finally the android atomics? | 15:54 |
| racarr | I thought I was going to make my big integration test for input branch pass last night and now segfaults in android atomics | 15:55 |
| racarr | tried with and without android types | 15:55 |
| alan_g | racarr: I haven't | 15:55 |
| alan_g | Is this a hybris/android target? | 15:56 |
| racarr | alan_g: No native x86 | 15:57 |
| alan_g | Not seen it. Want me to look? (Yet.) | 15:59 |
| racarr | alan_g: I will try and make a reduced test case later. I haven't spent so much time on it yet | 15:59 |
| racarr | I was just hoping it sounded familiar | 15:59 |
| alan_g | Sorry to disappoint you | 16:00 |
| racarr | deciding what to do with prepare-for-inprocess-egl-clients now | 16:01 |
| racarr | :) no worries | 16:01 |
| racarr | it is weird because the android doesn't really need | 16:12 |
| racarr | a NativeDisplayContainer | 16:12 |
| racarr | so it would be possible to write the | 16:12 |
| racarr | mir_egl_native_display_is_valid using | 16:13 |
| racarr | an ifdef (just mir_connection_is_valid) on android | 16:13 |
| racarr | seperate versions of mir_egl_native_display_is_valid | 16:13 |
| racarr | or an android implementation (which is rather trivial) | 16:14 |
| racarr | but seems kind of like a verbose way to do nothing | 16:14 |
| alf_ | status: investigating a graphical glitch in the WIP code to change render-surfaces to use DisplayServer(Configuration) | 16:15 |
| racarr | alf_: Any opinions on what to do with android for NativeDisplayContainer? | 16:17 |
| racarr | I am inclined to just move the definition of mir_toolkit::mesa_native_display_is_valid | 16:17 |
| racarr | to android/gbm | 16:17 |
| alf_ | racarr: let me refresh my memory | 16:17 |
| racarr | alf_: :) Don't feel like you have to process it immediately | 16:18 |
| alf_ | racarr: it would be refreshing change from trying to debug a graphical glitch :) | 16:18 |
| racarr | Aha...I know the feeling | 16:20 |
| racarr | the basic issue is pretty simple, mir_egl_native_display_is_valid uses mcl::EGLNativeDisplayContainer::instance which is defined in the gbm bits | 16:20 |
| racarr | along with the implementation of EGLNativeDisplayContainer | 16:21 |
| racarr | trying to decide if android should also implement EGLNativeDisplayContainer (seems unnecessary) | 16:21 |
| racarr | or one of these other approaches should be used | 16:21 |
| hikiko | hi | 16:23 |
| alf_ | racarr: It would be a dummy implementation, so I don't see the harm in doing it this way. It would move the complication to the build system instead of the code. | 16:24 |
| alf_ | racarr: (almost dummy implementation) | 16:24 |
| racarr | hmm | 16:27 |
| racarr | Im not sure which way to do it though (using the build system) so now I am kind of leaning | 16:28 |
| racarr | to just implementing the display container haha | 16:28 |
| alf_ | racarr: IIRC, The only symbol that the rest of the code needs mcl::EGLNativeDisplayContainer::instance(), so defining it in src/client/android/android_native_display_container.cpp should do the trick | 16:32 |
| racarr | alf_: But it wants an instance of EGLNativeDisplayContainer returned | 16:32 |
| racarr | so have to write a little android stub | 16:33 |
| racarr | thats what I just did though :) | 16:33 |
| alf_ | racarr: right, and great :) | 16:33 |
| alf_ | racarr: perhaps Kevin will find the abstraction useful and use it more extensively in the android backend | 16:34 |
| racarr | thats what I am thinking | 16:34 |
| racarr | alan_g: prepare-for-inprocess-egl-clients is updated | 16:34 |
| racarr | android build works :) | 16:34 |
| alan_g | racarr: I'll look soon | 16:35 |
| racarr | Going to change https://code.launchpad.net/~robertcarr/mir/happy-monday-dedupe-more-stubs/+merge/153713 to approved if no one objects soon :) | 16:35 |
| === hikiko is now known as hikiko_away | ||
| alan_g | racarr: It will conflict with something I'm working on - but that's life | 16:41 |
| racarr | What are you working on? | 16:43 |
| racarr | hmm actually I need | 16:44 |
| racarr | another approve, I think no review since I merged trunk | 16:44 |
| racarr | I dunno if someone wawnts to review... | 16:44 |
| racarr | changes at 190-211 came in during trunk merge | 16:44 |
| alan_g | racarr: https://code.launchpad.net/~alan-griffiths/mir/refactor-frontend-Surface-cleanup/+merge/154138 | 16:45 |
| alan_g | racarr: looking at prepare-for-inprocess-egl-clients | 16:46 |
| racarr | :) thanks | 16:51 |
| racarr | frntend-Surface-cleanup looks fine so far (quick read) | 16:51 |
| alan_g | racarr: that's what you MP would conflict with. | 16:51 |
| johnjohn101 | any ideas on what video system will be best supported by mir (short term)? | 16:51 |
| alan_g | racarr: "+Cflags: -I@INCLUDEDIR@/mir" - can that be right? | 16:52 |
| racarr | err. let me look | 16:52 |
| racarr | alan_g: No its not | 16:53 |
| racarr | its left over from when we had like | 16:53 |
| racarr | err.../usr/include/mir/mir_toolkit/api.h | 16:54 |
| racarr | r512 :) | 16:54 |
| racarr | hrm | 16:55 |
| racarr | my test doesn't seem | 16:55 |
| racarr | to fail or pass or crash or anything | 16:56 |
| alan_g | racarr: we need to nail down this naming issue. | 16:56 |
| racarr | it appears to exit unit tests normally | 16:56 |
| racarr | alan_g: Which, sorry | 16:56 |
| racarr | for headers? | 16:56 |
| alan_g | racarr: and their directories and packages | 16:56 |
| alan_g | racarr: there's a reason the first TDD step is to write a failing test. | 16:57 |
| racarr | alan_g: It did fail until I implemented it | 16:58 |
| racarr | and then it failed in more surprising ways (the atomic stuff, which is now fixed) | 16:58 |
| racarr | but now it just runs, seems to go through the test | 16:59 |
| racarr | and exit google mock normally | 16:59 |
| alan_g | what was that (atomic stuff)? | 16:59 |
| racarr | but there is nothing about passing or failure or exceptions or errors or | 16:59 |
| racarr | anything | 16:59 |
| racarr | just wasn't keeping a droidinput::sp when I needed to | 16:59 |
| alan_g | Tried putting #error in the test body? | 16:59 |
| racarr | ? | 17:00 |
| alan_g | To prove you're compiling the test and haven't lost it in a merge | 17:00 |
| racarr | oh well I just tried that but yes | 17:00 |
| racarr | it is the test... | 17:01 |
| racarr | I can remove expectations | 17:01 |
| racarr | and get errors about unexpected calls etc | 17:02 |
| alan_g | racarr: could you be leaking the mock objects? | 17:02 |
| alan_g | Then their expectations are not validated | 17:02 |
| racarr | mm thought about that so then I tried verifying them | 17:03 |
| racarr | and also checking for leaks | 17:03 |
| racarr | the thing is it doesn't even print OK/FAIL or whatever | 17:04 |
| racarr | it just exits | 17:04 |
| racarr | tried breaking in exit | 17:04 |
| racarr | but its not informative | 17:04 |
| alan_g | racarr: puts("GOT HERE")? | 17:04 |
| racarr | it finishes the entire test | 17:04 |
| racarr | body | 17:04 |
| racarr | and invokes the tear down | 17:04 |
| alan_g | racarr: that's too weird. | 17:05 |
| alan_g | What's the branch, which test? | 17:06 |
| racarr | alan_g: lp:~robertcarr/mir/send-inputs-to-client | 17:07 |
| racarr | unit_tests/inut/android/test_android_input_manager.cpp | 17:08 |
| racarr | set_input_focus | 17:08 |
| alan_g | alf_: do we have a useful answer for johnjohn101 @"any ideas on what video system will be best supported by mir (short term)?" | 17:08 |
| alan_g | racarr: I'll see what happens here | 17:09 |
| racarr | alan_g: thanks | 17:10 |
| racarr | the thing is if you comment out | 17:10 |
| racarr | line 239 | 17:10 |
| racarr | the expectations fail | 17:10 |
| racarr | but it pritns things and becomes useful again and properly faild | 17:10 |
| alan_g | racarr: bzr denies that branch exists | 17:10 |
| racarr | properly fails*. | 17:11 |
| racarr | err.. | 17:11 |
| racarr | alan_g: Oh send-input-to-clients | 17:11 |
| racarr | not send-inputs-to-client | 17:11 |
| racarr | XD | 17:11 |
| alan_g | Wandering "s" ;) | 17:11 |
| alf_ | johnjohn101: Do you mean what kind of GPU? Also, do you care about mobile devices or desktop? | 17:13 |
| alan_g | racarr: missing file? fatal error: mir_test_doubles/mock_input_focus_selector.h: No such file or directory | 17:16 |
| racarr | whoops...sorry haven't done my pre push pass on this branch yet | 17:17 |
| alan_g | racarr: no worries - but I need that file to test what you have | 17:18 |
| racarr | alan_g: Pushed another rev | 17:19 |
| alan_g | racarr: ack | 17:19 |
| alf_ | johnjohn101: in any case, on the desktop it's anything with a working DRM/KMS and GL (Mesa) driver (mostly tested with intel and radeon). For mobile is the nexus and galaxy nexus phones. | 17:20 |
| alf_ | alan_g: racarr: Is anyone looking into stabilizing the VM CI build? If not, I will try to take a look tomorrow. | 17:21 |
| alan_g | alf_: what's the problem? | 17:22 |
| alan_g | racarr: I see the problem | 17:23 |
| racarr | Oh? | 17:23 |
| racarr | *prepares for facepalm* | 17:23 |
| alan_g | (But it does leak) | 17:23 |
| racarr | oh really | 17:23 |
| alan_g | racarr: I don't see the solution yet | 17:23 |
| alan_g | ;) | 17:23 |
| alf_ | alan_g: racarr: BespokeDisplayServerTestFixture.focus_management is consistently failing in VM builds (both for CI and autolanding) | 17:25 |
| racarr | alan_g: Oh hmm wait something related to the MockInputDispatcher leaks? | 17:25 |
| racarr | alan_g: I have not looked yet no...didn't know it was | 17:25 |
| alan_g | alf_: I didn't know => haven't looked into it. All yours. | 17:26 |
| alf_ | alan_g: racarr: ok | 17:27 |
| alf_ | all: Have a great rest of day | 17:27 |
| alan_g | alf_: Have a great evening! | 17:27 |
| racarr | See you alf_ | 17:30 |
| racarr | alan_g: Hmm wait even if I remove all the expectations I am still getting the same weird non-failure | 17:31 |
| racarr | but it was definitely failing earlier...what have I done! | 17:31 |
| === mmrazik is now known as mmrazik|eod | ||
| alan_g | racarr: The process is exiting (with status 1) after doing the TearDown() step. I have a vague recollection of seeing that with an attempt to access an already dead object during destruction. | 17:38 |
| racarr | hmm | 17:40 |
| === kgunn is now known as kgunnAFK | ||
| racarr | status: Stuck and hungry so breaking to cook bacon and a bagel :) | 17:50 |
| racarr | during the day I sometimes think of myself as an object for transforming bacon, bread, and tea and C++ in to | 17:51 |
| racarr | different C++ | 17:51 |
| ogra_ | poor jono | 17:54 |
| ogra_ | but at least he has a bagel as company | 17:55 |
| jono | lol | 17:56 |
| racarr | Took me a second! | 17:58 |
| alan_g | racarr: I don't see what is happening. No C++ exception, no signal and _exit() is called with an uninformative stack. Going to play chess instead. | 17:58 |
| ogra_ | funnily you wrote that while on the ubuntu phone list the mail with "[Ubuntu-phone] No bacon?" rolled in | 17:59 |
| ogra_ | we're really community driven these days :) | 17:59 |
| ogra_ | bacon everywhere ! | 18:00 |
| === mmrazik|eod is now known as mmrazik | ||
| === alan_g is now known as alan_g|chess | ||
| racarr | alan_g|chess: Enjoy :) I will figure it out | 18:01 |
| racarr | thanks | 18:01 |
| === kklimonda_ is now known as kklimonda | ||
| min2 | hello | 18:15 |
| racarr | narrowed it down significantly... | 18:17 |
| racarr | something weird with droidinput::sp and gmock going on | 18:17 |
| racarr | surprising! ;) | 18:18 |
| racarr | oh or maybe not...it seems to really just be the construction of the window handle from the application handle... | 18:19 |
| racarr | maybe there is something I am missing about droidinput::RefBase | 18:19 |
| racarr | hmm | 18:25 |
| racarr | I fixed it but I don't understand how...and ran in tot he next problem! InputChannel constructor throws without real fds | 18:25 |
| === kgunnAFK is now known as kgunn | ||
| racarr | hmm ok later maybe a factory and mocking for droidinput::InputChannel | 19:05 |
| racarr | for now the test can use a socketpair ;) | 19:05 |
| === yofel_ is now known as yofel | ||
| bcbc2 | I'm running mir on 13.04 with the ppa. When I add 'type=mir' to lightdm.conf and restart lightdm it runs in low graphics mode. If I then reboot I just get a black screen. I'm following the instructions here: http://unity.ubuntu.com/mir/using_mir_on_pc.html Any hints on how to debug? | 20:08 |
| kgunn | bcbc2: did you "ensure you have the proper custom Mesa build installed" | 20:18 |
| bcbc2 | kgunn: it says "If you installed Mir using the packages from mir-team staging PPA ..., you should be good to go. | 20:21 |
| kgunn | bcbc2: it sure does...and you should....hmmm | 20:22 |
| bcbc2 | kgunn: I tested it with those instructions for "Running MIR natively". I used mir_egltriangle and it worked okay. Does that qualify as 'some-mir-client' in those instructions? | 20:26 |
| kgunn | bcbc2: yes | 20:27 |
| kgunn | its what you think....just a little gl triangle app rendering to a mir surface | 20:27 |
| bcbc2 | kgunn: ok... good. So are there any log files I should be checking too troubleshoot the black screen? I've been rebooting into recovery mode and removing 'type=mir' before restarting to get around it. | 20:30 |
| johnjohn101 | is mir shipping with the next version of ubuntu ( 13.10 maybe). | 20:31 |
| kgunn | bcbc2: sorry...i'm not the best at desktop x stuff... | 20:31 |
| kgunn | bcbc2: i'll be honest...i've been on quatal....wonder if its cause your on raring? | 20:32 |
| kgunn | bcbc2: no specific knowledge....just thinking aloud | 20:32 |
| bcbc2 | kgunn: ok - cool. It's not a big deal. I'll maybe play around with quantal or take a break. Thanks. | 20:33 |
| kgunn | bcbc2: you prompted me to update a second hand machine i had to raring....maybe i'll try those instructions and see what gives | 20:33 |
| kgunn | also....i'll mention it to some of the other fellows who have more experience on x/compiz/mesa | 20:34 |
| kgunn | johnjohn101: shipping is kind of loaded | 20:35 |
| kgunn | johnjohn101: in general there is a goal/vision of convergence of what we achieved with the ubuntu touch/phablet | 20:36 |
| kgunn | if you read some of the spec | 20:36 |
| johnjohn101 | next year is ok. i'm ready for ubuntu to be at the next level | 20:36 |
| kgunn | https://wiki.ubuntu.com/Mir | 20:37 |
| kgunn | johnjohn101: sorry...digging out links i'm slow :) | 20:37 |
| kgunn | one more | 20:37 |
| kgunn | https://wiki.ubuntu.com/UnityNextSpec | 20:38 |
| johnjohn101 | tx kgunn | 20:38 |
| kgunn | not sure when you got disconnected | 20:39 |
| kgunn | but if you look at those 2 links | 20:39 |
| johnjohn101 | last message from you was "one more" | 20:39 |
| kgunn | https://wiki.ubuntu.com/UnityNextSpec | 20:39 |
| johnjohn101 | sorry working and connecting to clients and it resets | 20:39 |
| kgunn | np | 20:39 |
| kgunn | so those 2 links outline what/why and point to the how which is really in all the blueprints | 20:40 |
| kgunn | but you could think...focus is to get solid on "small screen" devices first | 20:40 |
| johnjohn101 | kind of crazy for ubuntu to switch to QT on a dime | 20:40 |
| kgunn | then grow into "large screen" devices to achieve 1 code base to rule them all | 20:40 |
| kgunn | johnjohn101: it may seem a little crazy...but i think Qt evolved to the point where you can get gl goodness & great ease of use/fast development (as a toolkit) | 20:42 |
| === kgunn is now known as kgunnAFK | ||
| racarr | [ RUN ] AndroidInputManagerDispatcherInterceptSetup.server_input_fd_of_focused_surface_is_sent_unfiltered_key_events | 21:21 |
| racarr | Device added: id=0, name='', sources=0x00000101 | 21:21 |
| racarr | [ OK ] AndroidInputManagerDispatcherInterceptSetup.server_input_fd_of_focused_surface_is_sent_unfiltered_key_events (4 ms) | 21:22 |
| racarr | Yay | 21:22 |
| kdub_ | racarr, on device :) i saw our input library booting up the input devices | 21:24 |
| kdub_ | *? | 21:25 |
| racarr | kdub_: Probably! | 21:30 |
| racarr | the way it is in trunk is if you have permissions on the input device it should probe the appropriate ones and events will flow from kernel->event hub->input reader->input dispatcher->input dispatcher policy->event filters (there are none in trunk) | 21:30 |
| racarr | and then there will be no focused window so it will be dropped | 21:30 |
| racarr | this last branch is to hook up focus and | 21:31 |
| racarr | THEY GOOOOO | 21:31 |
| RAOF | Who wants to review client-side-buffer-age! It'll be fun! | 22:25 |
| racarr | RAOF: I will do it in just 10 minutes. it will be good to switch state back and forth before I do self review | 22:26 |
| RAOF | Oh, god. Self review. BAH | 22:26 |
| racarr | hehe | 22:30 |
| racarr | RAOF: https://code.launchpad.net/~robertcarr/mir/send-input-to-clients/+merge/154221 exists and is close to its final state if you want something t look at :) will propose properly after self review round after reviewing client-side-buffer-age! | 22:30 |
| racarr | But first, tea + food | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!