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@xxxxxxxxxxxxxxx> > > > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
