[PATCH v2] drm: get fbdev size from cmdline mode if it exists

[Vincent ABRIOU]

On 01/11/2017 12:11 PM, Laurent Pinchart wrote:
> 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
>

Android support fbdev and drm/kms.

> I haven't checked the latest version to be honest.
>

The last Android version still support fbdev.

Vincent