XMir hangs in xf86OpenConsole() WAS: Re: Fwd: [Bug 1256116] Re: Documentation instructs to install the package unity-system-compositor, but this is not sufficient for having Mir

[Christopher James Halse Rogers]

On Wed, Apr 9, 2014 at 8:24 PM, Thomas Hellstrom 
<thellstrom at vmware.com> wrote:
> Hi!
> 
> Please see below.
> 
> On 04/09/2014 10:11 AM, Christopher James Halse Rogers wrote:
>>  On Wed, Apr 9, 2014 at 5:44 PM, Thomas Hellstrom
>>  <thellstrom at vmware.com> wrote:
>>>  Hi!
>>> 
>>>  Thanks for the reply.
>>>  I've done a bit of debugging, and this happens because the 
>>> unity-greeter
>>>  tries to create up a pixmap of size (0,0). X  doesn't allow that 
>>> and
>>>  sends an error to unity-greeter that shuts down. Lightdm then 
>>> shuts down
>>>  Mir and XMir and tries to start a new non-XMir X server and that's 
>>> the
>>>  one that hangs. So the hang seems to be a symptom of a bug /
>>>  inconsistency in the lightdm error path.
>>> 
>>>  So why does unity-greeter (actually gtk::screen) think the screen 
>>> is of
>>>  size (0,0)? I tried to dump the gtk <-> Xserver communication and 
>>> it
>>>  appears like gtk queries the crtcs / outputs and gets (0,0) 
>>> answers,
>>>  although X replies the root window is of size 800x600, so I need to
>>>  somehow make XMir respond with the correct modes on crtcs / 
>>> outputs.
>>>  Reading the XMir code it appears like nothing really performs an 
>>> initial
>>>  modeset, although an initial mode configuration is performed.
>>> 
>>>  Is the XMir-enabled DDX driver responsible for calling
>>>  xf86SetDesiredModes(), and in that case, where is a suitable place 
>>> for
>>>  the driver to do that?
>> 
>>  Yeah, we currently expect XMir-enabled DDXen to call
>>  xf86SetDesiredModes themselves, at the same point as they'd normally
>>  call call it (and after xmir_mode_pre_init()).
>> 
>>  We could do it in the XMir module itself, but I was leary of side
>>  effects the DDXen weren't expecting
> 
> OK. That made XMir work again.

Yay!

> 
> Is this a new requirement or was that present also with Ubuntu 13.10?

This was also present with 13.10, I think; it's been there since the 
start of multihead support.

> 
> In any case, while window movement and 3D looks as snappy as in 13.10
> there is a 0.5 second or so latency when I type text in
> terminal windows. Very annoying. Is that a known problem? I'll try to
> find out whether this delay happens in XMir or in Mir.

Urgh. I thought we had some automated tests for that! You're probably 
seeing https://bugs.launchpad.net/mir/+bug/1295851 ; likely what's 
happening is that Mir is compositing the second-to-last frame again, 
rather than the most recent frame you've submitted.