Make pairing process occur on hot-reload
Kanuan opened this issue · comments
This should allow users to spam the apply settings button to trigger the hot-reload, sending the pairing packet any time it's necessary. This might fix issues with controllers that fail to pair if the packet is received too early.
If possible, also make it so the "last pairing check" and "host address" packets are updated then.
Should pairing occur on every hot-reload? Or should we introduce a different way of triggering pairing on demand by pressing some button in the ControlApp?
Making it occur on every hot-reload seems wasteful, specially if the user is testing settings
There aren't a ton of mechanisms in how to communicate with a HID driver since IO control requests are governed by what features the HID report descriptor exposes. However, being a user-mode driver we have some options to "cheat", for example a named event could be registered, similar to the hot reload file system watcher, that can be signaled by the control app and trigger the pairing. Remaining question would be where to get the desired MAC address from; if a radio exists that's easy but what about a custom MAC to mimic functionality of the old sixaxis pair tool. Maybe also pulling it from the JSON would be the least amount of change required.
Yeah, was planning on taking the custom address from the config file, was wondering more how to trigger it "manually" and not on every hot-reload.
I think I'll do the following:
- Introduce a counter variable in the user config disk file
- Load this counter value to memory when (re-)loading user settings in the driver
- Send pairing request on device boot, but also if the counter changed on a hot-reload
- Make it so the counter in the disk file only increases on command in the ControlApp instead of everytime settings are adjusted
There is no such need for that much complexity. The last host address sent to the controller is already known and cached in the device context during runtime. If the address pulled from the config file matches this value, don't send the pairing packet, case closed.
As for triggering this mechanism, introduce a named event that is shared between driver and app, if the app signals it, see if the host address in the JSON is different from the current one, if so, send the USB packet, done.
An extra even isn't even needed, since unnecessary requests can easily be avoided by address comparison if the JSON is modified and saved, pairing can be triggered from hot reload, further reducing complexity.
Two new settings are needed. A pairing type preference like default (auto select host radio address) and custom (use MAC from 2nd config field) that writes whatever the user desires.
My proposal was more on how to force the repairing process to occur repeatedly to the same address for devices we believe are time sensitive and may not accept the pairing request on boot.
But you are right, if the user wants to re-trigger the process it's possible to simplify things in the driver side by just making the Control app first automatically set some random address before setting the address again to the desired one
Setting it to 00:00:00:00:00:00, waiting a bit, then using the desired value could achieve that without screwing anything.
yeah, was just writing that. Set the values to all zeroes before setting the desired one.
Is it safe to directly set the pairing address to "0" or should I make the driver check for it and not send the pairing request if so?
Well, the address copy in the driver context memory should only be updated with a new value, if the USB request was successful. Technically leaving it at 0 if the subsequent "pairing" process failed is valid; after all if a controller is reset via the back pin, the host value would be read as zeroed out as well anyway. So 00:00:00:00:00:00 is a valid MAC at any time.
And yes, as I wrote before, if the controller is already set to e.g. 0C:13:37:DE:AD:BE and that exact value is read again on reload, the whole address updating should simply be skipped altogether. If a force refresh is desired:
- Set custom value in JSON to all zeroes
- Save file
- Wait a bit
- Set custom value in JSON to actual value
- Save file
- Hopefully it now has worked for the controller in question
Last pairing status can be queried from the already existing device property and reacted on in the UI accordingly.
#321 is also related. As a follow-up change, a failure to fetch device or host MAC should log an error in the future as it does already, however should not fail device power up. This would open the door to support devices that have no concept of a MAC or where fetching it is timing-sensitive.