Announcement

Collapse
No announcement yet.

Canonical Posts X.Org, Driver Patches For XMir

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Pajn View Post
    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"

    Comment


    • #32
      Originally posted by Pajn View Post
      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

      Comment


      • #33
        Originally posted by Pajn View Post
        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.

        Comment


        • #34
          Originally posted by TheBlackCat View Post
          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

          Comment


          • #35
            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.

            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).

            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.

            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.

            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.

            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.

            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.

            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.

            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.

            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.

            Comment


            • #36
              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

              Comment


              • #37
                Originally posted by Pajn View Post
                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.

                Comment


                • #38
                  Originally posted by jrch2k8 View Post
                  +#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...

                  Comment


                  • #39
                    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.
                    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.

                    Comment


                    • #40
                      Originally posted by nomadewolf View Post
                      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 ....

                      Comment


                      • #41
                        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.
                        Wayland is for the entire Linux community, 100% progression for Linux. Almost all of the major distros (except Ubuntu) and DE's support Wayland.

                        Mir is for Ubuntu/Unity, fragmentation and reverse progression for Linux. The only ones supporting Mir is Canonical.

                        Comment


                        • #42
                          Originally posted by synaptix View Post
                          Wayland is for the entire Linux community, 100% progression for Linux. Almost all of the major distros (except Ubuntu) and DE's support Wayland.

                          Mir is for Ubuntu/Unity, fragmentation and reverse progression for Linux. The only ones supporting Mir is Canonical.
                          i say we port Unity to Wayland

                          Comment


                          • #43
                            Originally posted by Delgarde View Post
                            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...
                            DDX drivers are very specific to X.org, IIRC, and the other option would be writing drivers from scratch, something I don't think they are capable of right now.
                            That's a concern I have in general with both Wayland and Mir, how will they get 2D acceleration. I don't think glamor is the best approach (this would be the obvious guess, since it uses OpenGL which is exposed by mesa/closed source drivers), since it actually uses 3D operations to emulate 2D, thus wasting 2D capabilities on cards and is actually slower than real 2D in some cases, as when it's compared to SNA for Intel.

                            Originally posted by LinuxGamer View Post
                            i say we port Unity to Wayland
                            I thought about that, but since I don't use it I don't have too much incentive to do so, specially since this implies learning a lot of things I currently know near to nothing about. Maybe the same archers that maintain Unity on Arch will eventually port it to Wayland.

                            Comment


                            • #44
                              Originally posted by mrugiero View Post
                              I thought about that, but since I don't use it I don't have too much incentive to do so, specially since this implies learning a lot of things I currently know near to nothing about. Maybe the same archers that maintain Unity on Arch will eventually port it to Wayland.
                              That would very likely require a complete fork of Unity, diverging from the original - you could be sure that if such a port were to appear, Canonical would break any compatibility between the two just out of spite, and then you'd have to play catch-up to Canonical's upstream changes if you wanted to maintain compatibility - it's the same problem other DE's would face if they'd decide to support Mir.

                              For that matter, I don't know why anyone would want to run Unity - it offers nothing special really, there are no applications that only work on Unity that I know of... and you can pretty much emulate the UI by adding a dock and a custom application launcher to your DE of choice. The only possible reason to want to use Unity would be if you wanted to use the "scopes" - but I don't really see why anyone would want that feature enough to go through all that trouble, as it's not really all that popular feature in the first place.

                              Comment


                              • #45
                                Originally posted by mrugiero View Post
                                I thought about that, but since I don't use it I don't have too much incentive to do so, specially since this implies learning a lot of things I currently know near to nothing about. Maybe the same archers that maintain Unity on Arch will eventually port it to Wayland.
                                its just a recode of Gnome its not that hard to make "Unity" do to 98% of it being Gnome look at what Linux Mint has done using Gnome + we have most of the code base we just need to wait for Gnome to be fully ported to Wayland you don't even need compiz using wayland

                                Comment

                                Working...
                                X