=== thomi|lunch is now known as thomi
thomiRAOF: I'm having problems building glmark2 in a chroot - it complains about not being able to find the 'gl' package - that should be provided by libgl1-mesa, right?01:32
RAOFthomi: Which mesa are you using? There was a version of mesa in the PPA which was broken. You need libgl1-mesa-dev installed.01:33
RAOFthomi: (It's been brought to my attention that not everyone knows about apt-file - if this describes you, then ‘apt-file search gl.pc’ will tell you what package contains gl.pc)01:34
thomiRAOF: that's what it's installing...01:34
thomiRAOF: I wonder if you could scan over this? http://pastebin.ubuntu.com/5669187/01:35
thomiI'll try and get that waf log01:37
RAOFYou might need the newer mesa - I take it the PPA hasn't yet managed to build the mesa branch?01:37
thomino, I think Martin sent you an email about that?01:38
thomiRAOF: I tell a lie - I built and pushed it manually last week01:40
thomiso there's a a mesa package in the PPA from 28/0301:40
RAOFthomi: Oh, right. It just doesn't have the version I expected01:52
thomiRAOF: it's using the version I built last Friday01:52
RAOFYeah. I just expected that to be called +mir301:53
thomiRAOF: so it turns out that gl.pc exists in the chroot02:01
RAOFthomi: Are you able to get /tmp/buildd/glmark2-2012.08+266+13/build/config.log ?02:02
thomiRAOF: yeah, just figured out what the issues is:02:02
thomiit needs the xcb-dri2 package02:02
thomiwhich isn't a build-dep02:02
RAOFHm. That would be a bug in libgl1-mesa-dev, then.02:02
RAOFA development package should always depend on all the other development packages required to use it.02:03
thomiwant me to file a bug?02:04
RAOFthomi: Yeah, thanks. It's probably only a problem in the Mir mesa package so far, though.02:26
RAOFBah! GCC's libstdc++ doesn't implement list.erase(const_iterator it) as specified by C++11.02:29
dufluRAOF: It does implement that erase. I have used it for years. You mean the version that returns an iterator? That one is uncommon02:49
RAOFduflu: Hm. My g++ failed to find it, and http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 suggests that it's not implemented.02:50
RAOFduflu: Perhaps you're thinking of list.erase(iterator it)?02:50
dufluRAOF: Maybe02:53
dufluThough it would make sense to use a non-const iterator, kinda02:54
RAOFYeah, kinda. C++11 standard says it takes a const_iterator, though.02:54
RAOF(As does list.insert(const_iterator it))02:55
RAOFWhich also makes sense, as they don't modify any list elements.02:55
* RAOF wonders whether the valgrind tests _really_ need to take 7 minutes02:56
robert_ancellracarr, hey, got an input question. How do I intercept alt+ctrl+Fn in the current server? Is that possible?03:02
RAOFI'm unsure...03:05
RAOFduflu: When you throw() in the edge-types merge proposal, is that caught somewhere sane?03:06
dufluRAOF: Yeah it's caught well below that. In an existing location at above the frontend. I forget where. The tests cover it03:07
RAOFCool. That merge looks reasonable to me, then.03:08
dufluRAOF: It's usually a good indicator of efficiency, how well your code runs under valgrind. Valgrind is a good analog of a "slow machine" which we should be able to support. So yeah, 7 minutes is way too much03:09
dufluValgrind, particularly, shows you where your code is CPU-bound.03:11
smspillazRAOF: duflu the only reason why those valgrind tests would take 7 minutes is because you have to set up and tear down valgrind all the time03:12
smspillazcode under valgrind is supposed to run about 5x slower in the best case03:13
RAOFDoesn't valgrind interact poorly with highly threaded code, too?03:14
smspillaz*shrug* maybe03:18
smspillazbut I know that tests taking forever under valgrind is likely to be a direct product of the valgrind startup cost03:18
smspillazconsidering the fact that your unit tests probably run in half a second and your integration tests maybe run in 20 seconds tops03:18
smspillazadd n * valgrind startup and it gets expensive fast03:19
duflu5x slower would be fine. But the several orders of magnitude we see, not so fine03:20
smspillazI've been thinking recently the maybe the best way to do the tests is to create static libraries linked to libgtest with all of your tests and then link them together into a single binary for each main () that you wish to provide (eg gtest_main, xorg_gtest_main etc)03:21
smspillazif you want to valgrind / callgrind / whatever your tests, it means that you only need to run valgrind once per binary as opposed to once per test03:21
* smspillaz has been working on a little thing that would effectively do just that03:22
dufluOoh, sorry. Yes. Valgrind startup is an artificially slow bottleneck. We should ideally not be starting new processes all the time03:23
smspillazits my one gripe with ctest's ExperimentalMemCheck target03:24
robert_ancellRAOF, you should probably approve your use-dma-buf MP - it's marked as needs fixing by you03:24
RAOFrobert_ancell: No-one else has reviewed it.03:24
RAOFOh, ahem.03:24
duflusmspillaz: I still intend on resolving that Compiz branch madness when didrocks says I can03:26
dufluLast I checked, the diff was small03:26
smspillazduflu: didn't didrocks say you could ?03:26
duflusmspillaz: He said wait a little03:26
smspillazI'm pretty sure you got the "go for it" like a month ago now :p03:26
dufluHe was "busy"03:26
RAOFrobert_ancell: And to answer your question, no, I don't think you can get alt+ctrl+Fn in the X server.03:27
dufluIt's ridiculous because the diff was only 160 lines when I last checked03:27
smspillazduflu: why would there be a diff for changing a branch name ?03:27
RAOFrobert_ancell: Except it just occurs to me that this is not what you were actually asking :)03:27
robert_ancellRAOF, in X? I mean intercept it inside /usr/bin/mir03:27
duflusmspillaz: You need to merge the "raring" and "0.9.9" branches first. They differ03:28
smspillazoh right. I believe that was intentional03:28
robert_ancellRAOF, I was trying to work out why I wasn't getting the VT signal on my VT branch, then I realized that of course nothing would be grabbing the key combination03:28
smspillazthe diff is much larger now03:28
* duflu -> coffee03:28
smspillazduflu: the "raring" branch was basically the great-distro-strategy to cut off myself and mc-return so they could cherry pick everything03:28
smspillazbecause you know03:29
smspillazcherry picking always results in more stable code03:29
robert_ancellduflu, can you see if https://code.launchpad.net/~robert-ancell/mir/frontend-class-renaming/+merge/156430 seems like an improvement to you?03:29
smspillazI don't understand it when people think they know better than the maintainers ...03:29
RAOFBecause the common case is that we _do_ know better than the maintainers :)03:30
bschaefersmspillaz, welll we are suppose to fix that raring branch, as it was a mistake from what I understand...03:30
RAOF(Because we often have significantly different goals to the maintainers)03:30
smspillazRAOF: sure, you have different goals03:30
smspillazmy point is that cherry-picking tends to do more harm than good, especially the kind of cherry picking focused on "lets get the fix without the refactoring"03:31
smspillazunless you have a very detailed knowledge of that codebase to understand why that might be a good idea03:31
duflubschaefer, smspillaz: Yeah no need for anyone to get angry or worry about it. We have consensus that it should and will be resolved03:32
smspillazI'm not angry at all :)03:32
bschaeferduflu, yeah, its on the heap, but someone has to do it, and Ill be poking around to see what needs to be done soon ...03:33
duflubschaefer: I'll do it as soon as didrocks says I can. In fact, I might do the parts that don't interfere with anyone's work soon03:33
bschaeferduflu, well its always nice to learn :), I just got caught up with that 100 scopes thing last week and didn't get around to it03:34
* bschaefer thinks its green lighted atm03:34
duflusmspillaz: Also, it's not about who knows best or being picked on. It's a matter of we should have branched earlier to give distro stabilization time and you somewhere to land new stuff without worrying distro03:35
duflubschaefer: It was agreed by everyone but didrocks explicitly asked me to wait03:35
smspillazduflu: I wasn't interested in landing anything new that wasn't going to affect distro03:35
smspillazwhy would I work on a dead end?03:36
bschaeferduflu, oo, didn't know that, I can poke him tomorrow morning as well about it :)03:36
bschaefersmspillaz, to learn!03:36
smspillazI have other projects where I can do that03:36
duflusmspillaz: That dead end is the only complete and functional desktop we have for now. It's no dead end (yet)03:36
bschaefersmspillaz, very much so :)03:36
smspillaz*shrug* if distro wanted to branch early ... they really could have just asked03:37
smspillazthat being said, they've already done it03:37
dufluYeah, just /wrong/03:37
dufluNever mind. I'll fix it03:37
smspillazand needless to say, upstreams should be following the freeze process anyways03:38
smspillazso there shouldn't even be a need for a branch03:38
duflurobert_ancell: Looks like some things I was thinking about. Will get to it03:39
robert_ancellduflu, ta03:39
=== jono is now known as Guest90083
RAOFUrgh. Git's UI is a fractal of horibleness.04:24
=== tvoss|easter is now known as tvoss
RAOFWhen can I stop caring about Quantal?06:37
dufluRAOF: When you absolutely have to...06:40
dufluRAOF: Or after I upgrade my desktop ;)06:40
tvossalf_, ping07:29
alf_tvoss: pong07:39
tvossalf_, did you see thomi's mail to mir-devel? Is the branch he is looking at the current one?07:39
alf_tvoss: hmm, I thought I pushed the right branch, trying to push again...07:42
tvossalf_, ack07:42
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
alan_gtvoss: ping08:15
tvossalan_g, pong08:32
tvossalan_g, no invite arriving in my inbox09:54
alan_gtvoss: looking...09:56
alan_gtvoss: ... - it says you've been invited. Hang on.09:56
tvossalan_g, thx09:57
alan_gtvoss: just removed and re-added you09:57
tvossalan_g, thx09:57
arssonis there any other packages that needs to install manually that mir require?11:13
alan_garsson: is your context not covered by http://unity.ubuntu.com/mir/?11:16
arssoni have done everything what told there but i only get black screen when running mir11:21
alan_garsson: That's what I'd expect - unless you also start a client application that puts something on the screen11:22
arssonok... i'm stupid so how do i do that?11:24
alan_garsson: something like: ./mir & sleep 1 && ./mir_egltriangle & sleep 8 && kill $(pidof ./mir_egltriangle) & sleep 1 && kill $(pidof ./mir)11:39
arssoni have only run command ($~ mir)  do i need to type something else that start unity desktop with mir?11:56
alan_garsson: are you thinking that mir is a finished product? It is a library in development and will be used by a *future* version of unity.12:08
arssonno but i'm exited and anxious12:11
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
=== alan_g is now known as alan_g|reboot
=== gema_ is now known as gema
=== rsalveti_ is now known as rsalveti
alan_gracarr: afternoon14:20
racarralf_: Re: enable-inprocess-egl14:21
racarrdid you apply the mesa patch mentioned in the comments for the branch14:22
racarrthis patch is incorrect14:22
alf_racarr: I didn't apply it14:23
racarralf_: Posted a new one14:25
racarrit's necessary otherwise the14:25
racarrDRM EGL backend conflicts with the mir one14:25
alf_racarr: thanks, I will try it out14:27
racarralan_g: Left some comments on receive-input-in-client (+ updates)14:36
alan_gracarr: will look...14:37
=== alan_g is now known as alan_g|tea
alf_racarr: It doesn't seem mir_toolkit/mesa/native_display.h is installed by make install14:56
dharmaonemissed the session :( this might have been answered already - will existing ubuntu apps work on new versions of ubuntu that use QT and mir - or will they have to be rewritten?15:00
tvossdharmaone, depends on the toolkit support for Mir, but in general: you don't need to rewrite your app to run against Mir15:02
tvossdharmaone, I think the session was recorded and you can watch it on youtube15:02
kdubmorning folks, status, began working on our own framebuffer native window for android15:03
dharmaoneok :) what about current apps that are not written with QT - will they have to be rewritten? (not really mir related)15:03
tvossdharmaone, again, toolkit dependent, but in general no :) the point is that an app hardly ever should know about the underlying display server15:04
alf_status: reviewing, bug fixing, thinking about main loop15:05
tvossdharmaone, there might be some apps that are tightly coupled to X for one or the other reason. Those will be supported by an in-session, on-demand rootless X server that talks to Mir (much like in OS X)15:05
tvossdharmaone, http://youtube.com/ubuntuonair15:06
=== alan_g|tea is now known as alan_g
racarrstatus: Made some updates to branches. Did some review15:07
racarrworked on new version of qtubuntu and ubuntu-platform-api-mirclient yesterday and produced some working code15:07
racarrgoing to go through and see if there is anything else I need to do right now and if not work on those some more15:08
racarr(goal: Qt backend against Mir with input:))15:08
racarrAnybody need some help or review or anything?15:12
alan_gracarr: quick hangout?15:19
racarralan_g: Sure15:21
racarrgcalling you15:21
racarralan_g: I can hear you just a sec15:22
racarrtvoss: Made some comments on QtUbuntu stuff and input/platform-api, etc here https://bugs.launchpad.net/mir/+bug/116339315:45
ubot5Launchpad bug 1163393 in Mir "qmir does not support input" [Undecided,Confirmed]15:45
racarr(we talked about this briefly in the past and you said you would think about it :))15:45
racarrtalked about using this approach of abstraction through the platform api15:46
tvossracarr, will look into it, thanks for the pointer15:46
kdubalf_, updated hwc-integration :)15:52
kdub sorry to be a bother about it :P15:52
alf_kdub: no worries, unfortunately I found a couple of naming nitpicks (see comment), but I will pre-approve to unblock you since I don't have anything else15:57
kdubalf_, thanks, will take care of those15:58
racarrgoing to make android input stack compile in clang16:25
racarrmany of the more confusing errors seem to be about the boost asio based looper which we are dropping anyway :)16:25
racarr/home/augustwest/src/mir/mir/fix-input-build-clang/cmake/src/mir/mir_discover_gtest_tests.cpp:(.text+0x12b3): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)'16:27
racarrinfinite erros around this line now...16:27
racarrlibandroidinput.so actually links :)16:27
racarrok er building clang from trunk doesn't work either for me16:29
racarr-DCMAKE_CXX_COMPILER=/usr/bin/clang -DCMAKE_C_COMPILER=/usr/bin/clang -DMIR_DISABLE_INPUT=true16:29
racarrhow should it work?16:29
racarrHow can I see the options that the jenkins clang build uses?16:29
racarrMIR_DISABLE_INPUT=true does not seem to be the same as MIR_DISABLE_INPUT=ON but both will stop libandroidinput.so from building ;)16:33
racarroh maybe that wasn't it. Looks like clang behaves differently invoked as clang++16:35
mpttvoss, hi. The phone calls for "Accessibility controls for visually impaired". So for starters, I'm thinking of speccing an "Invert black and white" setting. Does that sound feasible for Mir on the phone?16:40
racarralan_g: https://code.launchpad.net/~robertcarr/mir/fix-input-build-clang/+merge/15663416:41
racarrIt turns out it was trivial :)16:41
racarrI mean unit-tests fails but it builds!16:41
racarrand I think unit-tests failed anyway16:41
mpttvoss, i.e. composit (composite?) such that for every pixel, the value is reversed, while the hue and shade stay the same.16:42
tvossmpt, hey there :) I think it's better if you check with kgunn and robert_ancell on Mir specifics, but in general, I think it should be possible to apply a custom shader to the final composited image that inverts colors16:43
kdubmpt, right. mir can do it, its more a matter of feature scheduling as to when16:43
mptkgunn, what do you think? ^^^^16:43
kdubalthough mpt, contributions are welcome :)16:44
mptkdub, the contribution I am instructed to make is to design the settings :-P16:44
alan_gracarr: do you understand the need for "mt::" in tests/integration-tests/input/android/test_android_input_manager.cpp? The rest looks obvious16:45
kdubmpt haha, just trying to remind the rest of the channel that we are open :)16:45
mptkdub, fair enough. I've had good, though unpredictable, results from publishing UI designs for wishlist features.16:46
=== mmrazik is now known as mmrazik|eod
kgunnmpt: i'd say let's capture it in a bp...16:47
kdubmpt, yeah... i can see that they would be tricky to convey widely16:47
kgunnmpt: is this a "just capture it" query....or is there a pressing thought behind it16:48
mptkgunn, the comically misnamed "Unity API" team has the job of implementing settings UI. So in designing that UI, I need to find out which settings are likely to actually exist. Bad to have UI for a setting without the setting, and (to a lesser extent) vice versa.16:49
kgunnmpt: :) sure16:49
racarralan_g: Yes the namespace {}16:51
mptkgunn, excuse the ignorant question, but is display brightness handled by the display server, or is that at a lower level?16:51
racarrmakes it a seperate instantiation of the function for each16:51
racarrso the functions become "unused"16:51
racarrwhich is an error with our clang settings16:51
racarrwell they become unused by people who include mock_event_filter but don't use the matcher16:52
racarrtranslation units blablablabla16:52
alan_gracarr: Great16:52
kgunnmpt: great question actually....brightness for sure will have a low level element to it...but the question is, should mir abstract that sort of thing away16:52
kgunntvoss: ^   my gut says...probably a server side shell interaction w mir?16:53
tvosskgunn, I think it's partly a setting but there needs to be a post-process step for the compositor ... at least htat's my gut feeling16:54
mptThe only reason I ask is to know whether it should be in the same blueprint16:55
racarralan_g: Fixed the whitespace here too https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 (r619 will take a sec to refresh)16:56
alan_gracarr: seems like a conflict now. But I'll change my vote anyway17:03
kgunntvoss: post process for brightness?...hmmm, i suppose you could have both true hw (backlight) brightness & sw (backlight compensation)17:03
kgunnmpt: i'll capture both17:03
racarralan_g: Thanks :) fixing conflict now17:04
=== alan_g is now known as alan_g|life
kdubracarr, fix-input-build-clang reminded me that if we need to disable input, we could do that via a server config17:04
kdubstill trying to get rid of compile options :)17:05
racarrkdub: That's the goal for fix-input-build-clang!17:05
racarrwill propose a branch to disable MIR_DISABLE_INPUT later today17:05
kdubracarr, great :)17:06
tvosskgunn, hmmm, I was more or less thinking about color inversion17:08
racarralan_g|life: Have a good evening :)17:08
kgunntvoss: just to make sure we're talking about the right things...mpt had 2 distinct questions...17:09
kgunn1 about color saturation (like an effect)17:09
kgunn1 about brightness17:09
racarrI think, from the perspective of what we can do, we can say that we can apply any sort of shader effect to any subset of the scene graph (including the final image)17:10
racarrbut it doesn't necesssarily mean postprocessing17:10
racarrfor example, color inversion, should likely be done in the first rendering pass, rather than say rendering to an FBO and postprocessing17:10
racarroh just saw the original question now17:11
kgunnracarr: well....maybe, it might actually be cheaper to post process (depending on # of layers etc)17:11
racarris it feasible for mir on the phone17:11
racarrkgunn: No. You always have to render each visible thing once17:11
racarrso the question is, do I render it once directly onscreen with a shader to invert the colors17:12
kgunnracarr: dirty region tracking?17:12
kgunnracarr: i was thinking setting changed...you got lots of surfaces17:12
racarror render it offscreen, then take the final composited image and render it with a shader to invert the colors17:12
kgunnracarr: but those surfaces might be visually static17:12
racarroh maybe, that's true when the setting17:13
racarrwe don't want to be rendering offscreen for postprocessing in anticipation of settings changing though17:13
kgunnracarr: no not at all17:14
racarrif we already are rendering offscreen though! the effect probably should be postprocessing17:14
kgunnracarr: keep it all dynamic....but build it in such a way you could "postproc" conceptually17:14
kgunnracarr: and...i consider semico hw goodies as postproc conceptually17:15
kgunne.g. they might give you a slick way to do this to the fb17:15
kgunnfor cheao17:15
racarrsome are.17:15
racarrI think of the line where postprocessing begins as when the fragment shader emits a fragment17:16
racarrbut who knows why :) thats just something I made up17:16
kdubkgunn, i think there are, but they'd have to move to support it in hwc if they want it17:16
kgunnkdub: yep17:16
kgunnkdub: racarr ....for sure, either gles or hwc would be the postproc houses....and no we shouldn't build ineffeciency in just in case of a potential savings, but we shouldn't prevent using something cool either, e.g. keep it dynamic (not just flexible)17:17
racarrI understand :)17:17
racarrmpt: It's interesting to think about what to support perhaps besides17:18
racarrinversion...I know it's not unheard of for windows/osx users (and some people through a compiz plugin)17:18
racarrto use a few other kind of color filters for various forms of color blindness17:18
racarror i.e. I remember someone in the compiz forums ages ago worked in astronomy of some such and requested a red light only filter (to not affect his night vision as strongly)17:19
racarr...apparently I am in full on attention-deficit-mode this morning. *runs around*17:19
kgunnmpt: racarr this was a good topic....made me think about backlight compensation....a very big deal in mobile17:25
* kdub thinks we could root ID out of mc::BufferSwapper17:27
kdubwith the post processing effects, i think its safer to rely on gles for them primarily, and then build it dynamic enough that we can use either gles or a special route17:28
kdubwith alpha being the quintessential effect with 'special routes'17:28
kgunnkdub...ack...gles is the fundamental functional baseline, makes sense17:29
tvosskgunn, ah, for brightness, it's a system/shell setting17:30
racarrkdub: I feel like I flipped back and forth maybe on whether rooting ID out sounded like a good idea17:31
racarrbut it sounds good today!17:31
kdubracarr, we did, i remember the situation pointedly :) the last thing that I remember was that the interface was something to fix later17:32
kduband my android server window work is making me rethink the interface a bit17:33
kdubi'll mp separately so it can get a thorough review though, once thats done17:33
racarrkdub: Is resizing still in your head?17:33
kdubit is! i was just going to suggest a blueprint related to it to kgunn actually17:34
kgunnkdub: like a new one....or just add to an existing...i was going to put a couple of bullets in mir-converged17:39
kdubkgunn, i prefer new blueprints with 2-4 day long task segments... makes me feel like i'm reporting enough :) resizing will be a multiple-landings-required sort of task17:43
racarrkdub: Oh great :)17:48
kgunnkdub: what a good title? supposing its more than just resizing?....i need to check the other bp's as we might have had this already17:53
racarrearly morning -> early lunch bbs17:54
=== racarr is now known as racarr|lunch
UbuPhillup__thomi: hi19:12
racarr|lunchMorning thomi19:12
thomihey everyone, what's up?19:15
=== racarr|lunch is now known as racarr
racarrMan I love lunch19:26
kgunnkdub: sorry if you answered...my network has been blinking today19:29
kgunnkdub: but what would be a good title for the resize work?19:30
kgunnmeaning, does it cover rescale? surface moves etc ?19:30
kdubkgunn, hmm.. maybe something like19:30
kdub"fixed client buffer resize" where fixed is added to emphasize that we resize buffers to a known size19:33
kduband provide feedback much like we do now with the box outline of the size the client will be resized to19:33
kgunnkdub: so is it more like resize to a phys dev/screen? rather than an app-window resize ?19:35
kdubkgunn, no, we're talking client resize19:35
kgunnkdub: got it, sorry, to keep digging...what about rotate? & moves? or are those seperate topics19:37
kdubkgunn, its something a bit down the road19:38
kdubbut i consider those separate topics19:38
kdubmy fbnativewindow work led me to want to refactor a funky interface we have19:38
kduband i'm refactoring in a way that is friendly to the future of mir resizing client buffers19:39
thomiwoooo! got glmark2 running on mir :)19:39
thomihmmm, either my brain is broken, or some of these tests aren't too happy on mir19:42
kgunnthomi: what are you running them on ? hw wise?19:43
thomiit's the QA testing laptop, which has 4GB ram, and an intel graphics chipset... when glmark2 finishes I can get the exact specs19:44
thomiit's an "Intel Ivybridge mobile" - whatever that means19:45
kdubracarr, quick review when you have a chance? https://code.launchpad.net/~kdub/mir/fix-hwc-test/+merge/15666919:46
* thomi needs more coffee, brb19:47
racarrkdub: Will soon :) Just finishing up some refactoring on inprocess-egl19:54
racarrkdub: +120:05
kdubracarr, thx20:08
kgunnrobert_ancell: morning20:09
robert_ancellkgunn, hello20:10
kgunnrobert_ancell: we had a couple of interesting topics...20:10
kgunnmpt pointed out a feature to have settings (as in system) to put your composed fb in a "color mode"20:11
kgunnthink saturation or sepia or some such20:11
kgunnthen we started talking brightness....which lead to a discussion on hw vs sw, and fb post processing20:11
kgunnat any rate...i added about 4 work items to mir-converged20:11
kgunnaltho conceivably we'll need brightness control on phones20:12
robert_ancellkgunn, ok cool. What's the use case for the "colour mode"?20:12
kgunnrobert_ancell: visually impaired20:13
kgunnso like black / white invert20:13
kgunnor no blue/grey combos20:14
robert_ancellkgunn, ah. Traditionally that's been done via themes - is a global method considered better?20:14
kgunncolor blindness20:14
kgunnglobal - i guess so, that way nothing gets thru20:14
racarrkdub: I can't crosscompile anymore because the chroot creator can't find a package for libhybris20:14
racarrwhere am I supposed to be getting it from?20:14
kgunnyou have a more uniform experience20:14
robert_ancellyeah, sounds like the easiest method.20:15
kdubracarr, the phablet-ppa . i sent out the line in the email about the hybris update20:15
kgunnthen kdub & i have been talking about addressing client resize....20:15
kgunni thot we already had that in a bp (was just looking now)20:16
kgunnif not, he was wanting to tackle...anativewindow stuff allowed him to potentially refactor for resize in mind20:16
kgunn(but i wondered if duflu might have had it on his plate?)20:16
racarrkdub: Got it :)20:16
robert_ancellkgunn, should be in mir-converged I think. I think we decided it wasn't needed on a phone20:16
kdubi guess mir-converged is what i meant by 'down the road' earlier20:18
kgunnkdub: and yes, it is in there20:18
kgunnkdub: robert_ancell ...will we really not need it for phone ?20:19
kgunni suppose any resize due to a ui animation/transition would be hidden from client20:19
robert_ancellkgunn, In San Mateo we couldn't come up with a case where it was required, but we should revisit that if we can think of one20:19
kdubi agree with robert_ancell that its probably not critical for phone for a while20:19
robert_ancellkgunn, kdub, I think it is a good target of opportunity to implement early if there's no higher priority work20:20
kgunnkdub: is there a convenience factor to it for you....e.g. you're mucking around it, may as well address it?20:20
kgunnrobert_ancell: kdub is so awseome he completed the nexus4 bp :)20:20
kdubkgunn, not really, i'll just leave the door open for resize in what i'm doing now20:21
robert_ancellkdub, \o/20:21
kdubyay :) i'll try to make a video for our weekly email20:22
kgunnkdub: cool!20:22
kdubrobert_ancell, kgunn, in mir-converged, can I assign 'window resizing' and 'mir on mir' to myself?20:23
kgunnkdub: if you're feeling froggy :)20:23
robert_ancellkdub, absolutely20:24
kgunnracarr: so i was thinking (danger)...20:24
kgunnif you get qt backend w. input working...could we sloppily put unity next on it?20:25
kgunnmaybe a trimmed version20:25
racarrwell thats the plan eventually but this is out of process Qt20:31
racarrin process Qt is working too but no20:31
racarrin process Qt with input yet (thats kind of nextish after all the existing stuff lands...i.e. thursday?)20:31
racarrThen there is the branch for running the unity stuff out of proces that kevin did20:31
kdubwhich is just client side qt20:31
racarrWell using all the phablet input stuff20:32
racarrnot the mir stuff20:32
racarrkdub: https://code.launchpad.net/~robertcarr/mir/remove-mir-disable-input/+merge/156696 exists :)21:15
racarrkdub: Want to talk about prepare-for-inprocess-egl soon?21:15
racarrhoping for RAOF to show up21:15
racarrRAOF: Ping?21:15
racarrerr by prepare-for-inprocess-egl I mean21:15
racarrkdub: Pushed changes to prepare-for-inprocess-egl to use Platform as you suggest21:20
kdubracarr, cool21:28
racarrkdub: Do you have an idea of how hard it will be to implement for android/a plan? Should I start thinking about it21:31
racarrbranch as it stands returns (EGLNativeDisplayType)0 ;)21:31
racarroh I guess21:31
racarrthe native display is the same on android EGL_DEFAULT_DISPLAY21:32
racarrbut a native window abstraction is needed.21:32
kdubracarr, that's sort of what i'm getting into place now with the framebuffer native type21:43
kgunnrobert_ancell: btw...https://blueprints.launchpad.net/ubuntu/+spec/mir-beyond-converged22:25
kgunnfor stuff that's fringe22:25
robert_ancellkgunn, awesome22:25
robert_ancellkgunn, check out that dependency tree :)22:25
kgunnborg like22:26
RAOFracarr: Pong!22:32
racarrbrb being non violently mugged by the garage door repairmen22:34
racarrRAOF: Two things I was pinging you abobut actually! need another round of review on receive-input-in-client22:43
racarrand enable-inprocess-egl should be almost ready to land so I wanted some feedback on the mesa changes22:44
racarrand perhaps to land them in sync22:44
RAOFracarr: What are the mesa changes needed to land enable-inprocess-egl?22:45
RAOFI thought we'd already landed them?22:45
racarrRAOF: https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888/comments/34248822:46
racarrerr that patch is slightly backwards due to git failure the - if (mir_connection_is_valid22:46
racarris against the wrong branch22:46
racarrwe had landed that as the client library function, mir_egl_native_display_is_valid but then22:47
racarrthat needs an inserver implementation too and I wasn't sure about22:47
racarrimplementing client library symbols in the server22:47
racarrso there is that22:47
racarrthen the second two bits are about letting mesa load multiple instances of the dri2 driver22:47
racarrfor multiple platforms22:47
racarrshockingly it seems to work22:47
RAOFWe've already landed that change, haven't we?22:49
racarrI don't think so22:49
racarrnope doesn't look like it22:49
RAOFAh, right. We've got *some* of that landed.22:51
racarrI blogged a blog about what I have been doing lately in mir: http://racarr.me/wordpress/?p=1722:59
racarrprobably uninteresting to mir team members :p22:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!