Intel Haswell Laptop Impact When Running XMir

[mrugiero]

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

Considering the only difference driver-wise is that Mir calls KMS instead of X.org (everything else is just as with plain X.org), is the only explanation I can think of, but yeah, it's pure speculation.

[LinuxGamer]

yeah but you know things happen

"Matthew Garrett
The more I look at the Mir VT switching code, the more I realise that Canonical have no fucking idea what they're doing."

Matthew Garrett is an authority because.... ?

He's a Long Time Kernel Developer?

[ворот93]

He's a Long Time Kernel Developer?

So what? Is he in any way related to writing graphics server?

[LinuxGamer]

So what? Is he in any way related to writing graphics server?

here go Ask him https://twitter.com/mjg59

yeah but you know things happen

"Matthew Garrett
The more I look at the Mir VT switching code, the more I realise that Canonical have no fucking idea what they're doing."

add this Quote too if you want

[ворот93]

here go Ask him https://twitter.com/mjg59



add this Quote too if you want

Do it yourself. The burden of proof is on your side, not mine.

[LinuxGamer]

Do it yourself. The burden of proof is on your side, not mine.

you know what i may have seen him on these forums not to long ago

[LinuxGamer]

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.

so if this is you i quoted you and out came the flame

"Matthew Garrett
The more I look at the Mir VT switching code, the more I realise that Canonical have no fucking idea what they're doing."

Matthew Garrett is an authority because.... ?

i told him you was a Long time Kernel Develop and he replyed

So what? Is he in any way related to writing graphics server?

so is it me or is he saying you don't know what you're talking about?

[AJenbo]

Do it yourself. The burden of proof is on your side, not mine.

If he turns out to be the most prolific linux graphic developer you will probably just disregard it on acount that linux graphic is pants and only 1% uses linux.

[mjg59]

The Mir VT switching code is currently done entirely in Mir. This is wrong, because all other input events are handled by the X server and the X server has expectations that it'll be in charge of VT switching. You can demonstrate this fairly easily by changing the mappings of ctrl+alt+f* under X, for instance by setting ctrl+alt+f2 to XF86_Switch_VT_3. Do this under Xorg and ctlr+alt+f2 will switch you to VT3. Do it in XMir and it'll switch you to VT2.

The problem with XMir in its current form is that it's a piece of software that expects to have direct control of the hardware, and instead it's being run in a lightly abstracted form. This has led to problems like having multiple cursors on the screen (one X cursor and one Mir cursor) - that was solved by simply hiding the Mir cursor. unity-system-compositor still has all the input devices open, it just does nothing with them in an XMir environment. Well, nothing other than listen for ctlr+alt+f*. Which results in a more significant problem. Because Mir changes VT without XMir's knowledge, XMir is still listening to input events. Open an irc client in XMir and join a public channel. Hit ctrl+alt+f1 and log in. Hit ctrl+alt+f7 again and note that your username and password all ended up in IRC.

This can be worked around, of course. And all of these problems will go away once there's a native Mir desktop. But it's still indicative of a completely broken approach to the problem - you have two pieces of software that both think they're in charge of presenting UI to the user, and they're fighting over access as a result. Mir should own the input devices and deliver events to XMir, and XMir should be able to dictate policy to Mir. Instead they both own the input devices and Mir ignores XMir's policy.

But this has nothing to do with the performance impact of XMir on Haswell. As people have pointed out, the performance of full-screen 3D apps should be pretty much identical once support for skipping the compositor is added. Some amount of performance loss in 2D and windowed 3D apps is pretty inevitable, but not enough that most people will care. I don't think it's performance that will decide whether XMir is a success or a failure.

[mrugiero]

But this has nothing to do with the performance impact of XMir on Haswell. As people have pointed out, the performance of full-screen 3D apps should be pretty much identical once support for skipping the compositor is added. Some amount of performance loss in 2D and windowed 3D apps is pretty inevitable, but not enough that most people will care. I don't think it's performance that will decide whether XMir is a success or a failure.

I do notice a considerable slow down on general use with Xubuntu on XMir, compared to direct X.org. Not unusable, but noticeable.