[PATCHv2 26/31] drm/omap: Create fbdev emulation only for the first DRM connector

[Daniel Vetter]

On Mon, Mar 27, 2017 at 10:25:46AM +0300, Tomi Valkeinen wrote:
> On 27/03/17 09:40, Daniel Vetter wrote:
> > On Mon, Mar 27, 2017 at 09:28:07AM +0300, Tomi Valkeinen wrote:
> >> On 25/03/17 23:22, Daniel Vetter wrote:
> >>> On Fri, Mar 24, 2017 at 11:40:47AM +0200, Tomi Valkeinen wrote:
> >>>> From: Peter Ujfalusi <peter.ujfalusi at ti.com>
> >>>>
> >>>> Add fbdev emulation only for the first DRM connector.
> >>>> When the fbdev emulation was created for all connectors with different
> >>>> resolution, the lower res display would only be able to show part of the
> >>>> framebuffer.
> >>>> By creating the fbdev emulation only for the first connector we can avoid
> >>>> this.
> >>>>
> >>>> Signed-off-by: Peter Ujfalusi <peter.ujfalusi at ti.com>
> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen at ti.com>
> >>>
> >>> Why this driver-specific behavior? This is how it works everywhere.
> >>>
> >>> If this doesn't work in some case, then we need to fix this in the fbdev
> >>> helper. Or have a modparam for that. But definitely not diverging
> >>> behaviour between drivers.
> >>
> >> The default behavior often results in a rather unusable fbdev on the
> >> other screen.
> >>
> >> For example, a board with a low-res LCD and HDMI. Fbdev is created based
> >> in the LCD resolution, and on HDMI you'll get 1080p resolution with a
> >> tiny fbdev. Or, if fbdev is created based on the HDMI resolution, on the
> >> LCD you'll see a tiny portion of the huge fbdev.
> >>
> >> I personally did suggest our folks to just disable the fbdev totally,
> >> but apparently there are still some uses for the fbdev, so this patch
> >> seemed like a simple way to make the behavior a bit nicer.
> >>
> >> But I agree that it would be best to have this fully configurable, as
> >> different use cases have different needs. Then again, I'd rather just
> >> disable the fbdev than start spending time on improving it =).
> > 
> > Yeah I think a module option for  the fbdev helper which implements
> > exactly this would be fine. Assuming that would make your users happy.
> > 
> > I just want to avoid everyone having to hand-roll the same hacks, since
> > this problem is the same everywhere (never boot with a retina screen and
> > the low-res projector plugged in ...).
> 
> Ok, I'll drop this for now and look for a more generic solution.
> 
> What should the default behavior be? The current one? Module parameters
> are often nice, but if the wanted default behavior (as it is for us)
> requires setting a parameter, it's not so nice.
> 
> Is it ok if the driver can choose its default behavior, which can then
> be overridden with module parameters?
> 
> Then again... I get the gut feeling that this is kind of pointless
> effort. fbdev won't work well anyway =). Even if we had such a module
> parameter, would you bother and remember to set it when booting with
> retina and a low-res projector? When you'd notice that the fbdev is
> messed up, would you reboot and set the module parameter, or would you
> just unplug the projector and reboot without it?
> 
> In other words, would such a parameter really be usable...
> 
> I don't know... I think the only sane behavior is to have the fbdev only
> on a single screen. Or, on multiple screens but only if the resolutions
> of the displays are exactly the same. Or if you can scale the fbdev so
> that it fits into any screen.

I think we could do the module param + Kconfig default like the recent
overallocation thing. And yes I'm torn on fbdev too, but otoh if we can
make the kms fbdev emulation more feature-full and useful (with minimal
amount of work), that means more reasons to abandon fbdev drivers and use
kms drivers. Even when userspace won't switch just yet. I think that's
good, because it's gets kms foot into the door.

Same reason really why we grumpily merged the vblank wait and
overallocation/page-flip patches.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch