compiz team mailing list archive

[Phil Wieland <phil@xxxxxxxxxxxxxxx>]

Nothing.  Just delete that file if it exists before remotely logging in.
If you are at a remote location, you can ssh into the machine to do
this.

As I understand it, the reason is this:

Every time you log in, from a remote computer or on the local console, a
test is performed to decide whether the display can support certain
features of Unity.  This test takes a few seconds, so someone decided to
record the result by creating a file in /tmp, so that next time you log
in it doesn't need to perform the test.  So what happens is, you boot up
your brand new installation for the first time and log in to the local
console, the test runs and the result is recorded by creating
/tmp/unity_support_test.0  Now, every time you log in unity assumes you
have the features of a local console.  You install xrdp or nx or
whatever and then try a remote login.  The functionality available is
different and unity needs to fall back to a simpler version but it sees
the file in /tmp and doesn't test so it tries to run as though you were
a local console, and fails.

If you have deleted the file, then when you remotely log in the test
will be performed and unity will see the different feature set and act
appropriately.  It will then create /tmp/unity_support_test.1 which
means that if you later log in to the local console you won't get the
right result, but remote logins will work OK.

Just to be clear, this workaround is for bug 889996.  I believe 833729
is fixed.

I use nx nomachine to log in to my desk PC here at home from a windows
machine at work successfully on a daily basis, so it does work.

-- 
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/833729

Title:
  compiz crashed with SIGSEGV in CompositeScreen::compositingActive()

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz-core/+bug/833729/+subscriptions