| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| alan_g | alf__: happy with the latest renames in https://code.launchpad.net/~alan-griffiths/mir/extending-SurfaceObserver/+merge/213516? | 11:50 |
|---|---|---|
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g | ||
| alf__ | greyback: Hi! Do you know which component in our stack handles the display-off signal from powerd and sets the new Mir display configuration? | 13:08 |
| greyback | alf__: I believe unity-system-compositor does that job. powerd does a dbus call, which USC receives and sets the display config | 13:13 |
| alf__ | greyback: great thanks | 13:18 |
| anpok | kgunn: https://code.launchpad.net/~andreas-pokorny/mir/no-initial-display-configuration-sent-to-hosting-server/+merge/213126 do we need this to land soon - necessary for split greeter, but just a workaround - we are still discussing alternatives | 13:35 |
| kgunn | anpok: for split greeter...yes sir! i'd really like to get split in asap | 13:38 |
| alan_g | kgunn: it is a shame it didn't get into the 0.1.8 MP then. | 14:17 |
| kgunn | alan_g: drat....altho we can cherry pick | 14:22 |
| === alan_g is now known as alan_g|tea | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === chihchun is now known as chihchun_afk | ||
| kdub | do we have any relatively recent build silos with the unity stack handy? | 16:18 |
| === alan_g|tea is now known as alan_g | ||
| === dandrader is now known as dandrader|lunch | ||
| racarr | nnn | 16:34 |
| racarr | whoops | 16:34 |
| alan_g | Missing ffe? | 16:38 |
| anpok | 0xAFFE? | 16:42 |
| anpok | a C0 | 16:42 |
| alan_g | Focus Follows Eyes | 16:44 |
| anpok | ah ok .. I thought you meant FFE in c0ffe | 16:45 |
| anpok | for some people coffee is like 23 .. you can find it everywhere | 16:46 |
| kdub | we store an address of a reference and use it as an ID in GLRenderer -_- | 16:56 |
| alan_g | kdub: you can't take the address of a reference. Only the address of what it references. | 16:57 |
| alan_g | That sort of trick breaks badly if the reference is bound to a temporary. | 16:58 |
| kdub | right, and the renderlist is about to become a temporary, so have to detangle that | 16:59 |
| kdub | unexpected surprises, all part of refactoring :D | 17:00 |
| === alan_g is now known as alan_g|EOD | ||
| === dandrader|lunch is now known as dandrader | ||
| anpok | kdub: I think input dispatch wants the same from the scene.. | 17:16 |
| anpok | a list of things-on-screen that can take input | 17:16 |
| kdub | anpok, but the input stuff shouldn't really be taking a Renderable :) | 17:16 |
| kdub | anpok, that makes sense though, there's a for-each-if for input too | 17:17 |
| anpok | hm I wonder if it is worth to have something different than renderable | 17:17 |
| kdub | from an interface perspective, I'd say it would be better to have a Renderable and an InputTarget (or similar name) | 17:17 |
| anpok | I mean touch input dispatch is all about graphical items on screen | 17:17 |
| kdub | well, even at that there's a delta between what they're doing, like renderable has 'number_of_uncomposited buffers' and 'alpha' | 17:19 |
| anpok | yeah that part | 17:19 |
| kdub | whereas the input stuff would just need transform and 'input targettable' | 17:19 |
| anpok | well alpha == 0 means I dont care.. | 17:19 |
| anpok | true | 17:19 |
| kdub | right, so basic surface could condense all the compositor reasons for not being onscreen into something simpler for input | 17:20 |
| kdub | If you have a reason to target the for_each_if (for the input-based iteration over the stack) for elimination, I'd be happy about that :) | 17:21 |
| anpok | I think I want to get a condensed from the scene, copies. of the current scene status.. so that no locks are needed.. so this part is similar to gettign a renderlist from scene. | 17:22 |
| kdub | sounds good to me, i'm doing something similar in lp:~kdub/mir/kill-scene-lock | 17:23 |
| kdub | you'd still need a lock on the scene... just for a shorter period of time | 17:24 |
| kdub | while the 'light' data is copied | 17:24 |
| anpok | hm and for all involved surfaces? | 17:24 |
| anpok | is basic surface still a Renderable? | 17:25 |
| kdub | it is currently, but it doesn't have to be moving forward | 17:28 |
| kdub | I see something like Renderable(BasicSurface) and InputTargetable(BasicSurface) in the future | 17:29 |
| kdub | like, Renderable is really what the compositor/displaybuffer needs to do its stuff, its unfortunate that its a lot of handy info in one place :) | 17:31 |
| anpok | hmm I see something like Renderable(SceneNode) InputTargetable(SceneNode) and SceneNode having a position/orientation/alpha/dunno and a reference to BasicSurface | 17:35 |
| anpok | BasicSurface only has the buffers a size and what is needed to talk to the clients.. | 17:35 |
| kdub | sure, I think we mean the same thing, except SceneNode would be an interface that BasicSurface implements (in your case) and in mine, I wasn't specifying an interface | 17:37 |
| anpok | kdub: I asked because it is possible that you distill a list of renderables now, and someone moves the basic surface around afterwards.. | 17:37 |
| kdub | but yeah, right :) | 17:37 |
| anpok | nope I mean SceneNodes are instances that refer to BasicSurfaces | 17:37 |
| kdub | 'moves' meaning what? like moves the object? | 17:37 |
| kdub | or moves the position on the screen | 17:37 |
| anpok | yeah new pos | 17:37 |
| anpok | I would like to be able to have one client surface shown in different places on screen.. | 17:38 |
| anpok | so yeah SceneNode would be an indirection towards BasicSurface | 17:38 |
| kdub | sure, still not seeing the problem yet though | 17:38 |
| anpok | maybe also towards (BasicSurface|DecorationSurface) | 17:39 |
| anpok | with moving? | 17:39 |
| kdub | whichever problem is being posited :) | 17:39 |
| anpok | hehe | 17:39 |
| anpok | hm you might be drawing a frame with surface in State X+1 with occlusion filters applied to surfaces while they were in State X | 17:39 |
| anpok | *surfaces | 17:40 |
| anpok | thats why I thought copying would be better, and Renderable not being SceneNodes/BasicSurfaces(for now) | 17:40 |
| kdub | right, i think copying is better too | 17:40 |
| kdub | the Renderable(SceneNode) constructor does a copy (or lazy copy, where appropriate/feasible) | 17:42 |
| anpok | ok | 17:43 |
| kgunn | bregma: do you wanna approve | 17:57 |
| kgunn | https://code.launchpad.net/~robertcarr/unity-system-compositor/add-cursor-option/+merge/213896 | 17:57 |
| kgunn | https://code.launchpad.net/~robert-ancell/lightdm/usc-hardware-cursor/+merge/213897 | 17:57 |
| * bregma looks | 17:57 | |
| === mhall119_ is now known as mhall119 | ||
| anpok | racarr: what editor are you using, some of the n's ended up in a different window, I guess. | 18:24 |
| racarr | yes they were just accidental nns lol | 18:26 |
| racarr | keyboard drumming while thinking + accidental enter key | 18:26 |
| anpok | because one n might have made it to a MP | 18:26 |
| greyback | racarr: stupid question here, but is the "hardware cursor" a real overlay/plane cursor drawn by the driver, or is it drawn by Mir's Renderer/Compositor? | 18:47 |
| racarr | greyback: driver | 18:51 |
| greyback | racarr: nice, thanks | 18:51 |
| racarr | lunch back in a flash | 19:25 |
| racarr | back | 19:38 |
| === dandrader is now known as dandrader|bbl | ||
| dansuf | kgunn: I built touch system with old driver and when I run unity8 now I get the start screen but only that and I got repeating messages in the logcat | 20:18 |
| dansuf | E/qdgenlock( 1349): perform_lock_unlock_operation: GENLOCK_IOC_DREADLOCK failed (lockType0x1,err=Connection timed out fd=80) | 20:18 |
| dansuf | W/Adreno200-EGLSUB( 1349): <GetBackBuffer:2121>: genlock_lock_buffer GENLOCK_WRITE_LOCK failed | 20:18 |
| dansuf | W/Adreno200-EGL( 1349): <qeglDrvAPI_eglSwapBuffers:3477>: EGL_BAD_ALLOC | 20:18 |
| dansuf | which appear randomly or when I touch the screen | 20:18 |
| dansuf | w-flo, who inspired me to update my drivers, wrote in his commit that before using new drivers some changes to mir code and genlock fixes in hardware_qcom_display were needed | 20:22 |
| dansuf | I'll try to solve the problem of genlock on my own | 20:23 |
| kgunn | dansuf: yeah..sorry, i'd not have an idea on that one... | 20:25 |
| kgunn | dansuf: curious...when you say start screen? you mean...like this http://www.blogcdn.com/www.engadget.com/media/2013/02/ubuntu-hands-on-620-ces2013.jpg | 20:25 |
| dansuf | kgunn: it's more ugly because the fonts are too big, not in proper place with no smaller circles arond the big one and with no top panel (there is just a black space) | 20:27 |
| dansuf | kgunn: despite this, yes | 20:27 |
| dansuf | :D | 20:27 |
| kgunn | dansuf: ok...so at least _some_ progress | 20:31 |
| dansuf | kgunn: yeah, I have to leave now, If I have no clues about it I'll conbtact w-flo or developer who is providing unofficial support for my device | 20:32 |
| racarr | sometimes the put things in the namespace htey are used rule is difficult to follow...the cursor controller needs to use the change callback from scene, so I had to extend the change callback mechanism to support multiple change targets | 21:39 |
| racarr | so the thing is the compositor uses like set_change_callback(null callback) tl clear it, so when having multiple callbacks you need to have some sort of add_callback -> id | 21:40 |
| racarr | remove_callback(id) sort of system. | 21:40 |
| racarr | so mi::InputTargets and mc::Scene and ms::SurfaceStack gain like unsigned add_change_callback(unction) remove_change_callback(unsigned callback_id) | 21:41 |
| racarr | and you want to typedef unsigned CallbackID, or maybe even use RAII or something | 21:41 |
| racarr | but what namespace | 21:42 |
| racarr | can you put that return type in? | 21:42 |
| racarr | you have to put it in ms:: and in its own header...like say we do with depth id | 21:44 |
| racarr | which breaks the namespacing rule and contains license header to code in a ratio of 40:1 lol | 21:44 |
| racarr | cest la vie | 21:44 |
| racarr | nevermind im silly | 21:54 |
| racarr | if you use riaa and a unique_ptr+std::function deleter for | 21:55 |
| racarr | the type | 21:55 |
| racarr | you only need a forward declaration | 21:55 |
| racarr | in headers | 21:55 |
| racarr | its still breaks the namespace rule but eh | 21:55 |
| AlbertA | std::function deleter? | 22:04 |
| AlbertA | so add_change_callback will return what? | 22:04 |
| AlbertA | a unique_ptr<SomeType>? | 22:04 |
| AlbertA | racarr:^ | 22:05 |
| racarr | AlbertA: Yes. i.e. unique_ptr<ChangeCallbackInterest, std::function<void(ChangeCallbackInterest*)>> | 22:12 |
| racarr | so you dont need a definition | 22:12 |
| racarr | for ChangeCallbackInterest | 22:12 |
| racarr | ID, Registration | 22:12 |
| racarr | something | 22:12 |
| racarr | I dont know the name yet | 22:12 |
| AlbertA | and the custom deleter is for unregistering automatically? | 22:12 |
| racarr | Yes | 22:12 |
| AlbertA | cool | 22:13 |
| AlbertA | I was looking into it briefly | 22:13 |
| AlbertA | because I want to also hook into the scene change | 22:13 |
| racarr | Ah | 22:13 |
| AlbertA | for screencast purposes | 22:13 |
| racarr | well I have a branch to do it, i just need to comment it | 22:13 |
| racarr | and look at the diff | 22:13 |
| racarr | but will have it mped by EOD | 22:13 |
| === dandrader|bbl is now known as dandrader | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
