Missing /dev/io on rpi3 running 12-stable

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Missing /dev/io on rpi3 running 12-stable

bob prohaska
Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
a report of "failed to open /dev/io". There is indeed no /dev/io,
but there's also no /dev/io on a pi2 running 12-stable.

Nor does there seem to be  a kernel module with matching name....

Thanks for reading!

bob prohaska

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

Ian Lepore-3
On Wed, 2020-05-20 at 09:46 -0700, bob prohaska wrote:

> Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
> Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
> a report of "failed to open /dev/io". There is indeed no /dev/io,
> but there's also no /dev/io on a pi2 running 12-stable.
>
> Nor does there seem to be  a kernel module with matching name....
>
> Thanks for reading!
>
>

/dev/io is an x86 thing, doesn't apply to arm at all.  It allows
userland processes with sufficient privs to execute x86 in/out
instructions for talking to old-school ISA bus devices such as
keyboards.

-- Ian

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

Mikaël Urankar
In reply to this post by bob prohaska
Le mer. 20 mai 2020 à 18:46, bob prohaska <[hidden email]> a écrit :

>
> Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
> Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
> a report of "failed to open /dev/io". There is indeed no /dev/io,
> but there's also no /dev/io on a pi2 running 12-stable.
>
> Nor does there seem to be  a kernel module with matching name....
>
> Thanks for reading!
>
> bob prohaska

I haven't looked closely but it seems the error is in
x11-servers/xorg-server/files/configure.ac, AC_DEFINE(USE_DEV_IO)
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

bob prohaska
On Wed, May 20, 2020 at 07:09:11PM +0200, Mika??l Urankar wrote:

> Le mer. 20 mai 2020 ?? 18:46, bob prohaska <[hidden email]> a ??crit :
> >
> > Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
> > Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
> > a report of "failed to open /dev/io". There is indeed no /dev/io,
> > but there's also no /dev/io on a pi2 running 12-stable.
> >
> > Nor does there seem to be  a kernel module with matching name....
> >
> > Thanks for reading!
> >
> > bob prohaska
>
> I haven't looked closely but it seems the error is in
> x11-servers/xorg-server/files/configure.ac, AC_DEFINE(USE_DEV_IO)
>

Alas, the remedy does not suggest itself, at least not to me....

Can somebody offer a hint?

Thanks for writing!

bob prohaska

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

Warner Losh
On Wed, May 20, 2020, 12:16 PM bob prohaska <[hidden email]> wrote:

> On Wed, May 20, 2020 at 07:09:11PM +0200, Mika??l Urankar wrote:
> > Le mer. 20 mai 2020 ?? 18:46, bob prohaska <[hidden email]> a
> ??crit :
> > >
> > > Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
> > > Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
> > > a report of "failed to open /dev/io". There is indeed no /dev/io,
> > > but there's also no /dev/io on a pi2 running 12-stable.
> > >
> > > Nor does there seem to be  a kernel module with matching name....
> > >
> > > Thanks for reading!
> > >
> > > bob prohaska
> >
> > I haven't looked closely but it seems the error is in
> > x11-servers/xorg-server/files/configure.ac, AC_DEFINE(USE_DEV_IO)
> >
>
> Alas, the remedy does not suggest itself, at least not to me....
>
> Can somebody offer a hint?
>

Link /dev/bull to /dev/io and see what happens?

Warner


Thanks for writing!
>
> bob prohaska
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]"
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

bob prohaska
In reply to this post by bob prohaska
On Wed, May 20, 2020 at 08:56:31PM +0200, Mika??l Urankar wrote:

> Le mer. 20 mai 2020 ?? 20:16, bob prohaska <[hidden email]> a ??crit :
> >
> > On Wed, May 20, 2020 at 07:09:11PM +0200, Mika??l Urankar wrote:
> > > Le mer. 20 mai 2020 ?? 18:46, bob prohaska <[hidden email]> a ??crit :
> > > >
> > > > Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
> > > > Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
> > > > a report of "failed to open /dev/io". There is indeed no /dev/io,
> > > > but there's also no /dev/io on a pi2 running 12-stable.
> > > >
> > > > Nor does there seem to be  a kernel module with matching name....
> > > >
> > > > Thanks for reading!
> > > >
> > > > bob prohaska
> > >
> > > I haven't looked closely but it seems the error is in
> > > x11-servers/xorg-server/files/configure.ac, AC_DEFINE(USE_DEV_IO)
> > >
> >
> > Alas, the remedy does not suggest itself, at least not to me....
> >
> > Can somebody offer a hint?
>
> edit files/patch-configure, locate USE_DEV_IO and remove the whole hunk.
> then make clean; make deinstall install
>
Looks like it's not quite that simple. I took the "hunk" to be the preceding
line starting with @@ to the next line starting with @@. Make patch
finished with no errors, following a fresh make clean, but the build stopped
with

ld: error: undefined symbol: xf86EnableIO

>>> referenced by sdksyms.c
>>>               sdksyms.o:(xorg_symbols)
>>> referenced by xf86Configure.c
>>>               xf86Configure.o:(DoConfigure) in archive common/.libs/libcommon.a
>>> referenced by xf86Events.c
>>>               xf86Events.o:(xf86VTEnter) in archive common/.libs/libcommon.a
>>> referenced by xf86Init.c
>>>               xf86Init.o:(InitOutput) in archive common/.libs/libcommon.a
>>> referenced by xf86Init.c
>>>               xf86Init.o:(InitOutput) in archive common/.libs/libcommon.a

ld: error: undefined symbol: xf86DisableIO
>>> referenced by sdksyms.c
>>>               sdksyms.o:(xorg_symbols)
>>> referenced by xf86Events.c
>>>               xf86Events.o:(xf86VTLeave) in archive common/.libs/libcommon.a

ld: error: undefined symbol: xf86OSInitVidMem
>>> referenced by vidmem.c
>>>               vidmem.o:(xf86InitVidMem) in archive os-support/.libs/libxorgos.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[6]: *** [Makefile:814: Xorg] Error 1

Not sure what to try next....

Thanks for reading!

bob prohaska

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

bob prohaska
In reply to this post by Ian Lepore-3
On Wed, May 20, 2020 at 11:01:44AM -0600, Ian Lepore wrote:

> On Wed, 2020-05-20 at 09:46 -0700, bob prohaska wrote:
> > Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
> > Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
> > a report of "failed to open /dev/io". There is indeed no /dev/io,
> > but there's also no /dev/io on a pi2 running 12-stable.
> >
> > Nor does there seem to be  a kernel module with matching name....
> >
> > Thanks for reading!
> >
> >
>
> /dev/io is an x86 thing, doesn't apply to arm at all.  It allows
> userland processes with sufficient privs to execute x86 in/out
> instructions for talking to old-school ISA bus devices such as
> keyboards.

Which list is the appropriate forum, -ports, -arm or something else?
If there is a better problem description I'll use it.  ISTR xorg
compiling and running without a hitch on -current previously, ~
a year ago.

Thanks for writing,

bob prohaska
ps, any progress on vc4?

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

freebsd-arm mailing list


On 2020-May-20, at 19:25, bob prohaska <fbsd at www.zefox.net> wrote:
>
> Which list is the appropriate forum, -ports, -arm or something else?
> If there is a better problem description I'll use it.  ISTR xorg
> compiling and running without a hitch on -current previously, ~
> a year ago.

Does not look like I can match the RPi3 context
as a cross check. (I tried.) At best a RPi4.

I do not normally use a display but I normally do
build lumina and what it requires as part of checking
the build environment. (head -r360311 contexts
currently.)

I tried to see what I could do on the RPi3 and RPi4. The
surprise: RPi4 output worked fine at all stages and the
RPI3 got no video output at all at any time, not even the
RPi3's own early-stage test-output. (Same HDMI display
used for both.)

Both the RPi3 and RPi4 do report the following
when the display is connected:

EFI framebuffer information:
addr, size     0x3e513000, 0x6d8c00
dimensions     1824 x 984
stride         1824
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
. . .
VT(efifb): resolution 1824x984

Without the HDMI connection the RPi3 shows:

EFI framebuffer information:
addr, size     0x3eaf7000, 0x103000
dimensions     592 x 448
stride         592
masks          0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
. . .
VT(efifb): resolution 592x448

Back to with the HDMI connection . . .

Both RPi*'s show:

fb0: <BCM2835 VT framebuffer driver> on simplebus0
fb0: keeping existing fb bpp of 32
fbd0 on fb0
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0.
VT: Replacing driver "efifb" with new "fb".
fb0: 1824x984(1824x984@0,0) 32bpp
fb0: fbswap: 1, pitch 7296, base 0x3e513000, screen_size 7237632

It leaves me wondering if the RPi3 has a hardware
problem. (No display output even before u-boot is
involved, unlike normal.)


As for the RPi4: I do not see any attempt at a
/dev/io reference or any additional kernel modules
loaded. It does:

. . .
[   137.989] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
. . .
[   138.129] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
. . .
[   138.136] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
. . .
[   138.141] (II) Loading /usr/local/lib/xorg/modules/libshadow.so
. . .
[   138.144] (II) Loading /usr/local/lib/xorg/modules/libfb.so
. . .
[   140.068] (II) Loading /usr/local/lib/xorg/modules/input/libinput_drv.so
. . .

and kldstat shows:

# kldstat
Id Refs Address                Size Name
 1    6 0xffff000000000000  112dbf8 kernel
 2    1 0xffff00000112e000    257c8 umodem.ko
 3    2 0xffff000001154000    28658 ucom.ko

My ports builds are based on ports head -r533162 . I
explicitly build the following related to lumina
for the aarch64 contexts:

x11-drivers/xf86-video-scfb
x11/lumina
x11/xorg-minimal
x11/xterm

These, of course, lead to much more building. I built
with default options for them all.

No mouse or usb keyboard input to use lumina with on
the RPi4 so I can not claim anything about past its
initial display.

In my context, startx is tied to:

# more ~/.xinitrc
exec start-lumina-desktop

# ls -laT /etc/X11/
total 8
drwxr-xr-x   2 root  wheel   512 Mar 30 05:23:44 2020 .
drwxr-xr-x  27 root  wheel  2560 Apr 29 13:52:48 2020 ..

(Yep: empty.)

That is all I have. I'm not so sure any of it will
happen to help.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

bob prohaska
In reply to this post by bob prohaska
On Fri, May 22, 2020 at 10:28:13AM -0700, bob prohaska wrote:

> On Fri, May 22, 2020 at 06:38:40PM +0200, Mika??l Urankar wrote:
> > Le mer. 20 mai 2020 ?? 18:46, bob prohaska <[hidden email]> a ??crit :
> > >
> > > Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
> > > Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
> > > a report of "failed to open /dev/io". There is indeed no /dev/io,
> > > but there's also no /dev/io on a pi2 running 12-stable.
> > >
> > > Nor does there seem to be  a kernel module with matching name....
> >
> > I looked at the code and it's only a warning:
> > if ((IoFd = open("/dev/io", O_RDWR)) == -1) {
> >         xf86Msg(X_WARNING, "xf86EnableIO: "
> >                 "Failed to open /dev/io for extended I/O\n");
> >
> > Can you post the whole Xorg log somewhere?
> >
>  
> I'm in the process now of cleaning up, deinstalling everything and
> starting over, this time using -DBATCH from the start. The whole
> fiasco started when I succumbed to the temptations offered by
> dialog4ports (docs are good, amdgpu on a Pi made no sense).
>
> At the very least it'll bring the system to a reproducible state.
>
The cleanup is complete, running the command
X -configure
as root put in the logfile
root@nemesis:~ # more /var/log/Xorg.0.log
[252792.514]
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[252792.515] Build Operating System: FreeBSD 12.1-STABLE arm64
[252792.515] Current Operating System: FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361271 GENERIC arm64
[252792.517] Build Date: 22 May 2020  09:25:08PM
[252792.517]  
[252792.517] Current version of pixman: 0.40.0
[252792.517]    Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
[252792.517] Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[252792.518] (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 22 21:50:03 2020
[252792.518] (II) Loader magic: 0x43a5e0
[252792.518] (II) Module ABI versions:
[252792.518]    X.Org ANSI C Emulation: 0.4
[252792.518]    X.Org Video Driver: 24.1
[252792.518]    X.Org XInput driver : 24.1
[252792.518]    X.Org Server Extension : 10.0
[252792.520] List of video drivers:
[252792.520]    scfb
[252792.520]    modesetting
[252792.520] (II) LoadModule: "scfb"
[252792.521] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[252792.521] (II) Module scfb: vendor="X.Org Foundation"
[252792.521]    compiled for 1.20.8, module version = 0.0.5
[252792.521]    ABI class: X.Org Video Driver, version 24.1
[252792.521] (II) LoadModule: "modesetting"
[252792.522] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
[252792.522] (II) Module modesetting: vendor="X.Org Foundation"
[252792.522]    compiled for 1.20.8, module version = 1.20.8
[252792.523]    Module class: X.Org Video Driver
[252792.523]    ABI class: X.Org Video Driver, version 24.1
[252792.523] (WW) xf86EnableIO: Failed to open /dev/io for extended I/O
[252792.523] (WW) Falling back to old probe method for scfb
[252792.523] scfb trace: probe start
[252792.523] (WW) Falling back to old probe method for modesetting
[252792.523] No devices to configure.  Configuration failed.
[252792.524] (EE) Server terminated with error (2). Closing log file.

That repeats the missing /dev/io error seen previously.

Another correspondent asked what happens if startx is run
by a regular user on the console. That log file is different:

root@nemesis:~ # more /var/log/Xorg.1.log
[253234.555]
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[253234.556] Build Operating System: FreeBSD 12.1-STABLE arm64
[253234.556] Current Operating System: FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361271 GENERIC arm64
[253234.557] Build Date: 22 May 2020  09:25:08PM
[253234.557]  
[253234.558] Current version of pixman: 0.40.0
[253234.558]    Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
[253234.558] Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[253234.558] (==) Log file: "/var/log/Xorg.1.log", Time: Fri May 22 21:57:25 2020
[253234.559] (==) Using config directory: "/usr/local/etc/X11/xorg.conf.d"
[253234.560] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
[253234.561] (==) No Layout section.  Using the first Screen section.
[253234.561] (==) No screen section available. Using defaults.
[253234.561] (**) |-->Screen "Default Screen Section" (0)
[253234.561] (**) |   |-->Monitor "<default monitor>"
[253234.563] (==) No device specified for screen "Default Screen Section".
        Using the first device section listed.
[253234.563] (**) |   |-->Device "Card0"
[253234.563] (==) No monitor specified for screen "Default Screen Section".
        Using a default monitor configuration.
[253234.563] (==) Automatically adding devices
[253234.563] (==) Automatically enabling devices
[253234.563] (==) Not automatically adding GPU devices
[253234.563] (==) Max clients allowed: 256, resource mask: 0x1fffff
[253234.564] (==) FontPath set to:
        /usr/local/share/fonts/misc/,
        /usr/local/share/fonts/TTF/,
        /usr/local/share/fonts/OTF/,
        /usr/local/share/fonts/Type1/,
        /usr/local/share/fonts/100dpi/,
        /usr/local/share/fonts/75dpi/,
        catalogue:/usr/local/etc/X11/fontpath.d
[253234.564] (==) ModulePath set to "/usr/local/lib/xorg/modules"
[253234.564] (II) The server relies on udev to provide the list of input devices.
        If no devices become available, reconfigure udev or disable AutoAddDevices.
[253234.564] (II) Loader magic: 0x43a5e0
[253234.564] (II) Module ABI versions:
[253234.564]    X.Org ANSI C Emulation: 0.4
[253234.564]    X.Org Video Driver: 24.1
[253234.564]    X.Org XInput driver : 24.1
[253234.564]    X.Org Server Extension : 10.0
[253234.565] (II) LoadModule: "glx"
[253234.565] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[253234.576] (II) Module glx: vendor="X.Org Foundation"
[253234.576]    compiled for 1.20.8, module version = 1.0.0
[253234.576]    ABI class: X.Org Server Extension, version 10.0
[253234.576] (II) LoadModule: "scfb"
[253234.576] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[253234.577] (II) Module scfb: vendor="X.Org Foundation"
[253234.577]    compiled for 1.20.8, module version = 0.0.5
[253234.577]    ABI class: X.Org Video Driver, version 24.1
[253234.577] (II) scfb: driver for wsdisplay framebuffer: scfb
[253234.578] (--) Using syscons driver with X support (version 2.0)
[253234.578] (--) using VT number 9

[253234.578] (WW) Falling back to old probe method for scfb
[253234.578] scfb trace: probe start
[253234.578] (II) scfb(0): using default device
[253234.578] scfb trace: probe done
[253234.578] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[253234.578] scfb: PreInit 0
[253234.578] (II) scfb(0): Using: depth (24),   width (1920),    height (1200)
[253234.578] (EE) scfb(0): Specified fbbpp (24) is not a permitted value
[253234.579] (II) UnloadModule: "scfb"
[253234.579] (EE) Screen(s) found, but none have a usable configuration.
[253234.579] (EE)
Fatal server error:
[253234.579] (EE) no screens found(EE)
[253234.579] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[253234.579] (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
[253234.579] (EE)
[253234.580] (EE) Server terminated with error (1). Closing log file.
--More--(END)

The gripe about 24bpp being "not permitted" looks wrong, unless there's
not enough video memory allocated.

Having different failures for different users strikes me as very odd.
It rather suggests a permissions problem, but permissions aren't
mentioned in the logs.

If you can think of something to test please instruct.

Thanks for reading,

bob prohaska
 
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

Marcel Flores

> On May 22, 2020, at 10:14 PM, bob prohaska <[hidden email]> wrote:
>
> On Fri, May 22, 2020 at 10:28:13AM -0700, bob prohaska wrote:
>> On Fri, May 22, 2020 at 06:38:40PM +0200, Mika??l Urankar wrote:
>>> Le mer. 20 mai 2020 ?? 18:46, bob prohaska <[hidden email]> a ??crit :
>>>>
>>>> Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
>>>> Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
>>>> a report of "failed to open /dev/io". There is indeed no /dev/io,
>>>> but there's also no /dev/io on a pi2 running 12-stable.
>>>>
>>>> Nor does there seem to be  a kernel module with matching name....
>>>
>>> I looked at the code and it's only a warning:
>>> if ((IoFd = open("/dev/io", O_RDWR)) == -1) {
>>>        xf86Msg(X_WARNING, "xf86EnableIO: "
>>>                "Failed to open /dev/io for extended I/O\n");
>>>
>>> Can you post the whole Xorg log somewhere?
>>>
>>
>> I'm in the process now of cleaning up, deinstalling everything and
>> starting over, this time using -DBATCH from the start. The whole
>> fiasco started when I succumbed to the temptations offered by
>> dialog4ports (docs are good, amdgpu on a Pi made no sense).
>>
>> At the very least it'll bring the system to a reproducible state.
>>
> The cleanup is complete, running the command
> X -configure
> as root put in the logfile
> root@nemesis:~ # more /var/log/Xorg.0.log
> [252792.514]
> X.Org X Server 1.20.8
> X Protocol Version 11, Revision 0
> [252792.515] Build Operating System: FreeBSD 12.1-STABLE arm64
> [252792.515] Current Operating System: FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361271 GENERIC arm64
> [252792.517] Build Date: 22 May 2020  09:25:08PM
> [252792.517]  
> [252792.517] Current version of pixman: 0.40.0
> [252792.517]    Before reporting problems, check http://wiki.x.org
>        to make sure that you have the latest version.
> [252792.517] Markers: (--) probed, (**) from config file, (==) default setting,
>        (++) from command line, (!!) notice, (II) informational,
>        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [252792.518] (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 22 21:50:03 2020
> [252792.518] (II) Loader magic: 0x43a5e0
> [252792.518] (II) Module ABI versions:
> [252792.518]    X.Org ANSI C Emulation: 0.4
> [252792.518]    X.Org Video Driver: 24.1
> [252792.518]    X.Org XInput driver : 24.1
> [252792.518]    X.Org Server Extension : 10.0
> [252792.520] List of video drivers:
> [252792.520]    scfb
> [252792.520]    modesetting
> [252792.520] (II) LoadModule: "scfb"
> [252792.521] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
> [252792.521] (II) Module scfb: vendor="X.Org Foundation"
> [252792.521]    compiled for 1.20.8, module version = 0.0.5
> [252792.521]    ABI class: X.Org Video Driver, version 24.1
> [252792.521] (II) LoadModule: "modesetting"
> [252792.522] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
> [252792.522] (II) Module modesetting: vendor="X.Org Foundation"
> [252792.522]    compiled for 1.20.8, module version = 1.20.8
> [252792.523]    Module class: X.Org Video Driver
> [252792.523]    ABI class: X.Org Video Driver, version 24.1
> [252792.523] (WW) xf86EnableIO: Failed to open /dev/io for extended I/O
> [252792.523] (WW) Falling back to old probe method for scfb
> [252792.523] scfb trace: probe start
> [252792.523] (WW) Falling back to old probe method for modesetting
> [252792.523] No devices to configure.  Configuration failed.
> [252792.524] (EE) Server terminated with error (2). Closing log file.
>
> That repeats the missing /dev/io error seen previously.
>
> Another correspondent asked what happens if startx is run
> by a regular user on the console. That log file is different:
>
> root@nemesis:~ # more /var/log/Xorg.1.log
> [253234.555]
> X.Org X Server 1.20.8
> X Protocol Version 11, Revision 0
> [253234.556] Build Operating System: FreeBSD 12.1-STABLE arm64
> [253234.556] Current Operating System: FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361271 GENERIC arm64
> [253234.557] Build Date: 22 May 2020  09:25:08PM
> [253234.557]  
> [253234.558] Current version of pixman: 0.40.0
> [253234.558]    Before reporting problems, check http://wiki.x.org
>        to make sure that you have the latest version.
> [253234.558] Markers: (--) probed, (**) from config file, (==) default setting,
>        (++) from command line, (!!) notice, (II) informational,
>        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [253234.558] (==) Log file: "/var/log/Xorg.1.log", Time: Fri May 22 21:57:25 2020
> [253234.559] (==) Using config directory: "/usr/local/etc/X11/xorg.conf.d"
> [253234.560] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
> [253234.561] (==) No Layout section.  Using the first Screen section.
> [253234.561] (==) No screen section available. Using defaults.
> [253234.561] (**) |-->Screen "Default Screen Section" (0)
> [253234.561] (**) |   |-->Monitor "<default monitor>"
> [253234.563] (==) No device specified for screen "Default Screen Section".
>        Using the first device section listed.
> [253234.563] (**) |   |-->Device "Card0"
> [253234.563] (==) No monitor specified for screen "Default Screen Section".
>        Using a default monitor configuration.
> [253234.563] (==) Automatically adding devices
> [253234.563] (==) Automatically enabling devices
> [253234.563] (==) Not automatically adding GPU devices
> [253234.563] (==) Max clients allowed: 256, resource mask: 0x1fffff
> [253234.564] (==) FontPath set to:
>        /usr/local/share/fonts/misc/,
>        /usr/local/share/fonts/TTF/,
>        /usr/local/share/fonts/OTF/,
>        /usr/local/share/fonts/Type1/,
>        /usr/local/share/fonts/100dpi/,
>        /usr/local/share/fonts/75dpi/,
>        catalogue:/usr/local/etc/X11/fontpath.d
> [253234.564] (==) ModulePath set to "/usr/local/lib/xorg/modules"
> [253234.564] (II) The server relies on udev to provide the list of input devices.
>        If no devices become available, reconfigure udev or disable AutoAddDevices.
> [253234.564] (II) Loader magic: 0x43a5e0
> [253234.564] (II) Module ABI versions:
> [253234.564]    X.Org ANSI C Emulation: 0.4
> [253234.564]    X.Org Video Driver: 24.1
> [253234.564]    X.Org XInput driver : 24.1
> [253234.564]    X.Org Server Extension : 10.0
> [253234.565] (II) LoadModule: "glx"
> [253234.565] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
> [253234.576] (II) Module glx: vendor="X.Org Foundation"
> [253234.576]    compiled for 1.20.8, module version = 1.0.0
> [253234.576]    ABI class: X.Org Server Extension, version 10.0
> [253234.576] (II) LoadModule: "scfb"
> [253234.576] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
> [253234.577] (II) Module scfb: vendor="X.Org Foundation"
> [253234.577]    compiled for 1.20.8, module version = 0.0.5
> [253234.577]    ABI class: X.Org Video Driver, version 24.1
> [253234.577] (II) scfb: driver for wsdisplay framebuffer: scfb
> [253234.578] (--) Using syscons driver with X support (version 2.0)
> [253234.578] (--) using VT number 9
>
> [253234.578] (WW) Falling back to old probe method for scfb
> [253234.578] scfb trace: probe start
> [253234.578] (II) scfb(0): using default device
> [253234.578] scfb trace: probe done
> [253234.578] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
> [253234.578] scfb: PreInit 0
> [253234.578] (II) scfb(0): Using: depth (24),   width (1920),    height (1200)
> [253234.578] (EE) scfb(0): Specified fbbpp (24) is not a permitted value
> [253234.579] (II) UnloadModule: "scfb"
> [253234.579] (EE) Screen(s) found, but none have a usable configuration.
> [253234.579] (EE)
> Fatal server error:
> [253234.579] (EE) no screens found(EE)
> [253234.579] (EE)
> Please consult the The X.Org Foundation support
>         at http://wiki.x.org
> for help.
> [253234.579] (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
> [253234.579] (EE)
> [253234.580] (EE) Server terminated with error (1). Closing log file.
> --More--(END)
>
> The gripe about 24bpp being "not permitted" looks wrong, unless there's
> not enough video memory allocated.
>
> Having different failures for different users strikes me as very odd.
> It rather suggests a permissions problem, but permissions aren't
> mentioned in the logs.
>
> If you can think of something to test please instruct.
>
> Thanks for reading,
>
> bob prohaska
>
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "[hidden email]


Seems like the later error is the same as described here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319>

and

https://lists.freebsd.org/pipermail/freebsd-arm/2020-May/021596.html <https://lists.freebsd.org/pipermail/freebsd-arm/2020-May/021596.html>

-m


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Missing /dev/io on rpi3 running 12-stable

freebsd-arm mailing list
On 2020-May-22, at 23:23, Marcel Flores <marcel at brickporch.com> wrote:

>
>> On May 22, 2020, at 10:14 PM, bob prohaska <[hidden email]> wrote:
>>
>> On Fri, May 22, 2020 at 10:28:13AM -0700, bob prohaska wrote:
>>> On Fri, May 22, 2020 at 06:38:40PM +0200, Mika??l Urankar wrote:
>>>> Le mer. 20 mai 2020 ?? 18:46, bob prohaska <[hidden email]> a ??crit :
>>>>>
>>>>> Is there supposed to be a /dev/io by default in FreeBSD on a Pi3?
>>>>> Attempts to start X under 12.1-STABLE r361271 GENERIC fail with
>>>>> a report of "failed to open /dev/io". There is indeed no /dev/io,
>>>>> but there's also no /dev/io on a pi2 running 12-stable.
>>>>>
>>>>> Nor does there seem to be  a kernel module with matching name....
>>>>
>>>> I looked at the code and it's only a warning:
>>>> if ((IoFd = open("/dev/io", O_RDWR)) == -1) {
>>>>       xf86Msg(X_WARNING, "xf86EnableIO: "
>>>>               "Failed to open /dev/io for extended I/O\n");
>>>>
>>>> Can you post the whole Xorg log somewhere?
>>>>
>>>
>>> I'm in the process now of cleaning up, deinstalling everything and
>>> starting over, this time using -DBATCH from the start. The whole
>>> fiasco started when I succumbed to the temptations offered by
>>> dialog4ports (docs are good, amdgpu on a Pi made no sense).
>>>
>>> At the very least it'll bring the system to a reproducible state.
>>>
>> The cleanup is complete, running the command
>> X -configure
>> as root put in the logfile
>> root@nemesis:~ # more /var/log/Xorg.0.log
>> [252792.514]
>> X.Org X Server 1.20.8
>> X Protocol Version 11, Revision 0
>> [252792.515] Build Operating System: FreeBSD 12.1-STABLE arm64
>> [252792.515] Current Operating System: FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361271 GENERIC arm64
>> [252792.517] Build Date: 22 May 2020  09:25:08PM
>> [252792.517]  
>> [252792.517] Current version of pixman: 0.40.0
>> [252792.517]    Before reporting problems, check http://wiki.x.org
>>       to make sure that you have the latest version.
>> [252792.517] Markers: (--) probed, (**) from config file, (==) default setting,
>>       (++) from command line, (!!) notice, (II) informational,
>>       (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> [252792.518] (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 22 21:50:03 2020
>> [252792.518] (II) Loader magic: 0x43a5e0
>> [252792.518] (II) Module ABI versions:
>> [252792.518]    X.Org ANSI C Emulation: 0.4
>> [252792.518]    X.Org Video Driver: 24.1
>> [252792.518]    X.Org XInput driver : 24.1
>> [252792.518]    X.Org Server Extension : 10.0
>> [252792.520] List of video drivers:
>> [252792.520]    scfb
>> [252792.520]    modesetting
>> [252792.520] (II) LoadModule: "scfb"
>> [252792.521] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
>> [252792.521] (II) Module scfb: vendor="X.Org Foundation"
>> [252792.521]    compiled for 1.20.8, module version = 0.0.5
>> [252792.521]    ABI class: X.Org Video Driver, version 24.1
>> [252792.521] (II) LoadModule: "modesetting"
>> [252792.522] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
>> [252792.522] (II) Module modesetting: vendor="X.Org Foundation"
>> [252792.522]    compiled for 1.20.8, module version = 1.20.8
>> [252792.523]    Module class: X.Org Video Driver
>> [252792.523]    ABI class: X.Org Video Driver, version 24.1
>> [252792.523] (WW) xf86EnableIO: Failed to open /dev/io for extended I/O
>> [252792.523] (WW) Falling back to old probe method for scfb
>> [252792.523] scfb trace: probe start
>> [252792.523] (WW) Falling back to old probe method for modesetting
>> [252792.523] No devices to configure.  Configuration failed.
>> [252792.524] (EE) Server terminated with error (2). Closing log file.
>>
>> That repeats the missing /dev/io error seen previously.
>>
>> Another correspondent asked what happens if startx is run
>> by a regular user on the console. That log file is different:
>>
>> root@nemesis:~ # more /var/log/Xorg.1.log
>> [253234.555]
>> X.Org X Server 1.20.8
>> X Protocol Version 11, Revision 0
>> [253234.556] Build Operating System: FreeBSD 12.1-STABLE arm64
>> [253234.556] Current Operating System: FreeBSD nemesis.zefox.com 12.1-STABLE FreeBSD 12.1-STABLE r361271 GENERIC arm64
>> [253234.557] Build Date: 22 May 2020  09:25:08PM
>> [253234.557]  
>> [253234.558] Current version of pixman: 0.40.0
>> [253234.558]    Before reporting problems, check http://wiki.x.org
>>       to make sure that you have the latest version.
>> [253234.558] Markers: (--) probed, (**) from config file, (==) default setting,
>>       (++) from command line, (!!) notice, (II) informational,
>>       (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> [253234.558] (==) Log file: "/var/log/Xorg.1.log", Time: Fri May 22 21:57:25 2020
>> [253234.559] (==) Using config directory: "/usr/local/etc/X11/xorg.conf.d"
>> [253234.560] (==) Using system config directory "/usr/local/share/X11/xorg.conf.d"
>> [253234.561] (==) No Layout section.  Using the first Screen section.
>> [253234.561] (==) No screen section available. Using defaults.
>> [253234.561] (**) |-->Screen "Default Screen Section" (0)
>> [253234.561] (**) |   |-->Monitor "<default monitor>"
>> [253234.563] (==) No device specified for screen "Default Screen Section".
>>       Using the first device section listed.
>> [253234.563] (**) |   |-->Device "Card0"
>> [253234.563] (==) No monitor specified for screen "Default Screen Section".
>>       Using a default monitor configuration.
>> [253234.563] (==) Automatically adding devices
>> [253234.563] (==) Automatically enabling devices
>> [253234.563] (==) Not automatically adding GPU devices
>> [253234.563] (==) Max clients allowed: 256, resource mask: 0x1fffff
>> [253234.564] (==) FontPath set to:
>>       /usr/local/share/fonts/misc/,
>>       /usr/local/share/fonts/TTF/,
>>       /usr/local/share/fonts/OTF/,
>>       /usr/local/share/fonts/Type1/,
>>       /usr/local/share/fonts/100dpi/,
>>       /usr/local/share/fonts/75dpi/,
>>       catalogue:/usr/local/etc/X11/fontpath.d
>> [253234.564] (==) ModulePath set to "/usr/local/lib/xorg/modules"
>> [253234.564] (II) The server relies on udev to provide the list of input devices.
>>       If no devices become available, reconfigure udev or disable AutoAddDevices.
>> [253234.564] (II) Loader magic: 0x43a5e0
>> [253234.564] (II) Module ABI versions:
>> [253234.564]    X.Org ANSI C Emulation: 0.4
>> [253234.564]    X.Org Video Driver: 24.1
>> [253234.564]    X.Org XInput driver : 24.1
>> [253234.564]    X.Org Server Extension : 10.0
>> [253234.565] (II) LoadModule: "glx"
>> [253234.565] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
>> [253234.576] (II) Module glx: vendor="X.Org Foundation"
>> [253234.576]    compiled for 1.20.8, module version = 1.0.0
>> [253234.576]    ABI class: X.Org Server Extension, version 10.0
>> [253234.576] (II) LoadModule: "scfb"
>> [253234.576] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
>> [253234.577] (II) Module scfb: vendor="X.Org Foundation"
>> [253234.577]    compiled for 1.20.8, module version = 0.0.5
>> [253234.577]    ABI class: X.Org Video Driver, version 24.1
>> [253234.577] (II) scfb: driver for wsdisplay framebuffer: scfb
>> [253234.578] (--) Using syscons driver with X support (version 2.0)
>> [253234.578] (--) using VT number 9
>>
>> [253234.578] (WW) Falling back to old probe method for scfb
>> [253234.578] scfb trace: probe start
>> [253234.578] (II) scfb(0): using default device
>> [253234.578] scfb trace: probe done
>> [253234.578] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
>> [253234.578] scfb: PreInit 0
>> [253234.578] (II) scfb(0): Using: depth (24),   width (1920),    height (1200)
>> [253234.578] (EE) scfb(0): Specified fbbpp (24) is not a permitted value
>> [253234.579] (II) UnloadModule: "scfb"
>> [253234.579] (EE) Screen(s) found, but none have a usable configuration.
>> [253234.579] (EE)
>> Fatal server error:
>> [253234.579] (EE) no screens found(EE)
>> [253234.579] (EE)
>> Please consult the The X.Org Foundation support
>>        at http://wiki.x.org
>> for help.
>> [253234.579] (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
>> [253234.579] (EE)
>> [253234.580] (EE) Server terminated with error (1). Closing log file.
>> --More--(END)
>>
>> The gripe about 24bpp being "not permitted" looks wrong, unless there's
>> not enough video memory allocated.
>>
>> Having different failures for different users strikes me as very odd.
>> It rather suggests a permissions problem, but permissions aren't
>> mentioned in the logs.
>>
>> If you can think of something to test please instruct.
>>
>> Thanks for reading,
>>
>> bob prohaska
>>
>> _______________________________________________
>> [hidden email] mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "[hidden email]
>
>
> Seems like the later error is the same as described here:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319>
>
> and
>
> https://lists.freebsd.org/pipermail/freebsd-arm/2020-May/021596.html <https://lists.freebsd.org/pipermail/freebsd-arm/2020-May/021596.html>

I found the RPi3 (and related) fix in FreeBSD
head's sys/arm/broadcom/bcm2835/bcm2835_fbd.c :

QUOTE
Revision 352028 - (view) (download) (annotate) - [select for diffs]
Modified Sun Sep 8 09:47:21 2019 UTC (8 months, 2 weeks ago) by gonzo
File length: 7261 byte(s)
Diff to previous 331229
[rpi] Inherit framebuffer BPP value from the VideoCore firmware

Instead of using hardcoded bpp of 24, obtain current/configured value
from VideoCore. This solves certain problems with Xorg/Qt apps that
require bpp of 32 to work properly. The mode can be forced by setting
framebuffer_depth value in config.txt

PR: 235363
Submitted by: Steve Peurifoy <[hidden email]>
END QUOTE

The change leads to my RPi3 boot context reporting
what is used as:

fb0: <BCM2835 VT framebuffer driver> on simplebus0
fb0: keeping existing fb bpp of 32

So: efifb's figure was picked up by fb and then
fb's figure was picked up by scfb.

Conclusion: An MFC to older contexts would be appropriate.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable

bob prohaska
In reply to this post by freebsd-arm mailing list
On Fri, May 22, 2020 at 10:51:32PM -0700, Mark Millard wrote:
>
> They implicitly suggest that fbbpp needs to be set to 32 (for the sparse 32 bit
> framebuffer layout). You may want to try -fbbpp 32 on the command that starts
> the server to find out if it proves dsufficient.
>

Apparently something more clever than
X -fbbpp 32
or
startx -fbbpp 32
is required. Neither seems to make a difference.

Can the -fbbpp parameter be set in xorg.conf? Right now
it contains:
Section "Files"
EndSection
Section "Module"
    Load        "dbe"
    Disable    "dri"
    Disable    "dri2"
    Disable    "glx"
    SubSection  "extmod"
       Option  "omit xfree86-dga"
    EndSubSection
EndSection


Section "ServerFlags"
    Option    "AIGLX"        "false"
    Option    "NoAccel"    "True"
    Option    "NoDRI"        "True"
    Option    "DRI"        "False"
    Option    "DRI2"        "False"
EndSection


Section "InputDevice"
    Identifier  "Keyboard1"
    Driver      "kbd"
EndSection


Section "InputDevice"
    Identifier  "Mouse1"
    Driver      "mouse"
    Option      "Protocol"      "auto"
    Option      "Device"        "/dev/sysmouse"
EndSection


Section "Monitor"
    Identifier  "Monitor"
EndSection


Section "Device"
    Identifier  "Generic FB"
    Driver      "scfb"
    Option    "NoAccel"    "True"
EndSection


Section "Screen"
    Identifier  "Screen"
    Device      "Generic FB"
    Monitor     "Monitor"
    DefaultDepth 16
    SubSection "Display"
       Depth           16
    EndSubsection
EndSection


Section "ServerLayout"
    Identifier  "layout"
    Screen      0 "Screen" 0 0
    InputDevice "Mouse1" "CorePointer"
    InputDevice "Keyboard1" "CoreKeyboard"
EndSection

Thanks for reading!

bob prohaska

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable

freebsd-arm mailing list


On 2020-May-23, at 15:46, bob prohaska <fbsd at www.zefox.net> wrote:

> On Fri, May 22, 2020 at 10:51:32PM -0700, Mark Millard wrote:
>>
>> They implicitly suggest that fbbpp needs to be set to 32 (for the sparse 32 bit
>> framebuffer layout). You may want to try -fbbpp 32 on the command that starts
>> the server to find out if it proves dsufficient.
>>
>
> Apparently something more clever than
> X -fbbpp 32
> or
> startx -fbbpp 32
> is required. Neither seems to make a difference.
>
> Can the -fbbpp parameter be set in xorg.conf? Right now
> it contains:
> Section "Files"
> EndSection
> Section "Module"
>    Load        "dbe"
>    Disable    "dri"
>    Disable    "dri2"
>    Disable    "glx"
>    SubSection  "extmod"
>       Option  "omit xfree86-dga"
>    EndSubSection
> EndSection
>
>
> Section "ServerFlags"
>    Option    "AIGLX"        "false"
>    Option    "NoAccel"    "True"
>    Option    "NoDRI"        "True"
>    Option    "DRI"        "False"
>    Option    "DRI2"        "False"
> EndSection
>
>
> Section "InputDevice"
>    Identifier  "Keyboard1"
>    Driver      "kbd"
> EndSection
>
>
> Section "InputDevice"
>    Identifier  "Mouse1"
>    Driver      "mouse"
>    Option      "Protocol"      "auto"
>    Option      "Device"        "/dev/sysmouse"
> EndSection
>
>
> Section "Monitor"
>    Identifier  "Monitor"
> EndSection
>
>
> Section "Device"
>    Identifier  "Generic FB"
>    Driver      "scfb"
>    Option    "NoAccel"    "True"
> EndSection
>
>
> Section "Screen"
>    Identifier  "Screen"
>    Device      "Generic FB"
>    Monitor     "Monitor"
>    DefaultDepth 16
>    SubSection "Display"
>       Depth           16
>    EndSubsection
> EndSection
>
>
> Section "ServerLayout"
>    Identifier  "layout"
>    Screen      0 "Screen" 0 0
>    InputDevice "Mouse1" "CorePointer"
>    InputDevice "Keyboard1" "CoreKeyboard"
> EndSection

Unfortunately (until there is an MFC of the relevant
change from head that makes things work), man scfb
reports that you have no control because the
information is ignored:

       For this driver it is not required to specify modes in the Screen
       section of the configuration file.  The scfb driver picks up the
       currently used video mode from the framebuffer driver and uses it.
       Video modes specifications in the configuration file are ignored.

The fix that is in FreeBSD's head is in
sys/arm/broadcom/bcm2835/bcm2835_fbd.c :

QUOTE
Revision 352028 - (view) (download) (annotate) - [select for diffs]
Modified Sun Sep 8 09:47:21 2019 UTC (8 months, 2 weeks ago) by gonzo
File length: 7261 byte(s)
Diff to previous 331229
[rpi] Inherit framebuffer BPP value from the VideoCore firmware

Instead of using hardcoded bpp of 24, obtain current/configured value
from VideoCore. This solves certain problems with Xorg/Qt apps that
require bpp of 32 to work properly. The mode can be forced by setting
framebuffer_depth value in config.txt

PR: 235363
Submitted by: Steve Peurifoy <[hidden email]>
END QUOTE

Any version prior to being based on that sort of change needs
code changes for scfb to work. (It is too late for any
already-made final-releases to work.)

The reason that it used to work was a bug/defect in the
RPi* firmware that did not actually use 24 bits for the
frame buffer bits per pixel when it was specified: it
implicitly used 32 instead.

The one place that 24 does work for the RPi*'s is for the
console display. That is why they have not simply
disallowed 24 frame buffer bits per pixel in general.


Even Raspbian has the fbbpp 24 issue:

https://github.com/raspberrypi/firmware/issues/1338


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable

bob prohaska
On Sat, May 23, 2020 at 06:20:13PM -0700, Mark Millard wrote:

>
> Unfortunately (until there is an MFC of the relevant
> change from head that makes things work), man scfb
> reports that you have no control because the
> information is ignored:
>
>        For this driver it is not required to specify modes in the Screen
>        section of the configuration file.  The scfb driver picks up the
>        currently used video mode from the framebuffer driver and uses it.
>        Video modes specifications in the configuration file are ignored.
>
> The fix that is in FreeBSD's head is in
> sys/arm/broadcom/bcm2835/bcm2835_fbd.c :
>
> QUOTE
> Revision 352028 - (view) (download) (annotate) - [select for diffs]
> Modified Sun Sep 8 09:47:21 2019 UTC (8 months, 2 weeks ago) by gonzo
> File length: 7261 byte(s)
> Diff to previous 331229
> [rpi] Inherit framebuffer BPP value from the VideoCore firmware
>
> Instead of using hardcoded bpp of 24, obtain current/configured value
> from VideoCore. This solves certain problems with Xorg/Qt apps that
> require bpp of 32 to work properly. The mode can be forced by setting
> framebuffer_depth value in config.txt
>
> PR: 235363
> Submitted by: Steve Peurifoy <[hidden email]>
> END QUOTE
>
> Any version prior to being based on that sort of change needs
> code changes for scfb to work. (It is too late for any
> already-made final-releases to work.)
>
> The reason that it used to work was a bug/defect in the
> RPi* firmware that did not actually use 24 bits for the
> frame buffer bits per pixel when it was specified: it
> implicitly used 32 instead.
>
> The one place that 24 does work for the RPi*'s is for the
> console display. That is why they have not simply
> disallowed 24 frame buffer bits per pixel in general.
>

It looks as if the required bug report already exists:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319

Would any further noisemaking be constructive? Squeaky wheels
and all that 8-)

Thanks for reading and taking the time to explain what's happened!

bob prohaska

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable

freebsd-arm mailing list


On 2020-May-23, at 18:57, bob prohaska <fbsd at www.zefox.net> wrote:

> On Sat, May 23, 2020 at 06:20:13PM -0700, Mark Millard wrote:
>>
>> Unfortunately (until there is an MFC of the relevant
>> change from head that makes things work), man scfb
>> reports that you have no control because the
>> information is ignored:
>>
>>       For this driver it is not required to specify modes in the Screen
>>       section of the configuration file.  The scfb driver picks up the
>>       currently used video mode from the framebuffer driver and uses it.
>>       Video modes specifications in the configuration file are ignored.
>>
>> The fix that is in FreeBSD's head is in
>> sys/arm/broadcom/bcm2835/bcm2835_fbd.c :
>>
>> QUOTE
>> Revision 352028 - (view) (download) (annotate) - [select for diffs]
>> Modified Sun Sep 8 09:47:21 2019 UTC (8 months, 2 weeks ago) by gonzo
>> File length: 7261 byte(s)
>> Diff to previous 331229
>> [rpi] Inherit framebuffer BPP value from the VideoCore firmware
>>
>> Instead of using hardcoded bpp of 24, obtain current/configured value
>> from VideoCore. This solves certain problems with Xorg/Qt apps that
>> require bpp of 32 to work properly. The mode can be forced by setting
>> framebuffer_depth value in config.txt
>>
>> PR: 235363
>> Submitted by: Steve Peurifoy <[hidden email]>
>> END QUOTE
>>
>> Any version prior to being based on that sort of change needs
>> code changes for scfb to work. (It is too late for any
>> already-made final-releases to work.)
>>
>> The reason that it used to work was a bug/defect in the
>> RPi* firmware that did not actually use 24 bits for the
>> frame buffer bits per pixel when it was specified: it
>> implicitly used 32 instead.
>>
>> The one place that 24 does work for the RPi*'s is for the
>> console display. That is why they have not simply
>> disallowed 24 frame buffer bits per pixel in general.
>>
>
> It looks as if the required bug report already exists:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319
>
> Would any further noisemaking be constructive? Squeaky wheels
> and all that 8-)
>
> Thanks for reading and taking the time to explain what's happened!

I do not know if it would help but it looks like
gonzo (Oleksandr Tymoshenko) is the one that
checked-in a variant of Steve Peurifoy's
( ssw01 at mathistry.net ) changes to:

sys/arm/broadcom/bcm2835/bcm2835_mbox_prop.h
sys/arm/broadcom/bcm2835/bcm2835_mbox.c
sys/arm/broadcom/bcm2835/bcm2835_fbd.c

This was as a fix for:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235363
(which has the original and Florian Markl's updated
patch as attachments).

Unlike that defect report's more limited notes, the issue
is not limited or specific to Qt or QImage: it is far more
general. (Frame buffer bits per pixel being 24 does not
maintain memory alignment and so would be a problem for
performance except in basic contexts, or that is what I
think I understand.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: X trouble on Rpi3, was Re: Missing /dev/io on rpi3 running 12-stable

freebsd-arm mailing list


On 2020-May-23, at 20:18, Mark Millard <marklmi at yahoo.com> wrote:

> On 2020-May-23, at 18:57, bob prohaska <fbsd at www.zefox.net> wrote:
>
>> On Sat, May 23, 2020 at 06:20:13PM -0700, Mark Millard wrote:
>>>
>>> Unfortunately (until there is an MFC of the relevant
>>> change from head that makes things work), man scfb
>>> reports that you have no control because the
>>> information is ignored:
>>>
>>>      For this driver it is not required to specify modes in the Screen
>>>      section of the configuration file.  The scfb driver picks up the
>>>      currently used video mode from the framebuffer driver and uses it.
>>>      Video modes specifications in the configuration file are ignored.

Note, that was about things failing via:

[253234.578] (II) scfb(0): Using: depth (24),   width (1920),    height (1200)
[253234.578] (EE) scfb(0): Specified fbbpp (24) is not a permitted value
[253234.579] (II) UnloadModule: "scfb"

Well, an MFC to stable/12 has been done for the issue:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235363

--- Comment #15 from [hidden email] ---
A commit references this bug:

Author: gonzo
Date: Mon Jun  8 00:20:16 UTC 2020
New revision: 361899
URL: https://svnweb.freebsd.org/changeset/base/361899

Log:
 MFC r352028:

 [rpi] Inherit framebuffer BPP value from the VideoCore firmware

 Instead of using hardcoded bpp of 24, obtain current/configured value
 from VideoCore. This solves certain problems with Xorg/Qt apps that
 require bpp of 32 to work properly. The mode can be forced by setting
 framebuffer_depth value in config.txt

 PR:           235363
 Submitted by: Steve Peurifoy <[hidden email]>
 Tested by:    Johnathan Chen <[hidden email]> (stabe/12 patch)

Changes:
_U  stable/12/
 stable/12/sys/arm/broadcom/bcm2835/bcm2835_fbd.c
 stable/12/sys/arm/broadcom/bcm2835/bcm2835_mbox.c

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"