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?
Attachment:
signature.asc
Description: PGP signature
