=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [07:30] RAOF, duflu, I was thinking we could hack out the DRI2 and window management stuff from XMir and propose that upstream as a starting point. That seem fair? [07:31] Ah, DRI2 was not *quite* an exact copy of xfree86/dri2? Sadness. (I had forgotten about that). [07:31] That would remove the bits that I see as likely to be contentious. [07:32] RAOF, I spent some time trying to directly link but it was very hard to make the code happy [07:32] Fair chop. [07:32] robert_ancell: Any *hacking* and the code would lose my trust. Hence should not be upstreamed in that form [07:32] It has matured, which says a lot [07:33] duflu, hacking as in chopping out that stuff (you said we only recommend sw anyway). We would then propose DRI support and window management as a second step [07:33] They might take more work to be upstream acceptable [07:33] robert_ancell: The window management is core (and fragile if touched) [07:33] Which is one of the reasons why it's likely to be contentious upstream. [07:33] Also not really broken [07:33] It need not be core. [07:34] If you changed it, I would thoroughly recommend not upstreaming then. It no longer qualifies as mature [07:34] Maturity is roughly irrelevant for upstreaming. [07:35] Indeed, upstream is often *happier* if it's not mature. [07:35] OK. *shrug* [07:35] Because it means that possibly contentious design decisions aren't baked in as hard. [07:35] Can we keep a stable branch somewhere then? [07:35] Absolutely. [07:35] We wouldn't be shipping what's upstream until it's functionally equivalent. [07:36] This is sounding silly actually. Why propose something neither the sender not receiver likes? [07:36] nor receiver [07:37] Because it allows us to work it into a state that both sender and receiver likes. [07:37] If we could not endorse what we're proposing to upstream (and I would not) then why bother? [07:38] It's a starting point [07:38] Because having a base upstream and iterating in upstream is much more likely to happen than us perfecting it and then upstream taking it entirely as-is. [07:38] Some of the most important bits are the window management. We need those (just as soon as Unity8 catches up on features) [07:39] Those bits should really be in an actual window manager component? [07:39] I don't think so. They need to speak native Mir [07:39] That's an entirely solvable problem. [07:39] It works, it's mature. Please don't break it [07:40] Witness, for example, the instructive case of AMD's new GPU driver. They submitted a working, fairly polished driver, and are rewriting it basically from scratch to make it acceptable for upstream. [07:41] We are the only users of Xmir. There's no point proposing something that's only appropriate for some other user base that does not exist [07:42] Except Xmir is intimately bound with other parts of Xorg, and having it upstream means that it needs to be considered when someone wants to make a change that might break it. [07:42] I don't mind the ripping out of DRI2. That needs months/years of work yet anyway. But the WM work represents a lot of effort and maturing already [07:42] Then wouldn't it be a great idea to propose it upstream and see if it's acceptable, so you don't have to rip it out later? [07:43] Essentially I don't mind what anyone does, unless they break what already works for us. So long as the codebase we use does not get broken, it's OK [07:44] Also modified in any way kind of counts as breaking the level of maturity at least :P [07:58] robert_ancell: Also worth noting the WM stuff should not be contentious at all. There is prior art for the same approach to rootless in hw/xwin/ [07:59] Which I often referred to [08:09] is this entry from the wiki still accurate? "Make sure your hardware is supported. That means you're using a Mesa driver" [08:10] (ref: https://unity.ubuntu.com/mir/using_mir_on_pc.html ) [08:10] * duflu looks [08:11] Tak: Yes Mir on desktop still only supports intel/nouveau/radeon right now. Also VMs have some limited support: https://unity.ubuntu.com/mir/setup_kvm_for_mir.html [08:12] Tak: The docs fail to properly explain that Ubuntu already contains the right Mesa code [08:12] :-/ [08:12] Tak: Would love to add more hardware support. What do you need? [08:14] well, I'd be looking for desktop nvidia driver [08:14] Tak: Good news. RAOF is working on that with Nvidia right now [08:14] that is good news [08:14] Also, he just logged off for the week [08:15] hm and the doxygen docs on unity.ubunty.com/mir are still very outdated [08:15] kvm could be an option though [08:15] Tak: Then anpok is your expert [08:17] Tak: just enable qxl/spice in your kvm starup.. or even simpler use the checkboxes in virt-manager [08:17] anpok: Having the host running Nvidia binary driver, will it still work? [08:18] yes [08:18] And the crowd goes wild [08:18] yeah, I'll give it a try following the wiki page duflu posted [08:18] (I hope they release linux 3.18 soon! ;-) ) [08:18] but it will torture your cpu instead .. a bit.. [08:19] yeah .. it is about time.. [08:19] Tak: You laugh, but Android isn't that current yet [08:19] Or ChromeOS [08:19] Sometimes [08:20] btw, what about vmware? [08:21] Tak: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/setup_vmware_for_mir.md [08:22] ah, nice [08:24] virtualbox not yet === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [11:53] hm, no dice with vmware, time to try kvm === alan_g is now known as alan_g|lunch === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader_ is now known as dandrader === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g|lunch is now known as alan_g|EOW === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader