[07:30] <robert_ancell> 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] <RAOF> Ah, DRI2 was not *quite* an exact copy of xfree86/dri2? Sadness. (I had forgotten about that).
[07:31] <RAOF> That would remove the bits that I see as likely to be contentious.
[07:32] <robert_ancell> RAOF, I spent some time trying to directly link but it was very hard to make the code happy
[07:32] <RAOF> Fair chop.
[07:32] <duflu> robert_ancell: Any *hacking* and the code would lose my trust. Hence should not be upstreamed in that form
[07:32] <duflu> It has matured, which says a lot
[07:33] <robert_ancell> 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] <robert_ancell> They might take more work to be upstream acceptable
[07:33] <duflu> robert_ancell: The window management is core (and fragile if touched)
[07:33] <RAOF> Which is one of the reasons why it's likely to be contentious upstream.
[07:33] <duflu> Also not really broken
[07:33] <RAOF> It need not be core.
[07:34] <duflu> If you changed it, I would thoroughly recommend not upstreaming then. It no longer qualifies as mature
[07:34] <RAOF> Maturity is roughly irrelevant for upstreaming.
[07:35] <RAOF> Indeed, upstream is often *happier* if it's not mature.
[07:35] <duflu> OK. *shrug*
[07:35] <RAOF> Because it means that possibly contentious design decisions aren't baked in as hard.
[07:35] <duflu> Can we keep a stable branch somewhere then?
[07:35] <RAOF> Absolutely.
[07:35] <RAOF> We wouldn't be shipping what's upstream until it's functionally equivalent.
[07:36] <duflu> This is sounding silly actually. Why propose something neither the sender not receiver likes?
[07:36] <duflu> nor receiver
[07:37] <RAOF> Because it allows us to work it into a state that both sender and receiver likes.
[07:37] <duflu> If we could not endorse what we're proposing to upstream (and I would not) then why bother?
[07:38] <robert_ancell> It's a starting point
[07:38] <RAOF> 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] <duflu> Some of the most important bits are the window management. We need those (just as soon as Unity8 catches up on features)
[07:39] <RAOF> Those bits should really be in an actual window manager component?
[07:39] <duflu> I don't think so. They need to speak native Mir
[07:39] <RAOF> That's an entirely solvable problem.
[07:39] <duflu> It works, it's mature. Please don't break it
[07:40] <RAOF> 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] <duflu> 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] <RAOF> 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] <duflu> 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] <RAOF> 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] <duflu> 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] <duflu> Also modified in any way kind of counts as breaking the level of maturity at least :P
[07:58] <duflu> 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] <duflu> Which I often referred to
[08:09] <Tak> is this entry from the wiki still accurate? "Make sure your hardware is supported. That means you're using a Mesa driver"
[08:10] <Tak> (ref: https://unity.ubuntu.com/mir/using_mir_on_pc.html )
[08:10]  * duflu looks
[08:11] <duflu> 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] <duflu> Tak: The docs fail to properly explain that Ubuntu already contains the right Mesa code
[08:12] <Tak> :-/
[08:12] <duflu> Tak: Would love to add more hardware support. What do you need?
[08:14] <Tak> well, I'd be looking for desktop nvidia driver
[08:14] <duflu> Tak: Good news. RAOF is working on that with Nvidia right now
[08:14] <Tak> that is good news
[08:14] <duflu> Also, he just logged off for the week
[08:15] <anpok> hm and the doxygen docs on unity.ubunty.com/mir are still very outdated
[08:15] <Tak> kvm could be an option though
[08:15] <duflu> Tak: Then anpok is your expert
[08:17] <anpok> Tak: just enable qxl/spice in your kvm starup.. or even simpler use the checkboxes in virt-manager
[08:17] <duflu> anpok: Having the host running Nvidia binary driver, will it still work?
[08:18] <anpok> yes
[08:18] <duflu> And the crowd goes wild
[08:18] <Tak> yeah, I'll give it a try following the wiki page duflu posted
[08:18] <Tak> (I hope they release linux 3.18 soon! ;-) )
[08:18] <anpok> but it will torture your cpu instead .. a bit..
[08:19] <anpok> yeah .. it is about time..
[08:19] <duflu> Tak: You laugh, but Android isn't that current yet
[08:19] <duflu> Or ChromeOS
[08:19] <duflu> Sometimes
[08:20] <Tak> btw, what about vmware?
[08:21] <duflu> Tak: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/setup_vmware_for_mir.md
[08:22] <Tak> ah, nice
[08:24] <anpok> virtualbox not yet
[11:53] <Tak> hm, no dice with vmware, time to try kvm