All Activity

@Fredrik You should use the dxvk-2.7.1-stripped (I have re-uploaded recently) for the Hades game. It achieves a higher frame rate (~15%) than the stripped versions of dxvk-1.x.x-stripped.

@MartinB direct from the game's folder (no Steam) no special arguments

Hello, I just got a wifi 7 adapter (QCNCM865) and I was thinking the ath12k driver was available starting from kernel 6.13, I'm running the edge kernel 6.16.4 and the ath12k driver is failing to load and I can't find any wireless drivers in /usr/lib/modules/6.16.4-edge-rockchip64/kernel/net/wireless. Do I need to rebuild the kernel with the ath12k driver? or is there a kernel version available with that driver? Thanks for your help!

Hello as this seems really fun I was also trying to get this to work but running into problems so it would be amazing if you could clarify a bit more please? I have mainline Mesa but that comes with PanVK to level 1.4+ vulkaninfo --summary Devices: ======== GPU0: apiVersion = 1.4.328 driverVersion = 25.2.99 vendorID = 0x13b5 deviceID = 0xa8670000 deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU deviceName = Mali-G610 driverID = DRIVER_ID_MESA_PANVK driverName = panvk driverInfo = Mesa 25.3.0-devel (git-099ac5be1a) conformanceVersion = 1.4.1.2 deviceUUID = b5130000-0000-67a8-0000-000000000000 driverUUID = ac34a6fa-924e-d4b0-3a47-66ccf4729ee5 I then build your dxvk repo https://github.com/khanh-it And install like, export WINEPREFIX=/path/to/wineprefix cp x64/*.dll $WINEPREFIX/drive_c/windows/system32 cp x32/*.dll $WINEPREFIX/drive_c/windows/syswow64 (its weird that the x64 files go in the system32 folder and opposite too) I then did the 'Native' override to those libraries mentioned in winecfg. I downloaded https://github.com/pythonlover02/DXVK-Sarek/actions and stuck the dll's in the games x64 folder But I keep getting a black window and the error that the game can't find a graphics device, info: Game: Hades.exe info: DXVK-Sarek: v1.11.0 info: Built-in extension providers: info: Win32 WSI info: OpenVR info: OpenXR info: OpenVR: could not open registry key, status 2 info: OpenVR: Failed to locate module [BOX64] Using emulated /mnt/net_d/emu/PC/wine-10.15-staging-tkg-ntsync-amd64-wow64/lib/wine/x86_64-unix/winevulkan.so [BOX64] Using native(wrapped) libvulkan.so.1 info: Enabled instance extensions: info: VK_KHR_surface info: VK_KHR_win32_surface info: Mali-G610: info: Driver: 25.2.99 info: Vulkan: 1.4.328 info: Memory Heap[0]: info: Size: 5950 MiB info: Flags: 0x1 info: Memory Type[0]: Property Flags = 0x7 2025-10-22 15:35:50 [MainThread ] direct3d11.cpp:833 INFO| Created DXGI1.2 factory. info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_11_1 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_11_0 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_10_1 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_10_0 err: D3D11CoreCreateDevice: Requested feature level not supported info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_11_0 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_10_1 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_10_0 err: D3D11CoreCreateDevice: Requested feature level not supported info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_11_1 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_11_0 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_10_1 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_10_0 err: D3D11CoreCreateDevice: Requested feature level not supported info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_11_0 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_10_1 info: D3D11CoreCreateDevice: Probing D3D_FEATURE_LEVEL_10_0 err: D3D11CoreCreateDevice: Requested feature level not supported 2025-10-22 15:35:50 [MainThread ] direct3d11.cpp:1012 INFO| gpuCount = 0 2025-10-22 15:35:50 [MainThread ] program.cpp:2117 ERR| Failed to initialize ForgeRenderer. 2025-10-22 15:35:50 [MainThread ] program.cpp:2118 INFO| Showing MessageBox: No Graphics Device 2025-10-22 15:35:53 [MainThread ] luaext.cpp:445 INFO| Lua interface destroyed Would you please be able to elaborate a bit on the steps if you can see what I'm doing wrong? Cheers! UPDATE: Oh wait! I got it to work now, I copied the 'stripped' x32 dll's from (https://github.com/khanh-it/dxvk/releases Into the games x64 folder. (I had previously copied the x64 dll's into the x64 folder. Silly me obviously that's not how it works) Cool!

If any of you have experienced skipping and popping when seeking with vlc, you can try setting the audio sink to ALSA and one of the rockchip-es8316 options. That will smooth out the audio playback BUT you will quickly discover that anything pulseaudio related is locked out of using the soundcard while vlc is up. Instead, try this. Set vlc audio back to pulseaudio (or automatic, seems to map to the same thing) and then change these two lines in /etc/pulse/daemon.conf: -; default-sample-rate = 44100 -; alternate-sample-rate = 48000 +default-sample-rate = 48000 +alternate-sample-rate = 44100 Restart pulseaudio with systemctl --user restart pulseaudio and see if vlc plays nice with everything else as well as supporting smooth playback after seeking. It does for me. It seems that forcing pulseaudio to resample causes all sorts of hilarity (vlc seems to like putting everything out at 48000). I'm sure there's a reason why. I'm also sure if I know, I'll be sorry I do. I wonder, how hard is it to get the Vulkan video hardware decoding working? Has anyone gotten it to work?

@usual userWell, this was also my feeling that there might be something wrong with the device tree. The Hardkernel section for HDMI looks a little bit different compared to the HDMI section in the device tree I have used. I thought it would be kind of okay, because the kernel is a different one. But maybe this assumption was wrong... So what could I do if I'd like to try the Hardkernel DTB? Is there a chance that it just works? Or would it be the better way to create an device tree overlay? I don't know anything at all about that, sry... EDIT: Could there be other reasons? Like an deactivated video output option somewhere? Or maybe it need to be actively activated? Please let me know if I can provide further information, file contents or so...

After many days spent wondering why is my OPI Zero2w 1.5GB not booting some Armbian images (xfce desktop version for example), I have found there is a "bug" or difference in uboot models 1.5GB + 4GB vs 1GB+2GB. Fix that might work for Zero2w is here https://forum.armbian.com/topic/31654-orange-pi-zero-2w/ (planning to test it soon) Can somebody confirm Opi Zero2W 1.5GB has still this issue with some Armbian images ? Armbian minimal boots without aby issues. Not sure why it works and desktop doesnt.

ODROID M1: dmesg | grep -i hdm [ 0.132185] /vop@fe040000: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 0.132325] /hdmi@fe0a0000: Fixed dependency cycle(s) with /vop@fe040000 [ 0.170085] /hdmi@fe0a0000: Fixed dependency cycle(s) with /hdmi-con [ 0.170254] /hdmi-con: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 1.180141] dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) [ 1.181147] dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 1.182413] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops) ODROID M2: dmesg | grep -i hdm [ 0.104853] /vop@fdd90000: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.104911] /hdmi@fde80000: Fixed dependency cycle(s) with /vop@fdd90000 [ 0.121323] /hdmi@fde80000: Fixed dependency cycle(s) with /hdmi-con [ 0.121364] /hdmi-con: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.547910] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver [ 0.548835] rockchip-drm display-subsystem: bound fde80000.hdmi (ops dw_hdmi_qp_rockchip_ops) ODROID N2+: dmesg | grep -i hdm [ 0.079885] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /soc/vpu@ff900000 [ 0.080281] /soc/vpu@ff900000: Fixed dependency cycle(s) with /soc/bus@ff600000/hdmi-tx@0 [ 0.080908] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /soc/vpu@ff900000 [ 0.081352] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /soc/vpu@ff900000 [ 0.090819] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /soc/vpu@ff900000 [ 0.090892] /soc/vpu@ff900000: Fixed dependency cycle(s) with /soc/bus@ff600000/hdmi-tx@0 [ 0.097002] /soc/bus@ff600000/hdmi-tx@0: Fixed dependency cycle(s) with /hdmi-connector [ 0.097080] /hdmi-connector: Fixed dependency cycle(s) with /soc/bus@ff600000/hdmi-tx@0 [ 0.561480] meson-dw-hdmi ff600000.hdmi-tx: Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy) [ 0.561810] meson-dw-hdmi ff600000.hdmi-tx: registered DesignWare HDMI I2C bus driver [ 0.562112] meson-drm ff900000.vpu: bound ff600000.hdmi-tx (ops meson_dw_hdmi_ops) NanoPC-T6-LTS: dmesg | grep -i hdm [ 0.119431] /vop@fdd90000: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.119475] /hdmi@fde80000: Fixed dependency cycle(s) with /vop@fdd90000 [ 0.137536] /vop@fdd90000: Fixed dependency cycle(s) with /hdmi@fdea0000 [ 0.137589] /hdmi@fdea0000: Fixed dependency cycle(s) with /vop@fdd90000 [ 0.139716] /hdmi@fde80000: Fixed dependency cycle(s) with /hdmi0-con [ 0.139765] /hdmi0-con: Fixed dependency cycle(s) with /hdmi@fde80000 [ 0.139922] /hdmi@fdea0000: Fixed dependency cycle(s) with /hdmi1-con [ 0.139960] /hdmi1-con: Fixed dependency cycle(s) with /hdmi@fdea0000 [ 0.579865] dwhdmiqp-rockchip fde80000.hdmi: registered DesignWare HDMI QP I2C bus driver [ 0.580803] rockchip-drm display-subsystem: bound fde80000.hdmi (ops dw_hdmi_qp_rockchip_ops) [ 0.582184] dwhdmiqp-rockchip fdea0000.hdmi: registered DesignWare HDMI QP I2C bus driver [ 0.583115] rockchip-drm display-subsystem: bound fdea0000.hdmi (ops dw_hdmi_qp_rockchip_ops) At all HDMI ports work perfectly. And yes, they all use the same system booted from a USB enclosure. The only difference is the loaded DTB at system startup.

@KhanhDTP Amazing, thanks!! I'll give it a go. Just to check - how did you launch Portal ... from within Steam? ... or direct from the Portal folder? Did you use any special arguments when launching it? Thanks.

Only that its a known issue. In open source world it is normal to see magnitude more issues then its resolving capacity. I'll look into when possible - its high on 2do list. No need.

Yes for sure, thank you. > lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 003: ID 2b89:8761 Realtek Bluetooth Radio Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 004: ID 0583:2060 Padix Co., Ltd (Rockfire) 2-axis 8-button gamepad > sudo dmesg | grep -i bluetooth [ 1.706048] usb 6-1: Product: Bluetooth Radio [ 4.360426] Bluetooth: Core ver 2.22 [ 4.360457] NET: Registered PF_BLUETOOTH protocol family [ 4.360460] Bluetooth: HCI device and connection manager initialized [ 4.360466] Bluetooth: HCI socket layer initialized [ 4.360469] Bluetooth: L2CAP socket layer initialized [ 4.360480] Bluetooth: SCO socket layer initialized [ 4.415023] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 4.417020] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 4.417027] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 4.417442] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin [ 6.328832] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 6.328847] Bluetooth: BNEP filters: protocol multicast [ 6.328859] Bluetooth: BNEP socket layer initialized [ 870.557589] usb 6-1: Product: Bluetooth Radio [ 870.569776] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 870.571601] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 870.571614] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 870.571686] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin [ 1246.745679] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [ 1246.747602] Bluetooth: hci0: RTL: rom_version status=0 version=1 [ 1246.747629] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [ 1246.747756] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin [ 3667.259558] Bluetooth: RFCOMM TTY layer initialized [ 3667.259580] Bluetooth: RFCOMM socket layer initialized [ 3667.259595] Bluetooth: RFCOMM ver 1.11 [65689.757539] usb 4-1: Product: Bluetooth Radio [65689.769644] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000b lmp_ver=0a lmp_subver=8761 [65689.771604] Bluetooth: hci0: RTL: rom_version status=0 version=1 [65689.771649] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_fw.bin [65689.771913] Bluetooth: hci0: RTL: loading rtl_bt/rtl8761bu_config.bin And here's a pastebin of the full dmesg output. https://pastebin.com/wMuX0bVW I got the driver files from here, https://github.com/Elif-dot/RTL8761BU uname Linux opi5 6.16.4-edge-rockchip64 #1 SMP PREEMPT Thu Aug 28 14:34:51 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux thanks

Thanks for the quick confirmation! From your answer I guess it is an issue that is already under investigation. No need to open a dedicated issue on some tracker, right?

Hi, although this topic is quite old, I was trying to bring this forward. I think I had a partial success on this. I've built an Armbian image with a newly created defconfig file. I took the DTB file from above. Result: the board seems to boot (SD card). The blue LED starts to blink (heartbeat). Ethernet is working, I can SSH into the box. USB seems to work, at least my Logitech Unifying Receiver is recognized Problem: there is no HDMI output. with dmesg | grep -i hdm I got the following output: [ 0.083861] /vop@fe040000: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 0.083981] /hdmi@fe0a0000: Fixed dependency cycle(s) with /vop@fe040000 [ 0.118236] /hdmi@fe0a0000: Fixed dependency cycle(s) with /hdmi-con [ 0.118360] /hdmi-con: Fixed dependency cycle(s) with /hdmi@fe0a0000 [ 4.671032] dwhdmi-rockchip fe0a0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (DWC HDMI 2.0 TX PHY) [ 4.675209] dwhdmi-rockchip fe0a0000.hdmi: registered DesignWare HDMI I2C bus driver [ 4.689857] rockchip-drm display-subsystem: bound fe0a0000.hdmi (ops dw_hdmi_rockchip_ops [rockchipdrm]) I dont know if this help. Maybe someone can assist? @Igoreverybody here honors and respects you and your work and your effort. We (or at least me) do not expect you to bring up one after another working image for all boards out there. What we do is asking for help to help ourselves. It is more than clear and obvious, that you are frustrated by the numerous apparent "requests" on one side and a massive lack of volunteering support on the other side. BUT: for US it is also sometimes frustrating, that you try to end all those threads like this by saying "STFU, RTFM". I am (and many more are) NOT those people, who just pass by to say "Hey Armbian, when do you finally support board XYZ?????????". Many of us TRY to contribute. But sometimes the tasks are just too hard to teach ourselves. You do this on a daily basis. But for "beginners" building the first linux image is so damn challenging and especially when you are alone on the battlefield (like when trying to bring an unsupported board to life). Yes, I read the docs. And yes, I already did before you restructured the build system. So asking for help is not intended to upset you. And still, I don't expect any support from your side. We try to come as far as possible on our own. But maybe there has been a time, when even you needed some guidance which involved a little bit more than RTFM... I respect and appreciate your work!

Correct. It's a problem of: https://github.com/armbian/os/blob/main/.github/workflows/complete-artifact-matrix-all-stable.yml and this configuration: https://github.com/armbian/os/blob/main/userpatches/targets-all-not-eos.yaml It is something to study

Looks like the package in subject is not in the repos. However, there are other packages depending on it (explicitly indicating that the required version is >=25.8.2) so this prevents package updates. Interestingly, for the armhf target the package is available, so I suspect a build issue. Any clue?

Now it seems that the package is missing for version 25.8.2 and arm64 target. There are packages depending on it (and specifically asking for version >=25.8.2), so this prevents upgrades.

Armbian 25.8.1 Noble XFCE (BSD Kernel: 6.1.115) + PanVk - mesa 23.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + box64 3.9 (https://ryanfortner.github.io/box64-debs/) + wine-10.17-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.17) + DXVK-stripped v1.8.1 (https://github.com/khanh-it/dxvk/releases) ~60fps@720p @MartinB

This kernel is available only when you change repository to beta.armbian.com , which provides daily builds. EDGE kernels comes as is - glad to hear it works, but beware it might also break down as kernel is changing rapidly.

@MartinB Let me try it. How was your setup, anyway?

Hello, everyone! I have this same exact model, however, when I tried to boot it from the SD card it does nothing, I tried to hold the reset button and it seems to be stuck on boot. I used etcher to image the file shared by sicxnull, do I need to edit anything else? Am I míssing something? Thanks in advance for the help.

Can you send dmesg lsusb and lsmod outputs using paste.armbian.com

@lowscore I'did uploading for you! https://drive.google.com/file/d/1kgyjLl0JXTwFfWfplOKuQY3vLv_KtYlr/view?usp=sharing

Yeah so just like the title says, has anyone got a tip for a USB Bluetooth dongle that works with the mainline kernel? I got a UGREEN Bluetooth 5.0 dongle a while ago and have just tried again, installing firmware for it. It does get detected as a USB device and the firmware loads. But bluetoothctl never finds it. Gnome doesn't let me 'enable' bluetooth. I'd like to avoid buying a string of these so was just wondering if any are working with mainline? Cheers!

Yesterday, Oct 20th, I installed armbian version "Minimal/IOT images with Armbian Linux v6.1" to the Orange PI 5 PRO and updated kernel using armbian-config to kernel 6.18 RC1(2 options were available 6.12 and 6.18 R1, note 6.12 did not work). Armbian works fine including vulkan support(I tested with swith emulator) with this kernel(6.18 rc1), but today option to update to any kernel is not available anymore. I'm getting warning "No other kernels available!" System is pretty stable with this version. stas@orangepi5pro:~$ uname -r 6.18.0-rc1-edge-rockchip64 stas@orangepi5pro:~$ vulkaninfo --summary ========== VULKANINFO ========== Vulkan Instance Version: 1.4.309 Instance Extensions: count = 24 ------------------------------- VK_EXT_acquire_drm_display : extension revision 1 VK_EXT_acquire_xlib_display : extension revision 1 VK_EXT_debug_report : extension revision 10 VK_EXT_debug_utils : extension revision 2 VK_EXT_direct_mode_display : extension revision 1 VK_EXT_display_surface_counter : extension revision 1 VK_EXT_headless_surface : extension revision 1 VK_EXT_surface_maintenance1 : extension revision 1 VK_EXT_swapchain_colorspace : extension revision 5 VK_KHR_device_group_creation : extension revision 1 VK_KHR_display : extension revision 23 VK_KHR_external_fence_capabilities : extension revision 1 VK_KHR_external_memory_capabilities : extension revision 1 VK_KHR_external_semaphore_capabilities : extension revision 1 VK_KHR_get_display_properties2 : extension revision 1 VK_KHR_get_physical_device_properties2 : extension revision 2 VK_KHR_get_surface_capabilities2 : extension revision 1 VK_KHR_portability_enumeration : extension revision 1 VK_KHR_surface : extension revision 25 VK_KHR_surface_protected_capabilities : extension revision 1 VK_KHR_wayland_surface : extension revision 6 VK_KHR_xcb_surface : extension revision 6 VK_KHR_xlib_surface : extension revision 6 VK_LUNARG_direct_driver_loading : extension revision 1 Instance Layers: count = 2 -------------------------- VK_LAYER_MESA_device_select Linux device selection layer 1.4.303 version 1 VK_LAYER_MESA_overlay Mesa Overlay layer 1.4.303 version 1 Devices: ======== GPU0: apiVersion = 1.1.305 driverVersion = 25.0.7 vendorID = 0x13b5 deviceID = 0xa8670000 deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU deviceName = Mali-G610 driverID = DRIVER_ID_MESA_PANVK driverName = panvk driverInfo = Mesa 25.0.7-2 conformanceVersion = 1.4.1.2

Also step 1A & 1B are kind of weird... Like updating won't recognize the gpg key. I still could bypass the error by adding [trusted=true] on step 1B between deb and the link (or use sudo nano /etc/apt/sources.list.d/panfork-mesa.list if the file was already created).