[Intel-gfx] [PATCH v2 2/2] drm/i915: Don't advertise modes that exceed the max plane size

Ville Syrjälä ville.syrjala at linux.intel.com
Thu Sep 19 13:10:18 UTC 2019


On Wed, Sep 18, 2019 at 04:21:06PM -0400, Sean Paul wrote:
> On Wed, Sep 18, 2019 at 07:02:18PM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 18, 2019 at 11:24:09AM -0400, Sean Paul wrote:
> > > On Wed, Sep 18, 2019 at 06:07:07PM +0300, Ville Syrjala wrote:
> > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > Modern platforms allow the transcoders hdisplay/vdisplay to exceed the
> > > > planes' max resolution. This has the nasty implication that modes on the
> > > > connectors' mode list may not be usable when the user asks for a
> > > > fullscreen plane. Seeing as that is the most common use case it seems
> > > > prudent to filter out modes that don't allow for fullscreen planes to
> > > > be enabled.
> > > > 
> > > > Let's do that in the connetor .mode_valid() hook so that normally
> > > > such modes are kept hidden but the user is still able to forcibly
> > > > specify such a mode if they know they don't need fullscreen planes.
> > > > 
> > > > This is in line with ealier policies regarding certain clock limits.
> > > > The idea is to prevent the casual user from encountering a mode that
> > > > would fail under typical conditions, but allow the expert user to
> > > > force things if they so wish.
> > > 
> > > Isn't this exactly what atomic_check is for? Why not just add a debug message in
> > > get_max_plane_size to leave a breadcrumb?
> > 
> > There's already a debug message. Won't really help when the screen fails
> > to light up automagically on account of the preferred mode being too
> > big.
> 
> That's not the kernel's fault, why are we working around it at this level? There
> are lots of reasons beyond max plane size that can cause a modeset to fail. If
> userspace doesn't already have the smarts to fallback to a lower resolution on
> modeset failure, we should fix it or just ¯\_(ツ)_/¯

Sure, userspace (and fb_helper) should be smarter about this.
Unfortunately I don't have a time machine to deploy such a backport
so this is the best I can do for current userspace.

-- 
Ville Syrjälä
Intel


More information about the Intel-gfx mailing list