nokirunner

I don't know, I tend not to trust these measures, my soc also measured 80 - 90 degrees, with no particular operation except a desktop started. yet when I touched the heatsink it seemed quite warm. Could it be that they are not degrees celsius?

@fabiobassa Yes I understand the hint, cheaper devices, cheaper support etc .. but what I don't understand, their modules being based on the linux kernel anyway, why don't they have a native release of the drivers sources? They don't violate the Linux kernel GPL license ?? I noticed this also happens on other arm phones, due to their blob drivers, which then remain abandoned to old kernels which are difficult to update.. I also noticed that this happened more frequently in the past years .. now they tend to release drivers sources more easily to have them natively included in the linux kernel main line, maybe they have realized that it is more convenient for general maintenance, and to stay up to date with kernels with security and more.

Hey @jock, hey @fabiobassa, what's up? just from time to time come to this topic to see how is evolving all, never mind that I find some nice surprises and I miss them. Actually to be honest, I cut short and betrayed the case with a 4 gb rasberry-pi 4 which for my jobs with the diy CNC that I built myself, and with the 3d printer with octoprint, is optimal, I admit that it is also convenient for browsing and since the videos on youtube run in full hd without problems, and now that they have developed the Vulkan 3D drivers it's even better .. i noticed the big difference between armbian and raspberry pi os where the whole community is concentrated to make the software run better on those few existing hardware versions and I must say that in my opinion it is a good technique ... having all the same hardware it is easier to find bugs, to be fixed and there is a greater e solid stability between hardware and software. While armbian focuses on trying to get the same os to work on the most varied arm-based hardware in existence, and it's a nice challenge that doesn't always succeed. However, I admit that I enjoyed chatting on this channel, seeing the progress, and in a sense there is a small niche that has focused on these specific devices, which are actually a big deal, too bad the hardware and drivers creators are a bit stupid (or conveniently stupid for some obscure reason), they didn't directly decide to release good openosource drivers and made everything more complicated, the community would take care to keep them working well .. Already, I just wanted to comment with my opinions based on the accumulated experience, and now I come here mostly for hobbies and fun, I would like to have more skills to make some contribution greater than just as a beta tester, or one who goes to try the luck in making things work, well I'd like to, but unfortunately it's not in my ability.

well, the period of despair has passed, now I'm ready to throw myself back into the fray to experiment, I'm curious how firefox behaves, I'm writing this comment while the image is written on the sdcard .. ..then no LIMA, no 3D, or can we recover the 3D acceleration from the old owners drivers? ... I suspect no, no 3d at all. funny, that by blacklisting LIMA, you get a bit of decent 2D, it is very clear then, that the 3D drivers are going to use something wrong ... despite having noticed that LIMA's 3D worked .., when I come to the end to understand something I will be very happy.

maybe, but anyway I gave up, I tried for a couple of days to "try my luck by experimenting", but I couldn't get much, the level of skills needed are well beyond my abilities

guys, I had an idea, if we can roughly identify in a technical way the problem that this rk322x rockchip driver have whether it is the dri rockchip kernel or mesa LIMA, we could open a bugreport on the LIMA mesa git issues or on the dri (lima) kernel issues or both, maybe we are lucky and they already know how to fix it.

well, lately I got excited with the mainline kernel for more reasons, I thought that with a bit of cunning and a few tricks I would be able to fit both accelerations by force ... well it's obvious that it's not as simple as I thought .. I did this also because I see the 4.4 kernel as a dead end, we might as well concentrate the forces with the new ones, also because many improvements are still in sight, both on the gpu side and in other functions in general. (hoping these problems with the rk322x socs will be solved)

this is where the big players start playing and everything becomes so dark that I can only catch small shreds of light. but I try to ask a question: why when we force "modesetting" on card1 we have 2D acceleration but the 3D acceleration disappears? or rather, it is channeled to the cpu through softrender llvmpipe ... wouldn't it be the easiest way to try change the code by telling it to use the 3d acceleration libraries in these conditions? do you think it is possible to do such a thing?

@Gabriel Vinicius did you then do a test with the ir and this new image? it works??

Yes, but obviously something goes wrong with glamoregl, because not only is there no 2d acceleration, but everything becomes so slow that it is almost not usable. In my opinion it is as if channels some registers that should use hardware of any kind for the correct use, but here something is not going well, which worsens the situation even compared to a context without acceleration at all. That's what I wanted to highlight. all obviously refers to my hardware based on soc rk322x exsperience.

with this configuration I get a decent "2d acceleration" on card0 there is no trace of glamoregl, and there is no trace of 3d acceleration, in fact MESA tells me that it is in softrender on cpu via llvmpipe I also did a test putting modesetting in place of fbdev and glamoregl immediately comes back, 3d acceleration is activated on MALI, but there is a terribly slow 2D. At this point I give up. it is evident there is something broken somewhere. I would be curious to know if the same thing happens on other rk322x Major sister socs or is it just a problem of these rk322x socs

Xorg driver as "rockchip" Xorg.0_driver_as_rockchip.log Xorg driver as "modesetting" Xorg.0_driver_as_modesetting.log my mistake, I don't know where I saw "2020" ,perhaps searching and scrolling through this chronology I got confused with the latest HDMI commit https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/rockchip what is the command to see the devices tree like the one you attached?

I tried this on my rk232x based device and i suspect it doesn't work. If I put "modesetting" as driver then it recognizes rockchip and vdpau-rockchip, but with the method described by you I don't get the same result, it tells me that the driver rockchip is not found and starts the same through modesetting ... I suspect that for the rk322x it does not work ... and I also suspect that it is for this reason that glamoregl even if it seems to start does not work as 2d acceleration ... this driver dri is not optimized at all (or partially brocken) for rk322x at least the 5.6 kernel, maybe the latest versions like the upcoming kernel 5.9 already contain these fixes. edit : in fact there seems to be no trace of rk3228 registers. https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/rockchip/rockchip_vop_reg.h (Visual Output Processor) is the Display Controller for the Rockchip series of SoCs which transfers the image data from a video memory buffer to an external LCD interface look only other rockchip socs : edit2: better investingating maybe 14 june 2020 is added a basic hdmi support for rk3228 ... (is valid also for rk3229 ?) https://github.com/torvalds/linux/commit/53ffa1ee8de2cdfb0fcbef798486ba9c7f9316fd#diff-0f18fb301f41340ce62f8d1b44e1247e evidenced code here:

@jockMine are obviously just guesses of reasoning, based on the information I gathered, but I couldn't test . You will probably be right, being much more grounded and experienced. Only for fun I like to test things to verify, maybe you never know, with a bit of (culo) some miracle happens. I checked the drm kernel folder, there is only the module LIMA, why is not the there rockchip module also? one thing is certain and makes me suspect that something has gone wrong, something is wrong with the monitor recognition, only one resolution comes out, and the refresh management marks "zero" (showing that it is broken), perhaps, and it's just a guess, this module is not compiled.

@jockwell, thanks for the explanations. the fact is that there is certainly something badly designed right now. we hope for notable improvements in the future. i managed to compile and install the latest mesa with the latest LIMA driver updates, but nothing has changed. the last test I would like to do is to install the dri module for the kernel with the latest patches, but I would not want to recompile the whole kernel, but only the module I need, I wonder if I can do it while using an older kernel. ... this: https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/lima but also this, which I understand is the display driver, and takes care of interfacing with the hdmi manages the resolutions of the monitors and so on .. (which apparently, according to the LIMA documentation, must be started with xorg together with LIMA, but reading you and how you configured xorg, it seems to me that you have totally ignored the existence of this other "display driver" and that must be "mixed" with the LIMA driver) https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/rockchip according to the LIMA documentation, the two drivers must be combined in this way: (pay particular attention to that MatchDriver "display DRM driver" ... which must be replaced with "rockchip" or other drivers according to the various brands of the various socs) Section "ServerFlags" Option "AutoAddGPU" "off" Option "Debug" "dmabuf_capable" EndSection Section "OutputClass" Identifier "Lima" MatchDriver "<display DRM driver>" Driver "modesetting" Option "PrimaryGPU" "true" EndSection