| RAOF | kgunn: You rang, m'lud? | 00:13 |
|---|---|---|
| kgunn | RAOF: racarr__ was just sayin' that glamor on mir more coupled than he thot & might not lend itself to doing a demo of libreoffice on mir for next week...wondered if you had thots ? | 00:20 |
| kgunn | not sure how much you've looked at glamor | 00:20 |
| RAOF | Not a whole lot, although looking at the xf86-video-ati code I thought that the GBM bits were to do with making DRI work rather than 2d. | 00:21 |
| kgunn | but then we talked about not using glamor...which sounds like on desktop that'd be ok (on mobile, slow) | 00:22 |
| kgunn | but then there's menus | 00:23 |
| kgunn | RAOF: so just lookin' for some technical guidance, but my gut thinks go for it w/o glamor and put some work in to get the menus | 00:23 |
| RAOF | That seems reasonable. | 00:24 |
| kgunn | but willing to listen to reasons why we should focus on glamor, or not put effort in on menus | 00:24 |
| RAOF | We don't need glamor for the desktop. | 00:24 |
| kgunn | i didn't quite understand why "menus are free with galmor"...or am i reading into what Master Carr is saying ? | 00:25 |
| RAOF | You're reading that into what Master Carr is saying. | 00:29 |
| RAOF | Menus aren't free; they're the first part of window managment. | 00:29 |
| RAOF | Which _is_ a bit of a project :) | 00:29 |
| kgunn | so would that work really be the same w/ & w/o glamor? | 00:30 |
| RAOF | Yes. | 00:33 |
| RAOF | Glamor is merely “does it work (with GPU acceleration) on the phone”. | 00:33 |
| kgunn | right | 00:34 |
| kgunn | makes sense | 00:34 |
| RAOF | So one track is “sw-only xf86-video-mir that just uses the Mir API and X's software rendering” → “xf86-video-mir that uses glamor for 2d” → “xf86-video-mir that uses glamor for 2d and supports 3d” | 00:36 |
| RAOF | Those are all mostly required steps for “fast XMir on the phone” | 00:37 |
| RAOF | And then there's the “hello, window management” track, which gives you - for example - popup menus that popup in the right place :). | 00:37 |
| kgunn | ok, tbh, our goal of officelibre on mir is more about unity8 on desktop (not phone) | 00:39 |
| kgunn | racarr__: ^ | 00:40 |
| kgunn | RAOF: so, i got something i don't understand, trying to debug something using mir_demo_client_egltriangle, so i'm doing the VT1 basic server and VT2 demo on my laptop | 00:42 |
| RAOF | Ok, sounds good so far. | 00:42 |
| kgunn | i modify mir_surface.cpp, make install....i even changed the mir_demo_client_egltriangle as to make it update/install as well | 00:43 |
| kgunn | however...when i run | 00:43 |
| kgunn | i do not "see the change" | 00:43 |
| kgunn | from usr/local/bin installs... | 00:43 |
| kgunn | i have to run the demo client directly from the build folder | 00:43 |
| kgunn | how come? | 00:43 |
| RAOF | Well, that's what I do, because /usr/local installs are a *great* way to get extremely surprised in a month's time :) | 00:44 |
| kgunn | :) | 00:44 |
| kgunn | ok, so i'll just keep doing that... | 00:44 |
| kgunn | no problem | 00:44 |
| kgunn | but is there a reason why ?...i mean i really thot the install would take care | 00:44 |
| kgunn | also...is there a way to wipe out the local/bin | 00:45 |
| kgunn | ? | 00:45 |
| kgunn | to avoid that surprise ? | 00:45 |
| RAOF | My initial guess as to your problem would be whether or not cmake strips out the RPATH on everything when installing. | 00:45 |
| RAOF | kgunn: rm -r /usr/local/bin/* ? :) | 00:45 |
| kgunn | ok... | 00:45 |
| * RAOF has recently run this, having been surprised by an apitrace install lurking in there. | 00:45 | |
| kgunn | that easy huh | 00:45 |
| RAOF | Unless you've got something you actually *want* in /usr/local, yeah. | 00:45 |
| kgunn | cool | 00:46 |
| RAOF | You might also want to kill /usr/local/lib, because that little gem is *before* /usr/lib in the library search path. | 00:46 |
| kgunn | yep...researched enough to see that...and its first in my path | 00:47 |
| racarr__ | lol sorry to be confusing about menus | 00:48 |
| kgunn | racarr__: you weren't...i was playing the board game "Jump to Conclusions" | 00:48 |
| racarr__ | unrelated to glamor :) | 00:49 |
| racarr__ | oh | 00:49 |
| racarr__ | I prefer candyland. | 00:49 |
| kgunn | lol | 00:49 |
| AlbertA | kgunn: heh I love those office space references | 00:49 |
| RAOF | Mmm. Candy mountain! | 00:49 |
| kgunn | AlbertA: just for you :) | 00:49 |
| AlbertA | kgunn: I want to file my TPS report now | 00:49 |
| kgunn | AlbertA: yeah...i'm gonna need you to come in Saturday....yeah...why don't you just plan on coming in Sunday too | 00:50 |
| racarr__ | AlbertA: We're gonna have to ask you to come in to malta on a sunday... | 00:50 |
| kgunn | lol | 00:50 |
| AlbertA | evern funnier because we are | 00:50 |
| AlbertA | haha | 00:50 |
| * RAOF arrives home Monday morning. | 00:50 | |
| RAOF | (There will not be any RAOF on Monday or Tuesday after the sprint) | 00:51 |
| AlbertA | RAOF: I guess you didn't get the memo | 00:51 |
| AlbertA | RAOF: ;) | 00:51 |
| kgunn | RAOF: you're next movie watching assignment http://www.imdb.com/title/tt0151804/ | 00:53 |
| racarr__ | RAOF: Im bored. wanna write an X11 window manager? | 01:47 |
| RAOF | No, not really :) | 01:47 |
| racarr__ | lol my real question, is how to turn on rootless X. | 01:47 |
| racarr__ | I was thinking I would make input work in rootless (seems like there would be something to do) and maybe try and get some basic | 01:48 |
| racarr__ | infrastructure going. | 01:48 |
| RAOF | racarr__: I'm currently resurrecting my rootless X thingy, which seems to have been eaten by git. | 01:48 |
| racarr__ | Ah | 01:49 |
| RAOF | Oh! Yeah, that'll be what I need to actually get windows to display! | 01:49 |
| racarr__ | ? | 01:49 |
| RAOF | Need to tell things that there's a Composite manager. | 01:49 |
| RAOF | Otherwise they'll do stupid things, like draw on the root window. | 01:49 |
| racarr__ | ah. yes they will lol | 01:50 |
| mterry | anpok_, you still around by anychance? The cpu usage thing seems unrelated to mir... | 01:57 |
| mterry | anpok_, (copying unity8-greeter on top of unity8, then switching greeter code to run unity8 instead makes cpu usage be normal. So something is inspecting executable names) | 01:57 |
| mterry | anpok_, but I do still need help on the 'volume up/down presses ignored by android-input layer in greeter' issue... | 01:58 |
| RAOF | 2nd laptop mode: engage. | 02:56 |
| === irsol_ is now known as irsol | ||
| RAOF | Dear Google: any email sent to me written in Mandarin is almost certainly spam. kthxbye. | 04:07 |
| === chihchun_afk is now known as chihchun | ||
| === duflu_ is now known as duflu | ||
| anpok_ | yay just finished merging devel and making the unit test non-time-depending in my branch | 06:17 |
| anpok_ | non-time oO | 06:18 |
| * duflu high-fives anpok_ | 06:20 | |
| anpok_ | hi | 06:20 |
| duflu | Hi there | 06:20 |
| anpok_ | so avoid to time dependency in buffer consumption.. | 06:21 |
| anpok_ | we might need to consume all occuluded buffers (but not by drawing them :)) and provide expose/occlusion events for displays that got powered of | 06:22 |
| anpok_ | and hope that qt can deal with that | 06:22 |
| anpok_ | *off | 06:23 |
| duflu | anpok_: Hmm, I had proposed a branch that did just that. | 06:23 |
| duflu | It got rejected | 06:23 |
| duflu | Although it's a good idea | 06:23 |
| anpok_ | well you proposed drawing occluded buffers | 06:23 |
| duflu | anpok_: Different branch | 06:24 |
| anpok_ | oh | 06:24 |
| anpok_ | too many branches... | 06:24 |
| anpok_ | but for this to work we need the client api change .. | 06:24 |
| duflu | Ah, crap. | 06:25 |
| anpok_ | i mean.. we do not make an occlusion test when the compositor off | 06:25 |
| anpok_ | which we wanted to do anyhow sometime.. maybe today? | 06:25 |
| RAOF | Well, that looks like _part_ of libreoffice... | 06:29 |
| anpok_ | hm lets see how bzr deals with that | 06:31 |
| anpok_ | duflu: https://bugs.launchpad.net/mir/+bug/1318852 AlbertA is referring to the usage of src_alpha, one_minus_src_alpha as a blending function - which only works when the textures are not premultiplied | 06:34 |
| ubot5 | Ubuntu bug 1318852 in Mir "[enhancement] support proper per-pixel alpha for alpha-enabled display framebuffers" [Medium,New] | 06:34 |
| anpok_ | but which does not cause much trouble because we rarely have transparent client buffers | 06:35 |
| duflu | anpok_: Depends how often you run "mir_demo_client_egltriangle -b 0" ;) | 06:35 |
| anpok_ | duflu: well and how often do we verify that resulting rgb and a channels are mathematically correct and follow an additive blending model? | 06:36 |
| RAOF | Also, when are we going to support sRGB alpha? :) | 06:37 |
| anpok_ | duflu: the screencast bug fixed some time ago by applying filters (and I think avoid alpha writes) is caused by the used blending functions | 06:38 |
| RAOF | Hah! | 06:38 |
| RAOF | mir_surface_is_valid isn't particularly useful :) | 06:38 |
| anpok_ | we could safely assume premultiplied alpha for any client buffer and used (one, one_minus_src_alpha) | 06:38 |
| anpok_ | RAOF: hm where are you? | 06:38 |
| duflu | anpok_: I hope you're right. Although I can't yet see how this should produce a fragment with alpha != 1.0 ... | 06:39 |
| duflu | glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); | 06:39 |
| RAOF | anpok_: Still in hobart? | 06:39 |
| anpok_ | hm not makeing much sense, libreoffice valid surface? | 06:40 |
| duflu | RAOF: Oh... mir_surface_is_valid(NULL) ? | 06:41 |
| duflu | https://bugs.launchpad.net/mir/+bug/1248474 | 06:41 |
| ubot5 | Ubuntu bug 1248474 in Mir "mir_surface_is_valid(NULL) crashes instead of returning false" [Medium,Triaged] | 06:41 |
| anpok_ | assume you have an opaque background d_r, d_g, d_b, d_a, and blend a window shadow (s_r,s_g,s_b,s_a) above it with, lets assume a pixel s_a= 0.25 then your resulting alpha = s_a*s_a + d_a*(1-s_a) => 1/8 + 1*(3/4) => 7/8 | 06:44 |
| RAOF | duflu: Actually mir_surface_is_valid() for any non-surface :) | 06:44 |
| duflu | Wow Oo | 06:44 |
| duflu | Awesome. Surfaces everywhere! | 06:44 |
| duflu | It's a new paradigm | 06:44 |
| anpok_ | if you use GL_ONE instead (and make the shadow buffers and window decorations premultiplied) | 06:45 |
| anpok_ | you get -> 1*s_a + d_a(1-s_a)= 1/4 + 3/4 = 1 | 06:45 |
| racarr__ | Ah, yes, non surfaces are surfaces, 1=0, I see it all so clearly now...*runs off in to the night* | 06:45 |
| anpok_ | racarr__: see you late | 06:46 |
| anpok_ | r | 06:46 |
| duflu | racarr__: Consider that a good point to have a drink et al | 06:46 |
| RAOF | anpok_: Oh, no. I think something is destroying a surface, then X is handling an event that was queued from that surface. | 06:46 |
| racarr__ | Haha, I just got back from the wine bar and was just checking IRC before sleep :) | 06:47 |
| RAOF | So 0x926158 probably _was_ a valid surface, quite recently. | 06:47 |
| racarr__ | Good indeterminate time all! | 06:47 |
| RAOF | But now it's a SIGSEGV | 06:47 |
| RAOF | racarr__: Enjoy post-wine! | 06:47 |
| duflu | Whee, the handle validation problem | 06:47 |
| anpok_ | racarr__: apply the advanceable clock mp, it is global, but makes you independent on any extern time source | 06:47 |
| duflu | anpok_: OK, I trust you without stopping to check the math. If you have a superior solution in mind propose away :) | 06:47 |
| anpok_ | duflu: .. maybe i manage today... need to finish my input nightmare | 06:48 |
| RAOF | BAH! | 06:59 |
| RAOF | What's nulling mir_win->win? | 06:59 |
| duflu | RAOF: XMir's still *magic* after all | 07:06 |
| RAOF | Ah. And the reason why input isn't working is that nothing hooks it up. Oops! | 07:35 |
| RAOF | Wow. Apart from the bit where I've got the rendering offset and the bit where mir_demo_server_shell has issues with alt-tab, libreoffice is surprisingly usable. | 07:44 |
| duflu | RAOF: Whoa, that is worthy of celebration/video | 07:45 |
| RAOF | I think I'll wait until I've got the rendering correctly offset first :) | 07:45 |
| duflu | RAOF: Bah, Compiz never got that right ;) | 07:45 |
| RAOF | It got it more right than “big black box between the top-left corner and where the window wants to be” | 07:46 |
| RAOF | duflu: I'm not sure why you're exposing DPI to clients at all? I thought 100% of what you wanted was correctly-sized decorations, which are done in the server anyway? | 07:48 |
| duflu | RAOF: Clients need DPI (or something) to know how big to render text/buttons/etc. And particularly if a client is modifying its titlebar, it needs to agree with the server on the scale. | 07:49 |
| RAOF | Oh, they certainly do eventually. | 07:49 |
| duflu | But even before that, we want to avoid huge-titlebar-with-tiny-widgets or vice-versa | 07:50 |
| duflu | Cos then Mir wouldn't be any better than Unity 7 ;) | 07:50 |
| * duflu still thinks Trevinho is awesome | 07:58 | |
| anpok_ | now that the revert of 1hz rendering landed - i guess have to manually merge devel again? Or are we soon reverting the revert again? | 10:50 |
| alan_g | anpok_: I don't know that we have a plan for 1hz. But what makes this rev different to any other change to devel? | 10:57 |
| alf_ | Saviq: greyback: https://code.launchpad.net/~afrantzis/qtubuntu/fix-1321189/+merge/220613 | 11:00 |
| alf_ | Saviq: greyback: please note the lack of extensive testing | 11:00 |
| greyback | alf_: fix makes sense, that was my hunch anyway | 11:00 |
| Saviq | alf_, awesome | 11:00 |
| Saviq | Mirv, can you integrate that into the qtubuntu builds ↑? | 11:01 |
| Saviq | Mirv, it should fix the rendering issues under Qt 53. | 11:01 |
| Saviq | 5.3 | 11:01 |
| anpok_ | alan_g: it just touches the alarm tests due to some bsr and I have two branches in that area too | 11:02 |
| anpok_ | and i am lazy enough to not like conflicts :) | 11:02 |
| alan_g | anpok_: I don't see 1hz landing again until we've discussed what went wrong. So plan on your stuff landing before it gets sorted out. | 11:05 |
| anpok_ | alf_: not sure if you read the irc backlog of last night .. i finnally figured out why my clock improvements did not really improve things. | 11:22 |
| alf_ | anpok_: I haven't read it... at what time should I look? | 11:23 |
| anpok_ | oh not important.. 1900 my time .. maybe 2000 yours? | 11:24 |
| anpok_ | short story | 11:24 |
| anpok_ | posting actions on a io_service does not make the io_service reevaluate the pending timers | 11:24 |
| anpok_ | only when I create a new timer it will go and look for a new "now" | 11:25 |
| Mirv | Saviq: yes | 11:29 |
| Mirv | Saviq: sounds excellent | 11:30 |
| Mirv | pushing a build right away | 11:30 |
| Mirv | Saviq: note that even that your some output Qt 5.3 was actually using OpenGL ES 3.0, but let's see | 11:30 |
| Mirv | (ES 3.0 is now supported in 5.3) | 11:31 |
| === om26er_ is now known as om26er | ||
| Mirv | alf_: that was some awesome one-liner | 13:06 |
| alf_ | Mirv: glad it helped :) | 13:07 |
| mterry | anpok_, did you get my message late last night about the cpu issue with the greeter? | 13:56 |
| anpok_ | mterry: probably not | 14:04 |
| mterry | anpok_, ok, so I investigated more | 14:04 |
| anpok_ | ah at 3:57 | 14:04 |
| mterry | ah ok | 14:04 |
| anpok_ | and volome up down still an issue | 14:05 |
| mterry | anpok_, yeah both are still issues, I just know more :) | 14:05 |
| anpok_ | :) | 14:05 |
| anpok_ | the other one is already erased | 14:05 |
| mterry | anpok_, volume up/down is interesting. So it's an android-input issue about focus. But if I run the greeter as the user shell, it works. So it's not related to the actual code of the greeter either | 14:06 |
| mterry | Something about how the greeter environment is set up, versus a user environment apparenlty | 14:06 |
| anpok_ | hm ok i thought it would be a display off -> no focused surface issue or something | 14:06 |
| mterry | anpok_, the problem appears on first boot even before display off | 14:07 |
| mterry | Shoot. Now it's working on my device and I don't know what I did | 14:12 |
| anpok_ | but you DID something? | 14:13 |
| mterry | anpok_, I've been trying lots of things, but it started working, and after undoing what I did most recently it was still working. So I must have done something last night and not noticed it worked. I'm going to work backwards now :) | 14:14 |
| anpok_ | ok cool all issues erase.. me hurries back into input nightmares | 14:14 |
| anpok_ | you still might have found a bug | 14:17 |
| mterry | anpok_, heh, no I want you on retainer :) | 14:17 |
| === tedg is now known as ted | ||
| anpok_ | mterry: meeting the kids -> then I am all yours | 15:00 |
| anpok_ | *then | 15:00 |
| mterry | ricm:) | 15:00 |
| mterry | whoops | 15:00 |
| mterry | :) | 15:00 |
| anpok_ | at least I make you think that :) | 15:00 |
| === greyback is now known as greyback|afk | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === greyback|afk is now known as greyback | ||
| AlbertA | kgunn: alf: so I flashed a fresh image | 16:07 |
| AlbertA | kgunn: alf: with the current solution (buffer consuming thread) I still see a probably one frame flash | 16:07 |
| AlbertA | of old content | 16:07 |
| alf_ | AlbertA: sure, it depends how fast you do it :) | 16:08 |
| AlbertA | kgunn: alf: with 1Hz branch but set to 20Hz timeout I always see it... | 16:09 |
| AlbertA | kgunn: alf_: I wonder why | 16:10 |
| kgunn | like alf_ said, doesn't it depend on how fast you do it ? | 16:10 |
| AlbertA | kgunn: I mean in the 20Hz case, it doesn't matter how slow you do it | 16:11 |
| AlbertA | kgunn: 30 seconds later, it still flashes the one frame | 16:11 |
| kgunn | AlbertA: oh wait...so, you're cutting the compositor out of the chain in this method right | 16:12 |
| kgunn | so we | 16:12 |
| kgunn | have left the frames we dumped in there... | 16:12 |
| AlbertA | kgunn: right only framedropping | 16:12 |
| kgunn | just prior to turning off | 16:12 |
| kgunn | so those are what you see | 16:12 |
| AlbertA | kgunn: alf_: but that should be similar in the buffer consuming compositor too...I would think | 16:12 |
| kgunn | AlbertA: i didn't think so...cause buffer consuming compositor actually rendered to the "display" | 16:13 |
| kgunn | so they're gone | 16:13 |
| AlbertA | kgunn: I suppose the difference is | 16:13 |
| AlbertA | kgunn: it advances the compositor buffer | 16:14 |
| AlbertA | kgunn: and in framedropping it doesn't | 16:14 |
| kgunn | exactly | 16:16 |
| kgunn | dednick: can you retarget https://code.launchpad.net/~nick-dedekind/unity-mir/trusted-sessions/+merge/210775 to unity-mir/devel ? | 16:22 |
| kgunn | then i can put it in an existing silo | 16:22 |
| kgunn | with https://code.launchpad.net/~mir-team/unity-mir/mir-0.2.0-compatibility-changes/+merge/218734 | 16:22 |
| kgunn | AlbertA: or should we just merge https://code.launchpad.net/~mir-team/unity-mir/mir-0.2.0-compatibility-changes/+merge/218734 | 16:22 |
| kgunn | into unity-mir/devel... | 16:23 |
| kgunn | and MP unity-mir/devel to unity-mir trunk > | 16:23 |
| kgunn | ? | 16:23 |
| * kgunn goes to grab sandwich | 16:23 | |
| AlbertA | kgunn: yeah merge, if unity-mir/devel => means track mir changes it makes sense | 16:23 |
| kgunn | dednick: nvmd :) | 16:25 |
| kgunn | AlbertA: yes it does | 16:25 |
| dednick | kgunn: huh? :) | 16:25 |
| kgunn | lol...go back to trusted sessioning | 16:26 |
| kdub_ | AlbertA, camako: duflu asked for a resubmit on https://code.launchpad.net/~kdub/mir/overlay-gl-program/+merge/220690, so if you could take a look over again, I'd appreciate it :) | 16:55 |
| camako | kdub_, will do | 16:55 |
| AlbertA | kdub_:sure | 16:59 |
| ogra_ | moop | 17:47 |
| kgunn | ogra_: yep, waiting on jdstrand | 17:47 |
| ogra_ | yeah | 17:47 |
| kgunn | oh crap i gotta run...bbiab | 17:47 |
| kgunn | AlbertA: can help with the discussion ogra_ | 17:48 |
| AlbertA | ? | 17:48 |
| jdstrand | ogra_: do you still have /tmp/mir_socket too? | 17:48 |
| ogra_ | yes | 17:49 |
| jdstrand | kgunn: so, there should be two sockets. one for the root process and one for the session. the one for the session has been correctly moved to XDG_RUNTIME_DIR aiui. why is the root one in /tmp? can't it go in /run/mir or something? | 17:50 |
| ogra_ | jdstrand, kgunn had to run and pointed to AlbertA ... i guess we need to summmarize for him | 17:53 |
| ogra_ | AlbertA, so according to the landings 0.1.9 should hav abstracted the socket name for mir_socket but we still see mir_socket for system-compositor as well as the session Mir | 17:53 |
| ogra_ | and both even with 666 permissions | 17:53 |
| ogra_ | seemingly https://code.launchpad.net/~mir-team/mir/utopic r1185 was supposed to change that | 17:53 |
| ogra_ | but it looks like it didnt | 17:53 |
| ogra_ | (teh secutity team would like to have abstract socket names ... jdstrand can probably elaborate) | 17:53 |
| jdstrand | kgunn: plus, why is /tmp/mir_socket writable by world? | 17:53 |
| jdstrand | ah, I missed that he ran | 17:53 |
| jdstrand | so, /tmp/mir_socket is 777 and /run/user/32011/mir_socket is 775 | 17:54 |
| jdstrand | if we are using a named socket, I would expect 700 for both and /tmp/mir_socket to be in fome root owned directory (eg /run/mir) | 17:55 |
| jdstrand | s/fome/some/ | 17:55 |
| ogra_ | i think the session needs to be able to talk to it | 17:56 |
| ogra_ | not sure about the architecture here though | 17:56 |
| jdstrand | if so, then still could use a root-owned dir | 17:57 |
| === dandrader is now known as dandrader|lunch | ||
| jdstrand | the one in /run seems to lenient though | 17:57 |
| AlbertA | ogra_: we decided not to go for abstract socket names since the security team said at the time apparmor did not mediate them | 17:58 |
| jdstrand | too* | 17:58 |
| jdstrand | ah, well, that will be this cycle | 17:58 |
| jdstrand | jj has most of it ready | 17:58 |
| jdstrand | AlbertA: ok, what about 775 for the one in XDG_RUNTIME_DIR? could that be 700? | 17:59 |
| ogra_ | jdstrand, does that matter ? the dir is already 700 | 17:59 |
| jdstrand | actually, that doesn't really matter, /run/user/32011 is 700 | 17:59 |
| alan_g | Shouldn't the filesystem endpoint be suppressed on the system compositor anyway? | 17:59 |
| ogra_ | :) | 17:59 |
| === alan_g is now known as alan_g|EOD | ||
| * ogra_ thinks the session socket is all fine ... but the system one looks worrying | 18:00 | |
| AlbertA | jdstrand: at least a group no? | 18:00 |
| jdstrand | AlbertA: ok, so, the perms on the one in XDG_RUNTIME_DIR are weird, but not a security issue since a parent dir is 700. could we move /tmp/mir_socket to /run/mir (or something-- some root-owned dir)? | 18:00 |
| AlbertA | jdstrand: because we need mir clients to be able to connect to it | 18:00 |
| jdstrand | AlbertA: if you need the root owned socket to be 777, that's fine, but can it be put in a non worldwritable directory? | 18:03 |
| AlbertA | alan_g | EOD: but then how do you get the fd to connect to? | 18:03 |
| jdstrand | /run/mir_socket would even be fine | 18:03 |
| AlbertA | jdstrand: not sure who makes it 777...I suppose unity-system-compositor is changing the perms | 18:04 |
| ogra_ | but can user processes then write to it ? | 18:04 |
| ogra_ | sounds like that is needed | 18:04 |
| AlbertA | jdstrand: but sure it doesn't have to be /tmp | 18:04 |
| AlbertA | ogra_: the way I see it | 18:05 |
| AlbertA | ogra_: the nested mir server (unity8 process) needs to talk to it...so that could just be a group permission | 18:05 |
| ogra_ | which the user is in | 18:05 |
| ogra_ | which in turn makes it fully user writable | 18:06 |
| jdstrand | it may not necessarily be a security issue depending on how it opens the file and handles failure modes correctly. but putting it in /run makes sure it won't ever be | 18:06 |
| * jdstrand notes that confined apps cannot connect to /tmp/mir_socket now, nor /run/mir_socket. they do have access to /run/user/32011/mir_socket | 18:07 | |
| ogra_ | but in the split greeter world also the greeter needs to be in that group ... (the lightdm user) ... not sure what the security implications of that are | 18:07 |
| AlbertA | ogra_: in any case the socket file name/path is configurable so it just a matter of setting the right option when launching unity-system-compositor | 18:08 |
| ogra_ | right | 18:08 |
| ogra_ | mterry, ^^^ | 18:08 |
| ogra_ | can lightdm start u-s-c with a socket in a root owned dir ? | 18:08 |
| ogra_ | instead of tmp ? | 18:09 |
| mterry | ogra_, so we need a world-accessible place for tjhe USC socket? | 18:09 |
| ogra_ | well, jdstrand would like to see it in /run | 18:09 |
| mterry | ogra_, yeah, but the client sessions need to be able to access it | 18:09 |
| jdstrand | I would be surprised if it didn't work... | 18:09 |
| mterry | ogra_, both lightdm and USC are run as root, so I don't see a problem then | 18:10 |
| ogra_ | hmm, where do we set the var currently ... | 18:11 |
| * ogra_ cant find it in usc-wrapper or ubuntu-touch-session | 18:11 | |
| ogra_ | i know we had $MIR_SOCKET once | 18:12 |
| ogra_ | or is that dead | 18:12 |
| jdstrand | fyi, when we have abstract socket mediation in apparmor it opens the possibility to lock this down even more (eg, should be able to disallow any connections from unconfined and only allow connections from a particularly confined process-- eg, the session compositor) | 18:14 |
| jdstrand | we don't have to do that now or anything, just saying | 18:14 |
| AlbertA | ogra_: it's MIR_SERVER_FILE | 18:21 |
| ogra_ | AlbertA, right, but i dont see it being set anywhere .. we used to export that var in one of the start scripts before | 18:21 |
| AlbertA | ogra_: ah I see | 18:21 |
| ogra_ | (not a Mir thing :) ) | 18:22 |
| jdstrand | ogra_: so, it being in /tmp isn't a mir thing? I just did 'stop lightdm ; touch /tmp/mir_socket ; start lightdm' and was able to prevent lightdm from starting | 18:27 |
| ogra_ | jdstrand, no that var isnt a mir thing | 18:28 |
| ogra_ | jdstrand, ignore that ... i was looking at bending the var to make it use /run for a test | 18:29 |
| ogra_ | but i cant find where we set it anymore | 18:29 |
| jdstrand | I'd like to file a bug, but don't know where... | 18:29 |
| ogra_ | unity-system-compositor creates the socket on startup now i think | 18:30 |
| jdstrand | http://ubuntu-codesearch.surgut.co.uk/ didn't help me | 18:31 |
| jdstrand | ./src/system_compositor.cpp: return the_options()->get("file", "/tmp/mir_socket"); | 18:32 |
| jdstrand | (unity-system-compositor) | 18:32 |
| ogra_ | yeah | 18:33 |
| AlbertA | ogra_: yes if it's not set, mir will create a default socket in /tmp/mir_socket | 18:34 |
| AlbertA | I mean if MIR_SERVER_FILE is not set | 18:34 |
| ogra_ | right | 18:34 |
| jdstrand | fyi, bug #1322300 | 18:37 |
| ubot5 | bug 1322300 in unity-system-compositor (Ubuntu) "Please move /tmp/mir_socket to /run/mir_socket (or similar)" [Undecided,New] https://launchpad.net/bugs/1322300 | 18:37 |
| jdstrand | perhaps that should be retargeted to mir. feel free to do so | 18:37 |
| jdstrand | AlbertA: is the protocol for talking to the mir_socket defined somewhere? | 18:38 |
| AlbertA | yeah in mir | 18:39 |
| AlbertA | jdstrand: it's essentially google protobuf messages over the socket | 18:39 |
| jdstrand | thanks | 18:42 |
| kgunn | AlbertA: thanks, sorry had to run...back now, read the scrollback...so end result is to change /tmp/mir_socket default in mir? or in usc ? | 19:02 |
| AlbertA | kgunn: usc | 19:02 |
| kgunn | via MIR_SERVER_FILE got it | 19:02 |
| jdstrand | kgunn: not sure if you saw it, but I filed bug #1322300 | 19:07 |
| ubot5 | bug 1322300 in unity-system-compositor (Ubuntu) "Please move /tmp/mir_socket to /run/mir_socket (or similar)" [Undecided,New] https://launchpad.net/bugs/1322300 | 19:07 |
| kgunn | jdstrand: yep... | 19:08 |
| kgunn | just makin' sure i understood...if we were fixing it in usc or in mir | 19:08 |
| kgunn | mterry: meant to follow up with you and anpok_ , did you guys have luck in determining where the high cpu load was coming ? | 19:25 |
| kgunn | (and mem?) | 19:25 |
| mterry | kgunn, no... anpok_ pointed me at ricmm who said we have some code to disable sensors for unity8 (which may be related because sensors also take high CPU in this case), but didn't mention where. I've been distracted by the volume button bug in meantime though | 19:26 |
| === dandrader|lunch is now known as dandrader | ||
| mterry | kgunn, I'm trying to follow up with ricmm, but maybe he's EOD or something | 19:33 |
| ogra_ | mterry, he's sick | 19:33 |
| mterry | ogra_, oh poor guy | 19:34 |
| ogra_ | he was around for a split second from his rrom earlier | 19:34 |
| jdstrand | kgunn: I think the priority is higher than Opinion fwiw | 19:35 |
| jdstrand | it is perhaps 'low' in practice, but I can easily prevent mir from starting without privs if I can create a file in /tmp before mir starts | 19:36 |
| anpok_ | re | 19:36 |
| * kdub_ grumbles about our recomposite signalling | 19:59 | |
| kgunn | jdstrand: per discussion above with AlbertA, seems we want to fix it in USC....i only tied it to mir as "opinion" so it doesn't get lost | 20:07 |
| kgunn | make sense? | 20:07 |
| jdstrand | kgunn: oh, I missed that it was against the mir task. sorry | 20:08 |
| AlbertA | kdub_: heh... but you are making it better now...:) | 20:08 |
| jdstrand | kgunn: yeah, that makes sense | 20:08 |
| kgunn | mterry: ricmm is in malta this week with kidney stones i hear ...wonder if rsalveti might know how/where code is to turn off sensors | 20:08 |
| mterry | rsalveti, poke about your knowledge of any turning-off-sensors-for-unity8 code we have? | 20:09 |
| kdub_ | AlbertA, yeah, lucky me :) | 20:09 |
| rsalveti | qtubuntu-sensors? | 20:10 |
| kdub_ | but really, this isn't 'rewire the recomposition signalling' its 'make it possible to replace the compositor easily' | 20:10 |
| rsalveti | mterry: not sure if we have an easy way to disable it, Saviq would know | 20:10 |
| rsalveti | but the bridge is in qtubuntu-sensors afaik | 20:10 |
| mterry | rsalveti, hrm, a quick grep doesn't see the string unity8 in there | 20:11 |
| mterry | rsalveti, (I'm trying to solve a problem that is apparently some piece of code examining the process name for 'unity8') | 20:11 |
| rsalveti | no, that would be the just for qt, that implements the bridge between qml and platform-api | 20:11 |
| rsalveti | hm, weird | 20:12 |
| rsalveti | yeah, guess ricmm would be your guy | 20:15 |
| dandrader | mterry, what sensor are you talking about? | 20:16 |
| greyback | mterry: you sure it's unity8? Or just something that loads the ubuntumirserver QPA plugin? | 20:17 |
| mterry | dandrader, sensors.qcom and whatever Binder_2 both stay at ~10% CPU (along with the greeter). ricmm said we had some code to disable sensors for unity8, which I'm guessing is related? | 20:17 |
| greyback | mterry: have you profiled the process to see what method is being called so much? | 20:17 |
| mterry | greyback, I tried to use callgrind, but that slowed it down enough (even on lowest settings) that lightmd killed it. I haven't gotten to the point of recompiling lightdm with larger timeouts | 20:18 |
| greyback | mterry: try "perf" | 20:18 |
| mterry | greyback, oh yeah? Lighter weight? | 20:19 |
| greyback | mterry: *much* | 20:19 |
| mterry | greyback, OK, will do | 20:19 |
| greyback | mterry: this is a note I have on how to get/use it, hope it helps: http://pastebin.ubuntu.com/7502908/ | 20:20 |
| greyback | important to install the linux-*-tools package that suits the kernel | 20:21 |
| mterry | greyback, OK thanks! | 20:22 |
| dandrader | mterry, well, there's platforms/ubuntu/ubuntucommon/screen.cc:127:"void QUbuntuScreen::toggleSensors(bool enable) const {" in qtubuntu that I think is used by both ubuntumirserver (unity8) and ubuntumirclient QPAs, if that's any help | 20:22 |
| greyback | dandrader: looking at the same :) | 20:23 |
| mterry | dandrader, qtubuntu does check for "unity8" as a process name, but it doesn't seem to be used anywhere! I added debugging output and changed the check to look for unity8-greeter too, but no go | 20:25 |
| mterry | greyback, just filed https://code.launchpad.net/~mterry/unity-mir/no-focus/+merge/220718 for the volume up/down issue I've been seeing | 20:26 |
| * mterry is now laser focused on cpu bug | 20:26 | |
| greyback | mterry: no, it does no such thing. Unity8 loads the server plugin supplied by qtubuntu. qtubuntu does listen for orientation events somehow | 20:27 |
| mterry | greyback, grep qtubuntu for unity8, it does do a check. But I've been told that is dead code? | 20:27 |
| mterry | SurfaceFlinger support I guess | 20:27 |
| greyback | mterry: well I'm surprised. Yes it's checking the process name, and disabling sensors if it is unity8 | 20:29 |
| mterry | greyback, so while I think that's dead code, I'm worried that code got copied to some other component and is the source of my current problems | 20:29 |
| greyback | mterry: that piece of code is very much being used still. | 20:30 |
| mterry | greyback, ! I must be crazy then, because I put a qDebug() line in there and couldn't see it | 20:31 |
| greyback | mterry: I must be mistaken. qtubuntu code a maze | 20:33 |
| mterry | let me double check | 20:33 |
| greyback | mterry: sorry to divert, but could you please link a bug to https://code.launchpad.net/~mterry/unity-mir/no-focus/+merge/220718 | 20:41 |
| mterry | greyback, done | 20:43 |
| greyback | mterry: thanks! | 20:44 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| robert_ancell | What are edge_flags from MirMotionEvent? | 22:07 |
| robert_ancell | RAOF, are you getting loads of Cyrillic spam too? | 22:08 |
| kdub_ | just went to launchpad.net and expected to see the mir homepage | 22:47 |
| kdub_ | we should look into fixing that | 22:47 |
| kdub_ | :P | 22:47 |
| RAOF | robert_ancell: Dunno, but MirMotionEvent will probably be significantly different once we've worked out what we want in it :) | 23:03 |
| robert_ancell | ha! | 23:04 |
| RAOF | robert_ancell: Not too much Cyrillic spam, no. | 23:04 |
| robert_ancell | I get tonnes of Cyrillic spam to my Canonical account | 23:04 |
| RAOF | This is the stuff that makes it through the filters, right? I've not checked my Spam folder for the Canonical account in forever. | 23:11 |
| robert_ancell | No, the filters catch it all | 23:21 |
| robert_ancell | but I get enough false positives that I have to check the spam folder | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!