Detecting dis/connect woes

Announcements, questions
Post Reply
skagon
Posts: 6
Joined: 03 Nov 2019, 18:13

Detecting dis/connect woes

Post by skagon » 04 Nov 2019, 13:17

Hello there. As you can infer from the title, I've been struggling to find some way to detect and handle connects and disconnects (not necessarily in that order) of keyboards or whatever other devices. With little success, I might add.

Now, let me first present my findings. At first, I was trying to "catch" some kind of error, assuming that you'd get some kind of error when trying to set a handler on a device that does not exist. I tried using the pcall and lua_pcall functions, but somehow, the results I got were not the results I expected. Then I started trying the return of the lmc_set_handler function itself, again to no avail.

After a lot of trial and error, I realised the one sad truth: the device list, the one seen under "Devices" using the lmc.statistics flag, never gets updated. Therefore, there is no way to "trap" events such as "disconnect" or "connect".
The other problem is that, once a handler is set, it never goes away, even if the corresponding keyboard is disconnected.
Another problem I found during my tests, where I used a timer function to spawn more handles on the same keyboard, is that you cannot programmatically "unset" a handler. I know there is little point in that, but there's no lmc_delete_handler function.

So, here we come to the "request" part.

First and foremost, I would really like to see something along the lines of "keyboard event traps". Like, new keyboard is connected? Notify me! Some keyboard is disconnected? Notify me again! I want a trigger!

Secondly, if the only way to do an update on the devices is an lmc_reset call, there should also be something like lmc_reset_and_restart function. Like, reset (as it does now) but after reset is finished, restart the script!

Third, if it's not possible to do the first, get messages of device connects and disconnects, at least a function like lmc_rescan_devices would be needed. I bet you can see where I'm going with this one: use a timer to rescan devices, see if the one I want is still there and if it's not, delete the handler. The timer should keep running and scan periodically so, if the device gets reconnected, re-set the handler!

Fourth, the set functions do not return errors. Specifically, the lmc_set_device_name function doesn't report or return any errors whatsoever, if the device does not exist. It's "business as usual", even if I do lmc_set_device_name('spock', 'Space._The_final_frontier.')
Thankfully, the lmc_set_handler function does *something* in case of a missing device, even if that "something" is not what would be expected. Meaning, it does not return any values as a function should. However, it goes on to print an error message on the output pane!
Now, I'm no programming language expert, but shouldn't all functions return something like "0" if it finished successfully and "1" if it failed for whatever reason? Or is it there and I'm not seeing it?

I'd really love to hear your thoughts on those observations. Oh and thank you for an amazing program! That goes without saying.

admin
Site Admin
Posts: 620
Joined: 01 Nov 2010, 13:00
Location: Prague, Czech republic
Contact:

Re: Detecting dis/connect woes

Post by admin » 05 Nov 2019, 09:29

Aren't devices re-scanned on every print devices call? If you need to detect programatically plugged/unplugged keyboard (using timer) you better check function lmc_get_devices, e.g. here: https://github.com/me2d13/luamacros/iss ... -347039981
Return state of lmc_set_device_name can be tuned, I think it should currently return full device id and probably returns empty string if no device is found.
Unregister function can be added.
It's fine to discuss and clarify here (in forum) first but once we agree there's some new feature needed, it's better to log github issue so it's tracked. I tend to forget thigs we discuss in the forum :-)
Petr Medek
LUAmacros author

skagon
Posts: 6
Joined: 03 Nov 2019, 18:13

Re: Detecting dis/connect woes

Post by skagon » 05 Nov 2019, 14:58

Hey, thank you for the reply!

Actually, I've checked and double-checked: the devices are not re-scanned at all, it seems. I've got (well obviously) a numeric keypad which I'm disconnecting and reconnecting, but the devices list remains the same as when the script started – or since the last lua-reset, I'm not sure which.

This is why I've asked for some kind of trigger when some device is connected or disconnected. Rather than polling the device list every 500 milliseconds (or however much you want), it's better to have a proper trigger telling you what got connected or disconnected, IF, based on the set_device_name stuff you have added in your script, some of your "named" devices got connected or disconnected. I'm sure it can be done a lot faster from within LUAmacros than in a script running on a timer.

In reality you could do that change completely behind the scenes. I mean, handle the connects and disconnects internally and, if a device gets disconnected, stop the handle; if it gets reconnected, restart the handle.

What do you think?

admin
Site Admin
Posts: 620
Joined: 01 Nov 2010, 13:00
Location: Prague, Czech republic
Contact:

Re: Detecting dis/connect woes

Post by admin » 06 Nov 2019, 08:45

Need to check if there's some windows API that would notify luamacros about connecting/disconnecting event.
But generaly yes, this would be usefull feature.
Petr Medek
LUAmacros author

skagon
Posts: 6
Joined: 03 Nov 2019, 18:13

Re: Detecting dis/connect woes

Post by skagon » 06 Nov 2019, 13:46

I am so happy that you agree!

I don't know if Windows has some kind of event handler that would notify you of device connects or disconnects, but if the worst comes to the worst, you could always keep refreshing the devices list and checking if the "named" devices are still present. You could also add something like lmc.devicePollingRate variable, so that people can decide how often they want that "refresh" to occur. Personally, I'd be fine with every 5 seconds, but someone else might want it every 1 millisecond (in which case he'd totally swamp the computer but who cares)! :D

A proper "event" would be the best choice, though. If nothing gets connected or disconnected, why waste CPU cycles to check?

skagon
Posts: 6
Joined: 03 Nov 2019, 18:13

Re: Detecting dis/connect woes

Post by skagon » 06 Nov 2019, 14:24

Update: well, after some soul-searching, I remembered there used to be a Win32 function call named "RegisterDeviceNotification". After a little googling, I came up with these:

https://docs.microsoft.com/en-us/window ... ificationa
https://docs.microsoft.com/en-us/window ... tification

I hope they help!

Tell you the truth, I haven't been following what Microsoft is doing with the back-end, since they came up with those stupid "apps", so I'm not certain that the Win32 API is still relevant but… hey… it's something

skagon
Posts: 6
Joined: 03 Nov 2019, 18:13

Re: Detecting dis/connect woes

Post by skagon » 13 Nov 2019, 15:24

Hey there. Just wanted to check to see if you've got any news on that connect/disconnect front.

admin
Site Admin
Posts: 620
Joined: 01 Nov 2010, 13:00
Location: Prague, Czech republic
Contact:

Re: Detecting dis/connect woes

Post by admin » 15 Nov 2019, 21:14

Now I spent some time playing with that.
My findings:
- I can detect USB device change/remove but can't find out device type and name
- print devices really doesn't redetect them

So generaly it's doable, I can add callback on device connect and disconnect. In this handler you could detect devices and see the change. Adding detection of devices is not that easy because I simply can't throw the list away and build new one (this is what initial detection does now), because some devices can have handlers attached. So I need to detect fresh list and do some merging to keep current callbacks.
Petr Medek
LUAmacros author

skagon
Posts: 6
Joined: 03 Nov 2019, 18:13

Re: Detecting dis/connect woes

Post by skagon » 18 Nov 2019, 00:28

That is good news. Now, I won't pretend to know what's going on behind the scenes, but I'll take your word for it: there's a list and we can't throw the old one away whenever there's a device connect or disconnect. I'm sure you'll find a nice way to do it, though. It's not like there's a lot of connecting and/or disconnecting happening all the time. It's not even likely that someone will connect a keyboard and *immediately* start typing on it…

So all in all… keep up the good work! Can't wait to see the result! Thank you!

Post Reply