On Fri, Apr 21, 2017 at 6:53 PM, Eric Anholt <eric@xxxxxxxxxx> wrote: > Daniel Vetter <daniel@xxxxxxxx> writes: > >> On Wed, Apr 19, 2017 at 7:55 PM, Eric Anholt <eric@xxxxxxxxxx> wrote: >>> Daniel Vetter <daniel@xxxxxxxx> writes: >>>> On Tue, Apr 18, 2017 at 9:11 PM, Eric Anholt <eric@xxxxxxxxxx> wrote: >>>>> The FBDEV initialization would throw an error in dmesg, when we just >>>>> want to silently not initialize fbdev on a V3D-only VC4 instance. >>>>> >>>>> Signed-off-by: Eric Anholt <eric@xxxxxxxxxx> >>>> >>>> Hm, this shouldn't be an error really, you might want to hotplug more >>>> connectors later on. What exactly complains? >>> >>> drm_fb_helper_init() throws an error if the passed in connector count is >>> 0, so drm_fb_cma_helper() printks an error. >> >> Oh, _that_ thing. The error in there is correct, but (almost) everyone >> gets this parameter wrong. This isn't the max number of connectors the >> fb helper will light up, but just the max number of connectors _per_ >> crtc when driving in hw clone mode. There's two problems with that: >> - fb helpers don't support hw clone mode, we select 1:1 crtcs for each >> active connector >> - I mentioned that everyone gets this wrong? >> >> If you're moderately bored it'd be great to nuke the max_connector >> argument from drm_fb_helper_init, and hard-code it to 1 (with a big >> comment explaining that this needs to be changed, probably with >> dynamic reallocation, once someone gets around to implementing hw >> clone mode). >> >> If you're less bored, just hardcode this to 1 in vc4 and done. Plus a >> TODO.rst entry would be great in that case. > > If I'm driving a GPU with no display subsystem at all, it seems like I > shouldn't initialize fbdev for it, right? That's what we do for radeon/amdgpu on hw without display blocks. Alex _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
