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.

Sign up for GitHub

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

Add screen mirroring in Infotainment.vspec #737

Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
bbad298
Add SmartPhoneMirroring
spshin3 Apr 12, 2024
ef4ed6c
Add SmartPhoneMirroring
spshin3 Apr 12, 2024
24863d3
Update Infotainment.vspec
spshin3 Apr 16, 2024
d139b3a
Add SmartScreenMirroringRevert "Update Infotainment.vspec"
spshin3 May 3, 2024
02b3e85
Revert "Update Infotainment.vspec"
spshin3 May 3, 2024
35bd28c
Resolve DCO error
spshin3 May 3, 2024
3549954
Remove resolution
spshin3 May 7, 2024
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
26 changes: 26 additions & 0 deletions spec/Cabin/Infotainment.vspec
View file
Open in desktop
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,36 @@ 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.

SmartphoneScreenMirroring.Resolution:
datatype: string
type: sensor
allowed: ['RES_720P', 'RES_1080P', 'RES_4K']
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not clear if and how this is useful. If useful, there is possibly much more information that may be useful (screen size, etc.).

Pardon my lack of knowledge, but isn't resolution a factor of what the display supports as well as what the application wishes to use or requires? If so, how do we address it here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In my opinion, screen size is not an appropriate parameter for screen mirroring configuration. This is because even within the same screen size, smartphones can support various resolutions based on user preferences. The android base smartphone also supports the configuration of your resolution in 'configuration->display->screen resolution'.

The resolution setting is actually related to the display graphics processing load of the infotainment system, and typically, it can be adjusted to suit the user's preferences.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Would it be a possible way forward to clarify in the description that this signal concerns the resolution currently used, not maximum allowed resolution, possibly by changing to something like:

"Display resolution currently used for the mirrored content"

This off course does not prevent that more signals are added later if needed, like attributes for screen size, supported resolutions and so on, but that could be added later if/when needed.

description: Display resolution for the mirrored content.

#include include/PowerOptimize.vspec