Date: Sat, 09 May 2020 03:02:45 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 246319] x11-drivers/xf86-video-scfb X windows fails to start on recent 12.1-STABLE Message-ID: <bug-246319-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246319 Bug ID: 246319 Summary: x11-drivers/xf86-video-scfb X windows fails to start on recent 12.1-STABLE Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: x11@FreeBSD.org Reporter: bscott@bunyatech.com.au Flags: maintainer-feedback?(x11@FreeBSD.org) Assignee: x11@FreeBSD.org The problem appears to come down to (extract from Xorg.0.log): [ 52819.563] scfb: PreInit 0 [ 52819.563] (II) scfb(0): Using: depth (24), width (1280), height (10= 24) [ 52819.563] (EE) scfb(0): Specified fbbpp (24) is not a permitted value [ 52819.563] (II) UnloadModule: "scfb" [ 52819.563] (EE) Screen(s) found, but none have a usable configuration. I've experimented with different values for Depth and FbBpp (and Default...= ) in xorg.conf with very little changing. I have seen recent reference[1] to the same error (except for FBTURBO) on l= inux recently due to changed firmware where the problem would seem to be includi= ng an incorrect parameter framebuffer_depth=3D24 in their config.txt file and = the fix was to remove the offending line. Unfortunately I didn't have a framebuffer_depth=3D parameter in mine so I tried adding one with a value o= f 32. This didn't have any effect. In both cases the boot messages for the framebuffer show the messages: fb0: <BCM2835 VT framebuffer driver> on simplebus0 fbd0 on fb0 VT: Replacing driver "efifb" with new "fb". fb0: 1280x1024(1280x1024@0,0) 24bpp fb0: fbswap: 1, pitch 3840, base 0x3e83a000, screen_size 3932160 The fdt doesn't appear to have much of an opinion on the matter other than = the format looks like 32 bits (8 alpha(ignored), 8 red, 8 green, and 8 blue): framebuffer@3e6fa000 { format =3D "a8r8g8b8"; stride =3D <0x1400>; height =3D <0x400>; width =3D <0x500>; reg =3D <0x3e6fa000 0x500000>; compatible =3D "simple-framebuffer"; status =3D "okay"; }; I've had a little dig around in the code and can't see any recent changes, = much less any smoking guns of work in this sort of area. I should qualify that by saying that I'm definitely no expert and won't have hit the whole chain by = any stretch. xf86-video-scfb hasn't changed significantly for a while. It seems to take = what it is given by the underlying framebuffer and passes it back to X. The error message: "Specified fbbpp (24) is not a permitted value" isn't generated by this driver but I'm guessing by X when the 24bpp is passed back. sys/arm/broadcom/bcm2835/bcm2835_fb.c on stable/12 hasn't changed in any relevant way recently but does include some interesting things: #define FB_DEPTH 24 and later on: fb.bpp =3D FB_DEPTH; between calls to bcm2835_mbox_fb_get_w_h and bcm2835_mbox_fb_init. This is followed shortly after by sc->depth =3D fb.bpp; setting up what is = then retrieved by the X driver. Neither bcm2835_mbox_fb_get_w_h or bcm2835_mbox_fb_init change the bpp value but _fb_init uses it in a request to the firmware: msg.depth.body.req.bpp =3D fb->bpp; I haven't tinkered around with this at all because I'm comprehensively out = my depth at this point and building new kernels is a very slow way to experime= nt. The snapshots that I've tried are FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200326-r359308.img.xz, FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200409-r359721.img.xz and FreeBSD-12.1-STABLE-arm64-aarch64-RPI3-20200430-r360472.img.xz. The system I had been running before I trashed it was FreeBSD-12.1-RELEASE-arm64-aarch64-RPI3.img.xz. I have an older system layi= ng about (12.0 RELEASE) that I have tried and have verified that the fdt for t= he framebuffer hasn't changed. The fb messages at startup were also identical (i.e.indicating 24bpp because that's all the code can show). As an experiment, I tried doing some mix and match with kernels. My setup h= as the boot and kernel on the SD card and everything else on a USBconnected dr= ive. So... 12.0 RELEASE kernel + 12.1 STABLE world + packages etc - Same result. Inval= id bpp in X. 12.1 STABLE kernel + 12.0 RELEASE + a bunch of very outdated packages - Wor= ks perfectly. Nice looking X display. Various hacks in xf86-video-scfb such as forcing a FbBpp value of 32 irrespective of the returned value creates junk video (i.e. removed the eff= ect of the error checking) that may indicate that the underlying frame buffer t= ruly is 24bpp but X is refusing to support it. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246319-7141>