On Wed, Jan 11, 2017 at 01:11:45PM +0200, 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 ? Yeah, if the issue is just that by default android expects fbdev and gets confused if it's not there, then I don't think that patch makes much sense. If we need it because hw is horrible and this is the only way to make fbcon work reasonably well, I'm all fine with that. Either way, other people piping up with "I want this too" would help a lot. Even better when they do a full review :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
