[00:00] mm [00:00] like, its common for the software buttons on the nexus4 to be an overlay layer [00:00] i guess we don't have to solve the problem now [00:00] no it's interesting though [00:00] I'minterested in starting to rework the rendering [00:00] to explore the shell rendering effects, etc. [00:00] might be related. [00:01] yeah... its hard to abstract that [00:01] 'this layer is quicker, but... you can't use a shader on it' [00:02] Mm [00:02] there are sort of two approaches to the shell and how it interacts with rendering and effects [00:02] 1. Is the shell replaces the compositor, renderer, etc, does what it wants [00:03] and 2. is the surface stack functions more as a scene graph and the shell is declarative about what it wants [00:03] I think this functions as an argument for 2, where the shell would create an "overlay" layer inside the scenegraph (beefed up surface stack) [00:03] and insert say, the software button surface in it [00:03] well, we could do a mix somehow [00:04] then the graphics backend is free to figure out [00:04] Hey, can overlay this with HWC [00:04] then all of a sudden it has a blur shader [00:04] and the graphics backend can render it however [00:04] right [00:04] i think that dynamism is what we should aim for [00:04] plus if the behavior is abstracted well [00:04] thats a big win too [00:05] like, thats actually how composition on the nexus4 works [00:05] within the hwc [00:05] mm [00:06] We should have layers in the surface stack [00:06] lets introduce them for stacking [00:06] and add fancy rendering later [00:06] (maybe try and make a demo shell that implements the unity blur between two layers) [00:07] Hehe that's tricky to express [00:09] racarr, i mean, the quick way is just override the default gl_renderer.cpp [00:09] but expressing a good model for all the different effects is tricky [00:10] one possible way to express blur is like [00:10] there are two layers, say the app layer and the shell layer and we want to render the shell layer with a blur effect of the app layer [00:13] so the shell, does something like shell_layer->add_texture_sampler((Renderable)appLayer, "textureSamplerName") [00:13] then shell_layer->add_fragment_shader(shader source) [00:13] highly idealized of course ;) [00:14] the renderer [00:15] does a prepass on the graph, to resolve dependencies, i.e. it sees the shell layer references the app layer as a texture so we need to render it to an fbo [00:15] or maybe there are only 4 renderables in total and we have a bunch of texture units so we render it all with one massive multitexture [00:15] *hand wavy* [00:15] thats my idealized extreme of number 2 [00:22] I hate all technology [00:56] robert_ancell: Any better luck with XMir today? [01:30] RAOF, just about to try [01:30] brb [01:39] RAOF, http://paste.ubuntu.com/5597212/ - is that it getting confused with nouveau? [01:40] And if I remove the nouveau driver Mir wont even start [01:42] Wha? [01:43] RAOF, drmOpen seems to give "Operation not permitted" [01:43] Well, it's not meant to be drmOpening at all. [01:45] robert_ancell: Could you change lightdm so that it passes "-verbose 7" to X, and then give me the lightdm log? That should also catch things that X's backtrace handler doesn't, like missing symbols. [01:45] RAOF, that should have been -vebose 7 [01:49] robert_ancell: Ah, ok. Yes, the problem is that nouveau getting loaded. [01:49] I can reproduce on my hybrid system when I've got the ATI card powered up. [01:50] Urgh. [01:51] robert_ancell: And, as before, you can't turn off your nvidia card, can you. Bah! [01:51] I'm heading out to lunch soon. I'll see what I can wrangle when I get back. [01:51] RAOF, nope [05:01] If anyone still around wants to review [05:02] demo-shell again, alans needs fixing was covered by weakify-event-filters (and Alan agreed that was good in the morning) [05:02] and alf is on vacation so it just need one more +1 [05:02] robert_ancell: I think I've fixed your nouveau problem in the daily build that's happening now. [05:02] RAOF, yay! [05:02] anyway if we can land it or iterate in the next 2 hours or so before I go to sleep [05:02] I can propose software cursor :) [05:03] Also happy afternoon :) [05:03] racarr, if you think you've fixed the issues raised by Alan/Alexandros just land it [05:16] robert_ancell: Cheers :) will land and propose software cursor soon [05:18] racarr, regarding https://code.launchpad.net/~vanvugt/mir/clarify-c-types/+merge/160294. Is c_types supposed to refer to "C language types"? [05:31] Hah! And now that we've fixed the drivers to not load we run into xserver bugs. [05:44] robert_ancell: It's supposed to refer to C language types [05:44] it is used in the server by the native display but this merge seems to work because mesa/native_display.h is included [05:44] includes it [05:44] even if the src/server/* file removed it [05:46] racarr: Yeah there's still some conflict there with common.h. We need to resolve the differences between the two more clearly, somehow [05:47] I think mentioning "c_" is pointless, because all the toolkit headers are C-compatible [05:50] types.h :) [05:50] it was introduced just right before mir_toolkit so it was weird [05:52] oh god reminder email [05:52] I forgot the difference between tuesday and wednesday [05:58] racarr: Right, but common.h is also just for C-types. But wider-used simple types like enums [05:58] racarr, robert_ancell duflu do we do the weekly? [05:58] The tricky part is that some types like callbacks are too client-specific to go in common.h (visible to the server) [05:58] tvoss, sure. I'm looking after my daughter so I'll have to see how it goes but I'll attempt it [05:59] robert_ancell, cool [05:59] robert_ancell, grabbing headset then [06:00] RAOF, ^ [06:00] robert_ancell: Yeah, just hunting for the link. [06:02] racarr, ping? [06:04] hikiko, connection problems? [06:05] Joining! [06:07] yes robert_ancell [06:07] trying to fix it [06:07] hikiko, ok, we're mostly saying we'll just meet in Oakland [06:09] No one wants to talk much this week [06:10] :) [06:14] I entered!! but the hangout is done I guess [06:14] I am the only one there :) [06:15] fail!! [06:15] hikiko: Sorry. Not having any problems to discuss is good I guess. [06:16] haha, true :D [06:58] Oh dear. I failed to read the docs correctly on our pixel format semantics. Time to rewrite :P [07:49] Man, I wonder if this xserver code has ever actually been executed? [07:49] mlankhorst: xf86DeleteDriver just doesn't really work, does it? :) [08:00] * mlankhorst has no idea [08:00] Spoilers: it doesn't. [08:00] Well, it does unless you're using it in a situation when you'd want to use it. [08:01] * mlankhorst busy rebasing the kernel patches [08:02] Does one of them allow me to get the size of a dma-buf out of its fd? :) [08:02] oh I forgot [08:03] I'm happy to get some more kernel experience if you don't want to write that patch. [08:03] hehe I want to write it, it was just that I had to rework some other patches and I was resenting it so much I postponed all my kernel work a bit [08:04] * RAOF goes to bathe Zoë [08:12] * duflu wonders if RAOF named Zoë before, after, or because of his discovery of key composition ;) [08:13] Aaa Mir, why can't you tell red from blue? :( [08:25] Wellllll after :P [08:25] Good morning! [08:25] Good afternoon- almost end of the week [08:26] ;) [08:26] I'm panicking about lack of prep and need to run off in a while [08:31] Happy Raring Eve too [08:31] duflu, Happy Raring Eve [08:32] * alan_g checks he has the t-shirt [09:23] * RAOF wins the battle against Xorg [09:23] RAOF, \o/ === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === alan_g is now known as alan_g|lunch === mmrazik is now known as mmrazik|afk [13:02] * mlankhorst checks RAOF for scars === alan_g|lunch is now known as alan_g === mmrazik|afk is now known as mmrazik === olli_ is now known as olli === mmrazik is now known as mmrazik|afk === mmrazik|afk is now known as mmrazik === mmrazik is now known as mmrazik|afk [15:07] hello! status, bugs, worked on display logging [15:09] afternoon, got laptop up to date, reviewing and updating MP. Thinking about ownership issues. === mmrazik|afk is now known as mmrazik [15:12] kdub: hwc1.0...awesome! [15:16] kdub, \o/ [15:17] yay [16:42] /win goto 10 [16:42] ...:) [16:43] Hello there [16:47] Hello :) [17:05] Goodbye! === alan_g is now known as alan_g|life === tmoenicke is now known as tmoenicke|dinner === tmoenicke|dinner is now known as tmoenicke [19:35] I thought I broke the Qt mapping of the tab character [19:35] but really I forgot I was in demo shell [19:35] and it eats tab events [19:35] ... [19:48] Got lots of little quirks in Qt key input worked out [20:09] racarr, cool :) [20:09] racarr, soo, i added some more event defines in a branch here: [20:09] https://code.launchpad.net/~brandontschaefer/mir/more-event-defines/+merge/160756 [20:10] I saw your comment about waiting till next week, but I needed the MirMotionButton and MirKeyMeta for some SDL stuff so I went ahead and did that [20:16] bschaefer: Haha! I was just getting ready to add the mir key meta after lunch [20:16] so perfect! [20:16] now lunch though, will review after [20:17] haha nice :), im just about to go on lunch [21:08] back [21:11] soo, i just started looking into this missing button state for a mouse release...and whats weird is the mir_motion_action_hover_exit [21:11] has the correct button state [21:11] another thing thats weird is clicking in general generates a hover exit/enter event as well [21:12] so the events go like this when you press: HoverExit (correct button state), MousePressed (correct button state), Mouse Released (incorrect button state) [21:12] so im thinking that hover exit steals it [21:18] also thanks for the review [21:33] hmm [21:33] well click/release does enter/exit hovering [21:33] kind of weird though [21:37] indeed, i need to track down where the conversion from an android event -> mir event happens...possibly something in there? [21:49] err, that seems to be done in the lexicon, but that would mean android is giving odd states? interesting.. [21:49] bschaefer: I guess this is just how the android input works perhaps [21:49] it does make sense somehow, when the button is released the button state is 0 ;) [21:50] racarr, hmm perhaps, the problem is theres no look ahead when receiving events [21:50] ie, press button 1 down, press button 2 down, release button 1, which button was released? [21:51] I also don't know why you would need to know the button state on a hover exit :) [22:04] bschaefer: So...it seems to be as intended [22:05] racarr, whooo, umm I just got something weird...um [22:05] racarr, is the lexicon function thread safe? [22:05] if you look in InputReader.cpp around l2400 [22:05] is whre it begins sort of [22:05] It should be right! It doesn't access any [22:06] data or anything besides its arguments [22:07] racarr, so heres a sample of my log: [22:07] http://paste.ubuntu.com/5599532/ [22:07] and the print statement im using in void mia::Lexicon::translate(const droidinput::InputEvent *android_event, MirEvent &mir_event) [22:08] it does a static cast but the umm, android event seems to be off, as it should align up [22:08] racarr, ignore that... [22:08] * bschaefer put the print statement in the wrong place [22:08] :) [22:09] story of my life haha :) [22:09] haha, I put it before the mir_event was getting assigned so it had the last values it had in it hahaha [22:09] :) [22:10] I think this is as intended by android, and the idea is just, you receive an event and see the new button state and do what is appropriate [22:10] right, SDL being old doens't do things like this [22:10] but if SDL apps aren't happy with that (i.e. need an event this button was released) [22:10] I think you should just maintain [22:10] a simple mapping [22:10] for now [22:10] well, yeah Ill have to do a map [22:10] yeah [22:10] Im not sure if the android way is good or not but [22:10] * bschaefer was trying to avoid ambiguous events [22:11] well to me it makes for an ambiguous event, which means we have to do more book keeping :) [22:12] but android is more a of touch environment, so maybe thats a reason [22:12] * bschaefer makes a workaroud [22:13] bschaefer: You should propose the test anyway, just with the passing semantics [22:13] so we at least have something that says how it works [22:13] alright, I still need to fix a mocking problem, complaining about something [22:13] even if I remove the check if state ==0 [22:14] racarr, Ill try and get that out today [22:15] great [22:23] ok the one thing keeping me from using mir as a terminal multiplexor now [22:23] is input goes through to the VT :p [22:23] so ctrl+c [22:24] haha [22:25] racarr, also, turns out if you do MouseDown 1, then try MouseDown 2 its blocked by the mouse Down 1 [22:25] sooo I suppose thats no longer a problem, so I just have to save the last used button state...still annoying :) [22:35] struct termios terminal_attributes; [22:35] tcgetattr(vt_fd, &terminal_attributes); [22:35] cfmakeraw(&terminal_attributes); [22:35] terminal_attributes.c_oflag |= OPOST | OCRNL; [22:35] tcsetattr(vt_fd, TCSANOW, &terminal_attributes); [22:35] lol... [22:35] its like all the worst names in 5 lines [22:35] haha, are you really stealing the fd from the vt haha? [22:35] well that works [22:36] well I mean in the server [22:37] setting up the VT [22:37] the problem is I need the server not to respond to control sequences anymore :) [22:37] oo, I was thinking the tty for some reason [22:38] right, you don't want the server to die on a crtl+c :) [22:40] also for you enable input branch, with my change to trunk you'll need to change these: http://paste.ubuntu.com/5599384/ [22:40] (very simple...)