[00:12] <DalekSec> Anything else I can do?
[00:35] <c74d3> What security issues in X's design does Mir fix? (And, are there any security issues in Mir's design?)
[00:44] <tmpRAOF> The way that X clients can do whatever they want to each other, up to and including snoop all keyboard input.
[00:45] <tmpRAOF> There aren't any security issues in Mir's design that we've identified :)
[01:00] <c74d3> Thanks. In Mir, keyboard/mouse/etc. input will... only ever go to the focused window?
[01:01] <duflu> c74d3: No... "focus" refers to things that don't have coordinates (key presses) everything else goes wherever you're pointing
[01:01] <duflu> That said, we haven't implemented everything yet so you might see missing features
[01:02] <c74d3> But a program can't know about a mouse-click unless it's the one whose window is being clicked on?
[01:03] <duflu> 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] <duflu> Grabs allow a window to own the mouse
[01:03] <c74d3> 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] <duflu> tmpRAOF: Perhaps
[01:04] <c74d3> Oh, "grabs" as in "the program grabs the mouse", not "the mouse-pointer grabs something".
[01:04] <duflu> c74d3: Yes
[01:07] <c74d3> Can programs read other programs' output, e.g. for screen-captures (or, on the other side, stealing passwords etc.)?
[01:07] <tmpRAOF> No
[01:08] <tmpRAOF> *: in general.
[01:11]  * duflu is reminded he doesn't know how screencast's security works (or should work)
[01:12] <tmpRAOF> It's shell-mediated
[01:13] <duflu> tmpRAOF: Oh, I hadn't seen that invite from Thomas ;)
[01:13] <tmpRAOF> :(
[01:13] <tmpRAOF> :)
[01:17] <c74d3> "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] <duflu_> tmpRAOF: Did you lose internets last night too?
[01:19] <tmpRAOF> duflu_: I don't think so?
[01:20] <tmpRAOF> 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] <duflu_> 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] <c74d3> "desktop-environment", like KDE? With a file-management GUI, a system-settings GUI, etc.?
[01:22] <duflu_> c74d3: Yes
[01:23] <duflu_> That said, Mir should not discount Wayland. We've got a lot of selling/improving to do to support other shells
[01:24] <c74d3> Mir requires a desktop environment?
[01:25] <c74d3> Does a Mir shell need to include file-management etc. GUIs, or could it merely be equivalent to a X window manager?
[01:26] <DalekSec> duflu_: Oh heya.
[01:26] <tmpRAOF> c74d3: Mir is a library you use to build desktop environments, mostly.
[01:26] <duflu> DalekSec: Hello...
[01:27] <DalekSec> 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] <tmpRAOF> c74d3: In roughly the same way that Wayland is an RPC mechanism + default protocol specification for a display-server-desktop-environment thingy.
[01:28] <c74d3> tmpRAOF: hm, thanks.
[01:31] <duflu> DalekSec: Thanks. I thought I was being a bit optimistic on that one. What chipset/GPU?
[01:31] <DalekSec> http://paste.openstack.org/show/ilFEYLp8qY75dkGm4Px5/
[01:32] <duflu> DalekSec: Hmm i845 is even older than that of the first reporter... :)
[01:33] <duflu> DalekSec: In that case, can you please open a new bug?  https://bugs.launchpad.net/mir/+filebug
[01:34] <DalekSec> Generally looks like the same error...
[01:39] <duflu> 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] <duflu> Bugs are free. Please log them :)
[01:39] <DalekSec> Bah...
[01:40] <DalekSec> duflu: Just to be clear, this is xmir on Xubuntu/Xfce, not "native" mir.
[01:41] <duflu> DalekSec: It's still Mir under XMir. The "native" part isn't really important there...
[01:41] <DalekSec> Mhmm, just figured I'd note. :)
[01:43] <duflu> 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] <DalekSec> Anything besides chip, release, mirver, and error log?
[01:44] <tmpRAOF> unity-system-compositor is absolutely “native Mir”; we're writing a library that should support such things, not just Unity8's QML :)
[01:45] <duflu> DalekSec: Nope, that's enough thanks
[01:45] <DalekSec> lp 1420574
[01:45] <duflu> DalekSec: Ta muchly
[01:46] <DalekSec> duflu: Sure.  I'll stick around too in case you need anything else. :)
[01:46] <DalekSec> Cheers from the Xubuntu team!
[01:47] <duflu> 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] <duflu> (glxinfo | grep OpenGL)
[01:49] <DalekSec> 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] <duflu> 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] <DalekSec> Done.
[01:53] <DalekSec> ...Just as long as I don't have to show FPS. >_>
[01:55] <tmpRAOF> :P
[01:58] <DalekSec> Anywho, I believe that's enough of that for now.  See you another day.
[01:59] <duflu> DalekSec: Thanks. We're eager to make Mir work everywhere
[01:59] <DalekSec> Bit surprised honestly, based on how dated this is.
[02:25] <duflu> DalekSec: Well, it's not a Canonical priority but something I'd like to achieve on a weekend at least
[02:26] <DalekSec> 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] <duflu> DalekSec: Yeah that's a good explanation
[02:28] <duflu> 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] <DalekSec> I'm asking before posting as I'm not on 15.04, though don't believe that'd make a difference.
[02:28] <DalekSec> duflu: Not to be rude, but I never plan to use unity8. :)
[02:28] <duflu> DalekSec: Fair statement. You're not alone and we hope there are other shells
[02:28] <DalekSec> 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] <DalekSec> Anywho, I'll post.
[02:29] <duflu> DalekSec: I like the challenge. The key point is whether introducing Mir alienates any/many existing Ubuntu users. Presently that's "yes"
[02:30] <DalekSec> duflu: Hah!  Awesome. :)
[03:18] <DalekSec> duflu: Oh, and xfwm4's compositor is off in all the 14.10 output. :3
[03:19] <duflu> DalekSec: OK, I don't think that matters. First we need Mir to start, then XMir (or Unity8 or whatever) ...
[03:20] <DalekSec> Yeah, glxinfo isn't different, just might be good to mention.
[03:24] <tmpRAOF> 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] <duflu> tmpRAOF: Yeah fair point and I've been hoping to do so
[03:25] <duflu> Just that a native DRM compositor right now would only support fullscreen
[03:25] <tmpRAOF> Which is fine, because system compositor.
[03:25] <tmpRAOF> In the current state of affairs we don't actually *composite* at any point.
[03:26] <tmpRAOF> We just multiplex.
[03:26] <duflu> 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] <duflu> tmpRAOF: Well, proving server does composite (antialiasing and blending)
[03:27] <duflu> "compose"?
[03:27] <tmpRAOF> Yeah, absolutely. But DalekSec doesn't need proving server to run; they need unity-system-compositor to run :)
[03:27] <duflu> I think the verb is "composite"
[03:28] <duflu> tmpRAOF: Absolutely
[03:28] <duflu> Although both look feasible
[03:29] <duflu> Also, Gerry said he had done the change himself a while back. Not that many changes required to switch to full OpenGL
[03:29] <duflu> The hard part is how to maintain it
[03:30] <tmpRAOF> Oh, I thought you were thinking of switching to non-GL rather than just switching out GLES in favour of GL.
[03:30] <duflu> tmpRAOF: Both eventually
[03:30] <duflu> Support all the things
[04:35] <tmpRAOF> Yay! Benchmarking different locking approaches in add-multiplexing-dispatchable leads to me discovering a bug!
[04:39] <tmpRAOF> Also, cache invalidation :(
[06:24]  * Mirv gets highlighted on "mirver"
[06:28] <DalekSec> Hah, nice.
[07:49] <duflu> Mirv: Sorry, shouldn't happen often
[07:49] <duflu> Good morning BTW
[08:05] <mlankhorst> alf_: ping..
[08:16] <mlankhorst> ah nm I'll just remove the client_lib.h
[08:22] <alf_> mlankhorst: pong
[08:23] <mlankhorst> alf_: http://paste.debian.net/145453/ -- next time test you actually don't need libmirclient-dev please. :P
[08:24] <alf_> mlankhorst: ah, right, sorry for that
[09:24] <anpok> 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] <anpok> 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] <anpok> i will try a different approach there..
[09:34] <duflu> 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] <duflu> Now bisecting
[09:34] <alf_> duflu: interesting
[09:35] <duflu> Hmm, that could be the shadow extents. I think someone added that
[09:35] <alf_> anpok: ENOCONTEXT
[09:48] <anpok> :)
[09:49] <anpok> alf_: i am creating a second glib main loop instance and this messes things up
[10:07] <anpok> alf_: the signal handlers get unistalled due to the signal source cleanup happening in a later test run
[10:08] <alan_g> 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] <anpok> alan_g: just looking at that ..
[10:14] <alf_> alan_g: Haven't had time to look into them yet, but if you got sufficient feedback, feel free to TA.
[10:44] <duflu> close(mayhem);
[11:31] <mlankhorst> why does _mir_display_is_valid in the mesa patch use dlopen(NULL); to get a handle for dlsym, instead of dlsym(RTLD_DEFAULT) ?
[12:10] <tsdgeos> AlbertA2: do you have a ppa/silo with the qtubuntu/port-to-mirclient and dependent branches?
[12:11] <tsdgeos> i tried compiling them on my own and now i don't get unity8
[12:11] <tsdgeos> probably a bit too early for him
[12:41] <kgunn> tsdgeos: yeah, in a couple of hours.... i assume you mean this branch
[12:41] <kgunn> https://code.launchpad.net/~mir-team/qtubuntu/use-mir-surface-types
[12:41] <kgunn> yeah, not even up for review
[12:54] <mlankhorst> greyback: hmm.. are applications expected to only create a single mir_surface?
[12:54] <greyback> mlankhorst: qtmir doesn't support multiple surface apps yet
[12:55] <greyback> I'm working on it
[12:55] <mlankhorst> ahh
[12:55] <mlankhorst> that explains it.. Xmir with -windowed shouldn't have a window created right away
[13:22] <mlankhorst> huh?
[13:22] <mlankhorst> 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] <mlankhorst> oh I misunderstood..
[13:25] <mlankhorst> it's hover_enter/leave :/
[13:28] <mlankhorst> how is that a good name?
[13:42] <tsdgeos> kgunn: AlbertA2: no i meant https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164
[14:28] <AlbertA2> tsdgeos: kgunn: ok I'll address your feedback. I'll get started on a silo with papi/qtubuntu
[14:29] <tsdgeos> AlbertA2: actually i got it running now, i messed up before so there's no immediate need for me to try it
[15:45] <alan_g> arg8pah
[20:29] <mterry> Heyo!  Does anyone here know anything about xmir crashing when chromium is launched in vivid?
[20:30] <mlankhorst> still happens?
[20:30] <mlankhorst> is that on desktop or arm?
[20:39] <mlankhorst> mterry: You probably need to install more of the ubuntu-desktop to get it to work, not sure what exactly :/
[20:39] <mterry> mlankhorst, desktop
[20:40] <mlankhorst> mterry: it was working for me, do you have ubuntu-desktop installed?
[20:40] <mterry> mlankhorst, filed bug 1420959, not sure how helpful
[20:40] <mterry> mlankhorst, yes
[20:40] <mlankhorst> oh.. that version
[20:41] <mlankhorst> ln -svf Xmir /usr/bin/Xorg
[20:41] <mterry> !
[20:41] <mlankhorst> but there's no correct input support so you might need to use old xorg for now
[20:42] <mterry> mlankhorst, I don't have /usr/bin/Xmir
[20:42] <mterry> mlankhorst, I thought xmir didn't need manual intervention like that?
[20:43] <mlankhorst> oh wait I thought you were using my ppa
[20:43] <mlankhorst> there's 2 xmir's, one takes over Xorg, other one is standalone
[20:43] <mlankhorst> brb
[20:45] <mterry> mlankhorst, no not using your ppa, just vivid packages
[20:46] <mterry> 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] <mterry> mlankhorst, but I'd love to have a workaround if you have suspicions on why the crash happens
[20:57] <mlankhorst> mterry: unity mode is just a workaround :P
[20:57] <mterry> mlankhorst, you mean unity7 in xmir is just a workaround?
[20:57] <mlankhorst> I don't think it was ever particularly useful, just as stopgap until mir gets better
[20:58] <mterry> 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] <mlankhorst> ah :P
[20:58] <mterry> mlankhorst, while also running my desktop
[20:58] <mterry> mlankhorst, so for my use case, it'd be lovely
[20:58] <mlankhorst> if you can enable hw cursors in unity-system-compositor..
[20:59] <mterry> mlankhorst, I just don't like not being able to run chromium...
[20:59] <mterry> mlankhorst, I have a cursor I can see
[20:59] <mlankhorst> you could use Xmir-sa from my ppa
[20:59] <mlankhorst> but it relies on mir to render a cursor
[20:59] <mlankhorst> and it's limited by everything mir supports :P
[20:59] <mterry> mlankhorst, what's the distinction for that package?
[21:00] <mlankhorst> standalone
[21:00] <mlankhorst> it's still part of xserver-xorg-xmir though
[21:00] <mterry> mlankhorst, I guess I don't understand what standalone means in this context
[21:01] <mlankhorst> it's not a module to Xorg, but a full Xserver
[21:01] <mterry> mlankhorst, oh huh
[21:01] <mterry> mlankhorst, is that the future, or an experiment?
[21:02] <mlankhorst> latter, hopefully turning into the former when mir gains more features..
[21:03] <mlankhorst> 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] <mterry> mlankhorst, well.  Do you think it might work well enough for my usecase?
[21:05] <mlankhorst> perhaps
[21:06] <mlankhorst> I don't draw sw cursors in Xmir-standalone right now
[21:13] <mterry> 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?
[21:51] <mterry> mlankhorst, hrm yeah.  I tried running a pure Mir session (unity8) and got no cursor
[21:52] <mterry> mlankhorst, presumably if I had a touch screen, it would do something?
[21:52] <mterry> Or maybe input is just busted in Mir right now on the desktop
[22:11] <mterry> 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?