Allow XK_Scroll_Lock when LED state isn't supported

Otherwise such clients cannot use Scroll Lock at all, and that is
probably worse than any effects we might get from getting out of sync.

common/rfb/VNCSConnectionST.cxx

   // Avoid lock keys if we don't know the server state
   if ((server->getLEDState() == ledUnknown) &&
       ((keysym == XK_Caps_Lock) ||
-       (keysym == XK_Num_Lock) ||
-       (keysym == XK_Scroll_Lock))) {
+       (keysym == XK_Num_Lock))) {
     vlog.debug("Ignoring lock key (e.g. caps lock)");
     return;
   }
   // Lock key heuristics
   // (only for clients that do not support the LED state extension)
   if (!client.supportsLEDState()) {
-    // Always ignore ScrollLock as we don't have a heuristic
-    // for that
-    if (keysym == XK_Scroll_Lock) {
-      vlog.debug("Ignoring lock key (e.g. caps lock)");
-      return;
-    }
-
     if (down && (server->getLEDState() != ledUnknown)) {
       // CapsLock synchronisation heuristic
       // (this assumes standard interaction between CapsLock the Shift

vncviewer/CConn.cxx

 
   supportsLocalCursor = true;
   supportsDesktopResize = true;
-  supportsLEDState = true;
+  supportsLEDState = false;
 
   if (customCompressLevel)
     setCompressLevel(::compressLevel);