webui: Update resolution automation example text with auto refresh rate

[cgarst]

Description

The Resolution Automation example text is inconsistent about refresh rate across platforms. The refresh rate flag is omitted for QRes Windows and suggested with a static 60 for xrandr (Linux) and displayplacer (Mac). Given the rise in average refresh rates on mobile devices I suspect users prefer seeing refresh rate handling guidance in the example commands.

Note that the Moonlight client apps typically default to 60 as the default refresh rate passed to Sunshine. Users with high refresh devices typically set a higher preference in their Moonlight client settings to feed >60 into the Sunshine prep command.

Screenshot

Issues Fixed or Closed

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

I'm not sure it's wise to add this to the examples as users will blindly set the refresh rate, and possibly to unsupported refresh rates.

[cgarst]

Couldn't you say the same about the resolution itself? Static refresh rate guidance is there for 2 of 3 platforms today. Feels like setting it to auto and the client sending 60hz by default makes the guidance fairly sane.

[cgarst]

Oh btw - these tools won't enable a user to set a refresh rate that isn't advertised by the display to the OS. A weird number simply won't do anything. These commands are only able to set the same options as the user can set themselves in the OS UI.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.18%. Comparing base (9d5ee2f) to head (be1adea).

Additional details and impacted files

@@ Coverage Diff @@## nightly #2503 +/- ##
========================================
Coverage 6.18% 6.18% ========================================
Files 86 86 Lines 17548 17548 Branches 8186 8186 ========================================
Hits 1085 1085 - Misses 14652 15359 +707 + Partials 1811 1104 -707 

Flag	Coverage Δ
Linux	4.26% <ø> (ø)
Windows	2.04% <ø> (ø)
macOS-12	8.74% <ø> (+0.01%)	⬆️
macOS-13	7.85% <ø> (ø)
macOS-14	8.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 26 files with indirect coverage changes

[cgarst]

Description

The Resolution Automation example text is inconsistent about refresh rate across platforms. The refresh rate flag is omitted for QRes Windows and suggested with a static 60 for xrandr (Linux) and displayplacer (Mac). Given the rise in average refresh rates on mobile devices I suspect users prefer seeing refresh rate handling guidance in the example commands.

Note that the Moonlight client apps typically default to 60 as the default refresh rate passed to Sunshine. Users with high refresh devices typically set a higher preference in their Moonlight client settings to feed >60 into the Sunshine prep command.

Screenshot

Issues Fixed or Closed

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

I'm not sure it's wise to add this to the examples as users will blindly set the refresh rate, and possibly to unsupported refresh rates.

[cgarst]

Couldn't you say the same about the resolution itself? Static refresh rate guidance is there for 2 of 3 platforms today. Feels like setting it to auto and the client sending 60hz by default makes the guidance fairly sane.

[cgarst]

Oh btw - these tools won't enable a user to set a refresh rate that isn't advertised by the display to the OS. A weird number simply won't do anything. These commands are only able to set the same options as the user can set themselves in the OS UI.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.18%. Comparing base (9d5ee2f) to head (be1adea).

Additional details and impacted files

@@ Coverage Diff @@## nightly #2503 +/- ##
========================================
Coverage 6.18% 6.18% ========================================
Files 86 86 Lines 17548 17548 Branches 8186 8186 ========================================
Hits 1085 1085 - Misses 14652 15359 +707 + Partials 1811 1104 -707 

Flag	Coverage Δ
Linux	4.26% <ø> (ø)
Windows	2.04% <ø> (ø)
macOS-12	8.74% <ø> (+0.01%)	⬆️
macOS-13	7.85% <ø> (ø)
macOS-14	8.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 26 files with indirect coverage changes

[cgarst]

Description

The Resolution Automation example text is inconsistent about refresh rate across platforms. The refresh rate flag is omitted for QRes Windows and suggested with a static 60 for xrandr (Linux) and displayplacer (Mac). Given the rise in average refresh rates on mobile devices I suspect users prefer seeing refresh rate handling guidance in the example commands.

Note that the Moonlight client apps typically default to 60 as the default refresh rate passed to Sunshine. Users with high refresh devices typically set a higher preference in their Moonlight client settings to feed >60 into the Sunshine prep command.

Screenshot

Issues Fixed or Closed

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

I'm not sure it's wise to add this to the examples as users will blindly set the refresh rate, and possibly to unsupported refresh rates.

[cgarst]

Couldn't you say the same about the resolution itself? Static refresh rate guidance is there for 2 of 3 platforms today. Feels like setting it to auto and the client sending 60hz by default makes the guidance fairly sane.

[cgarst]

Oh btw - these tools won't enable a user to set a refresh rate that isn't advertised by the display to the OS. A weird number simply won't do anything. These commands are only able to set the same options as the user can set themselves in the OS UI.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.18%. Comparing base (9d5ee2f) to head (be1adea).

Additional details and impacted files

@@ Coverage Diff @@## nightly #2503 +/- ##
========================================
Coverage 6.18% 6.18% ========================================
Files 86 86 Lines 17548 17548 Branches 8186 8186 ========================================
Hits 1085 1085 - Misses 14652 15359 +707 + Partials 1811 1104 -707 

Flag	Coverage Δ
Linux	4.26% <ø> (ø)
Windows	2.04% <ø> (ø)
macOS-12	8.74% <ø> (+0.01%)	⬆️
macOS-13	7.85% <ø> (ø)
macOS-14	8.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 26 files with indirect coverage changes

[cgarst]

Description

The Resolution Automation example text is inconsistent about refresh rate across platforms. The refresh rate flag is omitted for QRes Windows and suggested with a static 60 for xrandr (Linux) and displayplacer (Mac). Given the rise in average refresh rates on mobile devices I suspect users prefer seeing refresh rate handling guidance in the example commands.

Note that the Moonlight client apps typically default to 60 as the default refresh rate passed to Sunshine. Users with high refresh devices typically set a higher preference in their Moonlight client settings to feed >60 into the Sunshine prep command.

Screenshot

Issues Fixed or Closed

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

I'm not sure it's wise to add this to the examples as users will blindly set the refresh rate, and possibly to unsupported refresh rates.

[cgarst]

Couldn't you say the same about the resolution itself? Static refresh rate guidance is there for 2 of 3 platforms today. Feels like setting it to auto and the client sending 60hz by default makes the guidance fairly sane.

[cgarst]

Oh btw - these tools won't enable a user to set a refresh rate that isn't advertised by the display to the OS. A weird number simply won't do anything. These commands are only able to set the same options as the user can set themselves in the OS UI.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.18%. Comparing base (9d5ee2f) to head (be1adea).

Additional details and impacted files

@@ Coverage Diff @@## nightly #2503 +/- ##
========================================
Coverage 6.18% 6.18% ========================================
Files 86 86 Lines 17548 17548 Branches 8186 8186 ========================================
Hits 1085 1085 - Misses 14652 15359 +707 + Partials 1811 1104 -707 

Flag	Coverage Δ
Linux	4.26% <ø> (ø)
Windows	2.04% <ø> (ø)
macOS-12	8.74% <ø> (+0.01%)	⬆️
macOS-13	7.85% <ø> (ø)
macOS-14	8.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 26 files with indirect coverage changes

[cgarst]

Description

The Resolution Automation example text is inconsistent about refresh rate across platforms. The refresh rate flag is omitted for QRes Windows and suggested with a static 60 for xrandr (Linux) and displayplacer (Mac). Given the rise in average refresh rates on mobile devices I suspect users prefer seeing refresh rate handling guidance in the example commands.

Note that the Moonlight client apps typically default to 60 as the default refresh rate passed to Sunshine. Users with high refresh devices typically set a higher preference in their Moonlight client settings to feed >60 into the Sunshine prep command.

Screenshot

Issues Fixed or Closed

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

I'm not sure it's wise to add this to the examples as users will blindly set the refresh rate, and possibly to unsupported refresh rates.

[cgarst]

Couldn't you say the same about the resolution itself? Static refresh rate guidance is there for 2 of 3 platforms today. Feels like setting it to auto and the client sending 60hz by default makes the guidance fairly sane.

[cgarst]

Oh btw - these tools won't enable a user to set a refresh rate that isn't advertised by the display to the OS. A weird number simply won't do anything. These commands are only able to set the same options as the user can set themselves in the OS UI.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.18%. Comparing base (9d5ee2f) to head (be1adea).

Additional details and impacted files

@@ Coverage Diff @@## nightly #2503 +/- ##
========================================
Coverage 6.18% 6.18% ========================================
Files 86 86 Lines 17548 17548 Branches 8186 8186 ========================================
Hits 1085 1085 - Misses 14652 15359 +707 + Partials 1811 1104 -707 

Flag	Coverage Δ
Linux	4.26% <ø> (ø)
Windows	2.04% <ø> (ø)
macOS-12	8.74% <ø> (+0.01%)	⬆️
macOS-13	7.85% <ø> (ø)
macOS-14	8.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 26 files with indirect coverage changes

[cgarst]

Description

The Resolution Automation example text is inconsistent about refresh rate across platforms. The refresh rate flag is omitted for QRes Windows and suggested with a static 60 for xrandr (Linux) and displayplacer (Mac). Given the rise in average refresh rates on mobile devices I suspect users prefer seeing refresh rate handling guidance in the example commands.

Note that the Moonlight client apps typically default to 60 as the default refresh rate passed to Sunshine. Users with high refresh devices typically set a higher preference in their Moonlight client settings to feed >60 into the Sunshine prep command.

Screenshot

Issues Fixed or Closed

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

I'm not sure it's wise to add this to the examples as users will blindly set the refresh rate, and possibly to unsupported refresh rates.

[cgarst]

Couldn't you say the same about the resolution itself? Static refresh rate guidance is there for 2 of 3 platforms today. Feels like setting it to auto and the client sending 60hz by default makes the guidance fairly sane.

[cgarst]

Oh btw - these tools won't enable a user to set a refresh rate that isn't advertised by the display to the OS. A weird number simply won't do anything. These commands are only able to set the same options as the user can set themselves in the OS UI.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.18%. Comparing base (9d5ee2f) to head (be1adea).

Additional details and impacted files

@@ Coverage Diff @@## nightly #2503 +/- ##
========================================
Coverage 6.18% 6.18% ========================================
Files 86 86 Lines 17548 17548 Branches 8186 8186 ========================================
Hits 1085 1085 - Misses 14652 15359 +707 + Partials 1811 1104 -707 

Flag	Coverage Δ
Linux	4.26% <ø> (ø)
Windows	2.04% <ø> (ø)
macOS-12	8.74% <ø> (+0.01%)	⬆️
macOS-13	7.85% <ø> (ø)
macOS-14	8.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 26 files with indirect coverage changes

[cgarst]

Description

The Resolution Automation example text is inconsistent about refresh rate across platforms. The refresh rate flag is omitted for QRes Windows and suggested with a static 60 for xrandr (Linux) and displayplacer (Mac). Given the rise in average refresh rates on mobile devices I suspect users prefer seeing refresh rate handling guidance in the example commands.

Note that the Moonlight client apps typically default to 60 as the default refresh rate passed to Sunshine. Users with high refresh devices typically set a higher preference in their Moonlight client settings to feed >60 into the Sunshine prep command.

Screenshot

Issues Fixed or Closed

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

I'm not sure it's wise to add this to the examples as users will blindly set the refresh rate, and possibly to unsupported refresh rates.

[cgarst]

Couldn't you say the same about the resolution itself? Static refresh rate guidance is there for 2 of 3 platforms today. Feels like setting it to auto and the client sending 60hz by default makes the guidance fairly sane.

[cgarst]

Oh btw - these tools won't enable a user to set a refresh rate that isn't advertised by the display to the OS. A weird number simply won't do anything. These commands are only able to set the same options as the user can set themselves in the OS UI.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.18%. Comparing base (9d5ee2f) to head (be1adea).

Additional details and impacted files

@@ Coverage Diff @@## nightly #2503 +/- ##
========================================
Coverage 6.18% 6.18% ========================================
Files 86 86 Lines 17548 17548 Branches 8186 8186 ========================================
Hits 1085 1085 - Misses 14652 15359 +707 + Partials 1811 1104 -707 

Flag	Coverage Δ
Linux	4.26% <ø> (ø)
Windows	2.04% <ø> (ø)
macOS-12	8.74% <ø> (+0.01%)	⬆️
macOS-13	7.85% <ø> (ø)
macOS-14	8.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 26 files with indirect coverage changes

[cgarst]

Description

The Resolution Automation example text is inconsistent about refresh rate across platforms. The refresh rate flag is omitted for QRes Windows and suggested with a static 60 for xrandr (Linux) and displayplacer (Mac). Given the rise in average refresh rates on mobile devices I suspect users prefer seeing refresh rate handling guidance in the example commands.

Note that the Moonlight client apps typically default to 60 as the default refresh rate passed to Sunshine. Users with high refresh devices typically set a higher preference in their Moonlight client settings to feed >60 into the Sunshine prep command.

Screenshot

Issues Fixed or Closed

N/A

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[CLAassistant]

All committers have signed the CLA.

[ReenigneArcher]

I'm not sure it's wise to add this to the examples as users will blindly set the refresh rate, and possibly to unsupported refresh rates.

[cgarst]

Couldn't you say the same about the resolution itself? Static refresh rate guidance is there for 2 of 3 platforms today. Feels like setting it to auto and the client sending 60hz by default makes the guidance fairly sane.

[cgarst]

Oh btw - these tools won't enable a user to set a refresh rate that isn't advertised by the display to the OS. A weird number simply won't do anything. These commands are only able to set the same options as the user can set themselves in the OS UI.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.18%. Comparing base (9d5ee2f) to head (be1adea).

Additional details and impacted files

@@ Coverage Diff @@## nightly #2503 +/- ##
========================================
Coverage 6.18% 6.18% ========================================
Files 86 86 Lines 17548 17548 Branches 8186 8186 ========================================
Hits 1085 1085 - Misses 14652 15359 +707 + Partials 1811 1104 -707 

Flag	Coverage Δ
Linux	4.26% <ø> (ø)
Windows	2.04% <ø> (ø)
macOS-12	8.74% <ø> (+0.01%)	⬆️
macOS-13	7.85% <ø> (ø)
macOS-14	8.19% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 26 files with indirect coverage changes