Unfortunately the values for those duplicate keys are not the same and
I'm not sure which ones are more correct. However, for now, I've
commented out the second occurrence.
This data is generated from /usr/include/X11/keysymdef.h using the
utils/u2x11 script.
* Adds the nova-novncproxy binary, to provide support for vnc + OpensStack nova
* Adds the ability to pass an auth token in via url, which is subsequently
passed back to the proxy as a cookie.
May window managers have a keyboard shortcut that switch away from the
current desktop (e.g. desktop switcher). Unfortunately, when this
happens, the meta/control keys that are used with the shortcut will
send a down event to the browser, but the up event will never be sent
because the browser no longer has focus at the point when the up event
happens. This can cause weird stuck key issues for VNC clients (not
just noVNC). To get around this, we try and detect when the browser
loses focus and release any keys that are on the keyDownList.
As an aside, if you run into this situation (in noVNC or another VNC
client), you can unstick the state by pressing and releasing the Ctrl,
Shift, Alt, etc.
Addresses: https://github.com/kanaka/noVNC/pull/135
With last_rect, the rects count can be high until a last_rect
pseudo-encoding is received which messes with the timing stats. So
count up the number of pixels rendered and show timing after the pixel
count reaches the width*height of the screen.
I.e. if the page is https:// then the WebSocket encrypt setting will
default to wss:// (TLS encryption).
Note that since noVNC settings are saved in cookies, this will only
affect first load. If you have already loaded the page, then the
encrypt setting will be whatever you last set it to.
The Jetty WebSocket server code used by the Clojure version of
websockify doesn't support WebSocket and Web at the same path so pass
in a default value for the path so that we can support the Clojure
version websockify.
Conflicts:
include/display.js
include/rfb.js
This merges in the fix for https://github.com/kanaka/noVNC/issues/70
This changes noVNC to use the preferred color ordering that most VNC
server prefer and that VMWare VNC requires. It's possible this may
break some VNC servers out there in which case we might have to do
something a bit more subtle such as having alternate render functions
for little and big endian color ordering.
Issue: https://github.com/kanaka/noVNC/issues/118
Reporter @maxnet also found and suggested the fix.
Probably could be more intelligent/generic by keying off the depth
sent by the server, but this will do for now.
