GBM Video Driver - Retro Gaming - Tinkering Image Howto

[Tomas J.]

I built it today...

[AreaScout]

I built it today...

Hi Tomas J.

I have a workaround for you, I can't say at the moment how I get it working because I use a hardly modified kernel AND different FFmpeg version

Ok to workaround that problem please create a file in /home/odroid and name it clearcache.sh

put that contain inside the file:

Code: Select all

#!/bin/bash
echo 3 > /proc/sys/vm/drop_caches

save the file and make it execute able

Code: Select all

sudo chmod 755 clearcache.sh

logon as root and execute that file via crontab

Code: Select all

su root
crontab -e

an editor opens, inside the editor add that line to execute the file every 5min:

*/5 * * * * /home/odroid/clearcache.sh

save and exit the editor

now your XU4 will not run out of memory

I will pinpoint the problem and will inform you when I know exactly what has to be done to solve the problem

RG

[Tomas J.]

Doesn't help. Clearcache script runs, bet memory usage by kodi still grows...

[AreaScout]

Doesn't help. Clearcache script runs, bet memory usage by kodi still grows...

nope, it works and yes kodi ist still growing, but every 5min it will free memory and kodi will NOT run out of memory

su root
free
echo 3 > /proc/sys/vm/drop_caches
free

you will notice that you will have a lot more free memory after typing the command

before: 83872

odroid@odroid:~$ free
total used free shared buff/cache available
Mem: 2042436 258712 83872 6260 1699852 1720928
Swap: 0 0 0

after: 1716776

odroid@odroid:~$ free
total used free shared buff/cache available
Mem: 2042436 225416 1716776 6260 100244 1753568
Swap: 0 0 0

[AreaScout]

@all

I have changed the Kodi patch from the tutorial to apply to latest revision on github

[Tomas J.]

No, it doesn't for me... (screenshot after about 10 min video play)
Memory frees only after quiting kodi.

[AreaScout]

Try to just watch a movie, I am sure Kodi will not stop after 30min

I am using internal FFmpeg now and original kernel with drm plane patch and the workaround does it's job

2018-11-11.png (62.84 KiB) Viewed 5187 times

[Tomas J.]

I did wait with cron script running - maybe not after 30, but 40 minutes kodi ran out of memory - movie stopped.
Just rebuilt kodi with your new patch - nothing new - after 15 min playback 50% memory used... (no cron script running).
BTW, I guess from your screenshot, that you will run out of memory too.

[AreaScout]

BTW, I guess from your screenshot, that you will run out of memory too.

Just watching a movie it runs 40min now but it seems you are right, very slowly it runs out of memory not so fast like before but it runs out, it could be that I can watch the movie to the end, will have to take a closer look on it, could be the kernel, libdrm (I had vanilla installed) or FFmpeg (I used the external FFmpeg)

RG

[odroid]

there are 2 drivers:

1. gscaler v4l2m2m driver, which exists and you can use (e.g. very simple to use with gstreamer)
2. gscaler drm driver, which can be accessed by a exynos specific API (kernel 4.18 onwards). if you select this one in kernel options, it will disable the v4l2m2m driver.

I haven't done much with it, I only looked at the kernel log (4.14) and could see that a rotator driver is loaded, the corresponding file seems to be drivers/gpu/drm/exynos/exynos_drm_rotator.c .

I have observed also something interesting, in Kernel 4.19 there was an commit who enabled NV12 for the Display Port https://github.com/torvalds/linux/commi ... ca15ef14b9 , if this is the driver that is used for XU3 Display Port then it could be that DRMPRIME with Kodi works out of the box now with it, I hope it is. 4.18 is not so far away from 4.19 could that be worth a try ?

@odroid

Maybe that DRM driver for the Display Port can then be used to connect the MIPI DSI device, that driver (if it's working with the XU3 DP) could be used ? it also does rotation very easily

edit: The Exynos 5422 does not contain a Mali Display Core so this was a wrong assumption, information found on internet was confusing -> bad, that driver would be easier to use

We have a plan to port 4.19 LTS kernel to XU4 /HC1/HC2 platforms early next year. So it is not easy to tell you how it works at this moment.
BTW, we will send you the MIPI-LCD test board tomorrow.

[Tomas J.]

Is there any hope, that someone will look at issue with kodi or nobody interested...

[AreaScout]

Is there any hope, that someone will look at issue with kodi or nobody interested...

Hello Tomas

It's not just Kodi, it happens also with FFplay and it's just this configuration/combination ( 4.14 Ubuntu 18.04 minimal GBM MFC DRM/KMS ), it does not happen with Ubuntu 18.04 X11 Desktop Image, there are lot's of changes in DRM code when looking to upstream kernel and odroid said that the 4.19 kernel will officially ported to our Exynos SoC boards, so no, this will not be addressed, the problem is with just this kernel version and just with everything which uses MFC+DRM, so you have to wait until early next year sorry for that, but anyone is busy with different things it seems and that tutorial was always meant to be for tinkering, so if you can't solve it for yourself you must have to wait.

RG

[Tomas J.]

I'm still using Kodi 16.1 - so I'm kind of used to wait...But refresh rate change with working vsync would be nice...

[AreaScout]

I'm still using Kodi 16.1 - so I'm kind of used to wait...But refresh rate change with working vsync would be nice...

I have just found a solution it seems, I have to test this a little bit more, but it looks like it works, will keep you informed

[AreaScout]

Ok I would be nice if someone could confirm/test this also, I have tested it with Kodi RC2 and current FFmpeg 4.0.3-Leia-Beta5 (internal Kodi FFmpeg version)

I hope it's not a works just on my setup thingy

Please apply this patch https://github.com/lrusak/FFmpeg/commit ... 8c4c1220c2

Compare it carefully, it has to be exactly like this, file can be found here xbmc/kodi/build/ffmpeg/src/ffmpeg/libavcodec/v4l2_m2m_dec.c

After applying the changes, the quickest way without rebuilding everything is just to delete three files ffmpeg-build, ffmpeg-install and ffmpeg-done

They can be found and they have to be deleted in two folders

xbmc/kodi/build/ffmpeg/src/ffmpeg-stamp

and

xbmc/kodi/build/ffmpeg/src/ffmpeg-build/ffmpeg-prefix/src/ffmpeg-stamp

then go back to xbmc/kodi

and usually do a:

Code: Select all

make -j7
sudo make install 

You can easily check memory while watching a video if you enable debug in Settings -> Event log -> Settings -> Enable Debug Logging

RG

[Tomas J.]

Just tried with latest Kodi RC3 - still no change...

[AreaScout]

Just tried with latest Kodi RC3 - still no change...

How did you check it ? If you just look on the value 'available' which counts for this measurement you can see that it's pretty stable, it will not go under 1.7GB no matter if I watch a full HD 1080p movie
Without that patch the value of 'available' decreases until the board crashes

Yesterday I was watching a 2 hour 1080p movie ~270MB memory usage at start ~270MB at end, measured with htop

When you start a movie memory usage will increase the first 10-20 seconds and then settle down, if it just does not work for you I am clueless at the moment hmmm

What else I have different ? ... I use an uInitrd which includes the firmware files, what file dates are your s5p-mfc firmware files ?

RG

[MastaG]

Great work AreaScout!
Too bad I don't have my Xu4 connected, but I'm hoping to test in the following days.

[Tomas J.]

With top, free, playback until stopped....( from kodi log - started 21:42, stream stalled 22:15) Can you check with kodi RC3 or guide how to rollback to RC2 (git checkout ???) With kodi RC1 (I think - downloaded 2018 11 11) patched v4l2_m2m_dec.c does'n build.
If you mean kernel source - linux/drivers/media/platform/s5p-mfc then date is 2018 11 11.

[AreaScout]

With top, free, playback until stopped....( from kodi log - started 21:42, stream stalled 22:15) Can you check with kodi RC3 or guide how to rollback to RC2 (git checkout ???) With kodi RC1 (I think - downloaded 2018 11 11) patched v4l2_m2m_dec.c does'n build.
If you mean kernel source - linux/drivers/media/platform/s5p-mfc then date is 2018 11 11.

No I mean the s5p-mfc* file date in /lib/firmware directory on your odroid

Here is the complete file how it looks in my source tree https://pastebin.com/zFxYBdF1 interesting part is line number 150 - 165, I use Kodi from 3.December "Merge pull request #14978 from MartijnKaijser/v18.0rc3" and it works there

Please compare it with your v4l2_m2m_dec.c, it should work I think

[Tomas J.]

Date is 2017 11 17. v4l2_m2m_dec.c is different, tomorrow i will try with yours.

[AreaScout]

Date is 2017 11 17. v4l2_m2m_dec.c is different, tomorrow i will try with yours.

Ok we use the same firmware, in uInitrd I have a newer one I think, but try my source file first before we go further

And don't forget to compare only the 'available' memory, because there is also page cache memory which is filled up completely but is an OS thingy and is not reserved, so when this is full, software can still get memory from there

Good luck !

[Tomas J.]

After building with your v4l2_m2m_dec.c I have (had...) working kodi - no memory leak, even watched a movie... But, I start thinking, what i done wrong in first place. File from
lrusak commit has av_packet_unref lines to, so why it does'n work? I rebuilt kodi with lrusak 4l2_m2m_dec.c - still working. Then deleted kodi dir content and build again - still working... Remembered one thing - when first building kodi with replaced v4l2_m2m_dec.c I run make install with old kodi still running (forgot, that I put kodi into rc.local..) - maybe first time install failed... The I deleted xbmc dir and started from beginning... At last I got kodi unworking And after replacing v4l2_m2m_dec.c and installing with old kodi running - not working. Ok, I quit kodi, rebuilt and install - still not working. Done the same with your v4l2_m2m_dec.c - still the same memory leak. Damn, I had it working and now don't know, what to do again... Tried to rollback few days kodi source - git checkout 1de0d40, built, replaced with your v4l2_m2m_dec.c, installed - still nothing. Will try couple things in next few days...

[AreaScout]

After building with your v4l2_m2m_dec.c I have (had...) working kodi - no memory leak, even watched a movie... But, I start thinking, what i done wrong in first place. File from
lrusak commit has av_packet_unref lines to, so why it does'n work? I rebuilt kodi with lrusak 4l2_m2m_dec.c - still working. Then deleted kodi dir content and build again - still working... Remembered one thing - when first building kodi with replaced v4l2_m2m_dec.c I run make install with old kodi still running (forgot, that I put kodi into rc.local..) - maybe first time install failed... The I deleted xbmc dir and started from beginning... At last I got kodi unworking And after replacing v4l2_m2m_dec.c and installing with old kodi running - not working. Ok, I quit kodi, rebuilt and install - still not working. Done the same with your v4l2_m2m_dec.c - still the same memory leak. Damn, I had it working and now don't know, what to do again... Tried to rollback few days kodi source - git checkout 1de0d40, built, replaced with your v4l2_m2m_dec.c, installed - still nothing. Will try couple things in next few days...

try a ldd /usr/local/lib/kodi/kodi.bin there should be no libavcodec.so or what so ever FFmpeg library listed when you run this command to see if you really use the internal FFmpeg, it could be that cmake detected an external FFmpeg version and therefore again has that memory leak

[MastaG]

Yes, Kodi can also be a bit picky about external ffmpeg, since it requires a recent version.

@AreaScout and/or @memeka
I'm running Fedora 29 on my XU4 instead of Ubuntu, so I'm building ffmpeg from upstream git.
https://github.com/FFmpeg/FFmpeg.git

I'm now building with AreaScout's memleak fix: https://github.com/lrusak/FFmpeg/commit ... 8c4c1220c2
But I don't want to miss out on other patches/fixes which benefit the MFC on the XU3/4.
I don't want to sound lazy, but would it be possible to point me to those patches? (I believe there was one to control the quality or bitrate when encoding?)

[AreaScout]

I'm now building with AreaScout's memleak fix: https://github.com/lrusak/FFmpeg/commit ... 8c4c1220c2
But I don't want to miss out on other patches/fixes which benefit the MFC on the XU3/4.
I don't want to sound lazy, but would it be possible to point me to those patches? (I believe there was one to control the quality or bitrate when encoding?)

I don't know who did that commit exactly Lukas or memeka ? I am not, I just found out that it's missing in internal FFmpeg from Kodi which I normally prefer.

The most interesting FFmpeg tree is v4l2-drmprime-v4 from Lukas (https://github.com/lrusak/FFmpeg/tree/v4l2-drmprime-v4) which is currently on review for mainline, it has several improvements and is able now to fall back to SW pixel format which we can then use to HW decode it for non drmprime use, but it's untested from my side, too busy with other things and some Christmas stress is also already noticeable.

RG

[Tomas J.]

That was a challenge... No , no external ffmpeg installed, no libavcodec linked in kodi, and kodi log shows ffmpeg 4.0.3-kodi used.
I noticed, that after replacing v4l2_m2m_dec.c file and rebuilding kodi.bin size stays the same, md5sum also the same...And no errors on rebuild. Next I tried with lrusac, AreaScout, original v4l2_m2m_dec.c - for some reason ,that maybe someone else can understand, kodi.bin doesn't change on rebuild. Next I pasted only av_packet_unref lines into original v4l2_m2m_dec.c file and voilà - kodi builds with different cheksum and even works without leaking memory So, what I did wrong in first place, was to replace all v4l2_m2m_dec.c file instead of just few lines...

[AreaScout]

That was a challenge... No , no external ffmpeg installed, no libavcodec linked in kodi, and kodi log shows ffmpeg 4.0.3-kodi used.
I noticed, that after replacing v4l2_m2m_dec.c file and rebuilding kodi.bin size stays the same, md5sum also the same...And no errors on rebuild. Next I tried with lrusac, AreaScout, original v4l2_m2m_dec.c - for some reason ,that maybe someone else can understand, kodi.bin doesn't change on rebuild. Next I pasted only av_packet_unref lines into original v4l2_m2m_dec.c file and voilà - kodi builds with different cheksum and even works without leaking memory So, what I did wrong in first place, was to replace all v4l2_m2m_dec.c file instead of just few lines...

Maybe you didn't build Kodi in a separate folder the second time ? Whatever ... you solved it ! congrats That GBM Backend works really nice on our XU4 boards, it's totally relaxing for the eyes/brain to have the movie exactly vsync !

RG

[AreaScout]

@all

I have just edit the Kodi tutorial/guide with an memory leak patch, to make building easier

viewtopic.php?f=98&t=32173&p=235249#p235249

RG

[odroid]

Thank you for the nice patch!

[MastaG]

@AreaScout, that patch for the memleak has been in upstream git since the 26th of june..
https://github.com/FFmpeg/FFmpeg/commit ... a4ce321515

[AreaScout]

@AreaScout, that patch for the memleak has been in upstream git since the 26th of june..
https://github.com/FFmpeg/FFmpeg/commit ... a4ce321515

Yes we all know now, that was the reason I didn't believe it when Tomas told me, because I was testing with different kernel and Lukas FFmpeg (v4l2-drmprime not v4) all the time, I only had the configuration from the tutorial very shortly, first I thought it is a bug in MFC or DRM part of the kernel, then at the very last I was remembering the unref commit, then I compared and saw that this is missing in internal Kodi FFmpeg !

But I would say it's a happy end

RG

[memeka]

@everyone - you can just use my/odroid's ffmpeg, and compile kodi with exernal ffmpeg.
last time i checked there was no patch necessary for kodi, you might want to check the minimal version of ffmpeg required by kodi, and patch kodi by changing the required ffmpeg version, this way you can use same ffmpeg for more that just kodi

[AreaScout]

@everyone - you can just use my/odroid's ffmpeg, and compile kodi with exernal ffmpeg.
last time i checked there was no patch necessary for kodi, you might want to check the minimal version of ffmpeg required by kodi, and patch kodi by changing the required ffmpeg version, this way you can use same ffmpeg for more that just kodi

Yep that's right, you would just have to change the path to FFmpeg in that file https://github.com/xbmc/xbmc/blob/maste ... EG-VERSION to declare what fork/version has to be taken

memeka FFmpeg, HK FFmpeg (which is in fakt is the one from memeka) and upstream FFmpeg since end of June can be taken, you could be bad of luck with FFmpeg from official distributions

I for myself prefer the internal FFmpeg version of Kodi, because it's still be the best tested one and it's linked static inside the Kodi binary and does not collide with any other FFmpeg version installed on the system

RG

[MastaG]

@everyone - you can just use my/odroid's ffmpeg, and compile kodi with exernal ffmpeg.
last time i checked there was no patch necessary for kodi, you might want to check the minimal version of ffmpeg required by kodi, and patch kodi by changing the required ffmpeg version, this way you can use same ffmpeg for more that just kodi

I'm building ffmpeg from upstream git with two of your patches applied:

Code: Select all

diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 710e40efd8..c2ac3f85f2 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -201,7 +201,7 @@ static av_cold int v4l2_decode_init(AVCodecContext *avctx)
 static const AVOption options[] = {
     V4L_M2M_DEFAULT_OPTS,
     { "num_capture_buffers", "Number of buffers in the capture context",
-        OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 20}, 20, INT_MAX, FLAGS },
+        OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 16}, 8, INT_MAX, FLAGS },
     { NULL},
 };
 
diff --git a/libavcodec/v4l2_m2m_enc.c b/libavcodec/v4l2_m2m_enc.c
index 636e1a96dd..eae994aa52 100644
--- a/libavcodec/v4l2_m2m_enc.c
+++ b/libavcodec/v4l2_m2m_enc.c
@@ -175,8 +175,13 @@ static int v4l2_prepare_encoder(V4L2m2mContext *s)
 
     /* set ext ctrls */
     v4l2_set_ext_ctrl(s, MPEG_CID(HEADER_MODE), MPEG_VIDEO(HEADER_MODE_SEPARATE), "header mode");
+        /* enable bit rate control */
+    if (avctx->bit_rate > 1) {
+        v4l2_set_ext_ctrl(s, MPEG_CID(FRAME_RC_ENABLE) , 1, "rate control");
+        av_log(avctx, AV_LOG_INFO, "h264_v4l2m2m encoder: enabling bit rate control: %llu\n", avctx->bit_rate);
+    }
     v4l2_set_ext_ctrl(s, MPEG_CID(BITRATE) , avctx->bit_rate, "bit rate");
-    v4l2_set_ext_ctrl(s, MPEG_CID(GOP_SIZE), avctx->gop_size,"gop size");
+    v4l2_set_ext_ctrl(s, MPEG_CID(GOP_SIZE), avctx->gop_size, "gop size");
 
     av_log(avctx, AV_LOG_DEBUG,
         "Encoder Context: id (%d), profile (%d), frame rate(%d/%d), number b-frames (%d), "
@@ -318,7 +323,7 @@ static av_cold int v4l2_encode_init(AVCodecContext *avctx)
 static const AVOption options[] = {
     V4L_M2M_DEFAULT_OPTS,
     { "num_capture_buffers", "Number of buffers in the capture context",
-        OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 4 }, 4, INT_MAX, FLAGS },
+        OFFSET(num_capture_buffers), AV_OPT_TYPE_INT, {.i64 = 8 }, 4, INT_MAX, FLAGS },
     { NULL },
 };

I believe these are for setting the correct buffers and bitrate control.
I'm not going to try out the drmprime stuff yet until it has been merged upstream (and proven stable).

[AreaScout]

@everyone - you can just use my/odroid's ffmpeg, and compile kodi with exernal ffmpeg.

Be careful memeka your FFmpeg is probably not build with the same options like internal Kodi FFmpeg and one maybe would not get the same experience Kodi and FFmpeg is tested for. But for tinkering it's for sure ok

@all

Another thing is if you have multible FFmpeg versions installed (self compiled one's) be aware that the include files are not compatible across multible versions, each version does have it's own headers, compiling Kodi with external FFmpeg and having different headers in /usr/include and /usr/local/inlcude could lead that on compile time the wrong version is included and therefore Kodi would have EXTREMELY strange behavior or segfault it would leave the binary in an inconsistent state.
I have all seen this, just a reminder !

RG

[MastaG]

Well after watching several movies using the official Plex addon for Kodi, I can confirm that there aren't any memory leaks.
This is on Fedora 28 with both Kodi and FFmpeg built from the master git branch.
Only difference is that I'm not using the bigmali.tar driver from HK but the wayland/kms/drm driver from the ARM site (so I can run Gnome 3.30 as well)

What does suck.. is that reicast on retroarch using either drm or wayland isn't fullspeed like the standalone version of reicast :/
But the standalone version of reicast only supports X11... so no Sonic Adventure for me on drm/wayland I guess

[AreaScout]

Well after watching several movies using the official Plex addon for Kodi, I can confirm that there aren't any memory leaks.
This is on Fedora 28 with both Kodi and FFmpeg built from the master git branch.
Only difference is that I'm not using the bigmali.tar driver from HK but the wayland/kms/drm driver from the ARM site (so I can run Gnome 3.30 as well)

What does suck.. is that reicast on retroarch using either drm or wayland isn't fullspeed like the standalone version of reicast :/
But the standalone version of reicast only supports X11... so no Sonic Adventure for me on drm/wayland I guess

Ah ! Thank you for confirming, Kodi with kms/drm driver brought me a lot of joy

I don't know 'Sonic Adventure' on reicast libretro but others play fine especially Naomi and they have a lot of improvements compared to the stand alone version, I really like it

@all

I have also some Kernel and Kodi deb packages for OpenMediaVault, I use it on my CloudShell2 to store my movies there near my TV and if I plug the HDMI cable in, Kodi starts and closes when I disconnect it If someone want's to test this, I will post it here or maybe I make an Howto about it, let me know

RG

[AreaScout]

@all

I have added setup instruction for CEC if it doesn't work for you !

[memeka]

quick question - what's the total CPU usage when using kodi to play 1080p videos?

[AreaScout]

Hello memeka

It is 50-60% fluctuating with some peaks going higher

I also have a question, yesterday I installed libwidevine to watch with Netflix and Amazon plugin on Kodi, it works but the performance is not that good because it's all software decoded, do you know a way to use this library to only manage the DRM part of the video and let FFmpeg HW decode the picture ?

RG

[MastaG]

@AreaScout, the same here.. after copying the arm version of libwidevinecdm.so it works.. but only software decoding :/

[rooted]

There is no hardware decoding through libwidevine unless you're using Android, not on any device running Linux AFAIK.

It works on my Android TV which has level 1 widevine, I guess this is why.

[MastaG]

@AreaScout, two question:
1. Regarding the patched libcec, shouldn't we enable support for exynos as well?
e.g: cmake -DHAVE_LINUX_API=1 -DHAVE_EXYNOS_API=1 ..

2. Regarding your kodi patch for using both drm planes.
Is it possible to do the switching inside the source code of kodi instead?
That way we don't have to patch the kernel..

[AreaScout]

There is no hardware decoding through libwidevine unless you're using Android, not on any device running Linux AFAIK.

It works on my Android TV which has level 1 widevine, I guess this is why.

yes I know that it works on this devices, although I have read about a special chromium browser which also can stream Netflix video content on Linux arm, that's why I was asking

@AreaScout, two question:
1. Regarding the patched libcec, shouldn't we enable support for exynos as well?
e.g: cmake -DHAVE_LINUX_API=1 -DHAVE_EXYNOS_API=1 ..

2. Regarding your kodi patch for using both drm planes.
Is it possible to do the switching inside the source code of kodi instead?
That way we don't have to patch the kernel..

1. That Exynos API is stone old and want's to make use of the /dev/CEC device which is simply not there on kernel 4.14 (it's /dev/cec0 with the new API), that older API will work on Kernel 3.10 OGST Images a.s.o
2. To be precise, Kodi can also draw everything on one plane and the drm plane patch is not needed, but it works better with two, it's by design and it's how the future path goes which is DRMPRIME and on 4k devices this means drawing GUI in 1080p while playing video plane in 4k, the DRM mixer will bring all planes together and does HW scaling the GUI plane to 4k which saves a lot of GPU work instead of rendering 4k textures in GPU


btw. what are your experience with libcec, if I start playing a movie, cec disconnects, in GUI everything is working, maybe we have to much CEC configure sections enabled in Kernel now ? anyone to confirm or test this ?

[AreaScout]

Well that was not 100% right, because Kodi will most likely not use 4k textures for GUI, but then consider it only for tinkering and experimenting with other kernels and DRMPRIME aka (Direct to Plane)

[MastaG]

Well I'm trying to understand what both the kernel and kodi patch are trying to accomplish.
I don't want to patch the kernel since I'm running Gnome on wayland.. but I wan't to keep the possibility to disable the desktop (gdm) and run kodi drm directly using two planes.

So we have the kernel:

Code: Select all

static const struct exynos_drm_plane_config plane_configs[MIXER_WIN_NR] = {
        {
                .zpos = 0,
                .type = DRM_PLANE_TYPE_PRIMARY,
                .pixel_formats = mixer_formats,
                .num_pixel_formats = ARRAY_SIZE(mixer_formats),
                .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE |
                                EXYNOS_DRM_PLANE_CAP_ZPOS,
        }, {
                .zpos = 1,
                .type = DRM_PLANE_TYPE_CURSOR,
                .pixel_formats = mixer_formats,
                .num_pixel_formats = ARRAY_SIZE(mixer_formats),
                .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE |
                                EXYNOS_DRM_PLANE_CAP_ZPOS,
        }, {
                .zpos = 2,
                .type = DRM_PLANE_TYPE_OVERLAY,
                .pixel_formats = vp_formats,
                .num_pixel_formats = ARRAY_SIZE(vp_formats),
                .capabilities = EXYNOS_DRM_PLANE_CAP_SCALE |
                                EXYNOS_DRM_PLANE_CAP_ZPOS |
                                EXYNOS_DRM_PLANE_CAP_TILE,
        },
};

static const uint32_t mixer_formats[] = {
        DRM_FORMAT_XRGB4444,
        DRM_FORMAT_ARGB4444,
        DRM_FORMAT_XRGB1555,
        DRM_FORMAT_ARGB1555,
        DRM_FORMAT_RGB565,
        DRM_FORMAT_XRGB8888,
        DRM_FORMAT_ARGB8888,
};

static const uint32_t vp_formats[] = {
        DRM_FORMAT_NV12,
        DRM_FORMAT_NV21,
};

and we have kodi:

Code: Select all

        if ((strcmp(p->name, "type") == 0) && (props->prop_values[j] != DRM_PLANE_TYPE_CURSOR))
        {
          switch (type)
          {
            case KODI_VIDEO_PLANE:
            {
              if (SupportsFormat(plane, DRM_FORMAT_NV12))
              {
                CLog::Log(LOGDEBUG, "CDRMUtils::%s - found video plane %u", __FUNCTION__, plane->plane_id);
                drmModeFreeProperty(p);
                drmModeFreeObjectProperties(props);
                return plane;
              }

              break;
            }
            case KODI_GUI_PLANE:
            {
              uint32_t plane_id = 0;
              if (m_video_plane->plane)
                plane_id = m_video_plane->plane->plane_id;

              if (plane->plane_id != plane_id &&
                  (plane_id == 0 || SupportsFormat(plane, DRM_FORMAT_ARGB8888)) &&
                  SupportsFormat(plane, DRM_FORMAT_XRGB8888))
              {
                CLog::Log(LOGDEBUG, "CDRMUtils::%s - found gui plane %u", __FUNCTION__, plane->plane_id);
                drmModeFreeProperty(p);
                drmModeFreeObjectProperties(props);
                return plane;
              }

              break;
            }
            case KODI_GUI_10_PLANE:
              uint32_t plane_id = 0;
              if (m_video_plane->plane)
                plane_id = m_video_plane->plane->plane_id;

              if (plane->plane_id != plane_id &&
                  (plane_id == 0 || SupportsFormat(plane, DRM_FORMAT_ARGB2101010)) &&
                  SupportsFormat(plane, DRM_FORMAT_XRGB2101010))
              {
                CLog::Log(LOGDEBUG, "CDRMUtils::%s - found gui 10 plane %u", __FUNCTION__, plane->plane_id);
                drmModeFreeProperty(p);
                drmModeFreeObjectProperties(props);
                return plane;
              }

              break;
            }
          }

So basically you're telling the kernel the second plane will be: DRM_PLANE_TYPE_OVERLAY instead of DRM_PLANE_TYPE_CURSOR, because it supports DRM_FORMAT_XRGB8888 in mixer_formats?
Or because kodi only looks at that specific type?
Couldn't you just tell Kodi to use the second plane, regardless of the type?

EDIT:
Perhaps by modifying Kodi and tell it to not skip the CURSOR plane?
In: xbmc/windowing/gbm/DRMUtils.cpp
if ((strcmp(p->name, "type") == 0) && (props->prop_values[j] != DRM_PLANE_TYPE_CURSOR))

[AreaScout]

Perhaps by modifying Kodi and tell it to not skip the CURSOR plane?
In: xbmc/windowing/gbm/DRMUtils.cpp
if ((strcmp(p->name, "type") == 0) && (props->prop_values[j] != DRM_PLANE_TYPE_CURSOR))

Yes you can do that, but you also have to change not to only support DRM_FORMAT_NV12, because that is disabled in the kernel I have found that with the kernel patch it has the best stability, drawing only on one plane did e.g segfault on debian

[MastaG]

Perhaps by modifying Kodi and tell it to not skip the CURSOR plane?
In: xbmc/windowing/gbm/DRMUtils.cpp
if ((strcmp(p->name, "type") == 0) && (props->prop_values[j] != DRM_PLANE_TYPE_CURSOR))

Yes you can do that, but you also have to change not to only support DRM_FORMAT_NV12, because that is disabled in the kernel I have found that with the kernel patch it has the best stability, drawing only on one plane did e.g segfault on debian

Well for me on Fedora 29 it works great using one plane only.. at least from my limited testing using the official Plex addon, no segfaults occurred.
Also I'm impressed with the Kodi performance running on DRM only.. the GUI is silky smooth.. much better compared to my old Minix Neo X8 running LibreElec.

I'm now going to test out using two planes, but without patching the kernel.
Something like this:

Code: Select all

index df46ad4bdc..5a4bf58306 100644
--- a/xbmc/windowing/gbm/DRMUtils.cpp
+++ b/xbmc/windowing/gbm/DRMUtils.cpp
@@ -346,13 +346,13 @@ drmModePlanePtr CDRMUtils::FindPlane(drmModePlaneResPtr resources, int crtc_inde
       {
         drmModePropertyPtr p = drmModeGetProperty(m_fd, props->props[j]);
 
-        if ((strcmp(p->name, "type") == 0) && (props->prop_values[j] != DRM_PLANE_TYPE_CURSOR))
+        if (strcmp(p->name, "type") == 0)
         {
           switch (type)
           {
             case KODI_VIDEO_PLANE:
             {
-              if (SupportsFormat(plane, DRM_FORMAT_NV12))
+              if (SupportsFormat(plane, DRM_FORMAT_NV12) || SupportsFormat(plane, DRM_FORMAT_XRGB8888))
               {
                 CLog::Log(LOGDEBUG, "CDRMUtils::%s - found video plane %u", __FUNCTION__, plane->plane_id);
                 drmModeFreeProperty(p);
@@ -529,7 +529,7 @@ bool CDRMUtils::OpenDrm(bool needConnector)
 
   for (auto module : modules)
   {
-    m_fd.attach(drmOpenWithType(module, nullptr, DRM_NODE_PRIMARY));
+    m_fd.attach(open("/dev/dri/card0", O_RDWR | O_CLOEXEC));
     if (m_fd)
     {
       if(!GetResources())
@@ -556,7 +556,7 @@ bool CDRMUtils::OpenDrm(bool needConnector)
 
       CLog::Log(LOGDEBUG, "CDRMUtils::%s - opened device: %s using module: %s", __FUNCTION__, drmGetDeviceNameFromFd2(m_fd), module);
 
-      m_renderFd.attach(drmOpenWithType(module, nullptr, DRM_NODE_RENDER));
+      m_renderFd.attach(open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC));
       if (m_renderFd)
       {
         CLog::Log(LOGDEBUG, "CDRMUtils::%s - opened render node: %s using module: %s", __FUNCTION__, drmGetDeviceNameFromFd2(m_renderFd), module);

At least it doesn't crash (yet), but I'll have to go home and check the results.

[AreaScout]

Well for me on Fedora 29 it works great using one plane only.. at least from my limited testing using the official Plex addon, no segfaults occurred.
Also I'm impressed with the Kodi performance running on DRM only.. the GUI is silky smooth.. much better compared to my old Minix Neo X8 running LibreElec.

I'm now going to test out using two planes, but without patching the kernel.
Something like this:

At least it doesn't crash (yet), but I'll have to go home and check the results.

I have tested this combination also, I have tested a looot, but every time I ended up with the plane swap patch although I didn't test on Fedora but also with OpenMediaVault and Armbian Kernel which is pretty unique, but if you find a combination which is working and stable for you without patching the kernel, I would say go for it, that's how this tutorial was meant to be -> tinkering