usual user

  • Content Count

  • Joined

  • Last visited

About usual user

  • Rank
    Elite member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. English is probably not balbes150 native language and he is using a translator. "Hijacked" would be a better translation, your post is off topic in that thread.
  2. For the details you have to read the TRM (e.g.) of the specific device. VOP is how Rockchip is calling the display subsystem components. It is as mem2mem exposed and is e.g. usable for hardware accelerated video scaling in video pipelines. Sorry, you are to late in the game With my current setup, as soon as the memory pressure issue is resolved, I am feature complete.
  3. That configuration looks sane to me. That is the problem, basic KMS/drm acceleration does not suffice. You need the full set to be efficient. E.g. to have also accelerated video output from the VPUs and moving an entire frame buffer for only a line scroll somewhere on the screen is very inefficient. But any drm IP has different capabilities. Take for example i.MX6, the drm IP has very little capabilities but a separate 2D GPU. And the 3D GPU renders in a format that can't be scaned out by the drm IP. It has to be converted by the 2D GPU first. This is something modesetting can't
  4. lima is not the culprit, it is modesetting which uses it improperly. Disable it for modesetting by: Section "Device" Identifier "KMS-1" Driver "modesetting" Option "AccelMethod" "none" EndSection and leave lima in place so e.g. kodi-gbm and Wayland compositors can make use of it. You should also include a stanza like this: Section "OutputClass" Identifier "dwhdmi-rockchip" MatchDriver "rockchip" Option "PrimaryGPU" "TRUE" EndSection Section "OutputClass" Identifier
  5. ftdoverlay is a convenient way to apply an overlay staticly to a base dtb. You spare the DTC decompile - manually edit - DTC compile dance. Usually you write overlays with label refernces, but to be able to apply such an overlay, the base dtb has to be compiled with the @-option. This has significant impact on the size and distributions usually don't do this. When you write the overlay with full paths, it contains all the information to be applied to a base dtb that was not created with the @-option. The mainline ftdoverlay need the patch to be able to apply it. Edit the pwms pr
  6. There is nothing hardcoded, there is only a default value. And as one value does not fit them all, you have to set it to the value that fits your need. See rk3399-rockpro64-tz.dts for reference. Unfortunately you cannot apply this with mainline ftdoverlay because it does not support full path notion for a reference to another node. But with fdt_overlay.patch.txt applied it is working as expected.
  7. The right way to use the fan would be to have a proper thermal setup (rk3399-rockpro64-tz.dts) in the devicetree. With this the kernel thermal system can handle the management. This is a visualisation of a tmon log documenting the working of the thermal system: rk3399-rockpro64.dtb is a mainline dtb with rk3399-rockpro64-tz.dtbo applied via: fdtoverlay --input rk3399-rockpro64.dtb --output rk3399-rockpro64.dtb rk3399-rockpro64-tz.dtbo See if this is working for you by replacing your dtb and check with tmon.
  8. I gave up xorg and switched to plasma-desktop. Kwin is supporting a wayland backend and so I get a lightning fast graphics desktop with all bells and whistles. Ok the bugs at the panfrost stack still exist but this environment makes efficient use of anything that is available. Thanks to the configurability of kwin, I can have the same look and feel of my previous desktop.
  9. AFAIK armbianmonitor does not log the cooling devices, hence my request for the tmon log.
  10. Is the throttling triggered by thermal reasons or only by cpu load? A tmon log will tell you if it is really thermal throttling.
  11. A tmon log would be interesting to see how the thermal system performs.
  12. Inspired by you, I have also done some more tests on my site. For me it is also freezing. Since I am on panfrost, we can rule out lima and panfrost for this. The one we have still in common is rockchipdrm. i.MX6 is using imxdrm and is not suffering this flaw, so IMHO the display subsystem is responsible for this error. I don't know how mature the lima GL support in Mesa already is, so IMHO Mesa is to blame here. But we are dealing with 2D acceleration functions of the display subsystem for Xwindow, so these errors are not relevant for our further investigations.
  13. This is only the proprietary kernel part that is already implemented in mainline via /dev/dri/renderD128. The missing functionality is how the binary bloob uses it, which must be implemented via the as yet non-existent armsoc submodule. glamor has it already but using it via modesetting is sub optimal because of KMS/drm implementation design decisions there.
  14. Exactly, they were done on the same device. The buffer pass around forces the 3D GPU IP to slow down because the required buffers are not available by time. The performance hit for the display output isn't reflected by the log but by visual inspection it makes huge difference. In both cases, the 3D rendering power is sufficient to allow a flowing 60Hz display. The DRM scan-out buffer is handed to the Mali proprietary OpenGL ES libraries and they do the buffer dance in the bloob via the Mali proprietary kernel interface. When 3D rendering is done the buffer is handed back to DRM
  15. To switch back to the old method simply rename extlinux.conf. e.g. mv extlinux.conf extlinux.conf-disabled But I don't know if the old files get still maintained.