When run from within 'ssh -X' or 'ssh -Y', MIT-SHM will appear to be
available even though it won't work: the shared memory will be on the
machine running vncviewer, not on the machine running the X server it
displays to. Depending on what shm segments are available on the
machine running the X server, the failure may not be apparent when
checking that MIT-SHM works.

Avoid this by not using MIT-SHM when XDisplayName() indicates we may
not be running locally.

Original bug report:
  https://bugzilla.redhat.com/show_bug.cgi?id=1072733

Although these are rare, they are still not indicative of bugs so
an exception (which ends up in the log and might also be shown to
the user) is more appropriate than an assert. Asserts should only
be used to catch blatant API misuse and similar.

It was confusing and not properly used everywhere.
Callers should use the stride they get when they get
the buffer pointer.

This allows us to gracefully fall back to the FLTK code in case the
platform specific code cannot be used.

Gets rid of a loooot of code and complexity.

Colour map clients are still supported through an
automatically generated map, but we lose the ability to
develop a client or server that uses colour maps
internally.

the necessary defines will only be visible as a side effect of
including other headers, leading to problems with things like
translations, which will fail in various places. 



git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4646 3789f03b-4d11-0410-bbf8-ca57d06f2519

handler; the shared memory extension is actually this broken so it will return
success all the way through even when you're on a remote connection where
things cannot possibly work.


git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4505 3789f03b-4d11-0410-bbf8-ca57d06f2519

did things.


git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4493 3789f03b-4d11-0410-bbf8-ca57d06f2519