Automatic Resolution Detection

[thebeline]

Added support for OCTOSCREEN_RESOLUTION=AUTO which uses xrandr to detect the default display resolution automatically.

Additionally, added check and error reporting for minimum resolution requirements.

Kind of inspired by issues such as #246, but probably not exactly a resolution to those issues, as the screen it's self still needs to be configured correctly.

This has been compiled and is running on all of my systems and behaves as expected.

[JeffB42]

@thebeline This looks interesting. I think it's too late for it to go into 2.7 (plus, it's labeled as experimental). Let's keep the PR open and I'll revisit this in during the development of 2.8.

[thebeline]

@thebeline This looks interesting. I think it's too late for it to go into 2.7 (plus, it's labeled as experimental). Let's keep the PR open and I'll revisit this in during the development of 2.8.

I mean. To be fair, I was the one who tagged it experimental. 😏 I'm currently running it on a 3.5 (yes, one of the evil ones) and a 5 inch display. So far so good.

The only reason I tagged it experimental is because it would need to be tested by someone with a 7, 8, 10, 2.5, etc etc. Which I don't have. 🤔

That being said, I can't see a reason it would fail.

[thebeline]

I spent some time considering failure states that would cause me concern, and I can only really think of 3:

• xrandr is not installed or available
  This is installed by default, so unlikely, but I will add it to the dependencies to be sure.
• The configured resolution of the display is less than the minimums
  This would exit the app with a miss-configured resolution error, as it would anyway. However, the check for this exits as a Fatal, so, on a fresh 3.5 with AUTO set and no drivers would loop. Which is less than ideal, so... That should probably be handled better.
• The user has multiple screens installed and somehow they are not mirrored?
  I can't think of how this would occur, or even how to make if occur (for testing), but... maybe? Seems too edge-case to be a concern.

So, of those three concerns, the first is an easy fix, the third is so edge-case so as to be irrelevant, and the second... Well... Kind of relates to #261, and is ultimately outside the scope of this feature.

I will push a few changes shortly.

[JeffB42]

The user has multiple screens installed and somehow they are not mirrored?

Just a FYI, I've taken the position that only select hardware (RPi3 & RPi4 - no Pi-Zero) and configurations are supported (OctoPi only, no other distros). This also includes telling users that only a single display is supported, and OctoScreen needs to be the only GUI/X11 process running (so no Debian desktop).

[thebeline]

The user has multiple screens installed and somehow they are not mirrored?

Just a FYI, I've taken the position that only select hardware (RPi3 & RPi4 - no Pi-Zero) and configurations are supported (OctoPi only, no other distros). This also includes telling users that only a single display is supported, and OctoScreen needs to be the only GUI/X11 process running (so no Debian desktop).

Well then it seems that edge-case is null, then. So, if the "supported" configurations are predictable, TBH, I would consider AUTO to be default. With manual setting for "unsupported edge-cases."

My thoughts

[thebeline]

@JeffB42 - Merge conflict resolved. Thanks for the error handling bit, I was a little confused on how that worked in Go.

[thebeline]

@JeffB42 - I am rounding back to some of my work here, wanted to check before I merged master into my branches if the PRs and branches are even relevant any more. With regards to this branch, is this something I should test to be sure it behaves as described and re-consider? Or is this no longer relevant?