usual user
-
Posts
425 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by usual user
-
-
On 9/15/2021 at 10:39 PM, jernej said:
You'll wait for more than a month.
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.
On 9/15/2021 at 10:50 PM, jock said:Also on my tests drm-copy is consuming more cpu power.
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 syncThis 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.
On 9/15/2021 at 10:50 PM, jock said:I didn't try gstreamer yet, but is it working smooth for you in X11 window?
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 syncConlusion:
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. -
1 hour ago, jock said:
If you're interested I can point the repository to you when I'm done.
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:
Spoiler--- linux-0011-v4l2-from-list.patch.orig<------>2021-09-08 20:04:26.000000000 +0200 +++ linux-0011-v4l2-from-list.patch<--->2021-09-15 19:00:00.000000000 +0200 @@ -756,9 +756,9 @@ index d31344c4acaa..d068383aeea8 100644 <----><------><------>return -EINVAL; .. <----><------>if (ctx->valid_fmt && ctx->valid_fmt != rkvdec_valid_fmt(ctx, ctrl)) -@@ -155,6 +151,9 @@ static const struct rkvdec_ctrls rkvdec_h264_ctrls = { +@@ -101,6 +151,9 @@ static const struct rkvdec_ctrls rkvdec_ .. - static const u32 rkvdec_h264_decoded_fmts[] = { + static const u32 rkvdec_h264_vp9_decoded_fmts[] = { <---->V4L2_PIX_FMT_NV12, +<---->V4L2_PIX_FMT_NV15, +<---->V4L2_PIX_FMT_NV16,But the kernel build drops out with this:
Spoilerdrivers/staging/media/hantro/imx8m_vpu_hw.c:145:27: error: ‘V4L2_PIX_FMT_NV12_4L4’ undeclared here (not in a function); did you mean ‘V4L2_PIX_FMT_NV12M’? 145 | .fourcc = V4L2_PIX_FMT_NV12_4L4, | ^~~~~~~~~~~~~~~~~~~~~ | V4L2_PIX_FMT_NV12MSo 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. -
On 9/11/2021 at 11:25 AM, usual user said:
Let's see what explodes when 5.15.0-rc1 is available next week.
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.
-
11 hours ago, jernej said:
Current master branch of gst-plugins-bad (what will land in next stable release) should already work pretty well with all stable codecs (MPEG2, H264 and VP8).
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.
-
Thank you @jernej for your detailed background information.
3 hours ago, jernej said:AFAIK ffplay doesn't use HW acceleration. At least I never managed to force it. That's why I gave ffmpeg based test command. I can't help you with mpv...
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. -
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).
22 hours ago, jock said:One thing that always makes me have headaches are the userland kernel headers, which are not the same kernel headers used to compile modules
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.
-
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.
-
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.
1 hour ago, jernej said:If you don't use LE kernel patches, decoding interlaced H264 content won't work on RK. HEVC also won't work without kernel patches.
Guess now I have to figure where LE is hideing the current 5.14.0 kernel patches.
-
On 7/1/2021 at 3:52 PM, RussianNeuroMancer said:
Unfortunately, this image does not load on my T4, get stuck here.
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.
-
21 hours ago, jernej said:
You are using sources meant to be used on 5.14.
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.
-
29 minutes ago, JMCC said:
Moved from the RK3399 multimedia integration thread to here
Thanks for moving it, I wouldn't have known how else I could have split it appropriately.
-
1 hour ago, tony013 said:
I would like to select between desktop and kodi by using different users or something like that.
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.
-
7 hours ago, tony013 said:
Do you mind to publish the source of your overlay?
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.7 hours ago, tony013 said:Do you know about a way to find conflicts between muxed modules, which share the same pin?
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.
-
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.
Spoilergpiochip0 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed "vcc3v0-sd" output active-high [used] line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed "host-wakeup" input active-high [used] line 5: unnamed "GPIO Key Power" input active-low [used] line 6: unnamed "ir-receiver" input active-low [used] line 7: unnamed "cd" input active-low [used] line 8: unnamed unused input active-high line 9: unnamed "shutdown" output active-high [used] line 10: unnamed "reset" output active-low [used] line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed "status_led" output active-high [used] line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: unnamed unused input active-high line 22: unnamed unused input active-high line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed unused input active-high line 27: unnamed unused input active-high line 28: unnamed unused input active-high line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-high gpiochip1 - 32 lines: line 0: "con1-07" unused input active-high line 1: "con1-11" unused input active-high line 2: unnamed unused input active-high line 3: "con1-13" unused input active-high line 4: "con1-15" unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: "con1-12" unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: unnamed unused input active-high line 22: "con1-16" unused input active-high line 23: "con1-18" unused input active-high line 24: "con1-22" unused input active-high line 25: unnamed unused input active-high line 26: unnamed unused input active-high line 27: unnamed unused input active-high line 28: unnamed unused input active-high line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-high gpiochip2 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused output active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: unnamed unused input active-high line 22: unnamed unused input active-high line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed "device-wakeup" output active-high [used] line 27: unnamed unused input active-high line 28: unnamed unused input active-high line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-high gpiochip3 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed "PHY reset" output active-low [used] line 16: unnamed unused input active-high line 17: unnamed unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: unnamed unused input active-high line 22: unnamed unused input active-high line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed unused input active-high line 27: unnamed unused input active-high line 28: "con1-37" unused input active-high line 29: "con1-38" unused input active-high line 30: "con1-40" unused input active-high line 31: unnamed unused input active-high gpiochip4 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high line 8: unnamed unused input active-high line 9: unnamed unused input active-high line 10: unnamed unused input active-high line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed unused input active-high line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: "con1-10" unused input active-high line 17: "con1-08" unused input active-high line 18: unnamed unused input active-high line 19: unnamed unused input active-high line 20: unnamed unused input active-high line 21: "con1-26" unused input active-high line 22: unnamed unused input active-high line 23: unnamed unused input active-high line 24: unnamed unused input active-high line 25: unnamed unused input active-high line 26: unnamed "vbus-typec" output active-high [used] line 27: unnamed unused output active-high line 28: unnamed "Headphone detection" input active-high [used] line 29: unnamed unused input active-high line 30: unnamed unused input active-high line 31: unnamed unused input active-highI 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.dtboThe 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. -
3 hours ago, tony013 said:
gpioinfo states the pin as unused
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.
3 hours ago, tony013 said:Is that an overlay or what is it? Who processes that file?
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.
3 hours ago, tony013 said:I would not have that key labeled "Power-key".
It's the label showing up in the listing:
Spoilerline 0: unnamed unused input active-high line 1: unnamed "vcc3v0-sd" output active-high [used] line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed "host-wakeup" input active-high [used] line 5: unnamed "Power-key" input active-low [used] line 6: unnamed "ir-receiver" input active-low [used] line 7: unnamed "cd" input active-low [used] line 8: unnamed unused input active-high line 9: unnamed "shutdown" output active-high [used] line 10: unnamed "reset" output active-low [used] line 11: unnamed unused input active-high line 12: unnamed unused input active-high line 13: unnamed "status_led" output active-high [used] line 14: unnamed unused input active-high line 15: unnamed unused input active-high line 16: unnamed unused input active-high3 hours ago, tony013 said:... anyway: does that "wakeup-source" mean, that the rockpi4 is able to wakeup on keypress after issuing a "poweroff"?
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.
Spoiler
3 hours ago, tony013 said:and last not least - how can I act on key-events in userspace?
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.
-
1 hour ago, tony013 said:
Interestingly the pwm, which I use for fan control is not recognized by gpioinfo.
Of course not, it's probably pinmuxed on special pwm functionality and therefore no longer available for GPIO.
1 hour ago, tony013 said:Well the button is not of good quality and some kind of flaky, but that many events? Puh
Now I understand, why I had so many problems in detecting the right button states ...
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.
-
50 minutes ago, tony013 said:
but I can't follow your calculation.
You are absolutely right, I am off by one.
A starts at 0 not 1
Sory for the noise.2 hours ago, tony013 said:line 18 is used by "sysfs" and gpiomon fails with
gpiomon: error waiting for events: Device or resource busy
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?
-
1 hour ago, tony013 said:
GPIO4_C2
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)
-
4 hours ago, TRS-80 said:
I figured I might as well learn the "new / supported" way.
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.
-
51 minutes ago, lucky62 said:
My remote has the few special keys, like Youtube, Netflix, TV control keys. These are also in my toml file, but names are not recognized by driver. Seems that key names must be only from defined set. What are the allowed names?
You cannot invent keycodes randomly, you must use the keycodes known to the input event system. "man rc_keymap" SEE ALSO
Quote53 minutes ago, lucky62 said:Second point not clear to me - how are the KEYs mapped to system/program actions?
For example - I would like to open YouTube in the browser when I will press the YouTube KEY, how to do?
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.
-
2 hours ago, RussianNeuroMancer said:
On NanoPC-T4 (which also equipped with rt5651) there is same issue, which same errors messages in dmesg. So maybe something else (besides rk3399-add-sclk-i2sout-src-clock.patch) is missing in Armbian?
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.
-
3 hours ago, jock said:
@lucky62 The key mapping is stored in the kernel, and ir-keytable is a tool to test but also store the key mappings in the kernel, It also allows you to retrieve and restore the whole mapping table at once.
You should use ir-keytable to do the mapping, then retrieve the whole table from the kernel and save it in a file, then restore the table in the kernel on every reboot.
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 ... -
6 hours ago, tparys said:
But, I spun up several jobs, the kernel pegged the fan shortly after, and after a few minutes got up to just over 60 C.
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.
-
5 hours ago, tparys said:
Would be interested to hear any thoughts/feedback
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%:Spoiler
CSC Armbian for RK3318/RK3328 TV box boards
in Rockchip CPU Boxes
Posted
I don't know what requirements Kivy places on the graphics stack, but since Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52, it certainly makes sense to read this to understand what to expect from a lima-driven GPU. I still remember very well times when my GPU only reached almost 2.0 and the performance was quite moderate. With now 3.1 it's a big difference for daily desktop use, although my GPU isn't yet declared fully compliant. But since this is bleeding edge development, at least the current mesa mainline release is required in any case. If not even the main branch to use just implemented extentions. Kernel driver wise everything necessary should already be available and therefor mesa is where you are looking for GPU support improvements.