Skip to content
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

Add screen mirroring in Infotainment.vspec #737

Merged
merged 7 commits into from
May 8, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions spec/Cabin/Infotainment.vspec
Original file line number Diff line number Diff line change
Expand Up @@ -247,6 +247,7 @@ HMI.DisplayOffDuration:
SmartphoneProjection:
type: branch
description: All smartphone projection actions.
comment: Smartphone projection exposes or controls specific applications on the Smartphone on the vehicle infotainment system.

SmartphoneProjection.Active:
datatype: string
Expand All @@ -260,11 +261,30 @@ SmartphoneProjection.Source:
type: actuator
allowed: ['USB', 'BLUETOOTH', 'WIFI']
description: Connectivity source selected for projection.
comment: Smartphone projection exposes or controls specific applications on the Smartphone on the vehicle infotainment system.

SmartphoneProjection.SupportedMode:
datatype: string[]
type: attribute
allowed: [ 'ANDROID_AUTO', 'APPLE_CARPLAY', 'MIRROR_LINK', 'OTHER' ]
description: Supportable list for projection.

SmartphoneScreenMirroring:
spshin3 marked this conversation as resolved.
Show resolved Hide resolved
type: branch
description: All smartphone screen mirroring actions.
comment: Smartphone screen mirroring mirrors the whole screen of the Smartphone on the vehicle infotainment system.

SmartphoneScreenMirroring.Active:
datatype: string
type: actuator
allowed: [ 'NONE', 'ACTIVE', 'INACTIVE' ]
description: Mirroring activation info.
comment: NONE indicates that mirroring is not supported.

SmartphoneScreenMirroring.Source:
datatype: string
type: actuator
allowed: ['USB', 'BLUETOOTH', 'WIFI']
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider using the following instead:

Suggested change
allowed: ['USB', 'BLUETOOTH', 'WIFI']
allowed: ['USB', 'BLUETOOTH', 'WI-FI']

Although many folks tend to write "Wifi" or "WiFi", the correct spelling is "Wi-Fi": https://www.wi-fi.org/

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no strong opinion but the literals used here correspond to what we have in https://github.com/COVESA/vehicle_signal_specification/blob/master/spec/Cabin/Infotainment.vspec#L258

SmartphoneProjection.Source:
  datatype: string
  type: actuator
  allowed: ['USB', 'BLUETOOTH', 'WIFI']
  description: Connectivity source selected for projection.

So if we are to change to WI-FI we should also consider changing Vehicle.Cabin.Infotainment.SmartphoneProjection.Source (and then comes the question on how to handle backward compatibility, just adding WI-FI and keep WIFI for now, but state that WIFImay be removed later)

I suggest we discuss it at a meeting

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My point was mainly that if we wish the catalog to be a standard, we should ensure we use and refer to other standards. Here, the Wi-Fi alliance is using "Wi-Fi" in all its documentation. Even their domain is www.wi-fi.com.

Most people write it as Wifi, so "WIFI" should be fine. If we already have "WFI" elsewhere, I am not sure it is worth it to change to other uses.

My nitpick fits in more in the context of my interest in developing a signal catalog submission review process that looks at these kinds of checks as well as other questions we may wish to ask for each submission.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your comment.

Personally, I don't have a strong opinion on this matter either. I also agree that following the global standards is important.

However, I'm little bit confused about whether it's appropriate to use "WI-FI" for data naming. When I see the android document, "WIFI" is used as a data type name, and "Wi-Fi" is used for descriptive text in the document. (https://source.android.com/docs/core/ota/modular-system/wifi)

Typically, hyphens ('-') are not used in data type names in VSS. Therefore, how about we keep using "WIFI" as it is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think changing "WIFI" to "WI-FI" is not too difficult since we only need to update the naming in SmartphoneProjection. More important thing is making the right decision regarding the correct naming between WIFI and WI-FI.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the VSS meeting earlier this week we agreed that keeping WIFI is the best option for now, as we then do not need to change the other existing signal that use WIFI.

description: Connectivity source selected for mirroring.

#include include/PowerOptimize.vspec