Looking at the Mir code it seems like this could be Mir's fault.
In hwc_blanking_control.cpp we only select (display_config_for) the first or "active" display config. I don't think this approach will work when setting up a new external display. Simply falling back to the first config in the list could easily be wrong.
That said, the HWC headers don't seem to help us. They only appear to provide width, height, and frequency information for each config. So we've apparently got no chance of correctly identifying which is the correct native resolution for an external display connected to an Android device.
What we could do however is expose all the available display configs as separate modes to Mir and that will allow the user to change the display mode in future (when a GUI exists for it). That's probably what should have been done in the first place.
Looking at the Mir code it seems like this could be Mir's fault.
In hwc_blanking_ control. cpp we only select (display_ config_ for) the first or "active" display config. I don't think this approach will work when setting up a new external display. Simply falling back to the first config in the list could easily be wrong.
That said, the HWC headers don't seem to help us. They only appear to provide width, height, and frequency information for each config. So we've apparently got no chance of correctly identifying which is the correct native resolution for an external display connected to an Android device.
What we could do however is expose all the available display configs as separate modes to Mir and that will allow the user to change the display mode in future (when a GUI exists for it). That's probably what should have been done in the first place.