How to dispose of an xkeysPanel? about xkeys HOT 10 CLOSED

@nytamin, while polling is often considered inelegant, it just works. We had a customer who could use no OS services due to the critical nature of their project. By polling we by pass all the timing of OS notifications and sometimes incredibly long time delays. I think in Windows we can get an attach notification after the detach if we plug and unplug rather quickly.

So I think this a good alternative way to manage connections. Being able to set the polling interval is also nice for a slower system.

from xkeys.

@michaelhatPIengineering sure, it was just waiting for some updated documentation. I've merged it now and published the latest version (2.3.0) to npm.

from xkeys.

I think that what you're looking for is the .close() method.

Here's an example that exits gracefully for me when testing locally:

const { XKeysWatcher } = require('xkeys')

const watcher = new XKeysWatcher({
  automaticUnitIdMode: true,
})
watcher.on('connected', (xkeysPanel) => {
  console.log('A panel was connected!')

  // Listen to pressed buttons:
  xkeysPanel.on('down', (keyIndex, metadata) => {
    console.log(`Button ${keyIndex} pressed`)
  })
  xkeysPanel.on('disconnected', () => {
    console.log(`X-keys panel  was disconnected`)
  })
  xkeysPanel.on('error', (...errs) => {
    console.log('X-keys error:', ...errs)
  })
  xkeysPanel.on('reconnected', () => {
    console.log(`Hello again!`)
  })

  setTimeout(() => {
    console.log('lighting up all keys')
    xkeysPanel.setAllBacklights(true)

    setTimeout(() => {
      console.log('turning off all keys')
      xkeysPanel.setAllBacklights(false)

      setTimeout(() => {
        console.log('shutting down')

        // Close the XKeys panel:
        xkeysPanel.close().catch(console.error)
        // Close the watcher:
        watcher.stop().catch(console.error)
      }, 1000)
    }, 1000)
  }, 1000)
})

console.log('Watching for panels...')

from xkeys.

@cwilling I realized that it would be a very small change in the library to allow for usb-detection by polling instead of using the "usb-detection" library.

I made a quick implementation in the PR #57 , could you give it a try and see if it works on your platform(s)?

from xkeys.

I tried #57 and it was perfect with 4 devices. Just before sending congratulations, I thought to try more devices. Unfortunately when I plugged in a 5th device, the same problem returned. Same for 6th device. This is on a 1yr old machine running Linux 5.15.1, so not bleeding edge but fairly up to date. I saw same problem (>3 devices) with earlier tests running Windows.

Although it would work on a Raspberry Pi with only 4 USB sockets, it would presumably be a problem if more devices were added via an external USB hub.

from xkeys.

I think you are hitting a known limitation with node-hid.
It is using the libuv thread pool for reading from hid devices and so is limited to the number of threads in the pool (default is 4).
There is an environment variable you can use to increase this pool size, i cent remember the name right now.

It's on my list of things to make a pr for (I am also concerned about performance implications), but with the variable workaround it's not too urgent to resolve

from xkeys.

I remember seeing some few year old issues to do with polling.

• Some usb devices don't like it and sound cards may audibly glitch
• it might be a blocking operation in node-hid, meaning press events could get delayed if clashing with a poll

That could all be better now, and of course it depends on use case as to whether polling or notifications are more appropriate.
There are known stability issues with the USB detection library too, I think only on Linux. I need to finish up a pr on that..

from xkeys.

Hey thanks @Julusian - great tip!

I found http://docs.libuv.org/en/v1.x/threadpool.html where it gives UV_THREADPOOL_SIZE as the environment variable to increase thread pool size. Sure enough, prepending my test app invocation with UV_THREADPOOL_SIZE=8 (absolute max permitted is 1024) allowed everything to run as expected.

Also, adding:

var { env } = require('process');
env.UV_THREADPOOL_SIZE = 8;

to the test app worked too.

BTW it worked regardless of whether watcher had usePolling set true or false.

from xkeys.

Not working immediately on Raspberry Pi though. More testing ...

sometime later:
it is now working on Raspberry Pi but I had to include #57 which I didn't do at first due to comment above that setting UV_THREADPOOL_SIZE was enough regardless of whether watcher had usePolling set true or false i.e. polling code now seemed unnecessary.

Well it's still true that I can set usePolling to false, or leave it out completely, but (it seems) only if #57 is included and UV_THREADPOOL_SIZE is set to something appropriate.

from xkeys.

I am having some strange issues with the Raspberry PI and @cwilling tells me that the #57 may help. Is there a chance that will be merged soon? It seems we need the larger thread pool and the polling.

from xkeys.