Skip to content
This repository has been archived by the owner on Jun 27, 2022. It is now read-only.

Only poll USB devices list when a change is detected #191

Merged
merged 17 commits into from
Jul 31, 2018

Conversation

MortalKastor
Copy link
Contributor

No description provided.

Copy link
Contributor

@gre gre left a 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) => {
Copy link
Contributor

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 => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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

Copy link
Contributor

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);
Copy link
Contributor

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 ? 😢

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🆗


lastDevices = currentDevices;
setTimeout(() => {
Copy link
Contributor

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);
Copy link
Contributor

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 🤔

Copy link
Contributor Author

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 🤔

@MortalKastor MortalKastor requested a review from gre July 25, 2018 16:02
Copy link
Contributor

@gre gre left a 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",
Copy link
Contributor

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 => {
Copy link
Contributor

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);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🆗

@gre
Copy link
Contributor

gre commented Jul 25, 2018

approach i suggest to take:

  • let's do a beta release from this branch (before merge) – see the main README on how to do
  • we stress test it directly on ledger live (on 3 OS s, multiple devices, using a non dev build too)
  • if all is fine, we can merge

@MortalKastor MortalKastor added the HODL Don't merge! label Jul 26, 2018
@MortalKastor MortalKastor self-assigned this Jul 26, 2018
@gre
Copy link
Contributor

gre commented Jul 26, 2018

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) &&
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link

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?

Copy link
Contributor Author

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.

Copy link

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!

Copy link
Contributor

@gre gre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@gre
Copy link
Contributor

gre commented Jul 30, 2018

let's all test together one more time on Linux, Windows and Mac and in Production build mode

@gre
Copy link
Contributor

gre commented Jul 31, 2018

let's rename setListenDevicesPollingInterval to setListenDevicesDebounce

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants