| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| jsgrant__ | Besides familarity, is there any real advantages with using a "display server" or a compositor? | 01:46 |
|---|---|---|
| === chihchun is now known as chihchun_afk | ||
| duflu | jsgrant__, you are free to use a text console.... but most people prefer a graphical interface which involves a display server and compositing. Which component does the compositing is not relevant to users | 01:48 |
| jsgrant__ | Oh! Sorry, I meant "over a compositor". | 01:49 |
| duflu | jsgrant__, it's not a choice of one or the other. All desktops contain both | 01:49 |
| duflu | It's better to think of it as all desktops involve a display server, and "compositing" is something that some part of the desktop does. Don't think of "compositor" as a component | 01:50 |
| jsgrant__ | duflu: Are we talking about compistor in the same sense, I'm wondering; I mean a'la a Wayland implementation of/on a client or the like. | 01:51 |
| duflu | jsgrant__, yes we are but your question only makes sense in a Wayland world. In Wayland you build a compositor as a component. In other desktops compositing already exists and is done by some existing part of the system | 01:52 |
| duflu | So there is no answer to the question if the question isn't relevant to other systems | 01:53 |
| jsgrant__ | duflu: Is there some overview somewhere of the actual architectural diffrences between the two systems/methods, that you know of? Looked around & can't find anything. | 01:53 |
| duflu | jsgrant__, let me check... | 01:54 |
| jsgrant__ | I've seen "Wayland is nicer than Xorg, because xorg is bloated" arguments -- that's about it. | 01:54 |
| jsgrant__ | duflu: If you don't know any offhand, don't let me assign you hw; Just find it curious I really can't find any in-depth comparissions. | 01:56 |
| duflu | jsgrant__, Yes I found a useful page (http://wiki.ubuntu.com/MirSpec). Confusingly it refers to compositor and shell as the same thing. That's true but only true for Mir :) | 01:56 |
| jsgrant__ | Maybe my searchfu is just poori.] | 01:56 |
| jsgrant__ | Will certainly look into page (notice now it's in the topic) & will look further; Have a feeling it must be out there more-so than I've been able to find thusfar, maybe just being drowned out by Wayland hype-pieces. | 01:58 |
| jsgrant__ | duflu: Ty. | 01:58 |
| duflu | I know people like to draw architectural diagrams where "compositor" or "window manager" are labelled boxes. However those only make sense in certain contexts. Specifically, having a separate "compositor" component is only really true for Wayland and Xorg. And having a separate "window manager" is only really true for Xorg (where it typically is also the compositor). But neither of those are true for Mir. You might have a Mir server which | 02:12 |
| duflu | does both compositing and window management, but those are not themselves separate components you need to build or reinvent. This is one way in which Mir tries to be different | 02:12 |
| jsgrant__ | Are there any alternative "window manager" environment you're aware of for Mir, that I can take a look at? Again if you aren't aware, don't have me give you hw. | 02:18 |
| jsgrant__ | "window manager"-like* | 02:19 |
| jsgrant__ | Sans Unity of course. | 02:19 |
| jsgrant__ | Just found, https://insights.ubuntu.com/2016/11/28/mir-is-not-only-about-unity8/ -- which kinda orbits this. | 02:21 |
| duflu | jsgrant__, yes the 'mir-demos' package contains 'mir_proving_server' and the 'miral-examples' package contains 'miral-shell' | 02:22 |
| duflu | Although none were ever really nice and ready for general use | 02:23 |
| * jsgrant__ wonders if it's worth the effort to try to run on Fedora or just spin up an Ubuntu VM. :^P | 02:23 | |
| jsgrant__ | Will probably end up doing both. Have spare box already running a minimal F25 install. | 02:24 |
| duflu | Mir by itself will run perfectly smoothly even on an original Atom from 2008. It's only Unity8 that had less backward-compatibility/performance | 02:25 |
| duflu | And actually Mir's backward compatibility is only limited by Mesa. Mesa chose to drop compatibility for older chips, so Mir (and others) can't go back that far | 02:27 |
| duflu | It's only Mesa dictating that limitation | 02:27 |
| duflu | *"so Mir (and others) can't go back much further than 2008 for Intel chips" | 02:29 |
| jsgrant__ | Have boxes about that old, but not in active rotation; Shouldn't be a problem then -- neat! :^) | 02:34 |
| Son_Goku | hey | 07:41 |
| Son_Goku | morning all | 07:41 |
| Son_Goku | tvoss: hey | 07:41 |
| === chihchun_afk is now known as chihchun | ||
| === JanC_ is now known as JanC | ||
| Son_Goku | alan_g: so apparently mir can't find capnproto on Fedora :/ | 12:43 |
| Son_Goku | because Debian changed how the capnproto cmake stuff looks compared to upstream | 12:44 |
| Son_Goku | well, and upstream doesn't install it when using autotools (which is what they recommend for Linux) | 12:44 |
| Son_Goku | and there's the fun bigger problem that capnproto isn't building on GCC7 :( | 12:44 |
| === chihchun is now known as chihchun_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!