| duflu_ | Oh, I just noticed the new trusty decorations. Very nice. | 01:44 |
|---|---|---|
| === duflu_ is now known as duflu | ||
| RAOF | Hey, is there any particular reason we don't run the valgrind tests on package build? | 01:45 |
| mlankhorst | probably because nobody added it? :p | 06:49 |
| === yofel_ is now known as yofel | ||
| === Wellark_ is now known as Wellark | ||
| anpok_ | good morning mir | 09:01 |
| alan_g | good morning anpok_ | 09:06 |
| anpok_ | I would like to extend the way we store and change transformations of surfaces. | 09:08 |
| anpok_ | In the example I wanted to implement in demo shell I want to make incremental increases of rotation angles around the z axis. | 09:08 |
| alan_g | anpok_: I think duflu has also been thinking along those lines | 09:10 |
| anpok_ | since I also need the inverse of the whole transformation, I would refrain from exposing a transformation matrix.. | 09:10 |
| duflu | Wha? All I'm thinking is doc review right now :) | 09:10 |
| anpok_ | so there are so many ways of storing transformations.. | 09:10 |
| duflu | anpok_: I have a plan, and it looks nothing like the existing classes. Can you wait for me to propose an approach? | 09:11 |
| anpok_ | and storage does not necessarily affect interface, but it does make certain interfaces simpler or harder to support.. | 09:11 |
| anpok_ | duflu: can I help some way? | 09:12 |
| duflu | anpok_: I'm in a mad rush to finish my work today, but I'm happy to talk about it another day...? | 09:12 |
| duflu | Do you need something that works soon? | 09:13 |
| anpok_ | my relative coordinates and input events not being sent to the surface bug is right now in conflict with you recent changes.. | 09:13 |
| duflu | anpok_: Oh. OK, which branch? | 09:14 |
| anpok_ | https://code.launchpad.net/~andreas-pokorny/mir/fix-1261647/+merge/210246 | 09:14 |
| anpok_ | I basically now require the input::surface to provide a transformation matrix to get from screen frame to local frame | 09:15 |
| anpok_ | I was curious about your branch.. curious in which direction it goes.. | 09:16 |
| duflu | anpok_: Assume there will be no surface-specific transformation matrix at all. Per-surface transformations are very short-lived transient things better controlled by an external animation object. So for input just assume it's always simple and orthogonal a rectangle | 09:17 |
| anpok_ | well I could imagine having objects in a scene that refer to the real surface to some degree, and those object contain the information about transformations | 09:18 |
| anpok_ | but I wouldnt call those object animations | 09:18 |
| duflu | anpok_: The permanent surface transformation as far as input cares is just the size and position. That's a simple matrix you can generate if you need to. | 09:20 |
| duflu | Rotations and slides however are more "view" things than "model" things so I'm trying to get those transformations out of the model (surface implementation classes) | 09:21 |
| anpok_ | touch input works on the visual .. or view part of our model. it should use as much information as possible from that model | 09:22 |
| anpok_ | I see that we have to split basicsurface | 09:22 |
| anpok_ | but the android input stack needs to have access on the view model.. and not directly the surfaces | 09:23 |
| duflu | anpok_: If you generate a transformation matrix based on top_left() and size() then I guarantee that will be correct. Anything more complex like a rotation or a slide is too fast and too short-lived to be relevant to input | 09:23 |
| anpok_ | but thats a shell decision | 09:24 |
| duflu | anpok_: Yeah it's a design decision that's actually Mir's responsibility as it relates to any-and-all shells. We should let shells do whatever they want too. I suggest if we do keep some transformation() methods then they will be for the exclusive use of input. However inputting to rotated or moving surfaces is not a useful feature to worry about right now. | 09:26 |
| duflu | That's unrelated to screen rotation | 09:27 |
| RAOF | Scaled surfaces - eg: pixel-doubled surfaces to handle HiDPI - need more input transformation than just top_left() and size(). | 09:29 |
| anpok_ | hm I thought a complete solution would be straight forward to implement. | 09:29 |
| anpok_ | I mean.. by restricting two only three dimensions.. | 09:30 |
| anpok_ | s/two/to | 09:30 |
| anpok_ | so the plan wasnt to have a surface model to communicate.. and a visual/scene model that refers to surfaces and contains the transformation and can be used to dispatch input and as base for rendering? | 09:31 |
| duflu | anpok_: BasicSurface has an arbitrary transformation() still, and if there's a good reason then it can keep it. Just that I want to keep the size and position out of that. Add it back in for input calculations if you need to... but I think that's dangerous because you're missing the extra information like how the whole screen is transformed | 09:31 |
| anpok_ | hm but you still do make use of the transformation in the gl renderer? | 09:38 |
| duflu | Remember window decorations have to use the same BasicSurface::transformation() but they have their own size and position, so the matrix cannot contain scaling and position just for the client area | 09:38 |
| duflu | anpok_: Yes, the GLRenderer still uses Renderable::transformation() and will continue to for now | 09:38 |
| duflu | anpok_: Although in reality I would be happy to say that transformation() will always be the identity matrix. Real animations will be added in during composition/rendering | 09:40 |
| duflu | Hmm, maybe | 09:42 |
| anpok_ | sure that part I agree | 09:43 |
| anpok_ | also the assumption that the caller would draw surfaces at -0.5,0.5 with a 1x1 quad.. | 09:43 |
| duflu | anpok_: Actually if you go Compiz-style then the animation is returned from Renderable::transformation() | 09:44 |
| anpok_ | sorry no compiz backlog here.. but animated scenegraphs.. | 09:45 |
| duflu | anpok_: Yeah we can't use normalized coordinates. They make attaching correctly sized window decorations too hard. To make all decorations seamless they need to have identical coordinates to the surface itself, and use a scale that is in pixels (not in "surface widths") | 09:46 |
| duflu | anpok_: I think transforming input beyond size and position is not useful right now. Not only Unity doesn't need it, but no shell I've ever seen will need it. Screen rotation is of course separate and already done | 09:48 |
| anpok_ | hm basically I thought that part is now better because the scene objects that we have now only provides the information without imposing a certain way of rendering | 09:48 |
| anpok_ | sure, i just find it hard to see in which direction we are going.. | 09:49 |
| duflu | anpok_: Also keep in mind the compositor/renderer may change the whole screen appearance like zooming out to a cube or sliding. In that case, to transform input properly you'd have to ask the renderer for the full matrix sequence and reverse-engineer it | 09:50 |
| anpok_ | mps only show incremental steps that may or may not approach in the direction | 09:50 |
| anpok_ | or just ask it to transform to local coordinates, which is simple if is encoded in a view model.. or if there are objects to talk about.. | 09:51 |
| duflu | anpok_: Yeah it's hard to see the grand plan sometimes, and we often trip over each other. | 09:52 |
| duflu | anpok_: I would be reluctant to approve anything which requires matrix math in the CPU/BasicSurface. But I don't plan on removing Renderable::transformation() any time soon so you can still base the work on that | 09:53 |
| duflu | Although that matrix will always be identity really | 09:54 |
| duflu | Put another way, all information should flow from the scene to the compositor/renderer. We don't want it flowing the other way. It just means for input to "look right" the renderer has to keep the surface visually in line with the model (except during brief animations) | 09:58 |
| anpok | 10:54 < duflu> Although that matrix will always be identity really | 10:05 |
| anpok | 10:57 <anpok_> I think not much math is needed.. at least compared to for example a cache miss.. | 10:05 |
| anpok | the other topic I had in mind was changing MirMotionEvent .. it needs a client abi bump .. wasnt sure if that is worth the change.. I dropped unnecessary fields | 10:06 |
| duflu | Sorry, busy finishing work for a while | 10:07 |
| duflu | I'll be back | 10:07 |
| duflu | anpok: Your comment from 10:57 never arrived here :) | 10:13 |
| duflu | Looks like Xchat timed out and reconnected | 10:13 |
| duflu | anpok: Extending *Event structures is unavoidable and I agree there's more information there than we use. But if it's an optional change we should defer the client ABI break for a later larger release. In the mean time you can safely rename the fields you think are unused to see if that causes an API break without breaking the ABI | 10:14 |
| anpok | ok.. | 10:18 |
| anpok | regarding matrix math .. i think it will be easy to have short cuts for the 90% cases. | 10:18 |
| anpok | that dont involve any | 10:18 |
| duflu | anpok: If you do go down the road of translating input coords *completely* with the screen, then keep in mind you'll also have to reverse engineer the screen transformation and any temporary changes to it like cube mode or workspace sliding. I think it's a bad idea to do that. Better to stay with just size+position support | 10:18 |
| duflu | Hah. I now realize why Compiz used relative motion for everything. So it didn't have to transform input | 10:20 |
| duflu | That and the ability to rotate your cubes without hitting a screen edge | 10:20 |
| duflu | anpok: Any significant complexity needs an expected use case. If not in Unity then in other shells. I don't think there is a use case for complete reverse mapping on input coordinates with arbitrary transformations right now. | 10:22 |
| duflu | And you still don't have access to the renderer's display transformation (which you need) | 10:22 |
| * duflu -> dinner | 10:25 | |
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| === alan_g is now known as alan_g|lunch | ||
| kgunn | alf__: afternoon sir, let's say i wanted to run glmark2 on my nexus4...at the moment, what do i do ? :) | 13:29 |
| alf__ | kgunn: bzr lp:glmark2, fix a line in the code (ask me then), ./waf configure --data-path=$(pwd)/data --with-flavors=mir-glesv2 , ./waf , build/src/glmark2-es2-mir | 13:32 |
| alf__ | kgunn: of course you need to run it against usc or a demo server, as unity8 doesn't accept arbitrary connections | 13:32 |
| kgunn | alf__: thanks... | 13:33 |
| * kgunn remembers waf defeating him some time ago | 13:33 | |
| alf__ | kgunn: http://paste.ubuntu.com/7079309/ is the change you need to make (before running waf) | 13:35 |
| === alan_g|lunch is now known as alan_g | ||
| mterry | racarr_, with your greeter-configuration-for-mterry branch, what other changes do I need? You had suggested there were other changes | 13:48 |
| kgunn | alf__: thanks...stuck in a uds session, will try when i free | 14:02 |
| alf__ | kgunn: np | 14:02 |
| greyback | alf__: unity8 would probably accept it if you append "--desktop_file_hint=/usr/share/applications/calculator.desktop" to the glmark command | 14:05 |
| greyback | kgunn: ^^ | 14:06 |
| kgunn | thank for the hot tip | 14:06 |
| alf__ | greyback: glmark2 doesn't understand this command-line option | 14:07 |
| === dandrader is now known as dandrader|afk | ||
| greyback | alf__: darn, it doesn't ignore it | 14:08 |
| greyback | alf__: this works: "/glmark2-es2-mir -- --desktop_file_hint=/usr/share/applications/calculator.desktop" | 14:22 |
| greyback | kgunn: ^^ | 14:22 |
| alf__ | greyback: interesting! | 14:22 |
| === dandrader|afk is now known as dandrader | ||
| kdub | alan_g, how's this sound? https://code.launchpad.net/~kdub/mir/platform-specific-options/+merge/210500/comments/496321 | 16:24 |
| * alan_g looks | 16:24 | |
| alan_g | kdub: I think there are more issues than I first realized | 16:37 |
| kdub | issues that are existing, because of the review, or both? | 16:39 |
| kdub | I suppose I wouldn't mind putting the logic in mir::DefaultServerConfiguration::DefaultServerConfiguration either | 16:40 |
| alan_g | Well, there's an issue that to do that you need mo::Configuration to support adding options. | 16:41 |
| alan_g | And that is at odds with users having a choice how to supply options | 16:42 |
| alan_g | There's an existing issue that nothing says that mo::Configuration has to support the keys listed in its header | 16:43 |
| kdub | so, not forcing reliance on boost::program_options | 16:43 |
| alan_g | Yeah, why not allow a hard-coded lookup table? | 16:44 |
| alan_g | It is a convenience that we do command-line, environment and config files, not a requirement. | 16:45 |
| kdub | hardcoded lookup table of what? | 16:45 |
| alan_g | Key -> vaule | 16:45 |
| alan_g | *value | 16:45 |
| kdub | oh, as an alternative implementation of option lookup | 16:46 |
| alan_g | Yes. I can imagine most users of Mir don't want to allow all the options to be configured | 16:46 |
| alan_g | Could all your logic go into mo::DefaultConfiguration? | 16:47 |
| kdub | I think so | 16:48 |
| kdub | well, hmm | 16:49 |
| * alan_g thinks that would make the most sense | 16:51 | |
| kdub | yeah, I think we should still make mo::Configuration::add_options boost-free though | 16:51 |
| kdub | that way platform library wouldn't need boost::program_options, and the server-implementers wouldn't need it either | 16:52 |
| kdub | alan_g, the problem though is that we then need a comment in mo::Configuration that says | 16:53 |
| kdub | 'make sure to load the platform stuff' | 16:53 |
| kdub | or to be more precise, 'make sure to load and set the platform-specific keys too' | 16:54 |
| alan_g | kdub: we shouldn't have mo::Configuration::add_options at all | 16:54 |
| alan_g | That belongs in mo::DefaultConfiguration | 16:54 |
| kdub | we need some interface for the platform to do add options, just because it dlsyms the function... | 16:55 |
| kdub | maybe a std::function to do so or something | 16:55 |
| alan_g | We need a comment that says "these keys are always required", "these keys are optional and needed by mesa/android", "other platforms need other keys" | 16:56 |
| alan_g | The way your MP does it is fine (within DefaultConfiguration) | 16:57 |
| alan_g | We don't need | 16:58 |
| alan_g | If someone replaces Configuration then they have to reverse-engineer the options they need to support. | 17:00 |
| alan_g | While if someone uses our implementation it is all a bit nicer for them. | 17:01 |
| === dandrader is now known as dandrader|lunch | ||
| kdub | maybe we need two mo::Configurations, the user one and the platform one | 17:03 |
| kdub | and the platform sets up its own mo::Configuration (no add_options) and supplies it to the server configuration | 17:03 |
| kdub | yeah, I kinda like that | 17:04 |
| * alan_g wonders which of us has gone mad | 17:05 | |
| alan_g | Where do you think that the platform configuration gets its option values from? | 17:06 |
| kdub | it gets its keys and defaults from the platform, but the values are parsed from the environment/command-line/config-file | 17:08 |
| alan_g | All the querying of command-line, environment and config is part of our default implementation of mo::Configuration | 17:08 |
| alan_g | None of that is a requirement on an alternative implementation | 17:09 |
| kdub | right | 17:11 |
| alan_g | Actually, I've just realized that your approach has bugs | 17:13 |
| alan_g | If you add an option "vt" (say) in platform... | 17:14 |
| alan_g | and specify MIR_SERVER_VT=2 in the environment... | 17:14 |
| alan_g | then the first time you parse the environment it won't be recognised... | 17:15 |
| alan_g | and an exception will be thrown by boost.Options | 17:15 |
| kdub | sure, but all the parsing is done before anything other than the options starts using it | 17:15 |
| kdub | I think there are better ways though | 17:15 |
| kdub | like, maybe I should pass argc/argv to the platform creation and let it decide what to from there | 17:16 |
| kdub | the platforms each have their own options, parsed however they want to | 17:16 |
| kdub | and the platforms can't see the server options, and the server can't see the platform ones | 17:17 |
| kdub | with the downside being, we have to guard against option-name collisions | 17:17 |
| alan_g | Or we could "special case" the --platform-graphics-lib option and load the library (and ask for its options) before doing any parsing. | 17:19 |
| alan_g | So, remove platform-graphics-lib as an option and, instead supply it via MIR_PLATFORM=android | 17:22 |
| kdub | I don't mind parsing the command line for it | 17:22 |
| kdub | essentially, that's whats being done in the MP now | 17:23 |
| kdub | the_options() triggers a parse, and we get the graphics library name out, then we go and add the platform options, and reparse | 17:24 |
| alan_g | kdub: the problem comes with what I described above - you can't supply platform lib options in the environment | 17:24 |
| kdub | I don't see the problem | 17:25 |
| kdub | we would parse the (command line and the environment and the config file) once to get the library name, then add the options, then parse those 3 again to fill in the other options | 17:25 |
| alan_g | If, during that parse an option that isn't recognised (--vt) in my example. boost objects | 17:26 |
| alan_g | You can make it ignore unknown command line arguments, but not in the environment | 17:27 |
| kdub | oh, so boost can't ignore MIR_SERVER_VT on the first parse? | 17:27 |
| alan_g | Exactly | 17:28 |
| alan_g | It throws an exception | 17:28 |
| kdub | okay, I understand now | 17:28 |
| alan_g | It is a PITA that we were forced to ignore unknown command-line options too | 17:29 |
| kdub | okay, so we could special case using MIR_PLATFORM (which both the client and server would listen to), or we could pass argc/argv to the platform creation | 17:29 |
| alan_g | I still think it best to handle all of it in mo::DefaultConfiguration - and just provide a way (like you do now) for the library to add options to the default | 17:32 |
| kdub | yeah, seems like it would keep the code all in one place better | 17:33 |
| alan_g | But, for that, we can't get the platform by using boost.Options to parse the environment | 17:33 |
| alan_g | and get the platform | 17:33 |
| rsalveti | kdub: did you ever look at what would be needed for mir to support an external monitor when using the android backend? | 17:46 |
| rsalveti | was using the hdmi adapter yesterday with mako (android), worked nicely | 17:47 |
| rsalveti | android basically just mirrors it | 17:47 |
| kdub | really? | 17:47 |
| kdub | thats excellent then | 17:47 |
| kdub | I wouldn't have expected that, I think non-cloning would take some effort though | 17:48 |
| rsalveti | yeah | 17:48 |
| rsalveti | kdub: just get http://www.amazon.com/gp/product/B00DWGB6CU/ref=oh_details_o00_s00_i01?ie=UTF8&psc=1 | 17:48 |
| rsalveti | works with mako, flo and hammerhead afaik | 17:48 |
| rsalveti | maybe not hammerhead, but I know it works with mako and flo | 17:49 |
| rsalveti | nexus 10 also got a mini/micro hdmi port | 17:49 |
| kdub | yeah | 17:49 |
| kdub | well, thats good news | 17:50 |
| === alan_g is now known as alan_g|walk | ||
| === dandrader|lunch is now known as dandrader | ||
| mterry | racarr_, with your greeter-configuration-for-mterry branch, what other changes do I need? You had suggested there were other changes | 18:04 |
| racarr_ | mterry: Hi! | 18:04 |
| racarr_ | um | 18:04 |
| mterry | racarr_, something about needing something else in Mir land to work | 18:05 |
| racarr_ | mterry: https://code.launchpad.net/~robertcarr/mir/remove-ensure-display-powered/+merge/209734 | 18:05 |
| mterry | racarr_, hmm, I have that too | 18:05 |
| racarr_ | mterry: And what is the behavior now? | 18:10 |
| mterry | racarr_, I didn't see a difference. Screen still turned on when greeter came up. Maybe I screwed up one of the merges | 18:10 |
| mterry | Had both your branches and changed unity8 to use right unity-mir method. (I thought) | 18:10 |
| racarr_ | hmm | 18:12 |
| racarr_ | I guess maybe something extra is going on | 18:12 |
| racarr_ | how can I reproduce? | 18:12 |
| mterry | racarr_, lp:~mterry/unity8/split should be enough | 18:12 |
| mterry | racarr_, though that doesn't have the edit necessary to use the right unity-mir call | 18:13 |
| mterry | I can give you that diff in a pastebin in a sec | 18:13 |
| mterry | racarr_, http://paste.ubuntu.com/7080641/ | 18:14 |
| racarr_ | mterry: Do I need to make any system configuration changes? | 18:15 |
| mterry | racarr_, naw | 18:15 |
| racarr_ | awesome. will look soon | 18:16 |
| mterry | racarr_, you'll autologin into a unity8 shell. Then try locking screen. It will go black for a sec, then the backlight will come back on (I claim) | 18:16 |
| racarr_ | not sure whats going on at this point so | 18:16 |
| racarr_ | just going to have to poke around with GDB and logs and such | 18:16 |
| mterry | racarr_, when I'm done with some other work, I'll re-test myself in case I'm drunk | 18:16 |
| racarr_ | mterry: It is almost 3 pm | 18:16 |
| racarr_ | :p | 18:16 |
| mterry | racarr_, just an expression! :) | 18:17 |
| racarr_ | yeah no hurry, I am not going to get to it for at least a few hours. in the zone on some cursor stuff then lunch | 18:17 |
| racarr_ | haha I know | 18:17 |
| === d-snp_ is now known as d-snp | ||
| kdub | starting to see why we don't have platform specific options yet | 19:39 |
| kdub | sometimes i load x86 mir on the phone, and then worry something has gone really wrong | 21:11 |
| === jibel_ is now known as jibel | ||
| === cjohnston_ is now known as cjohnston | ||
| mterry | racarr_, still here? Testing with just your remove-ensure-display-powered works for me now | 23:24 |
| mterry | racarr_, in my testing before, I had extracted your diff on top of 0.1.6 | 23:24 |
| mterry | racarr_, this time I used your branch as-is, and it worked | 23:24 |
| racarr_ | mterry: Yay! | 23:36 |
| racarr_ | Ok that should land soon | 23:36 |
| mterry | racarr_, oh! my testing included your unity-mir changes too. Let me test without to see if those are strictly necessary | 23:57 |
| racarr_ | I think they are... | 23:58 |
| mterry | I believe it. Just want to triple-confirm for my list of greeter-split branches | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!