Originally posted by coder543
View Post
Announcement
Collapse
No announcement yet.
Mark Shuttleworth Declares Mir A Performance Win
Collapse
X
-
-
Originally posted by jrch2k8 View Postwell i actually don't care if you do to be honest but at least i can say you don't understand how XMir works otherwise you won't post that assumption or try to stretch the ball to redhat park that way[especially since redhat is less related to wayland than Intel but still a good supporter and contributer]
conclusion if you don't understand ask nicely but don't go agresivelly assume things out of thin air and expect not to pass as a troll
I suggest you stop assuming that anyone who doesn't attack Mir is a Mir fanboy. I also suggest that you not assume anyone who doesn't attack Wayland is a Wayland fanboy. I have attacked neither, and I am neither. You know just enough to be dangerous, but not enough to know more, based on what I've seen. I don't say this as a fact, because I don't know this, but that's the most I've been able to observe.
Comment
-
Originally posted by coder543 View PostSee. Now I don't trust your knowledge here. Unity8 is the experimental version that runs natively on Mir. Unity7 will be running on XMir. So, I'll wait on someone else to tell me that XMir doesn't use Mir.
second the problem is define "use", i mean XMir uses Mir in a sense but not in another, lets break it a bit
1.) Mir surface manager: yes it is partially used since this handle coordinates, surfaces and up to some point colorspace in the framebuffer
2.) Mir compositor: partially used to compose the output of the XServer, still XServer do the heavy lifting
3.) Mir render process and GPU accel: is not used since the apps render to X11 and Xserver just use server side buffers and pass it to the screen to be composed
4.) EGL or GLSL or effects or any other Mir capable feature is never used since the XServer do the heavy lifting
5.) well some ipc between Mir and Xmir occurs too
so yes pragmatically speaking it uses Mir but it uses it like a simple game would do with SDL, the things you will need for native Mir apps arent even needed in the code to run XMir beside the very basics i mentioned, so Xmir only proves Mir can create surfaces, move them around, read XPixmaps, composite server side buffers and swap frames[mostly apply to Xwayland beside some differences].
See Xmir/Xwayland as a virtualization for graphics or like running Xorg in virtualbox emulating hardware in software but a bit less complicated
Comment
-
Originally posted by Luke_Wolf View PostActually it does show that Red Hat cares, because while Red Hat could have released Fedora 18 with wayland as the default with the GNOME and KDE desktops running natively on Wayland (My understanding is that both are in a state where they can be run but that it's in no way considered ready yet), but it would have given a black mark to wayland and itself as a distro, and so by not going on this before everyone (What everyone is really waiting on is the desktops not wayland) is ready and so as a result are showing that they are listening and that they care. There's no need to have a replay of KDE 4.0-4.2 with Wayland.
Comment
-
Originally posted by F i L View PostMir and Wayland are display servers, meaning they're the API which applications (directly or indirectly through Qt/Gtk) call to receive input, request resolutions, etc.. (sorry if you know this, i'm just being thorough). XMir/XWayland is a X11 extension (or patch or both, idk) which passes on X11 events to a Mir/Wayland and creates a rootless X11 environment housable under Mir/Wayland.
Much of the Mir API useful for applications isn't complete, so with Ubuntu 13.10 Mir has basically three tasks (that i'm aware of): Display management (multiple screens, resolutions, color, etc), OpenGL ES screen presentation (i think it's using OpenGL ES), and Input handling (wrapping up linux udev events). Since Mir in 13.10 is just running a full screen XMir app, I doubt the GLES code will need to be very complicated (basically just buffer swapping) and the input management should be straight forward as well (though i believe this is an area where Mir did not copy Wayland's design. could be wrong). My guess is that most of the work is being put into Display Management right now, and I've heard it's largely a copy of Waylands design.
All the Mir window management stuff is yet to be done in Unity 8, so until that is Ubuntu's default desktop you can't really claim "Mir" is receiving a ton of beta testing where Wayland is not.. especially considering Wayland is actually testing the window management features with Weston (and now Gnome/KDE) whereas Mir is still playing catch-up on the other stuff.
Comment
-
Originally posted by jrch2k8 View Postfirst "for now" [canonical trademark] seems canonical will try to push unity 8 in 13.10[was 14.04 until a week ago and 14.10 before that]
second the problem is define "use", i mean XMir uses Mir in a sense but not in another, lets break it a bit
1.) Mir surface manager: yes it is partially used since this handle coordinates, surfaces and up to some point colorspace in the framebuffer
2.) Mir compositor: partially used to compose the output of the XServer, still XServer do the heavy lifting
3.) Mir render process and GPU accel: is not used since the apps render to X11 and Xserver just use server side buffers and pass it to the screen to be composed
4.) EGL or GLSL or effects or any other Mir capable feature is never used since the XServer do the heavy lifting
5.) well some ipc between Mir and Xmir occurs too
so yes pragmatically speaking it uses Mir but it uses it like a simple game would do with SDL, the things you will need for native Mir apps arent even needed in the code to run XMir beside the very basics i mentioned, so Xmir only proves Mir can create surfaces, move them around, read XPixmaps, composite server side buffers and swap frames[mostly apply to Xwayland beside some differences].
See Xmir/Xwayland as a virtualization for graphics or like running Xorg in virtualbox emulating hardware in software but a bit less complicated
Comment
-
Originally posted by coder543 View PostIt's a little more complicated than SDL, but I take your meaning.
Comment
-
Originally posted by jrch2k8 View Postwell a bit but not much after all SDL do most of this with an abstraction layer to make it easier to code and a compositor can easily be written in GL ES to match the current state of Mir's, the bit would come as emulate input devices and surfaces for X to use <-- codingly speaking
Comment
Comment