-
Notifications
You must be signed in to change notification settings - Fork 378
Only poll USB devices list when a change is detected #191
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good workaround for now. I wish we could find a clean native solution that have everything out of the box.
not sure if all my comments make sense. this is for sure a tricky topic, and also that will need to test intensively, with multiple devices and on all OSs
@@ -68,6 +69,10 @@ export default class TransportNodeHid extends Transport<string> { | |||
listenDevicesPollingSkip = conditionToSkip; | |||
}; | |||
|
|||
static setListenDevicesDebugMode = (bool: boolean) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be better if we would allow to set a log function instead. I moved to this paradigm in ledgerjs recently too, because on Ledger Live we use a custom logger, which is not console.*
usbDetect.startMonitoring(); | ||
|
||
// Detect add | ||
usbDetect.on(`add:${VENDOR_ID}`, device => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we should filter like it was here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a pre-filter, taking advantage of the vendor ID filtering offered by usb-detection
, our isLedgerDevice
is used by getDevices
afterwards
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌
|
||
// Detect add | ||
usbDetect.on(`add:${VENDOR_ID}`, device => { | ||
debug("Device add detected:", device.deviceName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and this device don't have the path ? 😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it doesn't 😭 MadLittleMods/node-usb-detection#19
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🆗
|
||
lastDevices = currentDevices; | ||
setTimeout(() => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this timeout does not get cleared if the whole listen is stop()-ed
|
||
lastDevices = currentDevices; | ||
setTimeout(() => { | ||
poll(type); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have to poll multiple times because event happen too soon? Is it always the case, if so it would be great to estimate a minimal time and do an initial timeout to likely never have to poll twice. 🤔
I think it would maybe preferable to refactor things using lodash debounce
. each time there are remove/add events you just "push to 50ms later" the re-poll() , and the else case also is about triggering a poll().
e.g.
poll = debounce(() => { }, delay)
not sure what delay will be , if it make sense to be the same 1s that was before 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have to poll multiple times because event happen too soon?
From my tests I have to poll a second time (after 500ms) only for device removal on macOS and Windows, but I have no idea how much this behavior is consistent from machine to machine 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lil detail but rest LGTM! we'll give some try asap
@@ -26,7 +26,9 @@ | |||
"license": "Apache-2.0", | |||
"dependencies": { | |||
"@ledgerhq/hw-transport": "^4.19.0", | |||
"node-hid": "^0.7.2" | |||
"lodash.debounce": "^4.0.8", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's a lil detail, but I would prefer we depend on lodash
and doing import debounce from "lodash/debounce"
, like on live
usbDetect.startMonitoring(); | ||
|
||
// Detect add | ||
usbDetect.on(`add:${VENDOR_ID}`, device => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👌
|
||
// Detect add | ||
usbDetect.on(`add:${VENDOR_ID}`, device => { | ||
debug("Device add detected:", device.deviceName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🆗
approach i suggest to take:
|
if usb appears to be a pain to setup for windows, i suggest we go back to usb-detect, but manually manage the global event listening. for now, we could just listen always, because in LL we do this anwyay. just need to emit the events in some event emitter maybe, so each listen() can independently be created and unsubscribed. |
export default d => | ||
(["win32", "darwin"].includes(process.platform) | ||
? d.usagePage === 0xffa0 | ||
: d.interface === 0) && |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ this wasn't a problem on linux? to filter the potential multi devices?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My bad.
I restored the filtering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My usagePage
is 0xf1d0
, which means that devices aren't returned by that function. Is that normal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0xF1D0
is specific to FIDO (👀) U2F which is, indeed, purposefully filtered out so we don't list devices with the U2F
app open, or a currency app with Browser Support
set to on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, so I need to disable browser support when using hw-transport-node-hid
, I see! Sorry, the documentation is a bit scarce and I'm a newbie 😉. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
let's all test together one more time on Linux, Windows and Mac and in Production build mode |
let's rename |
No description provided.