On Tue, 7 May 2024, Riccardo Mottola wrote: > John D. Baker wrote: > > As you have seen, the "radeon*" and "radeondrmkmsfb*" drivers do not > > attach on "r100" class devices. They have been explicitly excluded > > because early in the DRMKMS integration in NetBSD, they exhibited the > > "(almost) black-on-black" video problem described in: > > I remember seeing that issue.. long time ago, but don't remember on > which OS and hardware combination. > > However, i checked a little better. > ATI Technologies Radeon > Mobility M7 LW (rev. 0x00) > > would be an RS250 chip, so a little bit newer. Does the same issue > apply? or is it "blacklisted" for any other reason?
That looks like the same description of the radeon device in my T42 ThinkPad: $ grep Radeon /r0/diskless/slate/var/run/dmesg.boot vga0 at pci1 dev 0 function 0: ATI Technologies Radeon Mobility M7 LW (rev. 0x00) radeondrm0 at vga0: ATI Radeon LW RV200 Mobility 7500 M7 (radeondrm0 is the legacy UMS "radeondrm* at drm?" device) As an R*200 device, it is not matched by the DRM2 code in NetBSD. > Since I am endeavouring in compiling a kernel, I might try enabling it, > if you tell me how. Just as a test, maybe magic happens. The following patch (against -current from about 4 years ago) will enable matching R100/R200 devices: +Index: sys/external/bsd/drm2/radeon/radeon_pci.c +=================================================================== +RCS file: /cvsroot/src/sys/external/bsd/drm2/radeon/radeon_pci.c,v +retrieving revision 1.14 +diff -u -p -r1.14 radeon_pci.c +--- sys/external/bsd/drm2/radeon/radeon_pci.c 24 Jan 2020 11:44:27 -0000 1.14 ++++ sys/external/bsd/drm2/radeon/radeon_pci.c 28 May 2020 23:49:44 -0000 +@@ -126,7 +126,7 @@ extern const struct pci_device_id *const + extern const size_t radeon_n_device_ids; + + /* Set this to false if you want to match R100/R200 */ +-bool radeon_pci_ignore_r100_r200 = true; ++bool radeon_pci_ignore_r100_r200 = false; + + static bool + radeon_pci_lookup(const struct pci_attach_args *pa, unsigned long *flags) > I also tried to compare with OpenBSD on another Laptop where > framebwuffer runs wonderfully. It uses radeondrm0. I don't know how this > in OpenBSD speak this compares to NetBSD. I really don't know. My understanding is that on OpenBSD and various Penguin-OSes, these older ATI devices work fine. I saw your message about trying "radeonfb* at pci?" in your kernel config. I did the same for amd64 systems with ATI ES1000, which also exhibits the "(almost) black-on-black" video problem if radeon*/radeondrmkmsfb* is allowed to match it: vga0 at pci6 dev 3 function 0: ATI Technologies ES1000 (rev. 0x02) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0 wsmux1: connecting to wsdisplay0 radeondrm0 at vga0: ATI ES1000 RN50 radeondrm0: Initialized radeon 1.29.0 20080613 but "radeonfb*" didn't attach and I got plain VGA instead. "radeondrm0" is the legacy UMS "radeondrm* at drm?". I did remember to re-enable "wsdisplay* at wsemuldisplaydev?", but maybe it failed because I forgot to re-enable the framebuffer font(s). -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSD FreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645