Page 1 of 2 12 LastLast
Results 1 to 10 of 57

Thread: Canonical Posts X.Org, Driver Patches For XMir

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,369

    Default Canonical Posts X.Org, Driver Patches For XMir

    Phoronix: Canonical Posts X.Org, Driver Patches For XMir

    Canonical last week posted 15 patches so Mesa could support their Mir Display Server and specifically the Mir EGL platform. Those patches haven't received many comments from upstream Mesa developers, but there were more than 200 comments in our forums. Over the night, Canonical has posted X.Org Server patches for supporting XMir plus the open-source driver patches so it can handle XMir with nested compositing...

    http://www.phoronix.com/vr.php?view=MTQxNjk

  2. #2
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    Send out your "skeleton" patches then Blame upstream when you Shit Breaks?

  3. #3
    Join Date
    Jul 2013
    Posts
    204

    Default

    Hope the patches get rejected by the Xorg team.

  4. #4
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    Quote Originally Posted by synaptix View Post
    Hope the patches get rejected by the Xorg team.
    i can tell you Love Canonical

  5. #5
    Join Date
    Sep 2010
    Posts
    654

    Default

    Quote Originally Posted by synaptix View Post
    Hope the patches get rejected by the Xorg team.
    X.org team?

    You mean Mesa team, X.org team, and then each FLOSS drivers teams?

    Mesa patches did not recived input as of now.

    But both X.org and FLOSS drivers teams (minux Nouveau, but those where sent only recently) replaied with some CONSTRUCTIVE feedback. And why sholdn't they? Mir is another possible back end for Xorg. FLOSS drivers also do not mind adding another supported platform. Mesa is OS agnostic really (though main effort is Linux)..

    There is also some possible coop effort with Wayland crew on supporting code in all those projects. (Though Christopher Rogers who is behind all that code, stated that shared code will most probably include only minor issues).
    Last edited by przemoli; 07-22-2013 at 11:04 AM.

  6. #6
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by DDF420 View Post
    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.

    Quote Originally Posted by LinuxGamer View Post
    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).

    Quote Originally Posted by kaprikawn View Post
    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.

    Quote Originally Posted by Pajn View Post
    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.

    Quote Originally Posted by przemoli View Post
    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.

    Quote Originally Posted by Pajn View Post
    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.

    Quote Originally Posted by Ericg View Post
    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.

    Quote Originally Posted by dee. View Post
    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.

    Quote Originally Posted by Pajn View Post
    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.

    Quote Originally Posted by LinuxGamer View Post
    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.

  7. #7
    Join Date
    Jun 2009
    Posts
    1,106

    Default

    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

  8. #8
    Join Date
    Oct 2012
    Posts
    136

    Default

    Quote Originally Posted by LinuxGamer View Post
    Send out your "skeleton" patches then Blame upstream when you Shit Breaks?
    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.

  9. #9
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    Quote Originally Posted by DDF420 View Post
    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 don't get how they're saying any thing is "stable" when it's not even Developed....

  10. #10
    Join Date
    Jan 2013
    Posts
    172

    Default

    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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •