[00:12] Anything else I can do? [00:35] What security issues in X's design does Mir fix? (And, are there any security issues in Mir's design?) [00:44] The way that X clients can do whatever they want to each other, up to and including snoop all keyboard input. [00:45] There aren't any security issues in Mir's design that we've identified :) [01:00] Thanks. In Mir, keyboard/mouse/etc. input will... only ever go to the focused window? [01:01] c74d3: No... "focus" refers to things that don't have coordinates (key presses) everything else goes wherever you're pointing [01:01] That said, we haven't implemented everything yet so you might see missing features [01:02] But a program can't know about a mouse-click unless it's the one whose window is being clicked on? [01:03] c74d3: That or it owned the start of a gesture (clicked in window and dragged outside of). Also note we need and haven't yet implemented grabs [01:03] Grabs allow a window to own the mouse [01:03] Okay, thanks. [01:04] * tmpRAOF notes that “grabs” are probably the wrong term, as they're easily confused with X11's (multiple) grab concept(s). [01:04] tmpRAOF: Perhaps [01:04] Oh, "grabs" as in "the program grabs the mouse", not "the mouse-pointer grabs something". [01:04] c74d3: Yes [01:07] Can programs read other programs' output, e.g. for screen-captures (or, on the other side, stealing passwords etc.)? [01:07] No [01:08] *: in general. [01:11] * duflu is reminded he doesn't know how screencast's security works (or should work) [01:12] It's shell-mediated [01:13] tmpRAOF: Oh, I hadn't seen that invite from Thomas ;) [01:13] :( [01:13] :) [01:17] "shell-mediated" -- The "shell" (which is like a window manager?) can approve or deny each screen-capture request, possibly after asking the user? [01:18] tmpRAOF: Did you lose internets last night too? [01:19] duflu_: I don't think so? [01:20] c74d3: Correct. The “shell” could also be called the desktop-environment. Mir doesn't have the same display server/window manager split that X has. [01:21] This is a good thing. I found myself looking at Weston code last week for the first time and there are some horrible implications for what Wayland expects each compositor to re-implement [01:22] "desktop-environment", like KDE? With a file-management GUI, a system-settings GUI, etc.? [01:22] c74d3: Yes [01:23] That said, Mir should not discount Wayland. We've got a lot of selling/improving to do to support other shells [01:24] Mir requires a desktop environment? [01:25] Does a Mir shell need to include file-management etc. GUIs, or could it merely be equivalent to a X window manager? [01:26] duflu_: Oh heya. === duflu_ is now known as duflu [01:26] c74d3: Mir is a library you use to build desktop environments, mostly. [01:26] DalekSec: Hello... [01:27] http://sigma.unit193.net/lightdm/unity-system-compositor.log was the log for 0.11.0 on the hardware affected (still) by bug 1212753. [01:27] bug 1212753 in mir (Ubuntu) "[i865] unity-system-compositor fails to start: Failed to choose ARGB EGL config" [Medium,Fix released] https://launchpad.net/bugs/1212753 [01:27] c74d3: In roughly the same way that Wayland is an RPC mechanism + default protocol specification for a display-server-desktop-environment thingy. [01:28] tmpRAOF: hm, thanks. [01:31] DalekSec: Thanks. I thought I was being a bit optimistic on that one. What chipset/GPU? [01:31] http://paste.openstack.org/show/ilFEYLp8qY75dkGm4Px5/ [01:32] DalekSec: Hmm i845 is even older than that of the first reporter... :) [01:33] DalekSec: In that case, can you please open a new bug? https://bugs.launchpad.net/mir/+filebug [01:34] Generally looks like the same error... [01:39] DalekSec: Yes, but things get messy if we declare them fixed and reopen. I would reopen if someone with i865 also says "not fixed" [01:39] Bugs are free. Please log them :) [01:39] Bah... [01:40] duflu: Just to be clear, this is xmir on Xubuntu/Xfce, not "native" mir. [01:41] DalekSec: It's still Mir under XMir. The "native" part isn't really important there... [01:41] Mhmm, just figured I'd note. :) [01:43] DalekSec: Obviously in the long term we all want to use shells that are closer to the hardware... that's faster and less resource hungry [01:44] Anything besides chip, release, mirver, and error log? [01:44] unity-system-compositor is absolutely “native Mir”; we're writing a library that should support such things, not just Unity8's QML :) [01:45] DalekSec: Nope, that's enough thanks [01:45] lp 1420574 [01:45] Launchpad bug 1420574 in Mir "[i845] unity-system-compositor fails to start: Failed to choose ARGB EGL config" [Undecided,New] https://launchpad.net/bugs/1420574 [01:45] DalekSec: Ta muchly [01:46] duflu: Sure. I'll stick around too in case you need anything else. :) [01:46] Cheers from the Xubuntu team! [01:47] DalekSec: Oh, one important question: Can you run OpenGL (mesa) demos on this system using native X/Xfce? If so, what are the GL renderer strings reported? [01:48] (glxinfo | grep OpenGL) [01:49] I'm back into the installed system, 14.10, but yes it works: OpenGL renderer string: Mesa DRI Intel(R) 845G x86/MMX/SSE2 [01:50] DalekSec: Can you please run "glxinfo | grep OpenGL" and paste the output in the bug? The key thing is to prove that Mesa supports your system (and therefore Mir should too) [01:52] Done. [01:53] ...Just as long as I don't have to show FPS. >_> [01:55] :P [01:58] Anywho, I believe that's enough of that for now. See you another day. [01:59] DalekSec: Thanks. We're eager to make Mir work everywhere [01:59] Bit surprised honestly, based on how dated this is. [02:25] DalekSec: Well, it's not a Canonical priority but something I'd like to achieve on a weekend at least [02:26] From 14.10, I take it "es2_info: es2_info.c:158: make_x_window: Assertion `num_configs > 0' failed." is a Very Bad Thing™? [02:27] DalekSec: Yeah that's a good explanation [02:28] DalekSec: I think I could write a renderer that will work for you and Mir in OpenGL 1.x but Unity8 will never support it. [02:28] I'm asking before posting as I'm not on 15.04, though don't believe that'd make a difference. [02:28] duflu: Not to be rude, but I never plan to use unity8. :) [02:28] DalekSec: Fair statement. You're not alone and we hope there are other shells [02:28] Others might, but I can't see anyone on this old a card 1. Trying to use unity. 2. Keeping it for much longer. [02:29] Anywho, I'll post. [02:29] DalekSec: I like the challenge. The key point is whether introducing Mir alienates any/many existing Ubuntu users. Presently that's "yes" [02:30] duflu: Hah! Awesome. :) [03:18] duflu: Oh, and xfwm4's compositor is off in all the 14.10 output. :3 [03:19] DalekSec: OK, I don't think that matters. First we need Mir to start, then XMir (or Unity8 or whatever) ... [03:20] Yeah, glxinfo isn't different, just might be good to mention. [03:24] duflu: unity-system-compositor as it currently stands doesn't really need GL at all; (at this point) we could entirely drop that requirement. [03:24] tmpRAOF: Yeah fair point and I've been hoping to do so [03:25] Just that a native DRM compositor right now would only support fullscreen [03:25] Which is fine, because system compositor. [03:25] In the current state of affairs we don't actually *composite* at any point. [03:26] We just multiplex. [03:26] tmpRAOF: I like to have such separations in code because it's a nice design sanity test for anyone making changes in future [03:27] tmpRAOF: Well, proving server does composite (antialiasing and blending) [03:27] "compose"? [03:27] Yeah, absolutely. But DalekSec doesn't need proving server to run; they need unity-system-compositor to run :) [03:27] I think the verb is "composite" [03:28] tmpRAOF: Absolutely [03:28] Although both look feasible [03:29] Also, Gerry said he had done the change himself a while back. Not that many changes required to switch to full OpenGL [03:29] The hard part is how to maintain it [03:30] Oh, I thought you were thinking of switching to non-GL rather than just switching out GLES in favour of GL. [03:30] tmpRAOF: Both eventually [03:30] Support all the things [04:35] Yay! Benchmarking different locking approaches in add-multiplexing-dispatchable leads to me discovering a bug! [04:39] Also, cache invalidation :( === chihchun_afk is now known as chihchun [06:24] * Mirv gets highlighted on "mirver" [06:28] Hah, nice. === chihchun is now known as chihchun_afk [07:49] Mirv: Sorry, shouldn't happen often [07:49] Good morning BTW [08:05] alf_: ping.. [08:16] ah nm I'll just remove the client_lib.h [08:22] mlankhorst: pong [08:23] alf_: http://paste.debian.net/145453/ -- next time test you actually don't need libmirclient-dev please. :P [08:24] mlankhorst: ah, right, sorry for that === chihchun_afk is now known as chihchun [09:24] alf_: so far I only looked at one of the intermittently failing test cases.. but there the scenario is somehow related to lp:1401488 [09:29] the main thread gets terminated in g_main_context_iteration when before one or two source handles from previous runs got cleaned up inside the event reading thread during its first iteration [09:32] i will try a different approach there.. [09:34] alf_: Found a fun regression: Clients consume double framerate if within 50-100 pixels of the shared screen edge (not even touching it) [09:34] Now bisecting [09:34] duflu: interesting [09:35] Hmm, that could be the shadow extents. I think someone added that [09:35] anpok: ENOCONTEXT [09:48] :) [09:49] alf_: i am creating a second glib main loop instance and this messes things up [10:07] alf_: the signal handlers get unistalled due to the signal source cleanup happening in a later test run [10:08] anpok: alf_ - any thoughts on port-window-management-example-to-current-input-API or WindowManager-is-an-EventFilter? (If not I'll TA) [10:10] alan_g: just looking at that .. [10:14] alan_g: Haven't had time to look into them yet, but if you got sufficient feedback, feel free to TA. [10:44] close(mayhem); [11:31] why does _mir_display_is_valid in the mesa patch use dlopen(NULL); to get a handle for dlsym, instead of dlsym(RTLD_DEFAULT) ? === marcusto_ is now known as marcustomlinson [12:10] AlbertA2: do you have a ppa/silo with the qtubuntu/port-to-mirclient and dependent branches? [12:11] i tried compiling them on my own and now i don't get unity8 [12:11] probably a bit too early for him === dandrader is now known as dandrader|afk [12:41] tsdgeos: yeah, in a couple of hours.... i assume you mean this branch [12:41] https://code.launchpad.net/~mir-team/qtubuntu/use-mir-surface-types [12:41] yeah, not even up for review [12:54] greyback: hmm.. are applications expected to only create a single mir_surface? [12:54] mlankhorst: qtmir doesn't support multiple surface apps yet [12:55] I'm working on it [12:55] ahh [12:55] that explains it.. Xmir with -windowed shouldn't have a window created right away === dandrader|afk is now known as dandrader [13:22] huh? [13:22] why do I get mir_pointer_input_event_action_enter on mouse up, and mir_pointer_input_event_action_leave on mouse down? [13:24] oh I misunderstood.. [13:25] it's hover_enter/leave :/ [13:28] how is that a good name? [13:42] kgunn: AlbertA2: no i meant https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164 [14:28] tsdgeos: kgunn: ok I'll address your feedback. I'll get started on a silo with papi/qtubuntu [14:29] AlbertA2: actually i got it running now, i messed up before so there's no immediate need for me to try it === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|lunch [15:45] arg8pah === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === alf__ is now known as alf_ === dandrader|lunch is now known as dandrader === alan_g is now known as alan_g|EOD === seb128_ is now known as seb128 === willcooke_ is now known as willcooke === dandrader is now known as dandrader|afk [20:29] Heyo! Does anyone here know anything about xmir crashing when chromium is launched in vivid? [20:30] still happens? [20:30] is that on desktop or arm? [20:39] mterry: You probably need to install more of the ubuntu-desktop to get it to work, not sure what exactly :/ [20:39] mlankhorst, desktop [20:40] mterry: it was working for me, do you have ubuntu-desktop installed? [20:40] mlankhorst, filed bug 1420959, not sure how helpful [20:40] bug 1420959 in xorg-server (Ubuntu) "xmir crashes when launching chromium" [Undecided,New] https://launchpad.net/bugs/1420959 [20:40] mlankhorst, yes [20:40] oh.. that version [20:41] ln -svf Xmir /usr/bin/Xorg [20:41] ! [20:41] but there's no correct input support so you might need to use old xorg for now [20:42] mlankhorst, I don't have /usr/bin/Xmir [20:42] mlankhorst, I thought xmir didn't need manual intervention like that? [20:43] oh wait I thought you were using my ppa [20:43] there's 2 xmir's, one takes over Xorg, other one is standalone [20:43] brb [20:45] mlankhorst, no not using your ppa, just vivid packages [20:46] mlankhorst, I thought we had this more or less working (we have preview images and such, eh?). So I figured it was just an everyday bug rather than a misconfigured xmir [20:46] mlankhorst, but I'd love to have a workaround if you have suspicions on why the crash happens [20:57] mterry: unity mode is just a workaround :P [20:57] mlankhorst, you mean unity7 in xmir is just a workaround? [20:57] I don't think it was ever particularly useful, just as stopgap until mir gets better [20:58] mlankhorst, sure... but I'd like it as a way to run unity-system-compositor while I test a mir-based lightdm greeter [20:58] ah :P [20:58] mlankhorst, while also running my desktop [20:58] mlankhorst, so for my use case, it'd be lovely [20:58] if you can enable hw cursors in unity-system-compositor.. [20:59] mlankhorst, I just don't like not being able to run chromium... [20:59] mlankhorst, I have a cursor I can see [20:59] you could use Xmir-sa from my ppa [20:59] but it relies on mir to render a cursor [20:59] and it's limited by everything mir supports :P [20:59] mlankhorst, what's the distinction for that package? [21:00] standalone [21:00] it's still part of xserver-xorg-xmir though [21:00] mlankhorst, I guess I don't understand what standalone means in this context [21:01] it's not a module to Xorg, but a full Xserver [21:01] mlankhorst, oh huh [21:01] mlankhorst, is that the future, or an experiment? [21:02] latter, hopefully turning into the former when mir gains more features.. [21:03] right now Xorg+mir works because it doesn't rely on anything from mir except as a means to swap the front buffer [21:04] mlankhorst, well. Do you think it might work well enough for my usecase? [21:05] perhaps [21:06] I don't draw sw cursors in Xmir-standalone right now [21:13] mlankhorst, so I've installed dbg packages to try to get a better stacktrace for that bug / see what's happening. But even with those installed, the backtrace in the logfile is bare-bones. But it doesn't leave anything in /var/crash either. How do I get a core dump from X? === dandrader|afk is now known as dandrader [21:51] mlankhorst, hrm yeah. I tried running a pure Mir session (unity8) and got no cursor [21:52] mlankhorst, presumably if I had a touch screen, it would do something? [21:52] Or maybe input is just busted in Mir right now on the desktop [22:11] mlankhorst, OK, I've decided to just live with no chromium. But I do want to test this hardware cursor. In xmir, I now see two cursors. Do you know how to disable the sw one?