New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SDL 0075] OEM specific Human Interface Device support as Plug-in architecture in SDL proxy #664

Closed
theresalech opened this Issue Jul 26, 2017 · 1 comment

Comments

Projects
4 participants
@theresalech
Contributor

theresalech commented Jul 26, 2017

Proposal: OEM specific Human Interface Device support as Plug-in architecture in SDL proxy

Many OEM head units (ex. Lexus Remote Touch, Mazda Commander Control, BMW Gesture Control, Audi MMI) do not support direct touch interaction, but rather support a focus and select model driven by physical controls. This proposal describes a proxy plug-in interface that models the physical controls as HID devices with OEM-specific plug-in implementations. Note: From conclusion in Steering Committee, this proposal was changed to alt#1 (specify proper RPC, not plug-in architecture).

Review: smartdevicelink/sdl_evolution#219

Steering Committee Decision:

The Steering Committee has agreed to move forward with a revised version of Alternative 1 for this proposal, and focus on RPC changes only. While this would typically warrant "returning for revisions," the Steering Committee has decided to make an exception and "accept with revisions" so that the feature can meet the deadline to be contained within the Core 4.4 Release.

This proposal has been accepted with the following revisions, to be made by the Xevo team:

  • Alternative 1 will be the planned approach, with focus only on RPC changes - a separate proposal describing a fuller structure around proxy implementation should be entered at a later date
  • Add ID to SpatialStruct
  • Change HapticSpatialData array from mandatory to optional
  • Increase the maximum size of the HapticSpatialData array (to at least 100, possibly 999)
  • Add the following to the description of SendHapticData RPC: when a request is sent, if successful, it will replace all spatial data previously sent through RPC

These changes have now been reflected in .md file.

@joeygrover

This comment has been minimized.

Show comment
Hide comment
@joeygrover

joeygrover Aug 9, 2017

Member

Updated with evolution pull request..
Add a single param to the VideoStreamingCapability struct:

    <struct name="VideoStreamingCapability">
        <description>Contains information about this system's video streaming capabilities.</description>
        ....
        <param name="hapticSpatialDataSupported" type="Boolean" mandatory="false">
            <description>True if the system can utilize the haptic spatial data from the source being streamed. </description>
        </param>
    
    </struct>
Member

joeygrover commented Aug 9, 2017

Updated with evolution pull request..
Add a single param to the VideoStreamingCapability struct:

    <struct name="VideoStreamingCapability">
        <description>Contains information about this system's video streaming capabilities.</description>
        ....
        <param name="hapticSpatialDataSupported" type="Boolean" mandatory="false">
            <description>True if the system can utilize the haptic spatial data from the source being streamed. </description>
        </param>
    
    </struct>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment