| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| 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:30 |
|---|---|---|
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| duflu | This is sounding silly actually. Why propose something neither the sender not receiver likes? | 07:36 |
| duflu | nor receiver | 07:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| duflu | Also modified in any way kind of counts as breaking the level of maturity at least :P | 07:44 |
| 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:58 |
| duflu | Which I often referred to | 07:59 |
| Tak | is this entry from the wiki still accurate? "Make sure your hardware is supported. That means you're using a Mesa driver" | 08:09 |
| Tak | (ref: https://unity.ubuntu.com/mir/using_mir_on_pc.html ) | 08:10 |
| * duflu looks | 08:10 | |
| 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:11 |
| 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:12 |
| 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:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| 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:19 |
| Tak | btw, what about vmware? | 08:20 |
| duflu | Tak: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/setup_vmware_for_mir.md | 08:21 |
| Tak | ah, nice | 08:22 |
| anpok | virtualbox not yet | 08:24 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| Tak | hm, no dice with vmware, time to try kvm | 11:53 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!