On Sat, Jul 06, 2019 at 08:52:43AM +0000, maya%netbsd.org@localhost wrote: > Yes, that would be nice. Even if we fail to make your card work, it'll > save a few steps for the next person trying to get it functional. Ok, what is the procedure for this, and where can I find the licence for the blobs, so that I can check if it's fine to add them? > However if we fail to make your card work we should add it to the > card blacklist in > sys/external/bsd/drm2/nouveau/nouveau_pci.c:nouveau_pci_match > > (I'm assuming it doesn't know how to recover cleanly) I can't start X, but I do get a graphical console (I got that even before without the firmware). > > I still get the same 4 errors from the driver as before though: > > > > [ 4.674760] nouveau0: autoconfiguration error: error: DRM: Pointer to flat panel table invalid > > This failure can be normal. > > > [ 4.674760] nouveau0: autoconfiguration error: warn: DRM: unknown connector type 70 > > This is no longer unrecognised upstream. > case DCB_CONNECTOR_WFD : return DRM_MODE_CONNECTOR_VIRTUAL; > > The git blame points to... > > commit df00d5da609f59022ee9aafdb4e2313aefeb6bda > Author: Rosen Penev <rosenp%gmail.com@localhost> > Date: Tue Jul 25 17:21:43 2017 -0700 > > drm/nouveau/disp: Silence DCB warnings. > > Most of these errors seem to be WFD related. Official documentation > says dcb type 8 is reserved. It's probably used for WFD. Silence > the warning in either case. > > Connector type 70 is stated to be a virtual connector for WiFi > display. Since we know this, don't warn that we don't. > > So, another warning to skip. Should we disable these in our tree? > > [ 4.674760] nouveau0: autoconfiguration error: warn: DRM: failed to create encoder 1/8/0: -19 > > ret here is -19, -ENODEV. > > That means switch (dcbe->type) is not DCB_OUTPUT_TMDS, DCB_OUTPUT_LVDS, DCB_OUTPUT_DP, DCB_OUTPUT_ANALOG. > > What outputs do you have? I see three Displayport, one HDMI and one DVI-I. > > [ 4.674760] nouveau0: autoconfiguration error: warn: DRM: Unknown-1 has no encoders, removing > > It gave up on this output since it doesn't know what to do with it. > > > > Full dmesg, with boot -x, might be more insightful. Does it have more > connectors that are fine? boot -x is too large for the default message buffer (should we perhaps increase that, at least on amd64?) but it contains plenty nouveau lines, is it sufficient? I'll also attach the output without -x. Thomas
Attachment:
boot-no-x.gz
Description: application/gunzip
Attachment:
boot-with-x.gz
Description: application/gunzip