| === thomi|lunch is now known as thomi | ||
| thomi | RAOF: 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 |
|---|---|---|
| RAOF | thomi: 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 |
| RAOF | thomi: (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 |
| thomi | RAOF: that's what it's installing... | 01:34 |
| thomi | RAOF: I wonder if you could scan over this? http://pastebin.ubuntu.com/5669187/ | 01:35 |
| thomi | I'll try and get that waf log | 01:37 |
| RAOF | You might need the newer mesa - I take it the PPA hasn't yet managed to build the mesa branch? | 01:37 |
| thomi | no, I think Martin sent you an email about that? | 01:38 |
| thomi | RAOF: I tell a lie - I built and pushed it manually last week | 01:40 |
| thomi | so there's a a mesa package in the PPA from 28/03 | 01:40 |
| RAOF | thomi: Oh, right. It just doesn't have the version I expected | 01:52 |
| RAOF | Hm | 01:52 |
| thomi | RAOF: it's using the version I built last Friday | 01:52 |
| RAOF | Yeah. I just expected that to be called +mir3 | 01:53 |
| thomi | RAOF: so it turns out that gl.pc exists in the chroot | 02:01 |
| RAOF | thomi: Are you able to get /tmp/buildd/glmark2-2012.08+266+13/build/config.log ? | 02:02 |
| thomi | RAOF: yeah, just figured out what the issues is: | 02:02 |
| thomi | it needs the xcb-dri2 package | 02:02 |
| thomi | which isn't a build-dep | 02:02 |
| thomi | :-/ | 02:02 |
| RAOF | Hm. That would be a bug in libgl1-mesa-dev, then. | 02:02 |
| RAOF | A development package should always depend on all the other development packages required to use it. | 02:03 |
| thomi | want me to file a bug? | 02:04 |
| RAOF | thomi: Yeah, thanks. It's probably only a problem in the Mir mesa package so far, though. | 02:26 |
| RAOF | Bah! GCC's libstdc++ doesn't implement list.erase(const_iterator it) as specified by C++11. | 02:29 |
| duflu | RAOF: It does implement that erase. I have used it for years. You mean the version that returns an iterator? That one is uncommon | 02:49 |
| RAOF | duflu: 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 |
| RAOF | duflu: Perhaps you're thinking of list.erase(iterator it)? | 02:50 |
| duflu | RAOF: Maybe | 02:53 |
| duflu | Though it would make sense to use a non-const iterator, kinda | 02:54 |
| RAOF | Yeah, kinda. C++11 standard says it takes a const_iterator, though. | 02:54 |
| RAOF | (As does list.insert(const_iterator it)) | 02:55 |
| RAOF | Which also makes sense, as they don't modify any list elements. | 02:55 |
| * RAOF wonders whether the valgrind tests _really_ need to take 7 minutes | 02:56 | |
| robert_ancell | racarr, hey, got an input question. How do I intercept alt+ctrl+Fn in the current server? Is that possible? | 03:02 |
| RAOF | I'm unsure... | 03:05 |
| RAOF | duflu: When you throw() in the edge-types merge proposal, is that caught somewhere sane? | 03:06 |
| duflu | RAOF: Yeah it's caught well below that. In an existing location at above the frontend. I forget where. The tests cover it | 03:07 |
| RAOF | Cool. That merge looks reasonable to me, then. | 03:08 |
| duflu | RAOF: 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 much | 03:09 |
| duflu | Valgrind, particularly, shows you where your code is CPU-bound. | 03:11 |
| smspillaz | RAOF: 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 time | 03:12 |
| smspillaz | code under valgrind is supposed to run about 5x slower in the best case | 03:13 |
| RAOF | Doesn't valgrind interact poorly with highly threaded code, too? | 03:14 |
| smspillaz | *shrug* maybe | 03:18 |
| smspillaz | but I know that tests taking forever under valgrind is likely to be a direct product of the valgrind startup cost | 03:18 |
| smspillaz | considering the fact that your unit tests probably run in half a second and your integration tests maybe run in 20 seconds tops | 03:18 |
| smspillaz | add n * valgrind startup and it gets expensive fast | 03:19 |
| duflu | 5x slower would be fine. But the several orders of magnitude we see, not so fine | 03:20 |
| smspillaz | I'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 |
| smspillaz | if 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 test | 03:21 |
| * smspillaz has been working on a little thing that would effectively do just that | 03:22 | |
| duflu | Ooh, sorry. Yes. Valgrind startup is an artificially slow bottleneck. We should ideally not be starting new processes all the time | 03:23 |
| smspillaz | yeah | 03:23 |
| smspillaz | its my one gripe with ctest's ExperimentalMemCheck target | 03:24 |
| robert_ancell | RAOF, you should probably approve your use-dma-buf MP - it's marked as needs fixing by you | 03:24 |
| RAOF | robert_ancell: No-one else has reviewed it. | 03:24 |
| RAOF | Oh, ahem. | 03:24 |
| duflu | smspillaz: I still intend on resolving that Compiz branch madness when didrocks says I can | 03:26 |
| duflu | Last I checked, the diff was small | 03:26 |
| smspillaz | duflu: didn't didrocks say you could ? | 03:26 |
| duflu | smspillaz: He said wait a little | 03:26 |
| smspillaz | I'm pretty sure you got the "go for it" like a month ago now :p | 03:26 |
| duflu | He was "busy" | 03:26 |
| RAOF | robert_ancell: And to answer your question, no, I don't think you can get alt+ctrl+Fn in the X server. | 03:27 |
| duflu | It's ridiculous because the diff was only 160 lines when I last checked | 03:27 |
| smspillaz | duflu: why would there be a diff for changing a branch name ? | 03:27 |
| RAOF | robert_ancell: Except it just occurs to me that this is not what you were actually asking :) | 03:27 |
| robert_ancell | RAOF, in X? I mean intercept it inside /usr/bin/mir | 03:27 |
| duflu | smspillaz: You need to merge the "raring" and "0.9.9" branches first. They differ | 03:28 |
| smspillaz | oh right. I believe that was intentional | 03:28 |
| robert_ancell | RAOF, 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 combination | 03:28 |
| smspillaz | the diff is much larger now | 03:28 |
| duflu | Awesome-bloody-tastic | 03:28 |
| * duflu -> coffee | 03:28 | |
| smspillaz | duflu: the "raring" branch was basically the great-distro-strategy to cut off myself and mc-return so they could cherry pick everything | 03:28 |
| smspillaz | because you know | 03:29 |
| smspillaz | cherry picking always results in more stable code | 03:29 |
| robert_ancell | duflu, can you see if https://code.launchpad.net/~robert-ancell/mir/frontend-class-renaming/+merge/156430 seems like an improvement to you? | 03:29 |
| smspillaz | I don't understand it when people think they know better than the maintainers ... | 03:29 |
| RAOF | Because the common case is that we _do_ know better than the maintainers :) | 03:30 |
| bschaefer | smspillaz, 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 |
| smspillaz | RAOF: sure, you have different goals | 03:30 |
| smspillaz | my 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 |
| smspillaz | unless you have a very detailed knowledge of that codebase to understand why that might be a good idea | 03:31 |
| duflu | bschaefer, smspillaz: Yeah no need for anyone to get angry or worry about it. We have consensus that it should and will be resolved | 03:32 |
| smspillaz | I'm not angry at all :) | 03:32 |
| bschaefer | duflu, 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 |
| duflu | bschaefer: 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 soon | 03:33 |
| bschaefer | duflu, well its always nice to learn :), I just got caught up with that 100 scopes thing last week and didn't get around to it | 03:34 |
| * bschaefer thinks its green lighted atm | 03:34 | |
| duflu | smspillaz: 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 distro | 03:35 |
| duflu | bschaefer: It was agreed by everyone but didrocks explicitly asked me to wait | 03:35 |
| smspillaz | duflu: I wasn't interested in landing anything new that wasn't going to affect distro | 03:35 |
| smspillaz | why would I work on a dead end? | 03:36 |
| bschaefer | duflu, oo, didn't know that, I can poke him tomorrow morning as well about it :) | 03:36 |
| bschaefer | smspillaz, to learn! | 03:36 |
| smspillaz | I have other projects where I can do that | 03:36 |
| duflu | smspillaz: That dead end is the only complete and functional desktop we have for now. It's no dead end (yet) | 03:36 |
| bschaefer | smspillaz, very much so :) | 03:36 |
| smspillaz | *shrug* if distro wanted to branch early ... they really could have just asked | 03:37 |
| smspillaz | that being said, they've already done it | 03:37 |
| duflu | Yeah, just /wrong/ | 03:37 |
| duflu | Never mind. I'll fix it | 03:37 |
| smspillaz | and needless to say, upstreams should be following the freeze process anyways | 03:38 |
| smspillaz | so there shouldn't even be a need for a branch | 03:38 |
| duflu | robert_ancell: Looks like some things I was thinking about. Will get to it | 03:39 |
| robert_ancell | duflu, ta | 03:39 |
| === jono is now known as Guest90083 | ||
| RAOF | Urgh. Git's UI is a fractal of horibleness. | 04:24 |
| === tvoss|easter is now known as tvoss | ||
| RAOF | When can I stop caring about Quantal? | 06:37 |
| duflu | RAOF: When you absolutely have to... | 06:40 |
| duflu | RAOF: Or after I upgrade my desktop ;) | 06:40 |
| tvoss | alf_, ping | 07:29 |
| alf_ | tvoss: pong | 07:39 |
| tvoss | alf_, 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 |
| tvoss | alf_, ack | 07:42 |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| alan_g | tvoss: ping | 08:15 |
| tvoss | alan_g, pong | 08:32 |
| tvoss | alan_g, no invite arriving in my inbox | 09:54 |
| alan_g | tvoss: looking... | 09:56 |
| alan_g | tvoss: ... - it says you've been invited. Hang on. | 09:56 |
| tvoss | alan_g, thx | 09:57 |
| alan_g | tvoss: just removed and re-added you | 09:57 |
| tvoss | alan_g, thx | 09:57 |
| arsson | is there any other packages that needs to install manually that mir require? | 11:13 |
| alan_g | arsson: is your context not covered by http://unity.ubuntu.com/mir/? | 11:16 |
| arsson | i have done everything what told there but i only get black screen when running mir | 11:21 |
| alan_g | arsson: That's what I'd expect - unless you also start a client application that puts something on the screen | 11:22 |
| arsson | ok... i'm stupid so how do i do that? | 11:24 |
| arsson | example? | 11:24 |
| alan_g | arsson: something like: ./mir & sleep 1 && ./mir_egltriangle & sleep 8 && kill $(pidof ./mir_egltriangle) & sleep 1 && kill $(pidof ./mir) | 11:39 |
| arsson | i have only run command ($~ mir) do i need to type something else that start unity desktop with mir? | 11:56 |
| alan_g | arsson: 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 |
| arsson | no but i'm exited and anxious | 12: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 | ||
| racarr | Morning | 14:19 |
| alan_g | racarr: afternoon | 14:20 |
| racarr | alf_: Re: enable-inprocess-egl | 14:21 |
| racarr | did you apply the mesa patch mentioned in the comments for the branch | 14:22 |
| racarr | err | 14:22 |
| racarr | this patch is incorrect | 14:22 |
| alf_ | racarr: I didn't apply it | 14:23 |
| racarr | alf_: Posted a new one | 14:25 |
| racarr | it's necessary otherwise the | 14:25 |
| racarr | DRM EGL backend conflicts with the mir one | 14:25 |
| alf_ | racarr: thanks, I will try it out | 14:27 |
| racarr | alan_g: Left some comments on receive-input-in-client (+ updates) | 14:36 |
| alan_g | racarr: 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 install | 14:56 |
| dharmaone | missed 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 |
| tvoss | dharmaone, depends on the toolkit support for Mir, but in general: you don't need to rewrite your app to run against Mir | 15:02 |
| tvoss | dharmaone, I think the session was recorded and you can watch it on youtube | 15:02 |
| kdub | morning folks, status, began working on our own framebuffer native window for android | 15:03 |
| dharmaone | ok :) what about current apps that are not written with QT - will they have to be rewritten? (not really mir related) | 15:03 |
| tvoss | dharmaone, again, toolkit dependent, but in general no :) the point is that an app hardly ever should know about the underlying display server | 15:04 |
| alf_ | status: reviewing, bug fixing, thinking about main loop | 15:05 |
| tvoss | dharmaone, 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 |
| tvoss | dharmaone, http://youtube.com/ubuntuonair | 15:06 |
| === alan_g|tea is now known as alan_g | ||
| racarr | status: Made some updates to branches. Did some review | 15:07 |
| racarr | worked on new version of qtubuntu and ubuntu-platform-api-mirclient yesterday and produced some working code | 15:07 |
| racarr | going to go through and see if there is anything else I need to do right now and if not work on those some more | 15:08 |
| racarr | (goal: Qt backend against Mir with input:)) | 15:08 |
| racarr | Anybody need some help or review or anything? | 15:12 |
| alan_g | racarr: quick hangout? | 15:19 |
| racarr | alan_g: Sure | 15:21 |
| racarr | gcalling you | 15:21 |
| racarr | alan_g: I can hear you just a sec | 15:22 |
| racarr | tvoss: Made some comments on QtUbuntu stuff and input/platform-api, etc here https://bugs.launchpad.net/mir/+bug/1163393 | 15:45 |
| ubot5 | Launchpad 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 |
| racarr | talked about using this approach of abstraction through the platform api | 15:46 |
| tvoss | racarr, will look into it, thanks for the pointer | 15:46 |
| kdub | alf_, updated hwc-integration :) | 15:52 |
| kdub | sorry to be a bother about it :P | 15: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 else | 15:57 |
| kdub | alf_, thanks, will take care of those | 15:58 |
| racarr | going to make android input stack compile in clang | 16:25 |
| racarr | many 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 |
| racarr | infinite erros around this line now... | 16:27 |
| racarr | libandroidinput.so actually links :) | 16:27 |
| racarr | ok er building clang from trunk doesn't work either for me | 16:29 |
| racarr | -DCMAKE_CXX_COMPILER=/usr/bin/clang -DCMAKE_C_COMPILER=/usr/bin/clang -DMIR_DISABLE_INPUT=true | 16:29 |
| racarr | how should it work? | 16:29 |
| racarr | How can I see the options that the jenkins clang build uses? | 16:29 |
| racarr | MIR_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 |
| racarr | oh maybe that wasn't it. Looks like clang behaves differently invoked as clang++ | 16:35 |
| mpt | tvoss, 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 |
| racarr | alan_g: https://code.launchpad.net/~robertcarr/mir/fix-input-build-clang/+merge/156634 | 16:41 |
| racarr | It turns out it was trivial :) | 16:41 |
| racarr | I mean unit-tests fails but it builds! | 16:41 |
| racarr | and I think unit-tests failed anyway | 16:41 |
| mpt | tvoss, i.e. composit (composite?) such that for every pixel, the value is reversed, while the hue and shade stay the same. | 16:42 |
| mpt | (Compose!) | 16:42 |
| tvoss | mpt, 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 colors | 16:43 |
| mpt | ok | 16:43 |
| kdub | mpt, right. mir can do it, its more a matter of feature scheduling as to when | 16:43 |
| mpt | kgunn, what do you think? ^^^^ | 16:43 |
| kdub | although mpt, contributions are welcome :) | 16:44 |
| mpt | kdub, the contribution I am instructed to make is to design the settings :-P | 16:44 |
| alan_g | racarr: do you understand the need for "mt::" in tests/integration-tests/input/android/test_android_input_manager.cpp? The rest looks obvious | 16:45 |
| kdub | mpt haha, just trying to remind the rest of the channel that we are open :) | 16:45 |
| mpt | kdub, 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 | ||
| kgunn | mpt: i'd say let's capture it in a bp... | 16:47 |
| kdub | mpt, yeah... i can see that they would be tricky to convey widely | 16:47 |
| mpt | hmm | 16:47 |
| kgunn | mpt: is this a "just capture it" query....or is there a pressing thought behind it | 16:48 |
| mpt | kgunn, 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 |
| kgunn | mpt: :) sure | 16:49 |
| racarr | alan_g: Yes the namespace {} | 16:51 |
| mpt | kgunn, excuse the ignorant question, but is display brightness handled by the display server, or is that at a lower level? | 16:51 |
| racarr | makes it a seperate instantiation of the function for each | 16:51 |
| racarr | include | 16:51 |
| racarr | so the functions become "unused" | 16:51 |
| racarr | which is an error with our clang settings | 16:51 |
| racarr | well they become unused by people who include mock_event_filter but don't use the matcher | 16:52 |
| racarr | translation units blablablabla | 16:52 |
| racarr | :p | 16:52 |
| alan_g | racarr: Great | 16:52 |
| kgunn | mpt: 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 away | 16:52 |
| kgunn | tvoss: ^ my gut says...probably a server side shell interaction w mir? | 16:53 |
| tvoss | kgunn, 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 feeling | 16:54 |
| mpt | The only reason I ask is to know whether it should be in the same blueprint | 16:55 |
| racarr | alan_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_g | racarr: seems like a conflict now. But I'll change my vote anyway | 17:03 |
| kgunn | tvoss: post process for brightness?...hmmm, i suppose you could have both true hw (backlight) brightness & sw (backlight compensation) | 17:03 |
| kgunn | mpt: i'll capture both | 17:03 |
| racarr | alan_g: Thanks :) fixing conflict now | 17:04 |
| === alan_g is now known as alan_g|life | ||
| kdub | racarr, fix-input-build-clang reminded me that if we need to disable input, we could do that via a server config | 17:04 |
| kdub | still trying to get rid of compile options :) | 17:05 |
| racarr | kdub: That's the goal for fix-input-build-clang! | 17:05 |
| racarr | will propose a branch to disable MIR_DISABLE_INPUT later today | 17:05 |
| kdub | racarr, great :) | 17:06 |
| tvoss | kgunn, hmmm, I was more or less thinking about color inversion | 17:08 |
| racarr | alan_g|life: Have a good evening :) | 17:08 |
| kgunn | tvoss: just to make sure we're talking about the right things...mpt had 2 distinct questions... | 17:09 |
| kgunn | 1 about color saturation (like an effect) | 17:09 |
| kgunn | 1 about brightness | 17:09 |
| racarr | I 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 |
| racarr | but it doesn't necesssarily mean postprocessing | 17:10 |
| racarr | for example, color inversion, should likely be done in the first rendering pass, rather than say rendering to an FBO and postprocessing | 17:10 |
| racarr | oh just saw the original question now | 17:11 |
| kgunn | racarr: well....maybe, it might actually be cheaper to post process (depending on # of layers etc) | 17:11 |
| racarr | is it feasible for mir on the phone | 17:11 |
| racarr | Sure! | 17:11 |
| racarr | kgunn: No. You always have to render each visible thing once | 17:11 |
| racarr | so the question is, do I render it once directly onscreen with a shader to invert the colors | 17:12 |
| kgunn | racarr: dirty region tracking? | 17:12 |
| kgunn | racarr: i was thinking setting changed...you got lots of surfaces | 17:12 |
| racarr | or render it offscreen, then take the final composited image and render it with a shader to invert the colors | 17:12 |
| kgunn | racarr: but those surfaces might be visually static | 17:12 |
| racarr | oh maybe, that's true when the setting | 17:13 |
| racarr | changes | 17:13 |
| racarr | we don't want to be rendering offscreen for postprocessing in anticipation of settings changing though | 17:13 |
| kgunn | racarr: no not at all | 17:14 |
| racarr | if we already are rendering offscreen though! the effect probably should be postprocessing | 17:14 |
| kgunn | racarr: keep it all dynamic....but build it in such a way you could "postproc" conceptually | 17:14 |
| racarr | Mm | 17:14 |
| kgunn | racarr: and...i consider semico hw goodies as postproc conceptually | 17:15 |
| kgunn | e.g. they might give you a slick way to do this to the fb | 17:15 |
| kgunn | for cheao | 17:15 |
| kgunn | oops/cheao/cheap | 17:15 |
| racarr | mm | 17:15 |
| racarr | some are. | 17:15 |
| racarr | I think of the line where postprocessing begins as when the fragment shader emits a fragment | 17:16 |
| racarr | but who knows why :) thats just something I made up | 17:16 |
| racarr | XD | 17:16 |
| kdub | kgunn, i think there are, but they'd have to move to support it in hwc if they want it | 17:16 |
| kgunn | kdub: yep | 17:16 |
| kgunn | kdub: 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 |
| racarr | I understand :) | 17:17 |
| racarr | mpt: It's interesting to think about what to support perhaps besides | 17:18 |
| racarr | inversion...I know it's not unheard of for windows/osx users (and some people through a compiz plugin) | 17:18 |
| racarr | to use a few other kind of color filters for various forms of color blindness | 17:18 |
| racarr | or 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 |
| kgunn | mpt: racarr this was a good topic....made me think about backlight compensation....a very big deal in mobile | 17:25 |
| * kdub thinks we could root ID out of mc::BufferSwapper | 17:27 | |
| kdub | with 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 route | 17:28 |
| kdub | with alpha being the quintessential effect with 'special routes' | 17:28 |
| kgunn | kdub...ack...gles is the fundamental functional baseline, makes sense | 17:29 |
| tvoss | kgunn, ah, for brightness, it's a system/shell setting | 17:30 |
| racarr | kdub: I feel like I flipped back and forth maybe on whether rooting ID out sounded like a good idea | 17:31 |
| racarr | but it sounds good today! | 17:31 |
| kdub | racarr, we did, i remember the situation pointedly :) the last thing that I remember was that the interface was something to fix later | 17:32 |
| kdub | and my android server window work is making me rethink the interface a bit | 17:33 |
| kdub | i'll mp separately so it can get a thorough review though, once thats done | 17:33 |
| racarr | ok | 17:33 |
| racarr | kdub: Is resizing still in your head? | 17:33 |
| kdub | it is! i was just going to suggest a blueprint related to it to kgunn actually | 17:34 |
| kgunn | kdub: like a new one....or just add to an existing...i was going to put a couple of bullets in mir-converged | 17:39 |
| kdub | kgunn, 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 task | 17:43 |
| racarr | kdub: Oh great :) | 17:48 |
| kgunn | kdub: what a good title? supposing its more than just resizing?....i need to check the other bp's as we might have had this already | 17:53 |
| racarr | early morning -> early lunch bbs | 17:54 |
| === racarr is now known as racarr|lunch | ||
| thomi | morning | 19:08 |
| UbuPhillup__ | thomi: hi | 19:12 |
| racarr|lunch | Morning thomi | 19:12 |
| thomi | hey everyone, what's up? | 19:15 |
| === racarr|lunch is now known as racarr | ||
| racarr | Man I love lunch | 19:26 |
| kgunn | kdub: sorry if you answered...my network has been blinking today | 19:29 |
| kgunn | kdub: but what would be a good title for the resize work? | 19:30 |
| kgunn | meaning, does it cover rescale? surface moves etc ? | 19:30 |
| kdub | kgunn, hmm.. maybe something like | 19:30 |
| kdub | "fixed client buffer resize" where fixed is added to emphasize that we resize buffers to a known size | 19:33 |
| kdub | and provide feedback much like we do now with the box outline of the size the client will be resized to | 19:33 |
| kgunn | kdub: so is it more like resize to a phys dev/screen? rather than an app-window resize ? | 19:35 |
| kdub | kgunn, no, we're talking client resize | 19:35 |
| kgunn | kdub: got it, sorry, to keep digging...what about rotate? & moves? or are those seperate topics | 19:37 |
| kdub | kgunn, its something a bit down the road | 19:38 |
| kdub | but i consider those separate topics | 19:38 |
| kdub | my fbnativewindow work led me to want to refactor a funky interface we have | 19:38 |
| kdub | and i'm refactoring in a way that is friendly to the future of mir resizing client buffers | 19:39 |
| thomi | woooo! got glmark2 running on mir :) | 19:39 |
| thomi | hmmm, either my brain is broken, or some of these tests aren't too happy on mir | 19:42 |
| kgunn | thomi: what are you running them on ? hw wise? | 19:43 |
| thomi | it's the QA testing laptop, which has 4GB ram, and an intel graphics chipset... when glmark2 finishes I can get the exact specs | 19:44 |
| thomi | it's an "Intel Ivybridge mobile" - whatever that means | 19:45 |
| kdub | racarr, quick review when you have a chance? https://code.launchpad.net/~kdub/mir/fix-hwc-test/+merge/156669 | 19:46 |
| * thomi needs more coffee, brb | 19:47 | |
| racarr | kdub: Will soon :) Just finishing up some refactoring on inprocess-egl | 19:54 |
| racarr | kdub: +1 | 20:05 |
| kdub | racarr, thx | 20:08 |
| kgunn | robert_ancell: morning | 20:09 |
| robert_ancell | kgunn, hello | 20:10 |
| kgunn | robert_ancell: we had a couple of interesting topics... | 20:10 |
| kgunn | mpt pointed out a feature to have settings (as in system) to put your composed fb in a "color mode" | 20:11 |
| kgunn | think saturation or sepia or some such | 20:11 |
| kgunn | then we started talking brightness....which lead to a discussion on hw vs sw, and fb post processing | 20:11 |
| kgunn | at any rate...i added about 4 work items to mir-converged | 20:11 |
| kgunn | altho conceivably we'll need brightness control on phones | 20:12 |
| robert_ancell | kgunn, ok cool. What's the use case for the "colour mode"? | 20:12 |
| kgunn | robert_ancell: visually impaired | 20:13 |
| kgunn | so like black / white invert | 20:13 |
| kgunn | or no blue/grey combos | 20:14 |
| kgunn | red/green | 20:14 |
| robert_ancell | kgunn, ah. Traditionally that's been done via themes - is a global method considered better? | 20:14 |
| kgunn | color blindness | 20:14 |
| kgunn | global - i guess so, that way nothing gets thru | 20:14 |
| racarr | kdub: I can't crosscompile anymore because the chroot creator can't find a package for libhybris | 20:14 |
| racarr | where am I supposed to be getting it from? | 20:14 |
| kgunn | you have a more uniform experience | 20:14 |
| robert_ancell | yeah, sounds like the easiest method. | 20:15 |
| kdub | racarr, the phablet-ppa . i sent out the line in the email about the hybris update | 20:15 |
| kgunn | then kdub & i have been talking about addressing client resize.... | 20:15 |
| kgunn | i thot we already had that in a bp (was just looking now) | 20:16 |
| kgunn | if not, he was wanting to tackle...anativewindow stuff allowed him to potentially refactor for resize in mind | 20:16 |
| kgunn | (but i wondered if duflu might have had it on his plate?) | 20:16 |
| racarr | kdub: Got it :) | 20:16 |
| robert_ancell | kgunn, should be in mir-converged I think. I think we decided it wasn't needed on a phone | 20:16 |
| kdub | i guess mir-converged is what i meant by 'down the road' earlier | 20:18 |
| kgunn | kdub: and yes, it is in there | 20:18 |
| kgunn | kdub: robert_ancell ...will we really not need it for phone ? | 20:19 |
| kgunn | i suppose any resize due to a ui animation/transition would be hidden from client | 20:19 |
| robert_ancell | kgunn, 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 one | 20:19 |
| kdub | i agree with robert_ancell that its probably not critical for phone for a while | 20:19 |
| robert_ancell | kgunn, kdub, I think it is a good target of opportunity to implement early if there's no higher priority work | 20:20 |
| kgunn | kdub: is there a convenience factor to it for you....e.g. you're mucking around it, may as well address it? | 20:20 |
| kgunn | robert_ancell: kdub is so awseome he completed the nexus4 bp :) | 20:20 |
| kdub | kgunn, not really, i'll just leave the door open for resize in what i'm doing now | 20:21 |
| robert_ancell | kdub, \o/ | 20:21 |
| kdub | yay :) i'll try to make a video for our weekly email | 20:22 |
| kgunn | kdub: cool! | 20:22 |
| kdub | robert_ancell, kgunn, in mir-converged, can I assign 'window resizing' and 'mir on mir' to myself? | 20:23 |
| kgunn | kdub: if you're feeling froggy :) | 20:23 |
| robert_ancell | kdub, absolutely | 20:24 |
| kgunn | racarr: so i was thinking (danger)... | 20:24 |
| kgunn | if you get qt backend w. input working...could we sloppily put unity next on it? | 20:25 |
| kgunn | maybe a trimmed version | 20:25 |
| racarr | well thats the plan eventually but this is out of process Qt | 20:31 |
| racarr | in process Qt is working too but no | 20:31 |
| racarr | in process Qt with input yet (thats kind of nextish after all the existing stuff lands...i.e. thursday?) | 20:31 |
| racarr | Then there is the branch for running the unity stuff out of proces that kevin did | 20:31 |
| kdub | which is just client side qt | 20:31 |
| racarr | mm | 20:31 |
| racarr | using | 20:32 |
| racarr | Well using all the phablet input stuff | 20:32 |
| racarr | not the mir stuff | 20:32 |
| racarr | kdub: https://code.launchpad.net/~robertcarr/mir/remove-mir-disable-input/+merge/156696 exists :) | 21:15 |
| racarr | kdub: Want to talk about prepare-for-inprocess-egl soon? | 21:15 |
| racarr | hoping for RAOF to show up | 21:15 |
| racarr | RAOF: Ping? | 21:15 |
| racarr | err by prepare-for-inprocess-egl I mean | 21:15 |
| racarr | enable-inprocess-egl | 21:16 |
| racarr | flashbacks | 21:16 |
| racarr | kdub: Pushed changes to prepare-for-inprocess-egl to use Platform as you suggest | 21:20 |
| kdub | racarr, cool | 21:28 |
| racarr | kdub: Do you have an idea of how hard it will be to implement for android/a plan? Should I start thinking about it | 21:31 |
| racarr | branch as it stands returns (EGLNativeDisplayType)0 ;) | 21:31 |
| racarr | oh I guess | 21:31 |
| racarr | the native display is the same on android EGL_DEFAULT_DISPLAY | 21:32 |
| racarr | but a native window abstraction is needed. | 21:32 |
| kdub | racarr, that's sort of what i'm getting into place now with the framebuffer native type | 21:43 |
| racarr | ohhhh | 21:53 |
| kgunn | robert_ancell: btw...https://blueprints.launchpad.net/ubuntu/+spec/mir-beyond-converged | 22:25 |
| kgunn | for stuff that's fringe | 22:25 |
| robert_ancell | kgunn, awesome | 22:25 |
| robert_ancell | kgunn, check out that dependency tree :) | 22:25 |
| kgunn | borg like | 22:26 |
| RAOF | racarr: Pong! | 22:32 |
| racarr | brb being non violently mugged by the garage door repairmen | 22:34 |
| racarr | ok | 22:41 |
| racarr | RAOF: Two things I was pinging you abobut actually! need another round of review on receive-input-in-client | 22:43 |
| racarr | and enable-inprocess-egl should be almost ready to land so I wanted some feedback on the mesa changes | 22:44 |
| racarr | and perhaps to land them in sync | 22:44 |
| RAOF | racarr: What are the mesa changes needed to land enable-inprocess-egl? | 22:45 |
| RAOF | I thought we'd already landed them? | 22:45 |
| racarr | RAOF: https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888/comments/342488 | 22:46 |
| racarr | err that patch is slightly backwards due to git failure the - if (mir_connection_is_valid | 22:46 |
| racarr | is against the wrong branch | 22:46 |
| racarr | we had landed that as the client library function, mir_egl_native_display_is_valid but then | 22:47 |
| racarr | that needs an inserver implementation too and I wasn't sure about | 22:47 |
| racarr | implementing client library symbols in the server | 22:47 |
| racarr | so there is that | 22:47 |
| racarr | then the second two bits are about letting mesa load multiple instances of the dri2 driver | 22:47 |
| racarr | for multiple platforms | 22:47 |
| racarr | shockingly it seems to work | 22:47 |
| RAOF | We've already landed that change, haven't we? | 22:49 |
| racarr | I don't think so | 22:49 |
| racarr | unless | 22:49 |
| racarr | nope doesn't look like it | 22:49 |
| RAOF | Ah, right. We've got *some* of that landed. | 22:51 |
| racarr | I blogged a blog about what I have been doing lately in mir: http://racarr.me/wordpress/?p=17 | 22:59 |
| racarr | probably uninteresting to mir team members :p | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!