Buttplug Device Configuration File - First Draft

buttplug-device-config.yml

# Welcome to Buttplug Device Config
#
# DO NOT EDIT THIS FILE. YOUR CHANGES WILL BE OVERWRITTEN.
#
# Use user-device-config.yml for local device definitions.
#
# Now that we've got that bit of impoliteness out of the way... Hi,
# I'm qDot. Welcome to the buttplug device configuration file.
#
# You've managed to wander into this place we keep all of the sex toy
# information. You're not really supposed to be here, but since you've
# shown up, might as give you a tour.
#
# Devices in Buttplug have the following info:
#
# - Protocol (Required)
#
#   - The language we talk to the device. In our config file, these
#     will all have specific names, usually brands like Lovense or
#     WeVibe. In some cases, specific toys may have their own protocol
#     too, like the Fleshlight Launch. Devices should usually only
#     have one protocol.
#
# - Identifier (name: id, Optional)
#
#   - The information we use to find a device. This will vary
#     depending on our bus type. Bluetooth needs name, service IDs,
#     etc. USB needs vendor ID and product ID pairs. This field is
#     optional, as we can't look for devices on serial ports or wifi
#     easily, and we expect the user to help us with those by
#     providing more information in their local config file.
#
# - Configuration (name: config, Optional)
#
#   - Common settings for a device. Usually used for serial.

# Define identifier types. These are the only values devices can have
# in their connection-info lists.

connection-info-types:
  - btclassic
  - btle
  - serial
  - usb
  - hid

# This is the list of possible protocols. Buttplug servers implement
# these protocols. Servers scan for devices (based on the information
# given below) and match the device with the protocol to present
# control to the user.

# protocols:
#   - lovense
#   - xinput
#   - erostek-et312
#   - erostek-et232
#   - wevibe
#   - vorze-sa
#   - vorze-cyclone
#   - kiiroo-v1
#   - kiiroo-v2
#   - libo
#   - magic-motion
#   - mysteryvibe
#   - picobong
#   - vibratissimo
#   - youcups
#   - trancevibrator

# Now for the actual protocol definitions. This is gonna get wild, so
# I'll keep a list of rules that you can refer to up here.
#
# - If you are curious about device identifiers or protocols, all
#   of those are documented at https://stpihkal.docs.buttplug.io
#
# - Some fields can be wildcarded using "*". This allows us to do
#   things like searching for all devices of a certain name.
#
# - Where possible, we assume all devices have at least one output (so
#   we can send the commands), and maybe one input. In cases
#   otherwise, a comment should be left denoting what we're doing
#   something different.
#
# - Most toys just mirror good ol' serial. With that in mind, we call
#   the host-to-device line tx, and device-to-host line rx.
#
# - If you see a "btle" connection info with service IDs but no
#   characteristic IDs, this means that we'll try autodetecting the
#   characteristics. We'll just expect it to have an input (which
#   we'll name "rx") and an output characteristic (which we'll name
#   "tx"), as mentioned above.
#
# - Similarly for USB, we'll test endpoints for r/w flags when no
#   endpoint handles are passed.
#
# - A "btle" connection info with multiple service listings can mean
#   one of two things. Either we expect the device to be identifiable
#   as multiple services (like Lovense), or the device may have
#   multiple services we use (like some BTLE toys that divide control
#   and sensor between different services).
#
# - If you're connecting to a buttplug server and don't see a device
#   that's listed here, it's not the fault of this config file.
#   Servers may not implement all protocols or busses for various
#   reasons. We just define which devices we may know about here. File
#   an issue on the library you're using.
#
# - If you're connecting to a buttplug server and some device doesn't
#   take a Buttplug message you're expecting it to, it's not the fault
#   of this config file. Servers implement protocols, and protocols
#   dictate which messages they are capable of sending. We don't
#   really keep a standard for that, we just define which devices we
#   may know about here. File an issue on the library you're using.
#
# - Serial info here is for default device configuration.



protocols:
  lovense:
    id:
      # Lovense is special. Special in oh so many ways.
      #
      # Lovense have changed BLE name formats at least once. For this
      # generic device, we just use the largest wildcard we can. We do
      # our name and capabilities finding in the protocol
      # implementation, because we have to query the device after
      # connection.
      #
      # The service uuids change constantly. This list is overly
      # exhaustive, because we have to specify services in WebBluetooth
      # and can't wildcard them. We'll add more as we find them.
      btle:
        name:
          - LVS-*
        services:
          - 0000fff0-0000-1000-8000-00805f9b34fb
          - 6e400001-b5a3-f393-e0a9-e50e24dcca9e
          - 50300001-0024-4bd4-bbd5-a6920e4c5653
          - 57300001-0023-4bd4-bbd5-a6920e4c5653
          - 5a300001-0024-4bd4-bbd5-a6920e4c5653
          - 50300001-0023-4bd4-bbd5-a6920e4c5653
          - 53300001-0023-4bd4-bbd5-a6920e4c5653
          - 5a300001-0023-4bd4-bbd5-a6920e4c5653
          - 4f300001-0023-4bd4-bbd5-a6920e4c5653

  xinput:
    # This will actually be ANY gamepad that supports XInput. XInput
    # is its own connector type, so we don't have any special
    # connection info here.
    #
    # TODO Maybe just start calling this "gamepad"? Maybe add "VR
    # Controller" too?
    null

  kiiroo-v2:
    id:
      btle:
        name:
          - Launch
        services:
          - 88f80580-0000-01e6-aace-0002a5d5c51b
    config:
      btle:
        88f80580-0000-01e6-aace-0002a5d5c51b:
          tx: 88f80581-0000-01e6-aace-0002a5d5c51b
          rx: 88f80582-0000-01e6-aace-0002a5d5c51b
          # The Launch has a special characteristic for loading
          # firmware.
          firmware: 88f80583-0000-01e6-aace-0002a5d5c51b
        
  erostek-et312:
    config:
      serial:
        baudrate: 19200
        databits: 8
        parity: N
        stopbits: 1

  vorze-cyclone-x:
    id:
      hid:
        vendor-id: 0x0483
        product-id: 0x5750

  rez-trancevibrator:
    id: 
      usb:
        vendor-id: 0xb49
        product-id: 0x064f

  kiiroo-v1:
    id:
      btle:
        name:
          - ONYX
          - PEARL
        services:
          - 49535343-fe7d-4ae5-8fa9-9fafd205e455
    config:
      btle:
        49535343-fe7d-4ae5-8fa9-9fafd205e455:
          rx: 49535343-1e4d-4bd9-ba61-23c647249616
          tx: 49535343-8841-43f4-a8d4-ecbe34729bb3
          cmd: 49535343-aca3-481c-91ec-d85e28a60318
          cmd2: 49535343-6daa-4d02-abf6-19569aca69fe

  vorze-sa:
    id: 
      btle:
        name:
          - CYCSA
          - Bach smart
          - UFOSA
        services:
          - 40ee1111-63ec-4b7f-8ce7-712efd55b90e
  # nintendo-joycon:
  #   name:
  #     en-us: Nintendo Joycon
  #   protocol: joycon
  #   connection-info:
  #     - hid:
  #         vendor-id: 0x057e
  #         product-id: 0x2006

Removed "capabilities" for now, since those are already basically handled in protocols. Might look at adding that back later, but not sure how needed it is.