Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 45

Thread: Intel Haswell Laptop Impact When Running XMir

  1. #21
    Join Date
    Mar 2011
    Posts
    374

    Default

    Quote 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?

  2. #22
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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?

  3. #23
    Join Date
    Mar 2013
    Posts
    50

    Default

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

  4. #24
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote 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?

  5. #25
    Join Date
    Jan 2011
    Posts
    1,287

    Default

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

  6. #26
    Join Date
    Apr 2011
    Posts
    114

    Default

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

  7. #27
    Join Date
    Jul 2013
    Location
    USA
    Posts
    715

    Default

    Quote 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" ?

  8. #28
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    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.

  9. #29
    Join Date
    Sep 2011
    Posts
    680

    Default

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

  10. #30
    Join Date
    Apr 2011
    Posts
    114

    Default

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

Posting Permissions

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