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