On Tue, Dec 13, 2016 at 04:52:01PM +0200, Jani Nikula wrote: > On Tue, 13 Dec 2016, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Dec 13, 2016 at 03:46:54PM +0530, Vidya Srinivas wrote: > >> Currently in dual display connected boot scenarios, minimum of the resolutions > >> is taken for fb width and height as reference. Based on this resolution, other > >> modes are pruned. > >> > >> Example Scenario: If DSI mode is 2560x1440 and HDMI is 1920x1080, during the probing > >> the fb width and height is set to max 1920x1080 and the DSI mode gets pruned as it is > >> more than the reference. As a result, there is no DSI display. > >> Patch fixes this issue by taking the max of the resolutions and creating the fb > >> based on the same. > > > > On the other hand, the viewable content is defined by the smaller mode. > > If that is the only output visible at panic time, you don't want that > > information lost due to it being invisible. > > > > This is only used for fbcon, which has to be the lowest common > > denominator. Any actual application can set their own modes and fb. > > Do we fail to take over non-native modes with scaling on DSI then? > Ville? I believe we are taking the panel fitter into account when we reconstruct the BIOS fb. So in case the BIOS is upscaling we'll come up with some less than screen size framebuffer. The fb helper will want to use the native mode of the panel however, so at some point we'll drop the BIOS fb (as it's too small) and allocate a new one. -- Ville Syrjälä Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
