Discussion: Major updates to the library about xkeys HOT 16 CLOSED

from xkeys.

Reading this thread makes me a happy user.
It's good to see the manufacturer of the device and the developer of the node.js module working together.

Getting to use a UID as you described is a nice upgrade, looking forward to be able to use is.
Luckily using 2 different x-keys at the moment (xke-124 t-bar and xk-80) but looking at possible expansion in the future. And getting to identify the devices based on a variable from the x-keys device would be very nice.

from xkeys.

Glad to see someone who has more insider knowledge on the devices who can contribute in some way. I haven't used this library in a while, mainly because my organisation isn't doing on-site events right now (for obvious reason) but we will use it again as soon as we actually can.

from xkeys.

Hi Michael!
Thanks for reaching out, your help will be much appreciated!

Let's get in touch, I would love for us to have a chat, talk about the quirks of Node and Typescript and make a plan for implementation.
You can reach me at [email protected]

from xkeys.

Just adding a note for transparency; Me and Michael have had some good talks, and we aim to fix and improve this library together going forward. There are some bugs in the data handling that'll need fixing, and also adding support for more/all of the various devices. Stay tuned!

from xkeys.

This is ..... AWESOME!

As a developer using this Node.js lib I can confirm its usefulness. A few things might need a bit polishing, but in general it's solid and nice to work with.

@nytamin (and @michaelhatPIengineering), are you interested in feedback/thoughts on things to consider when refining this lib? Happy to contribute if so (I believe we're both in Stockholm, Johan).

Cheers,
Göran

from xkeys.

Glad you like it so far, we will be adding and testing almost all the X-keys soon. And implementing some new functions for better discovery and management of multiple devices.

Wish I could join you at the pub in Stockholm....Someday soon I hope.
Michael

from xkeys.

And a more robust way to identify devices, this would for example make it
easier to handle re-connects in a good way.
I'm also interested in solving this, however I'm not sure if it is possible in a robust enough way. If I understood it correctly the other day we don't have any ID unique and hardcoded to a specific physical device - something that we would need to have in order to truly be able to determine a difference between a reconnected or newly connected panel.

We might be able to fake it, by either

1. Setting the user-id of the panel to a unique-ish id upon connection (if it hasn't already been set). That way we can uniquely identify them, but it's not really how the user-id should be used (it's intended instead to tie a certain panel to a certain functionality, so if you have two panels with the same labels on them, you should set them to the same user-id).
2. Hash the usb-port, product-id and user-id. This will (/can) work if you pull the panel and plug it into the same usb port again, but any other usb port, it'll be reported as a new panel again.

Since I'm definitely not the expert in the room, I'll let @michaelhatPIengineering weigh in on this as well.

I'm inclined to change the interface for the library completely to solve this situation, I'll run some local tests and will keep you in the loop.

from xkeys.

The long USB chain (i.e. usb hub connected to a usb hub connected to a usb hub....) issue on macOS (I think it's limited to macOS at least) is discussed upstream in the node-hid project.

But the issue doesn't really originate there but rather in hidapi. So there are some ifs and buts and general dependencies to take into account.

from xkeys.

Also, I had a brief chat with the node-hid maintainer regarding uniquely identifying devices. Just FYI, doesn't add much.

from xkeys.

USB HID did not originally make a good mechanism to ID 2 identical devices. (same PID)

The descriptor serial number is one, but in the early days of OTP (one time programmable) micro-processors for a high volume lower cost device such as keypad this was not easy.

Since X-keys could be labeled differently unit to unit we discovered very early that it was very important to have an ID that stayed with the unit, and not the port. QWERTY keyboards did not have this issue because Q is always Q.

If you think about it the key to any control system is really a good addressing system:

Machine ID=>Vendor ID (VID)=>Product ID (PID)=Unit ID (UID)=>Control ID (CID)

We need to know where the message came from to react properly to it.

Machine ID (usually the MAC address)
Vendor ID, (VID) supported by USB in descriptor,
Product ID, (PID) supported by USB in descriptor
Unit ID, (UID) , this is where it becomes complex
Control ID (CID), on a QWERTY this is the USB HID key code for example, on the X-keys it is a button (1bit) or an analog control (1 or 2 bytes)

So it seems that UID should be fairly straight forward in this hierarchy.

But I think the “H” in HID is a real problem.

Depending on the application, the pesky human in the system often has different expectations.

Does the person always want the same behavior?
Does the person always expect a unique device?
Are they replacing a unit they already had?
Do they want 2 units to behave the same and 2 others to behave different?

For any one of those questions there is probably a definite behavior that we want.
But the solution to one of those Qs is a problem for another.

Perhaps, this is why the original USB HID spec did not really address this issue.

So after over 20 years, I am sure I do not know the answer.

Even with a definite serial number, these questions still exist and the solution is still dependent on the application.

We created the UID, which is can be changed quickly without a reboot, and is not required to be unique. It is only 256 values but that has never caused an issue.

We use it as for an arbitration system for our Macroworks, where we are pretty sure a user wants to program 2 units different, but allow them to be the same if desired.

In some applications, we use some indicator, such as flashing LEDs or backlight to have the Human help us in the arbitration.

In some applications may almost be like “pairing” a blue tooth device, in others we can automatically auto increment and never get a conflict.

So we intend to supply all the functions needed to solve this very application dependent issue.

But remember, this is a HID device, and our goal is to solve the need of that “H” and usually it in only requires a little intervention at the beginning and ever after they forget about it.

So I will try to share our experience and make some examples for the functions for the common use cases.

Sorry I do not have a more definite answer.

from xkeys.

from xkeys.

Glad to hear! 🙂
Status update; we're continuing the work of improving the library. I expect we'll have something that's ready to receive critique from users/devs some time next week.
I'll post another update when we get there.

from xkeys.

from xkeys.

Status update: We are closing in on the finish-line now. If nothing major pops up we'll likely release it in a few days.

If anyone would like to try it out and critique it, that would be much appreciated!

You can try it out by using the latest nightly build:

npm install xkeys@nightly

Make sure to read the README-section about breaking changes: https://github.com/SuperFlyTV/xkeys/tree/develop#200

from xkeys.

Status update:
Things seem to work quite well, @michaelhatPIengineering 's team has provided quite a few good test-recordings, to ensure that the bits and bytes are in their right places. 🥇

I'm closing this thread, as version 2.0.0 has now been released, feel free to open new issues if you want to discuss features or if you encounter any problems/bugs.

from xkeys.