2019-06-27, 20:41
First of all, I do NOT expect anyone to offer to fix this, since it really can't be fixed on the Kodi side. Rather, I'd like to share knowledge that I've obtained in investigating a failure.
For the last several days, I've been trying to get Kodi running on a 96boards Rock960, which has an rk3399 SoC and is running on Android 9. This board is very closely related to another board called RockPi 4, so everything here applies to that board as well, among probably others as well.
The symptom I was seeing (yes, WAS), is EGL_BAD_ACCESS, immediately upon launching the application. There are more details to the crash, but given how things panned out, it isn't important to go into detail on that aspect.
Fairly quickly, I discovered that some Kodi forks were working on it (that is, they started up, loaded the UI, and appear to be entirely functional). In particular, SPMC (both 16 and 17), as well as another fork, which is unmentionable due to its content. I only used it to see if it would actually start, and it did.
So I bisected SPMC17 until I found the commit that "fixed" it. It turned out to be nothing more than a re-branding commit.
https://github.com/koying/SPMC/commit/74...911d696005
After grepping through the entire AOSP tree and all the binaries used to run the board, I found the string "org.xbmc.kodi" in the binary only Mali EGL driver version r18p0.
I'll take the approach of Hanlon's razer and assume that they were trying to do something useful, and broke it by accident, rather than implementing this to intentionally cripple it.
And I don't know if the responsible party is ARM or Rockchip.
The point is that it can be made to work with nothing more than a change to the package name to anything but "org.xbmc.kodi".
I find it somewhat disturbing to find that they've put some kind of a hack into the binary driver referring specifically to something they don't own. One would expect that a more appropriate way to implement a hack like this would be on a system property or config file, or in the very least, by communicating with the entity who owns the subject software.
Anybody have any idea what can be done besides rebuilding with a different package name? Is that a fair use of the kodi trademark, or something the lawyers should be thrown at?
And for what its worth, it looks like Rockchip has the video decode acceleration implemented correctly now. 10 bit 1080p HEVC is decoded in hardware now, sans rockchip hacks.
For the last several days, I've been trying to get Kodi running on a 96boards Rock960, which has an rk3399 SoC and is running on Android 9. This board is very closely related to another board called RockPi 4, so everything here applies to that board as well, among probably others as well.
The symptom I was seeing (yes, WAS), is EGL_BAD_ACCESS, immediately upon launching the application. There are more details to the crash, but given how things panned out, it isn't important to go into detail on that aspect.
Fairly quickly, I discovered that some Kodi forks were working on it (that is, they started up, loaded the UI, and appear to be entirely functional). In particular, SPMC (both 16 and 17), as well as another fork, which is unmentionable due to its content. I only used it to see if it would actually start, and it did.
So I bisected SPMC17 until I found the commit that "fixed" it. It turned out to be nothing more than a re-branding commit.
https://github.com/koying/SPMC/commit/74...911d696005
After grepping through the entire AOSP tree and all the binaries used to run the board, I found the string "org.xbmc.kodi" in the binary only Mali EGL driver version r18p0.
I'll take the approach of Hanlon's razer and assume that they were trying to do something useful, and broke it by accident, rather than implementing this to intentionally cripple it.
And I don't know if the responsible party is ARM or Rockchip.
The point is that it can be made to work with nothing more than a change to the package name to anything but "org.xbmc.kodi".
I find it somewhat disturbing to find that they've put some kind of a hack into the binary driver referring specifically to something they don't own. One would expect that a more appropriate way to implement a hack like this would be on a system property or config file, or in the very least, by communicating with the entity who owns the subject software.
Anybody have any idea what can be done besides rebuilding with a different package name? Is that a fair use of the kodi trademark, or something the lawyers should be thrown at?
And for what its worth, it looks like Rockchip has the video decode acceleration implemented correctly now. 10 bit 1080p HEVC is decoded in hardware now, sans rockchip hacks.
