Multiple device support

[nicola02nb]

Changes made

Added multiple device support with command arg -d, --device INDEX
Actions can be executed only to one device at a time

Checklist

• I adjusted the README (if needed)
• For new features in HeadsetControl: I discussed it beforehand in Issues or Discussions and adhered to the wiki

[Sapd]

Thank you!

Some points for now:

• --test-device seems to be completely broken
  • In the end I think it would be nice that also the test device is shown as another device (when the parameter is provided) together with a real device when one its connected
• -d should be I think a bit more flexible. It should also support -d vendorid:deviceid (like in the --dev menu). However I like the approach with showing the indexes directly in the text when running the program

[nicola02nb]

• --test-device seems to be completely broken

Ok, didn't checked that...

• In the end I think it would be nice that also the test device is shown as another device (when the parameter is provided) together with a real device when one its connected

You mean to add it to the curernt list of connected devices?

• -d should be I think a bit more flexible. It should also support -d vendorid:deviceid (like in the --dev menu). However I like the approach with showing the indexes directly in the text when running the program

Maybe an hybrid solution where you can use both of them would be also better...

Question: Which interface I choose to interact with a device changes nothing, right?

[Sapd]

Maybe an hybrid solution where you can use both of them would be also better...

Yes thats what I mean. That both -d index and -d vendorid:deviceid works. There is already a function for that, it just has to be moved to utility.c and modified in a way that also one id works:

HeadsetControl/src/dev.c

Line 72 in 689c1fc

static int get_two_ids(char* input, int* id1, int* id2)

You mean to add it to the curernt list of connected devices?

Yes, when the parameter is provided.

Question: Which interface I choose to interact with a device changes nothing, right?

Basically there is no sense in choosing the interface, its already given by the device implementation

[nicola02nb]

Running tests locally gives no errors.
I'm wonderig why CI does...

[nicola02nb]

Now it should be all done

it just has to be moved to utility.c and modified in a way that also one id works

Missed that...

[Sapd]

Will take a deeper look into the PR over the holidays

[Sapd]

One thing still missing/bugs:

./headsetcontrol -o json --test-device

That is to query all devices including features. However it seems to be missing features like battery if deviceid is not specified. For example here it shows the battery of the test device but not of the corsair device

{
  "name": "HeadsetControl",
  "version": "continuous-13-g855b7df-modified",
  "api_version": "1.2",
  "hidapi_version": "0.14.0",
  "device_count": 2,
  "devices": [
    {
      "status": "success",
      "device": "HeadsetControl Test device",
      "vendor": "HeadsetControl",
      "product": "Test device",
      "id_vendor": "0xf00b",
      "id_product": "0xa00c",
      "capabilities": [
        "CAP_SIDETONE",
        "CAP_BATTERY_STATUS",
        "CAP_NOTIFICATION_SOUND",
        "CAP_LIGHTS",
        "CAP_INACTIVE_TIME",
        "CAP_CHATMIX_STATUS",
        "CAP_VOICE_PROMPTS",
        "CAP_ROTATE_TO_MUTE",
        "CAP_EQUALIZER_PRESET",
        "CAP_EQUALIZER",
        "CAP_MICROPHONE_MUTE_LED_BRIGHTNESS",
        "CAP_MICROPHONE_VOLUME",
        "CAP_VOLUME_LIMITER",
        "CAP_BT_WHEN_POWERED_ON",
        "CAP_BT_CALL_VOLUME"
      ],
      "capabilities_str": [
        "sidetone",
        "battery",
        "notification sound",
        "lights",
        "inactive time",
        "chatmix",
        "voice prompts",
        "rotate to mute",
        "equalizer preset",
        "equalizer",
        "microphone mute led brightness",
        "microphone volume",
        "volume limiter",
        "bluetooth when powered on",
        "bluetooth call volume"
      ],
      "battery": {
        "status": "BATTERY_AVAILABLE",
        "level": 42
      },
      "equalizer": {
        "bands": 10,
        "baseline": 0,
        "step": 0.5,
        "min": -10,
        "max": 10
      },
      "equalizer_presets_count": 2,
      "equalizer_presets": {
        "flat": [ 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ],
        "random": [ 6.0, -8.0, 1.5, 7.0, -1.0, -7.5, -9.0, 0.0, 9.0, 10.0 ]
      },
      "chatmix": 42
    },
    {
      "status": "success",
      "device": "Corsair Headset Device",
      "vendor": "",
      "product": "",
      "id_vendor": "0x1b1c",
      "id_product": "0x1b27",
      "capabilities": [
        "CAP_SIDETONE",
        "CAP_BATTERY_STATUS",
        "CAP_NOTIFICATION_SOUND",
        "CAP_LIGHTS"
      ],
      "capabilities_str": [
        "sidetone",
        "battery",
        "notification sound",
        "lights"
      ]
    }
  ]
}

[nicola02nb]

It Is actually a missing implementation, it displays the values only for the selected device spicefied by -d <index | pId:vId>.
If you want to add it as a feature, that loads battery and other infos, just let me know, and I'll try to add id

[nicola02nb]

@Sapd I'm thinking about a solution that if you use -d it displays, loads, and also sends action, only the selected device.... if not, no action will be performed, but all devices infos will be shown.... do you like that?

[Sapd]

Sounds interesting, but what about making it this way: -d behaves exactly like you specified.
But when nothing specified, it will try to query everything? (however I looked into the code might need some effort in main.c)

[nicola02nb]

But when nothing specified, it will try to query everything?

I’m not sure about querying all compatible devices. It might unintentionally alter the settings of other connected headphones, if someone has more of them...

behaves exactly like you specified
(however I looked into the code might need some effort in main.c)

Seems doable to me...

[nicola02nb]

I'm also thinking of removing the -d index and keeping only -d vendorid:deviceid:

• It simplfies the implementation
• Using vendorid:deviceid is faster because I don't need to enumerate all devices when sending actions
• If someone runs headsetcontrol -d index in a loop the index can change if another compatible device is connected/disconnected

What do you think about that?

[Sapd]

What do you think about that?

Good points! I agree

I’m not sure about querying all compatible devices. It might unintentionally alter the settings of other connected headphones, if someone has more of them...

Why so? its only about querying (and on top only devices which are implemented in HeadsetControl). Basically Im thinking about that in accordance: https://github.com/Sapd/HeadsetControl/wiki/API-%E2%80%90-Building-Applications-on-top-of-HeadsetControl#querying-values

I highly appreciate your work btw (I just need a bit of time to answer currently)

[nicola02nb]

I highly appreciate your work btw

I'm glad to hear that :)

its only about querying

Just to get me clear, you mean to query only informations like BATTERY_STATUS and CHATMIX_STATUS, not also the actions.... rignt?

[Sapd]

I think there is still a bug:

# 0x1b1c:0x1b27 is a corsair device
headsetcontrol --test-device -o json -s 1 -d 0x1b1c:0x1b27

It sends the sidetone request still to the test device. But I specified the corsair device

  "actions": [
    {
      "capability": "CAP_SIDETONE",
      "device": "HeadsetControl Test device",
      "status": "success"
    }
  ],

Currently checking in detail

(btw ignore the format error, the problem is I think that our local versions are too new for the CI, but for the CI there is not a current version yet)

[Sapd]

Okay the behaviour is a bit funny:

headsetcontrol --test-device -o json -s 1 -d 0x1b1c:0x1b27

That actually sends it to the corsair device. But it shows that its sending it to the test device

headsetcontrol --test-device -o json -s 1 

That shows that its sending it to the test device. But it does nothing, not even on the test device

headsetcontrol --test-device -o json -s 1 -d 0xF00B:0xA00C

That sends and shows its sending to the test device

[nicola02nb]

Found out where the error was.. I forgot do disable the action for the devices that weren't selected.

The bug was caused beacuse I was creating the feature_requests arrays by copying multiple times the originale variable featureRequests which initializes the action gave by the command line (-s) resulting in all devices_found to have each one to have their feature_requests.should_process = true;

[Sapd]

Ah now it works when -d is specified (with test-device and/or without).

But when -d is omitted, even when just one device is plugged in (or just the test device), it simply does nothing.

I also think that when -d is omitted, but two devices are detected, it should probably error out

[nicola02nb]

Ah now it works when -d is specified (with test-device and/or without).

Seems good, right?

I also think that when -d is omitted, but two devices are detected, it should probably error out

With headsetcontrol -o json and two devices connected, I'm having no issues...

But when -d is omitted, even when just one device is plugged in (or just the test device), it simply does nothing.

That's how I ment it to work... but if you want it to do something even without -d option, you can give me details and I can try to implement it

[Sapd]

Seems good, right?

Yes.

That's how I ment it to work... but if you want it to do something even without -d option, you can give me details and I can try to implement it

That basically breaks functionality:

If you have one device connected, that one should set the sidetone of the one device (but does nothing). That also was the previous behaviour.

./headsetcontrol -o json -s 1

If two are connected, I think it should error out and show the error in the json (as it would be otherwise confusing)

[nicola02nb]

If you have one device connected, that one should set the sidetone of the one device (but does nothing). That also was the previous behaviour.

If two are connected, I think it should error out and show the error in the json (as it would be otherwise confusing)

Oh ok, you want that if there is only one connected you'll send action to it, elseway error out the action by saying that there are multiple devices connected an should specify one with -d....

show the error in the json

As an action error?

[Sapd]

Yep!

Actually when you now try -s with two devices (at least with test deice) and without json output, you see it gets send to both:

❯ ./headsetcontrol -s 1 --test-device
Found 2 supported device(s):
 HeadsetControl Test device (Test device) [0xf00b:0xa00c]
 Corsair Headset Device [0x1b1c:0x1b27]

Successfully set sidetone!
Successfully set sidetone!

But that should rather error out

As an action error?

Yes. There is currently an error_message field for that.