Jump to content

Azq2

Members
  • Posts

    14
  • Joined

  • Last visited

Everything posted by Azq2

  1. Your sure about video acceleration in chromium? In chrome://gpu i see "Video Decode: Hardware" But in chrome://media-internals/ i see "FFmpegVideoDecoder". And when i trying to play 1080p - all cpu cores have 100% load...
  2. Canon provides source code for cups driver, but with some proprietary binary libs. This libs available only for x86. No way for direct compiling cnijfilter for ARM (and other architectures). But we have qemu! We can transparently run x86 executables on any other host architectures. Easy steps to run cnijfilter on ARM (or any other arch): - Build https://github.com/endlessm/cnijfilter-common for x86 - Copy all needed x86 libs using recursive ldd. And copy it to /usr/lib/bjlib/ - Patch all executables: set interpreter to /usr/lib/bjlib/x86/ld-linux.so.2 and rpath to /usr/lib/bjlib/ - Install these patched packages to ARM system - Install qemu-user and qemu-user-binfmt (or qemu-arm-static) You do not need to do this manually. I have implemented an automated build system: https://github.com/Azq2/cnijfilter-arm-build All you need is any x86 machine to do the build. How to use 1. On any x86 machine: # Install dependencies sudo apt install debootstrap git util-linux # Get build system git clone https://github.com/Azq2/cnijfilter-arm-build # Start building cd cnijfilter-arm-build sudo ./build.sh build # Get .deb packages ls -lah ./result/full ls -lah ./result/light After build we have two variants of packages: full and light Item Full Light PPD files + + CUPS filters + + CUPS backends + - lgmon + - canon-maintenance + - cngpij + - cngpijmnt + - cnijlgmon2 + - cnijnetprn + - cnijnpr + - docs + - In most cases, a light package is completely sufficient: - We don't need canon usb backend, because cups have builtin USB support - We don't need canon network backend, because cups have builtin BJNP support (package cups-backend-bjnp) - Other canon maintenance utils are useless (in my opinion) 2. Copy .deb from result/light or result/full to your ARM machine. 3. On your ARM machine: # Install dependencies sudo apt install qemu-user qemu-user-binfmt # or sudo apt install qemu-user-static # Install common for all printers package sudo dpkg -i cnijfilter-common.deb # Install printer-specific package # Choose right package for your printer! e400series only for reference! sudo dpkg -i cnijfilter-e400series.deb 4. Done. You can now configure CUPS. Security with apparmor (optional) CUPS filters don't need any specific permissions. Create file /etc/apparmor.d/cnijfilter-filters with contents: #include <tunables/global> /usr/bin/bjfilter* { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } /usr/bin/cif[a-z]*[0-9d]* { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } /usr/lib/cups/filter/{cmdtocanonij,pstocanonbj,pstocanonij} { #include <abstractions/base> @{PROC}/sys/vm/mmap_min_addr r, } Then restart apparmor: sudo systemctl reload apparmor sudo aa-enforce cnijfilter-filters Note: this minimal file full coverage all executables in light package. For full package you need write additional rules by yourself.
  3. Please, don't forget delete test user for ssh: userdel -f test222 Also, i released image without openssh and "test222" user: https://zhumar.in/Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop_v3.zip Not official. Only for test. As own risk. If any other users with same problem want to test this image. Until it is fixed in the official release (in progress). sha256: 377040dd9c42beaec1531199099d0eb12a547cab3f4e761801bbe1c20afe00b1
  4. Do not forget to write if everything is ok.
  5. Patched image v2: https://zhumar.in/Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop_v2.zip (I forgot remove "next" kernel image on v1)
  6. Patched image: https://zhumar.in/Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop.zip Also have ssh (if network automaticaly connected, use ethernet): user: test222 password: EerYuVpmXEkOGoSG
  7. # Install required software sudo apt install parted qemu binfmt-support qemu-user-static # Mount armbian image sudo losetup /dev/loop0 Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop.img sudo partprobe /dev/loop0 sudo mount /dev/loop0p1 /mnt # Copy qemu static binary for arm chrooting sudo cp -pR /usr/bin/qemu-arm-static /mnt/usr/bin/qemu-arm-static # From dir, where you place downloaded debs sudo cp linux-image-rockchip_5.77_armhf.deb dpkg linux-dtb-rockchip_5.77_armhf.deb /mnt/tmp # Mount system dirs and go chroot cd /mnt sudo mount -t devtmpfs dev dev sudo mount -t sysfs sys sys sudo mount -t devpts dev/pts dev/pts sudo mount -t proc proc proc sudo chroot . # Now we in arm chroot. # Do magic mv /bin/sync /bin/sync2 ln -s /bin/true /bin/sync # Remove "next" dpkg -r linux-dtb-next-rockchip linux-image-next-rockchip # Do install required debs. dpkg -i /tmp/*.deb # Optional: you can install openssh-server in this step... # apt install openssh-server # adduser test222 # passwd test222 # usermod -G sudo -a test222 # Undo magic rm /bin/sync mv /bin/sync2 /bin/sync # Go to host exit # Now we in host # Unmount image sudo umount /mnt/*/* sudo umount /mnt/* cd / sudo umount /mnt sudo sync # Done. Flash Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop.img to your tinkerboard.
  8. Yes, copying not working. You are using Linux on PC?
  9. May be you don't delete old "next"kernel before installing 4.4 apt purge linux-image-next-rockchip linux-dtb-next-rockchip dpkg -i linux-image-rockchip_5.77_armhf.deb dpkg -i linux-dtb-rockchip_5.77_armhf.deb
  10. Okay. linux-image-rockchip_5.77_armhf.deb linux-dtb-rockchip_5.77_armhf.deb
  11. Try my fixes: [SOLUTION] Armbian kernel 4.4 has broken HDMI (don't work some resolutions) I think, your issue same.
  12. Hi! I connect my 1366x768 monitor to Tinkerboard, but resolution sets to 1280x720. $ xrandr Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192 HDMI-1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 410mm x 230mm 1920x1080 60.00 + 1280x720 60.00* 720x480 60.00 Yes, i tried set timings manualy. I set native from edid: Modeline "Mode 0" 85.50 1366 1436 1579 1792 768 771 774 798 +hsync +vsync But after applying this modeline: - monitor detects 1280x720 resolution instead of 1366x768 - crops image as 1024x768 - have many noises and waves on screen... very unstable image (pixel clock 84.857 mhz, but expected 85.5 mhz) I tried use modelines but result is one - not working. Why it happens? Answer is simple: https://github.com/TinkerBoard/debian_kernel/blob/e57365482d2e2e5105d9d368eca432248fcf92a2/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#L2273 /* * Hdmi or DisplayPort request a Accurate clock. */ if (output_type == DRM_MODE_CONNECTOR_HDMIA || output_type == DRM_MODE_CONNECTOR_DisplayPort) if (clock != request_clock) // see this return MODE_CLOCK_RANGE; Clock for HDMI must be set without any deviations. And this is the very reason why 1366x768 not listed in xrandr. But setting manual timings with xrandr omits this check. But not works too. Why? Here the answer was also simple. I added debug to hdmi_av_composer() for dump actual mpixelclock. And i set manual timings like this: Debug for this timings: [ 152.196219] hdisplay = 1366 pixel [ 152.196224] vdisplay = 768 lines // Front porch [ 152.196231] h_de_hs = 70 pixel clks // hsync len [ 152.196236] hsync_len = 143 pixel clks // back porch [ 152.196226] hblank = 426 pixel - (143 + 70) = 213 // Front porch [ 152.196234] v_de_vs = 3 lines // vsync len [ 152.196238] vsync_len = 3 lines // back porch [ 152.196229] vblank = 30 pixel - 6 = 24 // pixel clock [ 152.196241] vmode->mpixelclock = 84857000 hz [ 152.196243] vmode->mtmdsclock = 84857000 hz And what do we see? All is well, except pixel clock. I set 85.5 MHz, but driver set 84.857 MHz. WTF? 0.643 Mhz difference, Karl! What does it mean? PLL can't calculate dividers for wanted DCLK frequency. Okay, after few day of research i randomly checked TinkerOS. And it works: azq2@tinkerboard:~$ xrandr Screen 0: minimum 320 x 200, current 1280 x 720, maximum 8192 x 8192 HDMI-1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 410mm x 230mm 1366x768 59.79 + 1920x1080 60.00 59.94 1152x864 75.00 1280x720 60.00* 59.94 1152x720 59.97 1024x768 75.03 60.00 832x624 74.55 800x600 75.00 60.32 720x480 60.00 59.94 640x480 75.00 60.00 59.94 720x400 70.08 O_O WTF??? This is a bug of Armbian maintainers...? (spoiler: It turned out that yes -_-) I checked all patches that affect dw hdmi or VOP. And I found a problem. In commit 93ae28f78dce6c747f0616dced591af7edf31377 maintainer igorpecovnik upgrades kernel and for some strange reasons disables very important patch 01-linux-0005-dts.patch But this patch contains important changes for HDMI: +static struct rockchip_pll_rate_table rk3288_npll_rates[] = { + RK3066_PLL_RATE_NB(594000000, 1, 99, 4, 32), + RK3066_PLL_RATE_NB(585000000, 6, 585, 4, 32), + RK3066_PLL_RATE_NB(432000000, 3, 216, 4, 32), + RK3066_PLL_RATE_NB(426000000, 3, 213, 4, 32), + RK3066_PLL_RATE_NB(400000000, 1, 100, 6, 32), + RK3066_PLL_RATE_NB(342000000, 3, 171, 4, 32), + RK3066_PLL_RATE_NB(297000000, 2, 198, 8, 16), + RK3066_PLL_RATE_NB(270000000, 1, 135, 12, 32), + RK3066_PLL_RATE_NB(260000000, 1, 130, 12, 32), + RK3066_PLL_RATE_NB(148500000, 1, 99, 16, 32), + RK3066_PLL_RATE(148352000, 13, 1125, 14), + RK3066_PLL_RATE_NB(146250000, 6, 585, 16, 32), + RK3066_PLL_RATE_NB(108000000, 1, 54, 12, 32), + RK3066_PLL_RATE_NB(106500000, 4, 213, 12, 32), + RK3066_PLL_RATE_NB(85500000, 4, 171, 12, 32), + RK3066_PLL_RATE_NB(74250000, 4, 198, 16, 32), + RK3066_PLL_RATE(74176000, 26, 1125, 14), + { /* sentinel */ }, +}; + #define RK3288_DIV_ACLK_CORE_M0_MASK 0xf #define RK3288_DIV_ACLK_CORE_M0_SHIFT 0 #define RK3288_DIV_ACLK_CORE_MP_MASK 0xf @@ -214,7 +235,7 @@ static struct rockchip_pll_clock rk3288_pll_clks[] __initdata = { [gpll] = PLL(pll_rk3066, PLL_GPLL, "gpll", mux_pll_p, 0, RK3288_PLL_CON(12), RK3288_MODE_CON, 12, 8, 0, rk3288_pll_rates), [npll] = PLL(pll_rk3066, PLL_NPLL, "npll", mux_pll_p, 0, RK3288_PLL_CON(16), - RK3288_MODE_CON, 14, 9, ROCKCHIP_PLL_SYNC_RATE, rk3288_pll_rates), + RK3288_MODE_CON, 14, 9, 0, rk3288_npll_rates), }; It adds additional dividers for npll (used as source for DCLK). For exmaple, 85500000 needed for me. After applying this patch my problem resolved. All resolutions determinted and monitor works normal. root@tinkerboard:~# cat /sys/devices/platform/display-subsystem/drm/card0/card0-HDMI-A-1/modes 1366x768p60 1920x1080p60 1920x1080p60 1152x864p75 1280x720p60 1280x720p60 1024x768p75 1024x768p60 800x600p75 800x600p60 640x480p75 720x400p70 I send pull request https://github.com/armbian/build/pull/1317 I'm not sure that he will be accepted. I created this topic for tinkerboard users with same problem. This patch helped me. You can manualy build kernel with this patch (needed ubuntu bionic as host system): git clone https://github.com/armbian/build cd build wget https://patch-diff.githubusercontent.com/raw/armbian/build/pull/1317.patch -O 1317.patch patch -p1 < 1317.patch sudo ./compile.sh BOARD=tinkerboard BRANCH=default KERNEL_ONLY=yes RELEASE=bionic NO_APT_CACHER=yes BUILD_KSRC=no P.S. The commit description speaks for itself Debs for test: linux-image-rockchip_5.77_armhf.deb linux-dtb-rockchip_5.77_armhf.deb Or image with installed patched debs:https://zhumar.in/Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop_v3.zip sha256: 377040dd9c42beaec1531199099d0eb12a547cab3f4e761801bbe1c20afe00b1 Not official. Only for test. Use this as own risk.
  13. I have same problem. You have two ways: 1. Try set timings manualy. Find in /var/log/Xorg.0.log right modeline and add it to xrandr. # CVT xrandr --newmode "1920x1200_cvt" 193.25 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync xrandr --addmode HDMI-1 "1920x1200_cvt" xrandr --output HDMI-1 --mode "1920x1200_cvt" # if not working - GTF xrandr --newmode "1920x1200_gtf" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -HSync +Vsync xrandr --addmode HDMI-1 "1920x1200_gtf" xrandr --output HDMI-1 --mode "1920x1200_gtf" # or you can find right timings in /var/log/Xorg.0.log 2. If not working - try my pull request for 4.4 kernel: https://github.com/armbian/build/pull/1317
  14. I have same problem. You have two ways: 1. Try set timings manualy. Find in /var/log/Xorg.0.log right modeline and add it to xrandr. # CVT xrandr --newmode "1920x1200_cvt" 193.25 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync xrandr --addmode HDMI-1 "1920x1200_cvt" xrandr --output HDMI-1 --mode "1920x1200_cvt" # if not working - GTF xrandr --newmode "1920x1200_gtf" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -HSync +Vsync xrandr --addmode HDMI-1 "1920x1200_gtf" xrandr --output HDMI-1 --mode "1920x1200_gtf" # or you can find right timings in /var/log/Xorg.0.log 2. If not working - try my pull request for 4.4 kernel: https://github.com/armbian/build/pull/1317
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines