DalekSec | Anything else I can do? | 00:12 |
---|---|---|
c74d3 | What security issues in X's design does Mir fix? (And, are there any security issues in Mir's design?) | 00:35 |
tmpRAOF | The way that X clients can do whatever they want to each other, up to and including snoop all keyboard input. | 00:44 |
tmpRAOF | There aren't any security issues in Mir's design that we've identified :) | 00:45 |
c74d3 | Thanks. In Mir, keyboard/mouse/etc. input will... only ever go to the focused window? | 01:00 |
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:01 |
c74d3 | But a program can't know about a mouse-click unless it's the one whose window is being clicked on? | 01:02 |
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:03 |
* 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:04 |
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:07 |
tmpRAOF | *: in general. | 01:08 |
* duflu is reminded he doesn't know how screencast's security works (or should work) | 01:11 | |
tmpRAOF | It's shell-mediated | 01:12 |
duflu | tmpRAOF: Oh, I hadn't seen that invite from Thomas ;) | 01:13 |
tmpRAOF | :( | 01:13 |
tmpRAOF | :) | 01:13 |
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:17 |
duflu_ | tmpRAOF: Did you lose internets last night too? | 01:18 |
tmpRAOF | duflu_: I don't think so? | 01:19 |
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:20 |
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:21 |
c74d3 | "desktop-environment", like KDE? With a file-management GUI, a system-settings GUI, etc.? | 01:22 |
duflu_ | c74d3: Yes | 01:22 |
duflu_ | That said, Mir should not discount Wayland. We've got a lot of selling/improving to do to support other shells | 01:23 |
c74d3 | Mir requires a desktop environment? | 01:24 |
c74d3 | Does a Mir shell need to include file-management etc. GUIs, or could it merely be equivalent to a X window manager? | 01:25 |
DalekSec | duflu_: Oh heya. | 01:26 |
=== duflu_ is now known as duflu | ||
tmpRAOF | c74d3: Mir is a library you use to build desktop environments, mostly. | 01:26 |
duflu | DalekSec: Hello... | 01:26 |
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 |
ubot5 | 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 |
tmpRAOF | c74d3: In roughly the same way that Wayland is an RPC mechanism + default protocol specification for a display-server-desktop-environment thingy. | 01:27 |
c74d3 | tmpRAOF: hm, thanks. | 01:28 |
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:31 |
duflu | DalekSec: Hmm i845 is even older than that of the first reporter... :) | 01:32 |
duflu | DalekSec: In that case, can you please open a new bug? https://bugs.launchpad.net/mir/+filebug | 01:33 |
DalekSec | Generally looks like the same error... | 01:34 |
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:39 |
DalekSec | duflu: Just to be clear, this is xmir on Xubuntu/Xfce, not "native" mir. | 01:40 |
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:41 |
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:43 |
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:44 |
duflu | DalekSec: Nope, that's enough thanks | 01:45 |
DalekSec | lp 1420574 | 01:45 |
ubot5 | 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 |
duflu | DalekSec: Ta muchly | 01:45 |
DalekSec | duflu: Sure. I'll stick around too in case you need anything else. :) | 01:46 |
DalekSec | Cheers from the Xubuntu team! | 01:46 |
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:47 |
duflu | (glxinfo | grep OpenGL) | 01:48 |
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:49 |
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:50 |
DalekSec | Done. | 01:52 |
DalekSec | ...Just as long as I don't have to show FPS. >_> | 01:53 |
tmpRAOF | :P | 01:55 |
DalekSec | Anywho, I believe that's enough of that for now. See you another day. | 01:58 |
duflu | DalekSec: Thanks. We're eager to make Mir work everywhere | 01:59 |
DalekSec | Bit surprised honestly, based on how dated this is. | 01:59 |
duflu | DalekSec: Well, it's not a Canonical priority but something I'd like to achieve on a weekend at least | 02:25 |
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:26 |
duflu | DalekSec: Yeah that's a good explanation | 02:27 |
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:28 |
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:29 |
DalekSec | duflu: Hah! Awesome. :) | 02:30 |
DalekSec | duflu: Oh, and xfwm4's compositor is off in all the 14.10 output. :3 | 03:18 |
duflu | DalekSec: OK, I don't think that matters. First we need Mir to start, then XMir (or Unity8 or whatever) ... | 03:19 |
DalekSec | Yeah, glxinfo isn't different, just might be good to mention. | 03:20 |
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:24 |
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:25 |
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:26 |
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:27 |
duflu | tmpRAOF: Absolutely | 03:28 |
duflu | Although both look feasible | 03:28 |
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:29 |
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 | 03:30 |
tmpRAOF | Yay! Benchmarking different locking approaches in add-multiplexing-dispatchable leads to me discovering a bug! | 04:35 |
tmpRAOF | Also, cache invalidation :( | 04:39 |
=== chihchun_afk is now known as chihchun | ||
* Mirv gets highlighted on "mirver" | 06:24 | |
DalekSec | Hah, nice. | 06:28 |
=== chihchun is now known as chihchun_afk | ||
duflu | Mirv: Sorry, shouldn't happen often | 07:49 |
duflu | Good morning BTW | 07:49 |
mlankhorst | alf_: ping.. | 08:05 |
mlankhorst | ah nm I'll just remove the client_lib.h | 08:16 |
alf_ | mlankhorst: pong | 08:22 |
mlankhorst | alf_: http://paste.debian.net/145453/ -- next time test you actually don't need libmirclient-dev please. :P | 08:23 |
alf_ | mlankhorst: ah, right, sorry for that | 08:24 |
=== chihchun_afk is now known as chihchun | ||
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:24 |
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:29 |
anpok | i will try a different approach there.. | 09:32 |
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:34 |
duflu | Hmm, that could be the shadow extents. I think someone added that | 09:35 |
alf_ | anpok: ENOCONTEXT | 09:35 |
anpok | :) | 09:48 |
anpok | alf_: i am creating a second glib main loop instance and this messes things up | 09:49 |
anpok | alf_: the signal handlers get unistalled due to the signal source cleanup happening in a later test run | 10:07 |
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:08 |
anpok | alan_g: just looking at that .. | 10:10 |
alf_ | alan_g: Haven't had time to look into them yet, but if you got sufficient feedback, feel free to TA. | 10:14 |
duflu | close(mayhem); | 10:44 |
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) ? | 11:31 |
=== marcusto_ is now known as marcustomlinson | ||
tsdgeos | AlbertA2: do you have a ppa/silo with the qtubuntu/port-to-mirclient and dependent branches? | 12:10 |
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:11 |
=== dandrader is now known as dandrader|afk | ||
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:41 |
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:54 |
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 | 12:55 |
=== dandrader|afk is now known as dandrader | ||
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:22 |
mlankhorst | oh I misunderstood.. | 13:24 |
mlankhorst | it's hover_enter/leave :/ | 13:25 |
mlankhorst | how is that a good name? | 13:28 |
tsdgeos | kgunn: AlbertA2: no i meant https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164 | 13:42 |
AlbertA2 | tsdgeos: kgunn: ok I'll address your feedback. I'll get started on a silo with papi/qtubuntu | 14:28 |
tsdgeos | AlbertA2: actually i got it running now, i messed up before so there's no immediate need for me to try it | 14:29 |
=== chihchun is now known as chihchun_afk | ||
=== dandrader is now known as dandrader|lunch | ||
alan_g | arg8pah | 15:45 |
=== 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 | ||
mterry | Heyo! Does anyone here know anything about xmir crashing when chromium is launched in vivid? | 20:29 |
mlankhorst | still happens? | 20:30 |
mlankhorst | is that on desktop or arm? | 20:30 |
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:39 |
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 |
ubot5 | bug 1420959 in xorg-server (Ubuntu) "xmir crashes when launching chromium" [Undecided,New] https://launchpad.net/bugs/1420959 | 20:40 |
mterry | mlankhorst, yes | 20:40 |
mlankhorst | oh.. that version | 20:40 |
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:41 |
mterry | mlankhorst, I don't have /usr/bin/Xmir | 20:42 |
mterry | mlankhorst, I thought xmir didn't need manual intervention like that? | 20:42 |
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:43 |
mterry | mlankhorst, no not using your ppa, just vivid packages | 20:45 |
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:46 |
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:57 |
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:58 |
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? | 20:59 |
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:00 |
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:01 |
mlankhorst | latter, hopefully turning into the former when mir gains more features.. | 21:02 |
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:03 |
mterry | mlankhorst, well. Do you think it might work well enough for my usecase? | 21:04 |
mlankhorst | perhaps | 21:05 |
mlankhorst | I don't draw sw cursors in Xmir-standalone right now | 21:06 |
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:13 |
=== dandrader|afk is now known as dandrader | ||
mterry | mlankhorst, hrm yeah. I tried running a pure Mir session (unity8) and got no cursor | 21:51 |
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 | 21:52 |
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? | 22:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!