We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3986

Summary: Auto-detection to build KMSDRM on Raspberry Pi Rasbpian Stretch does not work
Product: SDL Reporter: Eric wing <ewmailing>
Component: buildAssignee: Ryan C. Gordon <icculus>
Status: ASSIGNED --- QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: connogriofa
Version: 2.0.7   
Hardware: ARM   
OS: Other   
Attachments: patch of pi kmsdrm build fix

Description Eric wing 2017-11-30 21:55:11 UTC 
The KMSDRM backend will not be compiled in on a typical Raspberry Pi Raspbian Stretch system trying to use the Broadcom drivers.

The problem is that the script is trying to use pkg-config to get the flags for the EGL library, but two assumptions are broken on the Pi.

1. The Broadcom libraries are now prefixed with 'brcm'. That means we have libbrcmegl instead of libegl.

2a. The pkg-config script is also named differently. It is brcmegl instead of egl.

2b. Raspbian puts these scripts in /opt/vc/lib/pkgconfig. But this is not in the default pkg-config path, so you must explicitly add it. It is recommended you add this to the build system directly.

I have a patch for the CMake side which I will post a link to after this (so I can commit this bug number to the commit log).

I've only looked at the CMake script, not the Autotools script.


My testing presumes the user has actually activated the GL KMS driver in raspi-config.
My suspicion is that any other testing that has not caught this problem on Raspbian Stretch is due to developers installing Mesa or other alternative EGL libraries. I do not know if those interact with the brcm drivers and if you get the hardware acceleration. But an advantage of using the brcm ones (and this fix) is I beleive  all these things should already be installed by default on a Raspbian Stretch system and do not require the user to install more things.
Comment 1 Eric wing 2017-11-30 21:59:44 UTC 
I published a repo with the fix at https://bitbucket.org/ewing/sdlpikmsbuildfix
Comment 2 Sam Lantinga 2017-12-01 02:56:47 UTC 
Can you attach a patch to this bug?

Thanks!
Comment 3 Eric wing 2017-12-03 23:16:58 UTC 
Created attachment 3107 [details]
patch of pi kmsdrm build fix

Here's the patch
Comment 4 Sam Lantinga 2017-12-04 00:18:48 UTC 
Thanks, can you attach a tested patch for configure.in as well?
Comment 5 Eric wing 2017-12-04 00:38:02 UTC 
(In reply to Sam Lantinga from comment #4)
> Thanks, can you attach a tested patch for configure.in as well?

Sorry, I really don't know my way around configure scripts. Is there anybody we can grab who is more knowledgable?
Comment 6 Sam Lantinga 2017-12-04 04:19:45 UTC 
I'm familiar with autoconf, but I don't have a raspberry pi setup.

Ryan, you want to look at this one?
Comment 7 Conn O'Griofa 2018-01-30 01:53:08 UTC 
Eric,

Are you testing against 2.0.7 or the latest master? If the former, you should ensure that you're testing with these patches that were merged post-2.0.7: https://bugzilla.libsdl.org/show_bug.cgi?id=3938

With the above patches, it's possible to compile a build with --enable-video-rpi and --enable-video-kmsdrm together, and everything works as expected depending on the active kernel overlay.

It wasn't necessary to modify the cmake file as you propose here, and I didn't encounter any dependency or build errors. Are you certain this is not going to break either the rpi or kmsdrm driver when targeting a build that includes both drivers?
Comment 8 Eric wing 2018-02-07 19:05:40 UTC 
(In reply to Conn O'Griofa from comment #7)
> Eric,
> 
> Are you testing against 2.0.7 or the latest master? If the former, you
> should ensure that you're testing with these patches that were merged
> post-2.0.7: https://bugzilla.libsdl.org/show_bug.cgi?id=3938
> 
> With the above patches, it's possible to compile a build with
> --enable-video-rpi and --enable-video-kmsdrm together, and everything works
> as expected depending on the active kernel overlay.
> 
> It wasn't necessary to modify the cmake file as you propose here, and I
> didn't encounter any dependency or build errors. Are you certain this is not
> going to break either the rpi or kmsdrm driver when targeting a build that
> includes both drivers?

This was tested against the latest master at the time I submitted the patch. 
The switches you describe don't apply to CMake as far as I understand as CMake doesn't use switches like that. I did not submit any changes to the Autotools system, though I suspect it needs similar changes. 

I believe the effect of this patch is to indeed get the KMSDRM backend compiled with the Pi drivers. The problem is that the Broadcom Pi drivers were relocated and renamed which is what this patch fixed.