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@xxxxxx> >>>> >>>> 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@xxxxxx> >>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxx> >>> >>> 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. Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
