usual user

  • Posts

    174
  • Joined

  • Last visited

Everything posted by usual user

  1. Thank you for sharing the schedule. But no hurry, my daily use cases are already working anyway. I'm only doing this for my own education and as a preview of maybe landing features in Mainline. For me, it's the other way around. hwdec=drm yield high CPU utilisation for bbb_sunflower_2160p_30fps_normal.mp4 and hwdec=drm-copy yield low CPU utilisation. As the values are fluctuating heavyly it is difficult to provide absolut numbers. But anyway here are some rough values: bbb_sunflower_1080p_30fps_normal.mp4: gst-play-1.0 ~35% mpv --hwdec=none --hwdec-codecs=all ~40% mpv --hwdec=drm --hwdec-codecs=all ~38% mpv --hwdec=drm-copy --hwdec-codecs=all ~28% bbb_sunflower_2160p_30fps_normal.mp4: gst-play-1.0 ~35% mpv --hwdec=none --hwdec-codecs=all ~98% playing slow, sound out of sync mpv --hwdec=drm --hwdec-codecs=all ~98% playing jerky, sound out of sync mpv --hwdec=drm-copy --hwdec-codecs=all ~34% playing slow, sound out of sync This is on plasma desktop with wayland backend. Desktop CPU usage fluctuates around 8 to 15% without playing a video, so it's uncertain which CPU cycles are really associated with video playback. The utilization is always distributed almost evenly over all cores. Frequency scaling is not considered here. For reference here the values for lxqt desktop with native xorg backend: bbb_sunflower_1080p_30fps_normal.mp4: gst-play-1.0 ~25% mpv --hwdec=none --hwdec-codecs=all ~30% mpv --hwdec=drm --hwdec-codecs=all ~28% mpv --hwdec=drm-copy --hwdec-codecs=all ~18% bbb_sunflower_2160p_30fps_normal.mp4: gst-play-1.0 ~18% paying as diashow mpv --hwdec=none --hwdec-codecs=all ~98% playing slow, sound out of sync mpv --hwdec=drm --hwdec-codecs=all ~98% playing jerky, sound out of sync mpv --hwdec=drm-copy --hwdec-codecs=all ~22% playing slow, sound out of sync Conlusion: The VPU decoder is not the bottleneck, but setting up an efifcient video pipeline with proper interaction of the several involved hardware acellerators. For Xwindow with the modeset driver this seems not realy possible.
  2. Thank you for the offer @jock. But 5.14.0 wise I had all VPU relevant LE patches and even the drm ones applied. With gstreamer framework it is working, even for bbb_sunflower_2160p_30fps_normal.mp4 without any problem. It is mpv that seems not be able to cope with the hight data rate. Useing --hwdec=drm-copy makes the CPU utilization ramp up go away and the video plays smoothly, but to slow and the sound get out of sync. I don't think I am missing anything kernel wise. Just tried to drop 2000-v4l-wip-rkvdec-vp9 in favour of this more recent patchset. Resolving a merge conflict to apply the LE patches on top was easy: But the kernel build drops out with this: So I will stay at the status quo of LE patches on 5.15.0-rc1 for now and wait till they rebase. VPU wise everything from LE is in place and seems to work.
  3. Moved on to 5.15.0-rc1. But applying the LE patches makes the kernel unbootable for rockchip. I had now omitted 2001 also, as it no longer applies cleanly, and of course the cherry-picking 0010, which have landed. Guess I have to take a closer look at which patches are really important to me and see if they are the cause. With only linux-0011-v4l2-from-list, linux-1001-v4l2-rockchip and 2000-v4l-wip-rkvdec-vp9 applied the kernel keeps working. Although the drm patches seem interesting, I'll leave them out for now.
  4. I'm currently at gstreamer1-1.19.1, which works for my daily use cases flawless with the distribution package. But as soon as a deficiency should show up, it would be no big deal for me to rebuild with current master or pull in in-flight patches. But till then I will let the improvements trickle in via the regular updates. Out of curiosity, I just started two instances of gst-play-1.0 with different videos at the same time, and both videos play flawlessly at the same time. OK, the mixed sound is a bit confusing.
  5. Thank you @jernej for your detailed background information. In the past I didn't care much about ffmpeg driven video pipelines. I made several attempts, but because of the sparse documentation and not even the basic support in mainline, I gave up pretty quickly. I do this out of curiosity and for early use of future maninline support. So as long as I can't find information on how to use it in daily use cases, I'll ignore it again. At least I have now some kernel patches that benefit gstreamer framework that I can track till they land in mainline.
  6. Thank you @jock for your detailed explanation. Since I use a different distribution, your instructions don't apply to my environment, but I know how to do it for myself. I just need to know what to do and @jernej has already pointed this out (needed patches and build requirements). I haven't considered this aspect so far, as it hasn't been mentioned that LE patched headers are required. I just applied all the LE kernel patches and just omitted obviously not necessary ones. Because ffmpeg build flawless with the native headers, I moved on. I have installed round about twenty kernels at the same time and it will be decided at boot which one to use. Therefore, I only move in new headers when necessary. gst-play-1.0, ffplay and mpv now play bbb_sunflower_1080p_30fps_normal.mp4 with similar achievement. For gst-play-1.0 I know how to visualize the composed video pipeline. And due to the v4l2slh264dec (V4L2 Stateless H.264 Video Decoder) component in gst-play-pipiline.pdf I know for sure that hardware acceleration is used. So I guess the ffmpeg video pipeline is also using hardware acceleration. gst-play-1.0 plays bbb_sunflower_2160p_30fps_normal.mp4 with same CPU utilization. For ffplay and mpv CPU utilization ramps up significantly and frame drops are reported. The video also plays jerky. I can't say which components of the ffmpeg video pipeline is the limiting factor here. Because the kernel patches also benefit the gstreamer framework, I will probably continue to use them. Let's see what explodes when 5.15.0-rc1 is available next week.
  7. My kernel has now 0010, 0011, 0020, 1000, 1001, 2000 and 2001 LE patch applied. I don't see any significant change in behavior, so I can't say if the ffmpeg-driven video pipeline realy uses hardware acceleration. The mpv command of @kprasadvnsi is playing for me. In the mpv.log the Codec list mentions, "h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper", but I don't know if this is used. Neither I don't know how to select which decoder (hantro, rkvdec) will be used, it's the first time I use mpv.
  8. I don't know what I really need to look for, but since "v4l2_request" in ffmpeg.log is mentioned several times, I think "v4l2-request-hwaccel" is present. Guess now I have to figure where LE is hideing the current 5.14.0 kernel patches.
  9. Looks like the clocking set up by uboot for HDMI is not suitable for setting up the native video mode that the monitor wants to set through the kernel. Either drop in an uboot without HDMI support and lose the uboot display support or set up a native HDMI mode for linux. It is known that manline rockchip is limited in selecting video modes, only native HDMI modes are suported for sure. There are several patches floating around to enable more modes for a particular clocking, but nothing finaly decided.
  10. A few days ago I also tried to build a ffmpeg with v4l2-request-hwaccel. Because my distribution already uses 4.4, I used these patches. Initially, I got similar error messages as @kprasadvnsi, but the 5.14 kernel header hint was the missing link. I also have a flawlessly compiled ffmpeg package now, but I also don't know if additional patches are needed for other mainline components or how to check the v4l2-request-hwaccel functionality.
  11. Thanks for moving it, I wouldn't have known how else I could have split it appropriately.
  12. I am running on fedora as can be seen here. Fedora is not device-specific, only architecture-specific. If you want to experiment, drop in a distro-boot capable u-boot for your device in the firmware area and you should be good enough to go. I have never tested my image on a different device so YMMV.
  13. Sure thing, the attached overlays are written in absolut path notation. That is, they apply to any target base dtb regardless of whether they are built with the "@" switch or not. They can serve as a basis to collect overlays for all types of devices. Gpiochip is configured in rk3399.dtsi, i.e. the overlays can be used as a template for all dtbs which include this file. Therefore, the compatible must be adjusted, and the con1-## names must be inserted in the right place. Because libgpiod provides python bindings, it should be easy to make use of the con1-## names. Now you can forget about WiringPi. All you need is a devicetree overlay that assigns the con1-## names, and you can make any device with gpiochip support usable without changing the user space software. The first step would be to look at the schematic to see if it's really wired that way. If so, you need to decide which feature you prefer and configure devicetree in the appropriate way. Maybe is this a solution to use a spare GPIO. If the wireing is ok, there is still the possibility it is misconfigured in the devicetree but only looking at the source will tell. rk3399-nanopc-t4-con1.dts rk3399-rock-pi-4-con1.dts
  14. I have written an overlay for my device to assign names to the GPIO lines wich are wired up to the extention connector. This facilitates the identification of the GPIOs to be selected. I have also written a rk3399-rock-pi-4 one. It can be staticly applied to the base dtb like this: [root]# mv rk3399-rock-pi-4a.dtb rk3399-rock-pi-4a.dtb.orig [root]# fdtoverlay --input rk3399-rock-pi-4a.dtb.orig --output rk3399-rock-pi-4a.dtb rk3399-rock-pi-4-con1.dtbo The wiring of the GPIOs differs substantially between my device and the rock-pi, but because of the chosen name format (con1-## with ## = connector pin number) this is not relevant for user space any longer. E. g.: "gpioget $(gpiofind con1-11)" always finds the correct line to request the state of pin 11 of the connector. Of course only GPIO supported pins can be used, e. g. my device has way less pins capable of GPIO than the rock-pi. Therefore, con1-03 may be for rock-pi, but never available for my device. The only remaining task is now to create one-time corresponding overlays for all devices to be supported and to apply them accordingly. rk3399-rock-pi-4-con1.dtbo
  15. As "not used for GPIO", but not automatically available if the SOC has configured it for another function. This situation can change at runtime if, for example, one driver is unloaded and another is loaded. It is only available for GPIO if the pinctrl is set up for GPIO functinality for that pin. And this requires suitable properties in devicetree. Be it native in the base dtb or applied as overlay. It is a devicetree source code snippet, how you apply it is up to you. You can add it to your source or write it as an overlay and then apply it dynamically or statically. It's the label showing up in the listing: Only if this line is also wired up to the pmic. When the power is cut off, no code is executed any longer that could initiate actions. As with any other keycode that the input event system outputs. If you had configured "linux,code = <KEY_A>;", you would not be able to tell if you have pressed the button or the "A" key on your keyboard.
  16. Of course not, it's probably pinmuxed on special pwm functionality and therefore no longer available for GPIO. For this there is the gpio-keys driver in the kernel. I would add something along this lines to the devicetree and leave anything else to the input event system: #include <dt-bindings/input/linux-event-codes.h> gpio-keys { compatible = "gpio-keys"; autorepeat; power { debounce-interval = <100>; gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>; label = "Power-key"; linux,code = <KEY_POWER>; wakeup-source; }; }; I left out the pinmux settings as your GPIO already seems to be set up properly.
  17. You are absolutely right, I am off by one. A starts at 0 not 1 Sory for the noise. Your IO is exported by sysfs interface at that time, which probably prevents the use of gpiod. Only one user allowed at a time. Can you retry without sysfs export?
  18. You did your calculation wrong. Rockhip divides each gpiochip into four eight bit segments (A B C D). Therefore, the correct resolution is: gpiochip 4 line 26 (C+2 | 3*8+2)
  19. From a user space point of view, there is no either or. It depends on which interface is supported by any existing software. If your kernel provides gpiochip and your software requires sysfs, enable "CONFIG_GPIO_SYSFS=y" and your software won't tell any difference between native sysfs. Gpiochip and sysfs interfaces can work simultaneously. New developments should use gpiochip, as it essentially offers more functionality. But before any IO functionalities can be used, the pin configuration of the SOC must be carried out correct. Almost no SOC uses single pins exclusively for IO, most of the time pins are able to perform several different dedicated functions. Of course, if a pin is configured for a different functionality, it is no longer available for IO at the same time. Gpiochip provides access to all possible IOs of the SOC, but only those really configured by pinctrl for IO are usable. How the pins on your specific device are wired is shown by the schematic. In order for the kernel drivers to know how the device is wired, this must be described in a kernel readable form. This is the reason why devicetree exists as it makes no sense to hard code it for any device.
  20. You cannot invent keycodes randomly, you must use the keycodes known to the input event system. "man rc_keymap" SEE ALSO Same way as done for any emitted key of your keyboard. User space cannot distinguish which input device emitted the keycode. Desktop environments typically have "shortcut keys" setup tools in the Settings pane.
  21. I use since long time pure mainline kernel for rt5651 support. The kernel hack that Armbian is still applying is not really required. If you like, I can upload a kernel for a quick test to see if it is also working for you. Or even easier, try this image for your NanoPC-T4, it should already have everything in place.
  22. Wrong approach, use "ir-keytable -ts rc1" to collect the scancode for any key on your remote control. Drop them in a toml file (man rc_keymap) and assign your linux input key‐codes. When done, check with "ir-keytable --test-keymap=<whatever_name>.toml". If the test is error-free, move <whatever_name>.toml to /etc/rc_keymaps/<whatever_name>.toml and register the file in /etc/rc_maps.cfg such as * rc-empty <whatever_name>.toml as a new last line. I recently did this for my FRIENDLYARM RC-100, see friendlyarm_rc-100.toml as reference. This way a udev rule picks up the keymap als soon as the rc kernel device is detected and the remote is working out of the box after every reboot. Now start collecting of <whatever_name>.toml files for any available remote control with the prefered keymapping and drop them in your distribution. This way choosing a remote control is only a registration in rc_maps.cfg away. Replace "rc-empty" if your remote reports a different keymap: # ir-keytable Found /sys/class/rc/rc1/ (/dev/input/event2) with: Name: gpio_ir_recv Driver: gpio_ir_recv, table: rc-empty ... friendlyarm_rc-100.toml
  23. This is only feeling and guesswork. I don't have your device model so can't check your setup by myself. Hence my request for a tmon log to see what is really going on. But if you are satisfied with your results, I have no further request and stop my curiosity.
  24. I'm curious how your thermal system performs, an opinion to post a tmon log while your device is being stressed? This is mine running for three hours with all six cores at 100%:
  25. i.MX6 support is feature complete since long time in mainline, I'm running fully flagged fedora on my i.MX6 devices for years. Not running current releases will missing bugfixes and latest features. No i.MX6 development is required, only an administrator who knows how to integrate software in his system. So you are fully qualified. You want the xf86-video-armada driver as referenced in the other thread. If you want to know how it fits together, see buffer-flow.pdf Armbian manages their build system with git. So you issue a pull request (PR) to get your modification discussed and hopefully finaly applied.