Announcement

Collapse
No announcement yet.

Intel Haswell Laptop Impact When Running XMir

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

  • #21
    Originally posted by Siekacz View Post
    With Xmir Xorg has nothing to do with hardware. Of course it still is there, but it in a "safe cage" - won't mess up everything anymore.
    When it has nothing to do with hardware, why does it need root rights?

    Comment


    • #22
      Originally posted by Siekacz View Post
      Well, I'm a Mir user right now, because of one reason. Xorg developers seemingly have no idea how to make suspend working. Every kernel and Xorg update is a russian roulette - suspend sometimes work, sometimes not. When I switch to Mir everything runs just fine. Now I'm waiting for the next week's release - unredirect fullscreen windows and multimonitor support will be on place. Then I'll say goodbye to crappy XServer, which messed up everything for years. Of course I will be using Xmir, but X won't have anything to mess up with hardware. That's something I like. Waiting for Unity 8...

      PS. I have Sandy Bridge laptop so it's a SHAME not to have really working suspend since 2011.
      AFAIK, suspension is kind of a drivers issue. And drivers are the same for Mir than for X.org. Do suspension work for you with XMir?

      Comment


      • #23
        Originally posted by mrugiero View Post
        AFAIK, suspension is kind of a drivers issue. And drivers are the same for Mir than for X.org. Do suspension work for you with XMir?
        Yup. With XMir it works flawlessly, when I switch back to X, during wake-up Xorg crashes (not kernel, Xorg).

        Comment


        • #24
          Originally posted by Siekacz View Post
          Yup. With XMir it works flawlessly, when I switch back to X, during wake-up Xorg crashes (not kernel, Xorg).
          I'll check what happens on my radeon, but did you report the bug?

          Comment


          • #25
            Originally posted by mrugiero View Post
            I'll check what happens on my radeon, but did you report the bug?
            My case is it works in both cases. So I confirm it seems to be intel specific. Doesn't sound as X's fault.

            Comment


            • #26
              Originally posted by Siekacz View Post
              With Xmir Xorg has nothing to do with hardware. Of course it still is there, but it in a "safe cage" - won't mess up everything anymore.
              No, Xmir has exactly as much access to hardware as Xorg does. All rendering is still carried out by the xorg drivers.

              Comment


              • #27
                Originally posted by Siekacz View Post
                Yup. With XMir it works flawlessly, when I switch back to X, during wake-up Xorg crashes (not kernel, Xorg).
                Let me Guess you also use TOP to "suggests that both Xorg and Compiz are using less memory and fewer CPU cycles under Mir than they were with X handling the hardware directly" ?

                Comment


                • #28
                  I saw a bug report blaming a race condition between upower and resume (I assume the latter is an X dependent function?). Maybe XMir is only delaying one of them enough to avoid it (because of the extra overhead caused by the extra layer), and thus palliating the effects of such race condition. If that's the case, a slight modification in such code to wait some time should have the same effect.

                  Comment


                  • #29
                    Originally posted by mrugiero View Post
                    I saw a bug report blaming a race condition between upower and resume (I assume the latter is an X dependent function?). Maybe XMir is only delaying one of them enough to avoid it (because of the extra overhead caused by the extra layer), and thus palliating the effects of such race condition. If that's the case, a slight modification in such code to wait some time should have the same effect.
                    It cold be that, or it could be that the abstraction solves the issue, or somthing compleatly differently, it just pure speculation at this point...

                    Comment


                    • #30
                      Originally posted by AJenbo View Post
                      It cold be that, or it could be that the abstraction solves the issue, or somthing compleatly differently, it just pure speculation at this point...
                      The only abstraction is that XMir may not be aware of the VT switch around suspend/resume. But in that case that's a bug in XMir - being unaware of the VT switch results in input events continuing to be delivered to the X session even when you're on another VT.

                      Comment

                      Working...
                      X