Canonical Posts X.Org, Driver Patches For XMir

[LinuxGamer]

With that logic Wayland is distro specific for Rebecca Black Linux and that is just stupid.


Of course that was what I said (non official).
Rejecting this patches would probably make Mir distro-specific yes, that's why it's so
stupid too do so just because your mad at Canonical. Everyone would gain to atleast
be able to run Mir. Maybe Mir sometimes in the future adds a cool feature that Wayland
doesn't want because the API wouldn't be clean enough or something like that. Then
maybe some users would like to run Mir on another distro.

No one gets hurt if Mir is easily runnable on Fedora or something else.

Wayland is in the Ubuntu Repos Debian Repo's Arch Linux repo's Fedora Repos if i remeber its in the openSUSE repos too and many more
"Maybe Mir sometimes in the future adds a cool feature that Wayland
doesn't"

[jrch2k8]

Everyone would gain to atleast
be able to run Mir. Maybe Mir sometimes in the future adds a cool feature that Wayland
doesn't want because the API wouldn't be clean enough or something like that. Then
maybe some users would like to run Mir on another distro.

that is precisely why per distro user packages repositories like AUR, PPA, EPEL, etc. exists, to not disturb upstream and/or test bleeding edge software.

so if Mir tomorrow have something interesting they will naturally appear in this repositories

[TheBlackCat]

Rejecting this patches would probably make Mir distro-specific yes

It is still distro-specific even with these patches. And it always will be as long as no other distros have any interest in Unity and no other DEs embrace Mir (so far they have all rejected it). It doesn't really matter whether a handful of users on other distros might want to run it, they won't be able to because no other distro will have a DE that can use it.

[LinuxGamer]

It is still distro-specific even with these patches. And it always will be as long as no other distros have any interest in Unity and no other DEs embrace Mir (so far they have all rejected it). It doesn't really matter whether a handful of users on other distros might want to run it, they won't be able to because no other distro will have a DE that can use it.

Also all the patches to Make Unity work are distro specific so they need to send in all the patches
"Embrace, extend, and extinguish" or is it "Embrace, extend, and exterminate" remeber some of them guy's leading development are From MS

[mrugiero]

Yawn
trolls will be trolls

This is missing too much functionality to be usefully appiled, but the
skeleton is here and the APIs it relies on are sufficiently stable. Sending
to the list for extra visibility and for preliminary comments.

I agree with you, except for one thing. It's not to the one committing the patch to say "it's sufficiently stable", because that's what revision is for. One is obviously under the impression one's code is sufficiently stable, else, one doesn't send the patch. So I don't think he has any right to decide it's sufficiently stable right now, by X standards. It's sufficiently stable by his own standards only, until the revision is made.

i don't get how they're saying any thing is "stable" when it's not even Developed....

When you talk about API stability, you mean it isn't supposed to change too much, not that it works correctly (since that's up to the implementation, not to the API itself).

What's the political landscape with Xorg with regards to Mir? Who decides whether these patches are accepted upstream? And are they likely to accept them?

Those aren't even supposed to be accepted, since their author said so. I don't know the answer on who decides, but he stated that's not complete and there's no gain yet on applying the patches. He wants the feedback, and IMO that's the correct way to work with upstream, you ask for feedback first, so you can iron out the details that might not comply with project's standards, and then you send patches that are meant to be applied on the code base.

Why shouldn't they? They accepted patches for Wayland so the only excuse for not accepting this (when they are fully done and polished) would be that they are dickheads but I don't think so.

Wrong. Again, they might not accept distro specific code, so until another distro states interest on Mir, they have the right to reject them without being dicks. This said, if they don't have this policy, yeah, if they meet the standards and the support is complete, they should accept them.

What is not developed?

There are RFC quality patches for gpu drivers and for xorg.

XMir is already usable right now. Mir works on mobile phones. Unity 7 works on XMir...

What is NOT developed?

First things first, 'working' doesn't mean it's well coded. It's working, yes. It's not working right, at least not on my box or LinuxGamer's. On the quality of the code, I didn't read it, so it can actually be quite good and just have some bugs and such, those things happen, I don't know.
The same developer said it's not fully developed. There are missing optimizations, missing, basic features, stuff to be done. It's just RFC right now, and it's OK. But since it's RFC, it's not supposed to be merged, and it's very likely to be 'rejected' (in the case of RFC, 'rejected' actually is the best you can have, because it's feedback on what things you should need to change before you actually commit something merge-able).
As for Mir on mobile phones, I don't know where you got that from, and I'm not aware of that being true (not calling you a liar, but I don't know of any phone running Mir).
Also, a patch to be accepted within a project should comply with the mission of this project, and they might oppose to the idea of running a whole desktop on a legacy compatibility layer. Unity 7 running on XMir means nothing if that's the case.

Mir isn't distro specific. Any distro can use it.
There have been developers interested in running it on Arch for example (not as an official default but in AUR).

But only one uses, that's what distro specific means. Any code could be used (or at least adapted so it can be used) on any distro. The thing is, does any distro aside Ubuntu use it, or said they want to?
I never heard of the things you quote on Arch developers. I heard of Unity running on Arch, but never said any statement on what they will do with Unity 8.
Also, Arch is a bad example, since it has anything but a standard GUI or something like that. For all we care, Arch could use an adapted Haiku GUI if any user is interested in porting it.

Distro-specific doesnt mean other distros CANT use it, it means other distros DONT use it. So until another big name distro steps up and says "We support this too, and we will help with maintenance" its distro-specific. Which seems like a chicken-egg problem, because other distros wont use it until its mainlined and it wont be mainlined until other distros use it, but thats kind of the point: if a project wants to make traction the distros need to step up and proactively show "We like this project! We want it to succeed! We will HELP it succeed!"

I don't think the fact it's mainstream or not affects at all on other distros wanting to use it.

Exactly right. Except, that most of the distros cannot really choose which they support, because they simply choose a desktop environment, and then go by whatever options that DE supports. You could argue that some distros pretty much run the development of certain DE's (eg. RHEL/Fedora = GNOME, Mint = Cinnamon/MATE), but that only applies to a small minority of distros. So first of all, there would need to be support for Mir in some DE that some distro is interested in providing.

So far, the only DE that is interested in offering support for Mir is Unity. Everyone else is going for Wayland. And since no other distro is offering Unity (because it's pretty much a Canonical-only solution, it's very hard if not impossible to even get running in a non-Ubuntu distro), no distro really has any reason to offer Mir at this point, unless they'd want to run a DE on top of XMir which, again, only an idiot would want to do.

That's a bit egg-chicken-ish, since I could argue that's because there wasn't really any choice aside of X. Most distros choose their init system, but they wouldn't if we only had systemd or upstart, etc. One might think Mir is a better solution, and try to use that and then select a desktop that is compatible with it, etc.

With that logic Wayland is distro specific for Rebecca Black Linux and that is just stupid.

Almost, but no. There are testing packages on official repos in several distros, even in Ubuntu. And several distros already said they want to switch.

Rejecting this patches would probably make Mir distro-specific yes, that's why it's so
stupid too do so just because your mad at Canonical.

Yes, it would be stupid to reject just out of spite. However, there might be reasons to reject them, for example, if they don't accept distro specific patches. You could argue against this policy, agree or disagree, but if that policy is there, is a valid reason to reject that isn't 'well, we don't like you, guys'. There are valid reasons not to accept distro specific patches, and there are probably also for accepting them.

Everyone would gain to atleast be able to run Mir.

This possible gain is not for everyone, but for people wanting Mir. Mainstreaming code related to this also compromises people who doesn't. A bug in that part could affect Wayland or X.org users, that's why they might want to have a good reason to accept the patches.

Maybe Mir sometimes in the future adds a cool feature that Wayland doesn't want because
the API wouldn't be clean enough or something like that.

The way you put it makes it sound like this feature could break things, so this should not be accepted.

Then maybe some users would like to run Mir on another distro.

And when users on several distros want it, then it might make sense to include support on mainstream. But before that happens, it's just speculation.
I could make a crappy window manager that breaks things and need X.org patches, and then they should accept my crappy patches because eventually my window manager could be super duper cool?

No one gets hurt if Mir is easily runnable on Fedora or something else.

Well, they actually get hurt if Mir support code on X.org ends up breaking something on Wayland or X.org.

Also all the patches to Make Unity work are distro specific so they need to send in all the patches
"Embrace, extend, and extinguish" or is it "Embrace, extend, and exterminate" remeber some of them guy's leading development are From MS

Programmers coming from MS means nothing, since that policy is something management decides. Programmers just write code for whoever pays, or for fun. Only in the latter case they usually decide what it will be used for.

[jrch2k8]

well reading some of the patches i find them ugly and very error prone to be honest and im not sure if they need thing like this:

Bool radeon_crtc_is_enabled(xf86CrtcPtr crtc)
{
drmmode_crtc_private_ptr drmmode_crtc = crtc->driver_private;
- return drmmode_crtc->dpms_mode == DPMSModeOn;
+ if (drmmode_crtc != NULL)
+ return drmmode_crtc->dpms_mode == DPMSModeOn;
+ else /* We're not in control; bail */ <-- ??
+ return FALSE; <-- mmmm not sure of side effects
}

and using preprocessor seems odd:

+#ifdef XMIR
+#include <xf86Priv.h> <--- especially this one at kms level but i can be wrong
+#include <xmir.h>
+#endif

this is really necessary in KMS code? maybe is smarter query at user level since they are basically querying busid?

radeon_check_mir_support(ScrnInfoPtr pScrn, struct pci_device *pci_dev){...}

dunno maybe an radeon developer would have more insight but after a quick look is seem a bit hackish

[nightmarex]

Of course. This is Linux. And that makes Mir not distro-specific.

Since it won't be in the "official" packages I could argue that it doesn't mean Arch is getting Mir. To each their own I guess.

Arch is what you make it, So it's technically a command prompt distro.

[Delgarde]

+#ifdef XMIR
+#include <xf86Priv.h> <--- especially this one at kms level but i can be wrong
+#include <xmir.h>
+#endif

this is really necessary in KMS code? maybe is smarter query at user level since they are basically querying busid?

I don't get why they need XMir support in individual drivers in the first place. If Xmir is a layer on top of Mir, isn't Mir supposed to do all the hardware stuff? Or is there some kind of handover between Mir's drivers and the corresponding traditional X drivers? And if so, what on earth is Mir actually doing when the desktop is running under Xmir? I'd assumed they were at least exercising some of the hardware-management code paths, but this looks like Xmir is doing most of that stuff still...

[nomadewolf]

Why shouldn't they? They accepted patches for Wayland so the only excuse for not accepting this (when they are fully done and polished) would be that they are dickheads but I don't think so.

The only reason canonical would make it's own display server when there arlready was one that did the job is because they're dickheads... so, i hope the patches never get accepted.

[LinuxGamer]

The only reason canonical would make it's own display server when there arlready was one that did the job is because they're dickheads... so, i hope the patches never get accepted.

100% no Point in Making it not for any thing ohh i may have hacked my way in to getting Xmir working but it looks really bad ....