Debian: Cannot change video mode inside a systemd service

[deanmsands3 0]

Distro: Debian Bullseye
OS: Linux 5.10.198
Arch: Arm64
GPU: Mali Midgard T-860
Driver: libmali-midgard-t86x-r18p0-wayland-gbm

Hello!

Trying to launch a browser session from a systemd service.

I'm getting this error when I try to run the service.

[  175.756156] rockchip-vop ff900000.vop: [drm:vop_crtc_atomic_enable] Update mode to 1920x1080p60, type: 11
[  175.756243] asus_write_resolution_to_file: HDMI failed to open file

What's causing this and how do I fix it?

Or how do I debug it?

Edited December 13, 2024 by deanmsands3

[deanmsands3 0]

From the rockchip-linux-kernel repo, branch: linux5.10-rk3399-debian11: /drivers/gpu/drm/rockchip/rockchip_drm_vop.c:

#define ASUS_HDMI_RESOLUTION_FILE_PATH "/boot/display/hdmi/xrandr.cfg"
#define ASUS_DP_RESOLUTION_FILE_PATH "/boot/display/dp/xrandr.cfg"
static void asus_write_resolution_to_file(char *buf, int writelen, int type)
{
        struct file *fp;
        loff_t pos = 0;

        if(type == DRM_MODE_CONNECTOR_HDMIA)
        {
                fp = filp_open(ASUS_HDMI_RESOLUTION_FILE_PATH, O_WRONLY, 0644);

                if(!IS_ERR(fp))
                {
                        kernel_write(fp, buf, writelen, &pos);
                        pr_info("%s: set HDMI resolution file to %s", __func__, buf);
                        filp_close(fp, NULL);
                }
                else
                        pr_err("%s: HDMI failed to open file\n", __func__);

        }
        else if(type == DRM_MODE_CONNECTOR_DisplayPort) {
                fp = filp_open(ASUS_DP_RESOLUTION_FILE_PATH, O_WRONLY, 0644);

                if(!IS_ERR(fp)) {
                        kernel_write(fp, buf, writelen, &pos);
                        pr_info("%s: set DP resolution file to %s", __func__, buf);
                        filp_close(fp, NULL);
                }
                else
                        pr_err("%s: DP failed to open file\n", __func__);
        }
        else
                pr_err("%s: error type\n", __func__);
}

So, this file, "/boot/display/hdmi/xrandr.cfg", which doesn't exist on the visible filesystem, has to be available to the kernel for this function to work.

But I can't find any information about it.

Any help from the Asus engineers?

[tooz 54]

hello @deanmsands3, 

did you compile the .img by yourself, or was it downloaded from the official website: Tinker Board 

if it's the latter, which version are you using?

we're trying to duplicate the issue and see what goes wrong

[deanmsands3 0]

It's a re-assembled image using the first 8 partitions of the official distro with a root fs rebuilt with debootstrap as well as the firmware and kernel modules from the original.

I compiled the Mali Midgard Wayland GBM driver from the Rockchip libmali repo and it works in some but not all cases.

I'm running Chromium w/Wayland turned on inside Cage kiosk 0.12.1 compiled for Bullseye.

While not a best practice, I have a one-shot service that changes the permissions on /dev/mali0 from 600 root:root to 660 root:video.

This doesn't work in a systemd service, but USUALLY works fine run from the command line after the system has finished booting. Usually.

 

I can try again with an official image but my priorities have shifted for the moment.

Using the official image, I would do the following.

• Disable the lightdm service.
• Install the Mali Midgard Wayland GBM driver.
• Write a oneshot systemd service to mod /dev/mali0's permissions, setting it to start after systemd-udevd.service.
• Write another systemd service for cage using the template in the wiki
  • modified so that it depends on the first service.
  • modified ExecStart to cage -- chromium --kiosk --enable-features=UseOzonePlatform --ozone-platform=wayland "https://www.google.com"
• Add the PAM config for cage (per the wiki).
• Enable the cage service.
• Reboot.

An alternative configuration would be everything from the first one except:

• No systemd service for cage.
• override getty@tty1 to auto-login to the kiosk user.
• modify the .bashrc script to run the cage command.

 

I also tried a variation of the second one using the pre-installed X drivers with openbox as a backend and a .xinitrc script to launch chromium. That one lacked hardware acceleration (which my project absolutely needs), but thinking back on it, I might have accidentally left in the Wayland parameters. I'll try it again later this week.

 

For those interested in trying the Wayland Drivers:

# On an AArch64 Bullseye OS (like the official image):
# Install the build dependencies (along with git)
# Check the BuildDepends line in https://github.com/TinkerBoard-Linux/rockchip-linux-libmali/blob/linux5.10-rk3399-debian11/debian/control
# This command is all one line.
sudo apt install git devscripts build-essential lintian \
    debhelper meson pkg-config libstdc++6 libgbm-dev \
    libdrm-dev libx11-xcb1 libxcb-dri2-0 libxdamage1 \
    libxext6 libwayland-client0
# Wait for the packages to install
mkdir drivers # The debian build process will store the debs in this folder.
cd drivers
git clone https://github.com/TinkerBoard-Linux/rockchip-linux-libmali.git
cd rockchip-linux-libmali
git checkout linux5.10-rk3399-debian11 # Or whichever branch you need
debuild -us -uc # Run the actual build
# Go make some coffee or something.
# Ponder the nature of the universe.
# Maybe a little more coffee.
# Reconnect with an old friend - and oh hey! It's done.
cd .. # Back to the drivers folder
# Find the deb package starting with "libmali-midgard-t86x-r18p0-wayland-gbm"

 

[tooz 54]

hello @deanmsands3, 

16 hours ago, deanmsands3 said:

I'm running Chromium w/Wayland turned on inside Cage kiosk 0.12.1 compiled for Bullseye.

 

the official distro uses x11 instead of wayland and we cannot guarantee that gpu/ diplay will function well with this massive change

in terms of mali midgard driver updates, we usually integrade the software development kits release from rockchip, instead of fetching sources from arm. this way we're more confident with the hardware compatibility 

16 hours ago, deanmsands3 said:

I compiled the Mali Midgard Wayland GBM driver from the Rockchip libmali repo and it works in some but not all cases.

 

may we know in what cases it works and in what cases it doesn't?

are you able to fetch the node in xrandr.cfg?

cat /boot/display/hdmi/xrandr.cfg

 

[deanmsands3 0]

10 hours ago, tooz said:

may we know in what cases it works and in what cases it doesn't?

How much time you got?

In Weston using FBDev mode as root or with permission-modded /dev/mali0:

• Weston: Success
• cog w/Wayland: Platform setup failed: Could not initialize  EGL (0x3001)

After a while, I must have changed something because Weston stopped working with FBDev.

In Weston using DRM mode as root or with permission-modded /dev/mali0:

• Weston: Success
• cog w/Wayland: EGLDisplay Initialization failed: EGL_NOT_INITIALIZED
  Cannot create EGL context: invalid display (last error: EGL_SUCCESS)
• glmark2:
  • glmark2: Error: Could not Initialize canvas
  • glmark2-wayland: Error: Failed to bind api
    Error: main: Could not initialize canvas
  • glmark2-es2-wayland: Success

From command-line as root or with permission-modded /dev/mali0:

• drmgl: Success ( https://gist.github.com/Miouyouyou/89e9fe56a2c59bce7d4a18a858f389ef/raw/b4b5c03398ef84446f9212e1112d87dcaee8fa87/Linux_DRM_OpenGLES.c )
• kmscube:
  • kmscube: Success
  • kmscube using card0: Success
• glmark2:
  • glmark2: Error: Could not Initialize canvas
  • glmark2-drm: error: Failed to bind api
    error: main: Could not initialize canvas
  • glmark2-es2: Success
  • glmark2-es2-drm: Success
     

Without modding /dev/mali0's permissions, a user in video, render, and input groups:

• Weston:
  • DRM w/ or w/o launcher: Failed creating base context during opening of kernel driver.
    Kernel module may not have been loaded
    arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '5'.
    arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '5'.
    failed to initialize
    failed to initialize EGL
  • FBDev:
    • weston-launcher: Success but without menu on the top
    • Without launcher: Failed creating base context during opening of kernel driver.
      Kernel module may not have been loaded
      arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '5'.
      arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '5'.
      failed to initialize
      failed to initialize EGL
• glmark2:
  • glmark2-es2: Error: Could not Initialize canvas
  • glmark2-es2-drm: arm_release_ver of this libmali is ‘r18p0-01rel0’, rk_so_ver is '5'
    Failed creating base context during opening of kernel driver
    Kernel module may not have been loaded.
    arm_release_ver of this libmali is ‘r18p0-01rel0’, rk_so_ver is '5'
    Error: eglInitialize() failed with error 0x3001
    Error: main: Could not initialize canvas
• drmgl: Failed creating base context during opening of kernel driver.
  Kernel module may not have been loaded
  arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '5'.
  arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '5'.
  failed to initialize
  failed to initialize EGL
• kmscube w/ or w/o card0: Failed creating base context during opening of kernel driver.
  Kernel module may not have been loaded
  arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '5'.
  arm_release_ver of this libmali is 'r18p0-01rel0', rk_so_ver is '5'.
  failed to initialize
  failed to initialize EGL

 

11 hours ago, tooz said:

are you able to fetch the node in xrandr.cfg?

I'll have to check while an application is running. With no application running, the /boot/display tree doesn't exist.