Jump to content

deanmsands3

Members
  • Content Count

    8
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. 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 I'll have to check while an application is running. With no application running, the /boot/display tree doesn't exist.
  2. 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"
  3. 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?
  4. 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?
  5. Rockchip released the r18 version of the libMali Midgard T86X drivers. Arm has r28 source listed on their site. The current Mali DDK doesn't cover the Midgard chips so I can't compile it myself. Will Rockchip update the drivers? Is there any way to contact them about this?
  6. The TinkerBoard boot logo? It's much simpler (for the Tinker 2/S). Just convert a 24-bit BMP (less than 700kb) and dd it to the splash partition. But I was hoping to hide the boot messages with a service like Plymouth. (5 hours later) And I found it. 1. Set the default Plymouth theme sudo update-alternatives --install /usr/share/plymouth/themes/default.plymouth default.plymouth /usr/share/plymouth/themes/spinner/spinner.plymouth 100 2. Update initramfs sudo initramfs -u 3. Mount the "boot" partition sudo mount /dev/mmcblk1p8 /boot 4. Append "console=tty0 quiet splash plymouth.ignore-serial-consoles" to /boot/cmdline.txt echo "console=tty0 quiet splash plymouth.ignore-serial-consoles" | sudo tee -a /boot/cmdline.txt 5. Reboot sudo reboot
  7. I'd like to have my Tinker 2S boot with a Plymouth animation to hide the boot-up messages. I have a Plymouth theme I created on an x64 host and I'd like to use it on my Tinker. If Plymouth isn't an option, is there an alternative?
  8. I've tried multiple solutions but have come up short on all of them. Right now I'm trying to get the WPEWebkit cog browser going. So far, no luck. I can get it to "start" in a Weston session (I've installed the Wayland libMali driver from the RockChip repo). However, it only displays an on-screen keyboard and no browser. Any suggestions?
×
×
  • Create New...