| 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:00 |
| kdub | yeah... its hard to abstract that | 00:01 |
| kdub | 'this layer is quicker, but... you can't use a shader on it' | 00:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| kdub | like, thats actually how composition on the nexus4 works | 00:05 |
| kdub | within the hwc | 00:05 |
| racarr | mm | 00:05 |
| 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:06 |
| racarr | Hehe that's tricky to express | 00:07 |
| 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:09 |
| 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:10 |
| 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:13 |
| racarr | the renderer | 00:14 |
| 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:15 |
| RAOF | I hate all technology | 00:22 |
| RAOF | robert_ancell: Any better luck with XMir today? | 00:56 |
| robert_ancell | RAOF, just about to try | 01:30 |
| robert_ancell | brb | 01:30 |
| robert_ancell | RAOF, http://paste.ubuntu.com/5597212/ - is that it getting confused with nouveau? | 01:39 |
| robert_ancell | And if I remove the nouveau driver Mir wont even start | 01:40 |
| RAOF | Wha? | 01:42 |
| robert_ancell | RAOF, drmOpen seems to give "Operation not permitted" | 01:43 |
| RAOF | Well, it's not meant to be drmOpening at all. | 01:43 |
| 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:45 |
| 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:49 |
| RAOF | Urgh. | 01:50 |
| 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 | 01:51 |
| racarr | If anyone still around wants to review | 05:01 |
| 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:02 |
| 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:03 |
| racarr | robert_ancell: Cheers :) will land and propose software cursor soon | 05:16 |
| 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:18 |
| RAOF | Hah! And now that we've fixed the drivers to not load we run into xserver bugs. | 05:31 |
| 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:44 |
| 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:46 |
| duflu | I think mentioning "c_" is pointless, because all the toolkit headers are C-compatible | 05:47 |
| racarr | types.h :) | 05:50 |
| racarr | it was introduced just right before mir_toolkit so it was weird | 05:50 |
| racarr | oh god reminder email | 05:52 |
| racarr | I forgot the difference between tuesday and wednesday | 05:52 |
| 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:58 |
| tvoss | robert_ancell, cool | 05:59 |
| tvoss | robert_ancell, grabbing headset then | 05:59 |
| robert_ancell | RAOF, ^ | 06:00 |
| RAOF | robert_ancell: Yeah, just hunting for the link. | 06:00 |
| robert_ancell | racarr, ping? | 06:02 |
| robert_ancell | hikiko, connection problems? | 06:04 |
| racarr | Joining! | 06:05 |
| 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:07 |
| duflu | No one wants to talk much this week | 06:09 |
| hikiko | :) | 06:10 |
| hikiko | I entered!! but the hangout is done I guess | 06:14 |
| hikiko | I am the only one there :) | 06:14 |
| hikiko | fail!! | 06:15 |
| duflu | hikiko: Sorry. Not having any problems to discuss is good I guess. | 06:15 |
| hikiko | haha, true :D | 06:16 |
| duflu | Oh dear. I failed to read the docs correctly on our pixel format semantics. Time to rewrite :P | 06:58 |
| 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? :) | 07:49 |
| * 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:00 |
| * mlankhorst busy rebasing the kernel patches | 08:01 | |
| 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:02 |
| 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:03 |
| * RAOF goes to bathe Zoë | 08:04 | |
| * duflu wonders if RAOF named Zoë before, after, or because of his discovery of key composition ;) | 08:12 | |
| duflu | Aaa Mir, why can't you tell red from blue? :( | 08:13 |
| RAOF | Wellllll after :P | 08:25 |
| alan_g | Good morning! | 08:25 |
| duflu | Good afternoon- almost end of the week | 08:25 |
| alan_g | ;) | 08:26 |
| duflu | I'm panicking about lack of prep and need to run off in a while | 08:26 |
| duflu | Happy Raring Eve too | 08:31 |
| tvoss | duflu, Happy Raring Eve | 08:31 |
| * alan_g checks he has the t-shirt | 08:32 | |
| * RAOF wins the battle against Xorg | 09:23 | |
| tvoss | RAOF, \o/ | 09:23 |
| === 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 | ||
| * mlankhorst checks RAOF for scars | 13:02 | |
| === 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 | ||
| kdub | hello! status, bugs, worked on display logging | 15:07 |
| alan_g | afternoon, got laptop up to date, reviewing and updating MP. Thinking about ownership issues. | 15:09 |
| === mmrazik|afk is now known as mmrazik | ||
| kgunn | kdub: hwc1.0...awesome! | 15:12 |
| tvoss | kdub, \o/ | 15:16 |
| kdub | yay | 15:17 |
| racarr | /win goto 10 | 16:42 |
| racarr | ...:) | 16:42 |
| alan_g | Hello there | 16:43 |
| racarr | Hello :) | 16:47 |
| alan_g | Goodbye! | 17:05 |
| === alan_g is now known as alan_g|life | ||
| === tmoenicke is now known as tmoenicke|dinner | ||
| === tmoenicke|dinner is now known as tmoenicke | ||
| 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:35 |
| racarr | Got lots of little quirks in Qt key input worked out | 19:48 |
| 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:09 |
| 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:10 |
| 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:16 |
| bschaefer | haha nice :), im just about to go on lunch | 20:17 |
| racarr | back | 21:08 |
| 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:11 |
| 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:12 |
| bschaefer | also thanks for the review | 21:18 |
| racarr | hmm | 21:33 |
| racarr | well click/release does enter/exit hovering | 21:33 |
| racarr | kind of weird though | 21:33 |
| bschaefer | indeed, i need to track down where the conversion from an android event -> mir event happens...possibly something in there? | 21:37 |
| 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:49 |
| 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:50 |
| bschaefer | I also don't know why you would need to know the button state on a hover exit :) | 21:51 |
| racarr | bschaefer: So...it seems to be as intended | 22:04 |
| 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:05 |
| racarr | data or anything besides its arguments | 22:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 | |
| bschaefer | well to me it makes for an ambiguous event, which means we have to do more book keeping :) | 22:11 |
| bschaefer | but android is more a of touch environment, so maybe thats a reason | 22:12 |
| * bschaefer makes a workaroud | 22:12 | |
| 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:13 |
| bschaefer | racarr, Ill try and get that out today | 22:14 |
| racarr | great | 22:15 |
| 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:23 |
| bschaefer | haha | 22:24 |
| 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:25 |
| 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:35 |
| racarr | well I mean in the server | 22:36 |
| 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:37 |
| bschaefer | right, you don't want the server to die on a crtl+c :) | 22:38 |
| 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...) | 22:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!