[PATCH v2] drm: get fbdev size from cmdline mode if it exists
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Wed Jan 11 11:11:45 UTC 2017
Hi Vincent,
On Wednesday 11 Jan 2017 09:03:07 Vincent ABRIOU wrote:
> On 01/11/2017 08:48 AM, Daniel Vetter wrote:
> > On Tue, Jan 10, 2017 at 10:06:44PM +0200, Laurent Pinchart wrote:
> >> On Tuesday 10 Jan 2017 13:33:29 Vincent ABRIOU wrote:
> >>> On 01/10/2017 12:39 PM, Daniel Vetter wrote:
> >>>> On Tue, Jan 10, 2017 at 12:21:09PM +0100, Vincent Abriou wrote:
> >>>>> In case no connector is found while creating the fbdev, gives the
> >>>>> possibility to specify the default fbdev size by firstly checking if
> >>>>> the command line is defining a preferred mode. Else go into fallback
> >>>>> and set 1024x768 fbdev size as it was already done.
> >>>>>
> >>>>> Cc: Tomi Valkeinen <tomi.valkeinen at ti.com>
> >>>>> Signed-off-by: Vincent Abriou <vincent.abriou at st.com>
> >>>>
> >>>> btw on all this there's also the possible solution to delay setup of
> >>>> the fbdev until the first connector switches to connected, and then
> >>>> only allocting the fb and doing the setup. Tegra has that, and Thierry
> >>>> did some patches to move that logic into the fb helpers. But there's
> >>>> some locking issues that need to be fixed first, hence why those
> >>>> patches haven't landed yet.
> >>>>
> >>>> But if you never probe the right mode, this here sounds like a good
> >>>> idea too.
> >>>
> >>> The early creation of fbdev is useful for userland system. If fbdev
> >>> creation is delayed until first connector is connected, userland systems
> >>> startup could fails (like Android that check fbdev availability at
> >>> startup).
> >>>
> >>> Today if no connector is connected, a default 1024x768 fbdev is created
> >>> but it does not necessarily match the targeted CRTC size. When the
> >>> connector is connected, fbdev is not reconfigured with the targeted CRTC
> >>> size and it is anyway too late for the userland to take into account new
> >>> fbdev size. Reading the cmdline is an easy way to solve this.
> >>
> >> Isn't it another case of working around userspace issue in the kernel ?
> >> Shouldn't the offending userspace code be fixed ? And while at it, moved
> >> from fbdev to DRM/KMS ? :-) I wrote a proof-of-concept patch a few years
> >> ago to use DRM/KMS in the Android init process. I'm sure it doesn't
> >> apply cleanly anymore, but I can share it if you're interested.
>
> Android is one example and it still give the possibility to start with
> fbdev. I'm not trying to fixe userspace issue (there is so many userspaces
> :)). The default case to set fbdev to 1024x768 already exist in the drm fb
> helpers. I just add a way to be flexible.
Sure, I understand that. My point is that, instead of making life easy for
userspace that hasn't switched to DRM/KMS yet, wouldn't it be time to push
them a bit more ?
> > So android still doesn't boot without fbdev? I thought that's been fixed
I haven't checked the latest version to be honest.
--
Regards,
Laurent Pinchart
More information about the dri-devel
mailing list