# This section includes all valid xinput.Gamepad Device
# settings that can be specified in an iohub_config.yaml
# or in Python dictionary form and passed to the launchHubProcess function
# Any device parameters not specified when the device class is
# created by the ioHub Process will be assigned the default value
# indicated here.
#
# This section includes all valid xinput.Gamepad Device
# settings that can be specified in an iohub_config.yaml
# or in Python dictionary form and passed to the launchHubProcess function
# Any device parameters not specified when the device class is
# created by the ioHub Process will be assigned the default value
# indicated here.
#
xinput.Gamepad:
    # name: The name you want to assign the xinput.Gamepad device for the experiment
    #   This name is what will be used to access the device within the experiment
    #   script via the devices.[device_name] property of the ioHubConnection or
    #   ioHubExperimentRuntime classes.
    #
    name: gamepad

    # enable: Specifies if the device should be enabled by ioHub and monitored
    #   for events.
    #   True = Enable the device on the ioHub Server Process
    #   False = Disable the device on the ioHub Server Process. No xinput.Gamepad events will
    #   be reported by the ioHub Server.
    #
    enable: True
 
    # device_number: Up to 4 XInput 'users' can be connected to the computer at one time. The
    #   gamepad's user ID is based on how many other gamepads are already connected to the
    #   computer when the new gamepad turns on. If a gamepad with a lower user id
    #   then disconnects from the computer, other active gamepad user ids remain the same.
    #   Therefore XInput user id is not equal to the index of the gamepad in a set 
    #   of gamepads. If the experiment should connect to the first active gamepad found, enter -1.
    #   Otherwise enter the user_id (1-4) of the gamepad user ID you wish to connect to.
    device_number: -1

    # monitor_event_types: *If* the ioHubDataStore is enabled for the experiment, then
    #   indicate if events for this device should be saved to the
    #   monitor_event_types: Specified which xinput.Gamepad Event types should be monitored
    #   for and therefore saved to the DataStore or sent to the Experiment Process.
    #
    monitor_event_types:  [GamepadStateChangeEvent,]

    # save_events: Save xinput.Gamepad events to the data_collection/xinput.Gamepad event 
    #   group in the hdf5 event file.
    #   True = Save events for this device to the ioDataStore.
    #   False = Do not save events for this device in the ioDataStore.
    #
    save_events: True

    # stream_events: Indicate if events from this device should be made available
    #   during experiment runtime to the Experiment / PsychoPy Process.
    #   True = Send events for this device to  the Experiment Process in real-time.
    #   False = Do *not* send events for this device to the Experiment Process in real-time.
    #
    stream_events: True

    # auto_report_events: Indicate if events from this device should start being
    #   processed by the ioHub as soon as the device is loaded at the start of an experiment,
    #   or if events should only start to be monitored on the device when a call to the
    #   device's enableEventReporting method is made with a parameter value of True.
    #   True = Automatically start reporting events for this device when the experiment starts.
    #   False = Do not start reporting events for this device until enableEventReporting(True)
    #       is set for the device during experiment runtime.
    #
    auto_report_events: True

    # event_buffer_length: Specify the maximum number of events (for each
    #   event type the device produces) that can be stored by the ioHub Server
    #   before each new event results in the oldest event of the same type being
    #   discarded from the ioHub device event buffer.
    #
    event_buffer_length: 256

    # device_timer: Devices that require polling to read any new native events
    #   that have become available must specify a device_timer property, with an
    #   interval sub proerty that specifies how frequently the device would be polled
    #   by the ioHub Server. The time is specified in sec.msec format and is a 'requested'
    #   polling interval. The actual polling interval will vary from this somewhat, the 
    #   magnitude of which depends on the computer hardware and OS being used and the
    #   number of other polled devices being monitored. The 'configdence_interval'
    #   attribute of events that have a parent device that is polled often can be used to
    #   determine the actual polling rate being achieved by the ioHub Process.
    device_timer:
        interval: 0.005

    # serial_number: The serial number for the specific isnstance of device used
    #   can be specified here. It is not used by the ioHub, so is FYI only.
    #
    serial_number: N/A

    # manufacture_date: The date of manufactiurer of the device 
    # can be specified here. It is not used by the ioHub,
    # so is FYI only.
    #   
    manufacture_date: DD-MM-YYYY

    # The device manufacturer's name.
    #   It is not used by the ioHub, so is FYI only.
    #
    manufacturer_name: N/A

    # model_name: The device model name can be specified here.
    #   It is not used by the ioHub, so is FYI only.
    #
    model_name: N/A

    # model_number: The device model number can be specified here.
    #   It is not used by the ioHub, so is FYI only.
    #
    model_number: N/A
    
    # software_version: The device driver and / or SDK software version number.
    #   This field is not used by ioHub, so is FYI only. 
    #
    software_version: N/A

    # hardware_version: The device's hardware version can be specified here.
    #   It is not used by the ioHub, so is FYI only.
    #
    hardware_version: N/A
    
    # firmware_version: If the device has firmware, its revision number
    #   can be indicated here. It is not used by the ioHub, so is FYI only.
    #
    firmware_version: N/A
    