search

directfb2 / DirectFB2

Core DirectFB library
GNU Lesser General Public License v2.1
136 stars 16 forks source link

DRM/KMS: Set default pixel format using info from kernel #85

Closed fifteenhex closed 1 year ago

fifteenhex commented 1 year ago

Issue:

The little SPI displays that are cheap/readily available only support 16BPP but DirectFB2 seems to default to trying to setup the display with 24BPP framebuffer and DRM in the kernel rejects it.

Putting the depth in the config file should fix it but maybe we can get the supported depth from the kernel and try to use that automatically.

fifteenhex commented 1 year ago

For reference, chocolate-doom on SDL2:

# chocolate-doom
                         Chocolate Doom 3.0.1
Z_Init: Init zone memory allocation daemon. 
zone memory: 0xb5a0f008, 1000000 allocated for zone
Using /root/.local/share/chocolate-doom/ for configuration and saves
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /root/.local/share/chocolate-doom/default.cfg
W_Init: Init WADfiles.
 adding /usr/share/games/doom/doom1.wad
===========================================================================
                            DOOM Shareware
===========================================================================
 Chocolate Doom is free software, covered by the GNU General Public
 License.  There is NO warranty; not even for MERCHANTABILITY or FITNESS
 FOR A PARTICULAR PURPOSE. You are welcome to change and distribute
 copies under certain conditions. See the source for more information.
===========================================================================
I_Init: Setting up machine state.
OPL_Init: Using driver 'SDL'.
NET_Init: Init network subsystem.
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [...................]
P_Init: Init Playloop state.
S_Init: Setting up sound.
D_CheckNetGame: Checking network game status.
startskill 2  deathmatch: 0  startmap: 1  startepisode: 1
player 1 of 1 (1 nodes)
Emulating the behavior of the 'Doom 1.9' executable.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 2.0.0  |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2017-2022  DirectFB2 Open Source Project (fork of DirectFB)
        (c) 2012-2016  DirectFB integrated media GmbH
        (c) 2001-2016  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2023-01-23 05:18) 
(*) DRMKMS/System: Using device /dev/dri/card0 (default)
(*) DRMKMS/System: Using PRIME file descriptor
(*) DRMKMS/System: Found 1 connectors, 1 encoders, 0 planes
(*) DirectFB/Input: Hot-plug detection enabled with Linux Input
(*) DirectFB/Genefx: NEON enabled
driver_probe()
(*) GE/driver: Opened GE, caps 0x1
(*) DirectFB/Graphics: MStar/SigmaStar ge 0.1 (linux-chenxing)
(*) DRMKMS/Screen: Default mode is 320x240 (1 modes in total)
(*) DirectFB/Core/WM: Default 0.3 (DirectFB)
(!) DRMKMS/Layer: drmModeSetCrtc( crtc_id 34, fb_id 38, xy 0,0, connector_id 31, mode 320x240@0Hz ) failed at index 0!
    --> Invalid argument
(!) Core/LayerRegion: Could not set region!
    --> An invalid argument has been specified
(!) Core/LayerRegion: dfb_layer_region_realize() in dfb_layer_region_flip_update() failed!
    --> An invalid argument has been specified
(!) DRMKMS/Layer: drmModePageFlip() failed!
    --> Device or resource busy
CreateUpscaledTexture: Limited texture size to 0x0 (max 16000000 pixels, max texture size 0x0)
(!) DRMKMS/Layer: drmModePageFlip() failed!
    --> Device or resource busy
Segmentation fault

Turning on DRMs debug seems to show that SDL2 is still trying to create a 24BPP framebuffer:

[  124.543474] panel-ilitek-ili9341 spi1.0: [drm:drm_mode_addfb2] [FB:38]
[  124.543497] [drm:drm_ioctl] comm="chocolate-doom" pid=216, dev=0xe200, auth=1, DRM_IOCTL_MODE_MAP_DUMB
[  124.543694] [drm:drm_ioctl] comm="chocolate-doom" pid=216, dev=0xe200, auth=1, DRM_IOCTL_MODE_SETCRTC
[  124.543736] [drm:drm_mode_setcrtc] [CRTC:34:crtc-0]
[  124.543767] [drm:drm_mode_setcrtc] Invalid pixel format AR24 little-endian (0x34325241), modifier 0x0
[  124.543788] [drm:drm_mode_object_put] OBJ ID: 38 (2)
[  124.543808] [drm:drm_ioctl] comm="chocolate-doom", pid=216, ret=-22
[  124.544369] [drm:drm_ioctl] comm="chocolate-doom" pid=216, dev=0xe200, auth=1, DRM_IOCTL_MODE_RMFB
[  124.544422] [drm:drm_mode_object_put] OBJ ID: 38 (2)
[  124.544440] [drm:drm_mode_object_put] OBJ ID: 38 (1)

Despite directfbrc setting the depth to 16:

# cat /etc/directfbrc 
no-sighandler
drmkms-use-prime-fd
depth=16
caramelli commented 1 year ago

Do you have the same issue when running: df_andi --dfb:pixelformat=RGB16,no-hardware

Note that the no-hardware parameter is only used to check the behavior without acceleration (coming from a possible GFX driver).

fifteenhex commented 1 year ago

The dfb examples are a bit big to fit into my rootfs (I have ~20MB to work with..). I tried dfbterm though:

# dfbterm  --dfb:pixelformat=RGB16,no-hardware

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 2.0.0  |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2017-2022  DirectFB2 Open Source Project (fork of DirectFB)
        (c) 2012-2016  DirectFB integrated media GmbH
        (c) 2001-2016  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2023-01-23 05:18) 
(*) DRMKMS/System: Using device /dev/dri/card0 (default)
(*) DRMKMS/System: Using PRIME file descriptor
(*) DRMKMS/System: Found 1 connectors, 1 encoders, 0 planes
(*) DirectFB/Input: Hot-plug detection enabled with Linux Input
(*) DirectFB/Genefx: NEON enabled
driver_probe()
(*) GE/driver: Opened GE, caps 0x1
(*) DirectFB/Graphics: MStar/SigmaStar ge 0.1 (linux-chenxing)
(*) DirectFB/Graphics: Acceleration disabled (by 'no-hardware')
(*) DRMKMS/Screen: Default mode is 320x240 (1 modes in total)
(*) DirectFB/Core/WM: Default 0.3 (DirectFB)
(*) Direct/Interface: Loaded 'DGIFF' implementation of 'IDirectFBFont'
(*) Direct/Interface: Loaded 'DFIFF' implementation of 'IDirectFBImageProvider'

Not seeing the DRM/KMS errors like that but I'm only seeing the cursor on a black screen.

I'll investigate some more.

fifteenhex commented 1 year ago

With pixelformat=RGB16 chocolate-doom/SDL2 seems to get a bit further too:

# chocolate-doom
                         Chocolate Doom 3.0.1
Z_Init: Init zone memory allocation daemon. 
zone memory: 0xb5a5f008, 1000000 allocated for zone
Using /root/.local/share/chocolate-doom/ for configuration and saves
V_Init: allocate screens.
M_LoadDefaults: Load system defaults.
saving config in /root/.local/share/chocolate-doom/default.cfg
W_Init: Init WADfiles.
 adding /usr/share/games/doom/doom1.wad
===========================================================================
                            DOOM Shareware
===========================================================================
 Chocolate Doom is free software, covered by the GNU General Public
 License.  There is NO warranty; not even for MERCHANTABILITY or FITNESS
 FOR A PARTICULAR PURPOSE. You are welcome to change and distribute
 copies under certain conditions. See the source for more information.
===========================================================================
I_Init: Setting up machine state.
OPL_Init: Using driver 'SDL'.
NET_Init: Init network subsystem.
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - [...................]
P_Init: Init Playloop state.
S_Init: Setting up sound.
D_CheckNetGame: Checking network game status.
startskill 2  deathmatch: 0  startmap: 1  startepisode: 1
player 1 of 1 (1 nodes)
Emulating the behavior of the 'Doom 1.9' executable.
HU_Init: Setting up heads up display.
ST_Init: Init status bar.

   ~~~~~~~~~~~~~~~~~~~~~~~~~~| DirectFB 2.0.0  |~~~~~~~~~~~~~~~~~~~~~~~~~~
        (c) 2017-2022  DirectFB2 Open Source Project (fork of DirectFB)
        (c) 2012-2016  DirectFB integrated media GmbH
        (c) 2001-2016  The world wide DirectFB Open Source Community
        (c) 2000-2004  Convergence (integrated media) GmbH
      ----------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2023-01-23 05:18) 
(*) DRMKMS/System: Using device /dev/dri/card0 (default)
(*) DRMKMS/System: Using PRIME file descriptor
(*) DRMKMS/System: Found 1 connectors, 1 encoders, 0 planes
(*) DirectFB/Input: Hot-plug detection enabled with Linux Input
(*) DirectFB/Genefx: NEON enabled
driver_probe()
(*) GE/driver: Opened GE, caps 0x1
(*) DirectFB/Graphics: MStar/SigmaStar ge 0.1 (linux-chenxing)
(*) DirectFB/Graphics: Acceleration disabled (by 'no-hardware')
(*) DRMKMS/Screen: Default mode is 320x240 (1 modes in total)
(*) DirectFB/Core/WM: Default 0.3 (DirectFB)
(!) DRMKMS/Layer: drmModePageFlip() failed!
    --> Device or resource busy
(!) DRMKMS/Layer: drmModePageFlip() failed!
    --> Device or resource busy
CreateUpscaledTexture: Limited texture size to 0x0 (max 16000000 pixels, max texture size 0x0)
(!) DRMKMS/Layer: drmModePageFlip() failed!
    --> Device or resource busy
Segmentation fault

The device or resource busy seems to be this:

[  201.610745] [drm:drm_mode_object_put] OBJ ID: 37 (5)
[  201.610764] panel-ilitek-ili9341 spi1.0: [drm:drm_atomic_check_only] checking 6b28ce69
[  201.610807] panel-ilitek-ili9341 spi1.0: [drm:drm_atomic_add_affected_planes] Adding all current planes for [CRTC:34:crtc-0] to 6b28ce69
[  201.610838] panel-ilitek-ili9341 spi1.0: [drm:drm_atomic_nonblocking_commit] committing 6b28ce69 nonblocking
[  201.610867] panel-ilitek-ili9341 spi1.0: [drm:drm_atomic_helper_setup_commit] [CRTC:34:crtc-0] busy with a previous commit
[  201.610892] panel-ilitek-ili9341 spi1.0: [drm:drm_atomic_state_default_clear] Clearing atomic state 6b28ce69

I think the screen is so slow dfb2 is frustrated trying to update it :D

caramelli commented 1 year ago

What output do you get when running the modetest tool provided by the libdrm library?

It would be interesting to test with a more basic example (dfbterm relies on LiTE and IDirectFBWindow objects). Maybe putting only df_andi and required data files in the rootfs (decker.dgiff, tux.dfiff, wood_andi.dfiff, destination_mask.dfiff).

Is it possible to test also with following parameters: --dfb:system=fbdev,pixelformat=RGB16,no-hardware (this requires enabling legacy fbdev support for your modesetting driver in the Linux kernel)

fifteenhex commented 1 year ago

I have gotten something SDL2 based working with DirectFB2: https://twitter.com/linux_chenxing/status/1625171611891691520 -- This is FAKE08 running. The performance is pretty terrible but I guess it shows it should work. I think something like this done properly is needed to stop constant timeouts happening when flipping the buffers on displays this slow: https://github.com/fifteenhex/DirectFB2/commit/155a5c2f3ed252ca52fa4b5d364a25e36e91f0ba

I will try out modetest and one of the pure df examples at some point. I'm building in buildroot to an image I have to flash so removing stuff to make it fit is a bit of a pain.

caramelli commented 1 year ago

https://github.com/directfb2/DirectFB2/pull/86 should allow using the drmkms system module automatically on a platform that does not support AR24 format (i.e. without specifying the pixelformat parameter)