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@xxxxxx> >>>>>>> Signed-off-by: Vincent Abriou <vincent.abriou@xxxxxx> >>>>>> >>>>>> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
