Better support for non-1080p displays

[pdsouza]

There have been a few reports of Maru OS picking a lower resolution than optimal on displays that do not support 1080p.

Ideally, we should be able to switch resolutions dynamically but this may be pretty tricky given the HDMI support on Android. At the least, look into improving the algorithm for selecting the best monitor mode.

Related posts:
https://groups.google.com/d/msg/maru-os/YexPDVojqgI/Nr_Hi5KgBgAJ
https://groups.google.com/forum/#!topic/maru-os/4Q9IHl-FpzE
https://groups.google.com/forum/#!topic/maru-os/s-DutzPsAdg

[pdsouza]

Added an enhanced resolution matching tweak that may improve this. At the very least, it makes the Nexdock (native res 1366x768) work properly at 720p without text scaling!

It will be disabled by default, but available as a settings option under Settings > Desktop > Tweaks since it needs more testing in the wild.

[sixtyfive]

Why does it have to be automatical? Simply a list of resolutions to select from manually would be a good first step, wouldn't it?

[DeXP]

+1 for resolutions list
https://groups.google.com/forum/#!topic/maru-os/rTTFJ0PnfGk

[mariogrip]

@pdsouza could you upload an image (with Settings > Desktop > Tweaks) so i can try it with my nexdock? I know i build it myself, but it would take a really long time to download the source on my network... Thanks :)

[pdsouza]

@mariogrip I'll have a proper release image available as soon as the next release is ready. Shouldn't be much longer!

[pdsouza]

Manual resolution selection can help, but some of these resolutions just aren't supported by the hardware display driver at all. Even worse, some display drivers only report the single best matching resolution after running it through an internal filter of compatible resolutions...they don't even report the others back to upper layers of the OS to report back to the user for manual selection. These drivers were really designed with standard HDMI displays in mind, and they tend to only support standard resolutions in the HDMI 1.3a spec / CEA-861.

For example, hammerhead's display driver doesn't support 1680x1050 at all (not on the HDMI spec of standard timings), and will only report back the best matching resolution that the monitor reports, bravely trying to default back to 640x480 if none is found.

In the case of multiple adapters from multiple manufacturers (USB -> Slimport -> HDMI -> VGA/DVI), which are typically needed for older monitors that do not support standard timings like 1080p, the situation gets trickier because there could be timing issues introduced by all of the adapters.

When I have time, I'll try to see if this can be improved further, but your best bet is sticking to standard HDMI resolutions. The "try to force native" tweak should help when the device picks a wrong resolution (the hammerhead driver has a weird preference for certain resolutions over others, sometimes picking them over the display's native resolution), but it still won't be able to work with resolutions unsupported by the device driver itself.

Hope this helps shed some light on the complexity of this issue! Hoping to make it better anyways though.

[sixtyfive]

By display driver you mean the firmware on these Slimport-to-whatever adapters?

I find it interesting that it'll default back to 640x480, which isn't one of the resolutions listed in the spec you're linking. In any case, 640x480 would work on any VGA display. So if that resolution could be forced, that'd be a step forward wrt older displays.

Our projector (an Acer X1260) like many projectors I believe, supports a wild amount of resolutions, including some contained in that spec. If you can include a manual selection for whatever resolutions get reported as viable to you, I'll try them all out and report if anything works.

[Regaddi]

The "Enhanced resolution matching" has on my 720p TV screen the effect, that no desktop is shown at all. The phone tells me "Maru Desktop running.", but my TV doesn't receive any signal.

[sixtyfive]

With the difficulties @pdsouza has described, and given the fact the the people who are likely to try out MaruOS at the moment are at the very least early adopters, I really don't see what would be speaking against a long list of resolutions to manually choose from?

[pdsouza]

@Regaddi Thanks for the feedback. Does the desktop display properly with the mode turned off?

@sixtyfive As I mentioned previously, this depends on the device's display driver. This is a hardware-specific driver written by the manufacturer (different per device/SoC) that is usually closed-source and shipped as a binary blob on the device. I explained in my last post that "Even worse, some display drivers only report the single best matching resolution after running it through an internal filter of compatible resolutions...they don't even report the others back to upper layers of the OS to report back to the user for manual selection." hammerhead's display driver only reports ONE resolution back to Android, so it is not possible to even have a list unless the driver is re-structured. Long story short, this is not portable across devices; it may work for one device if it's display driver reports back multiple resolutions, but not others.

[sixtyfive]

@pdsouza Sorry if there's a misunderstanding. I meant to just provide a list of generic resolutions, no matter what the device reports. I.e. just try and force the one that the user chooses. Either it'll work or it throw a horrible error/crash and burn/whatever, but let us try for ourselves!

[Regaddi]

@pdsouza Mostly. There's some overscan setting missing. There are somewhat between 50 and 100px missing on each side.

[pdsouza]

@Regaddi Please try changing your TV's overscan settings as decribed in our FAQ: https://github.com/maruos/maruos/wiki/FAQ#the-outer-edges-of-maru-desktop-do-not-show-up-on-my-tvhow-can-i-fix-it. This is a common issue on TVs vs. monitors.

@sixtyfive I think that could lead to confusion. Ignoring that though, the way the driver interface is architected on Android you can only select from the list of resolutions the display driver reports back, so this is a no-op. I hope we can find a better solution to this.