=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === duflu_ is now known as duflu === chihchun_afk is now known as chihchun [07:23] mlankhorst: Can (or have you already?) document how to try the new rootless XMir? [07:24] I forget everything I learned from the old xmir [07:24] It was so long ago [07:56] that's fine, it's just a mir application :P [07:56] just add -windowed to it [07:56] but it doesn't work well yet [08:06] or was it -rootless [08:18] mlankhorst: Weird. Why do I not see libxmir.so linking to GL-anything? [08:18] It looks like the old version [08:19] duflu: /usr/bin/Xmir.. [08:19] mlankhorst: Not packaged yet then? :) [08:19] ppa:mlankhorst/ppa [08:19] Ah [08:19] still crazy experimental at this point :P [08:20] Kay [08:20] especially windowed mode, until I can control positioning there's not much point to windowed mode since menu's won't work right [08:20] Hmm, I crashed USC. I should log/debug that [08:21] Xmir supports DRI2 (OpenGL) if mesa drivers are found, else it falls back to native EGL [08:21] mlankhorst: Have you looked at Alberto's new API for that? [08:21] not yet [08:22] mlankhorst: BTW I saw Trevinho running the rootless version. It had Composite loaded too. Should probably disable that [08:22] Composite+compiz [08:23] oh that's not rootless [08:23] Xmir can run in a window too, and you can load compiz inside it [08:23] OK [08:24] rootless mode gives each window its own mir window, but that doesn't work right yet [08:24] mlankhorst: OK, looking forward to future Xmir === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:59] mlankhorst: I just realised your menus problem isn't yet solveable (unless you have a mini-compositor in your XMir to avoid creating child surfaces :) ... https://bugs.launchpad.net/mir/+bug/1421572 [08:59] Launchpad bug 1421572 in Mir "[enhancement] Missing a generic API for child surface placement" [High,Triaged] [09:55] duflu: yeah thought so, so I didn't bother yet === marcusto_ is now known as marcustomlinson === dandrader is now known as dandrader|afk [12:26] alf_: I've not tracked through the dependencies yet but was just looking at what happens when a shell wants to reconfigure the display. For reasons that are probably inadequate it first stops the compositor, then applies its changes and then restarts the compositor. But the compositor indirectly depends on the shell (i.e. there's a mutual dependency). Shouldn't the compositor simply be listening to display config changes an [12:26] d handle them for itself? [12:33] alan_g: The idea was to serialize such reconfigurations in the main loop. Note that we need to stop the compositor because otherwise one of its threads may end up accessing display HW resources that we have reconfigured and cause problems/crashes. [12:35] alf_: Hmm. That's not what's happening of course. And the way it is - Display::configure(*conf) could notify listeners "change is happening"..."change is done" [12:36] And the compositor can stop & start accordingly [12:37] me::WindowManager (for example) doesn't use the main loop for config changes [12:37] * alan_g doubts me::WindowManager is a good example of anything though [12:41] alan_g: Ideally we would use the MediatingDisplayChanger (through a new interface suitable for the shell's needs) [12:43] I was just wondering about that (need to check the dependency graph though as depending on MediatingDisplayChanger which depends on Compositor doesn't avoid the loop I started with. [12:43] ) [12:47] alan_g: Yes, there are two orthogonal aspects here: the dependency loop which you want to break, and ensuring we go through the main loop [12:48] alf_: OK I've got enough to think about. Thanks. (I feel the design process starting) === dandrader|afk is now known as dandrader === alan_g is now known as alan_g|lunch === chihchun is now known as chihchun_afk === alan_g|lunch is now known as alan_g [14:05] racarr: did you see my last comment on https://code.launchpad.net/~mir-team/qtubuntu/port-to-mirclient/+merge/245164 ? [14:34] Hello [14:34] can I use Virtualbox with the unity next iso? [14:34] if not, can I use my gtx 860m notebook directly from boot (nouveau supports it) [14:42] berz3rk: not yet.. but vmware and kvm work [14:42] ok good [14:42] i try vmware [14:42] vbox has an out of source driver .. it needs a few bits [14:48] alan_g: when I boot vmware, I dont get any graphical user interface [14:49] anpok... [14:49] failed to create login service or something like that in systemd, but now i just see a white mouse cursor .. [14:50] berz3rk: these are the instructions I used once to test unity8 in VMWare: http://pastebin.ubuntu.com/10205619/ [14:52] i confirm those instructions worked for me too...(however i'm on intel gfx) [14:52] me too [15:08] kgunn: I should add these instruction to our official documentation [15:14] alf_: yes, please...seems like a good idea === dandrader is now known as dandrader|lunch === dandrader|lunch is now known as dandrader === ChickenCutlass is now known as ChickenCutlass_a === ChickenCutlass_a is now known as ChickenCutlass === ChickenCutlass is now known as ChickenCutlass_a === alan_g is now known as alan_g|EOW