LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 03-09-2018, 02:36 AM   #31
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 721

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401

I don't know yet if my suggestions from the previous post resolved your "looks kind of washed out" issue regarding the Desktop and Kodi, but I'd like to update this thread with some info about the color depth on the Raspberry Pi boards.

Some years ago, by the time I started using the Raspberry Pi boards, the 16bit color depth (high color ~ 65k) was the default/recommended value and the 24bit color depth (true color ~ 16 million) was broken due to some firmware issues. Using the 32bit color depth was not recommended because of the higher memory usage and the performance impact. A more recent thread where the 32bit color depth is not encouraged by the Raspberry Foundation:
https://www.raspberrypi.org/forums/v...c.php?t=108033
16 bit color depth looks indeed washed out and the 24bit (~ 16 million) is a little over the biological color perception limit of the eyes, which is a little over 10 million. Pushing the 32bit color depth doesn't really make sense for watching media content, 24 bit should suffice.

Meanwhile I got used with the limited 16bit color depth and forgot to check if the 24bit color depth is fixed or still broken. Now that stormtracknole reported his poor image quality, I just considered to check it again and I was successful in enabling this 24bit color depth on a Raspberry Pi Zero, running Slackware ARM 14.2, with the official Raspberry Pi kernel 4.4.50+ (and the firmware that comes with it) and only allocating 128MB for the GPU. I haven't noticed any apparent performance impact and I'm able to play full HD streams even at 50fps without frame drops and not using more than 75% of the GPU RAM.

- these are the /boot/config.txt options I'm using now for Kodi 17.4 on the Pi0:
Code:
gpu_mem=128
framebuffer_depth=24
#disabled the ignore_alpha option as it is only needed for the 32bit color depth
#framebuffer_ignore_alpha=1
 
1 members found this post helpful.
Old 03-09-2018, 07:35 AM   #32
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,076

Rep: Reputation: 153Reputation: 153
Yes, I was able to figure out shortly after I made my post. I figured that it had something to do with config.txt. Since this is a raspberry pi 3, I went ahead with using framebuffer_depth=32 and framebuffer_ignore_alpha=1 with no issues. I figure that framebuffer_depth=24 should be at least the default setting. Felt like it was Windows 95 for a while there.
 
1 members found this post helpful.
Old 03-10-2018, 05:09 AM   #33
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 721

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
There is a FAQ page on Kodi dedicated solely for the Raspberry Pi boards, that was updated recently and contains a lot of very useful information. Since I cannot edit my original guide anymore, I'll use this post to update the thread:
https://kodi.wiki/view/Raspberry_Pi_FAQ

I found these recommended GPU Memory setting really important:
https://kodi.wiki/view/Raspberry_Pi_...ith_256M_Pi.29
"320M on a Pi2 may be appropriate if using higher resolution imageres/fanartres and also higher colour."

To check the health/load/memory usage (including GPU) on the Raspberry Pi boards while running Kodi (general usage too), the following script is very useful:
https://github.com/MilhouseVH/bcmstat
Code:
wget https://raw.githubusercontent.com/MilhouseVH/bcmstat/master/bcmstat.sh
chmod +x bcmstat.sh
./bcmstat.sh A
In order to protect the SDCard from some intensive storage operations Kodi is doing, I'd suggest to create a RAM filesystem and use it to store the files Kodi is hammering the Card with. I don't know where Kodi is storing the artwork/fanart, since I'm not using this feature, but I've noticed that the database files in .kodi/userdata/Database are really busy. I took them from there and archived them, leaving only a symlink to the Database folder pointing to a tmpfs drive /attic , where I unpack them on system boot - rc.local and archive them back and store on system down/restart - rc.6
Here's my fstab related entry - just for inspiration:
Code:
tmpfs            /attic        tmpfs       nodev,nosuid,noatime,nodiratime,size=100M 0 0
 
Old 08-28-2018, 11:21 AM   #34
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,076

Rep: Reputation: 153Reputation: 153
abga,

I've been meaning to post this for a while, wanted to pass along that I was able to get tinyxml to build. There is a slight change in the SBo that needs to be made. I'm using the SlackBuild from slackbuilds.org.

Here's the portion of the code in question:
Code:
if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX="64"
else
  SLKCFLAGS="-O2"
  LIBDIRSUFFIX=""
fi
Because it's arm, it will default to the last option which does not include -fPIC in the SLKCFLAGS section. I modified mine to look like this:

Code:
if [ "$ARCH" = "i486" ]; then
  SLKCFLAGS="-O2 -march=i486 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "i686" ]; then
  SLKCFLAGS="-O2 -march=i686 -mtune=i686"
  LIBDIRSUFFIX=""
elif [ "$ARCH" = "x86_64" ]; then
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX="64"
else
  SLKCFLAGS="-O2 -fPIC"
  LIBDIRSUFFIX=""
fi
That made the code happy and tinyxml compiled without issues.
 
1 members found this post helpful.
Old 08-28-2018, 02:48 PM   #35
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 721

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
Thanks for the update stormtracknole!

You're right, the compilation fails on Slackware ARM -current without -fPIC and I guess it's because of the new gcc-8.2.0.
Code:
/usr/bin/ld: tinyxml.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxmlerror.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxmlparser.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxml.o(.text+0x198): unresolvable R_ARM_CALL relocation against symbol `fwrite@@GLIBC_2.4'
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
It still works on Slackware ARM 14.2 stable gcc-5.5.0 with or without -fPIC, however, it's safer to always modify the SlackBuild and add the -fPIC as you suggested.

I cannot edit my post #9 anymore, sorry.
 
1 members found this post helpful.
Old 08-28-2018, 05:54 PM   #36
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,076

Rep: Reputation: 153Reputation: 153
Quote:
Originally Posted by abga View Post
Thanks for the update stormtracknole!

You're right, the compilation fails on Slackware ARM -current without -fPIC and I guess it's because of the new gcc-8.2.0.
Code:
/usr/bin/ld: tinyxml.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxmlerror.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxmlparser.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: tinyxml.o(.text+0x198): unresolvable R_ARM_CALL relocation against symbol `fwrite@@GLIBC_2.4'
/usr/bin/ld: final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
It still works on Slackware ARM 14.2 stable gcc-5.5.0 with or without -fPIC, however, it's safer to always modify the SlackBuild and add the -fPIC as you suggested.

I cannot edit my post #9 anymore, sorry.
Yes, this was on -current but good to know that it works fine on 14.2. Also wrote a SlackBuild based on your suggestions for the hardware accelerated version of ffmpeg and kodi too. Makes creating a package easier.
 
Old 08-28-2018, 06:41 PM   #37
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 721

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
Quote:
Originally Posted by stormtracknole View Post
Yes, this was on -current but good to know that it works fine on 14.2. Also wrote a SlackBuild based on your suggestions for the hardware accelerated version of ffmpeg and kodi too. Makes creating a package easier.
I was also considering writing a generic Raspberry-focused SlackBuild for Kodi, but I needed to cover 3 platforms (Pi1/0,Pi2B,Pi3B), the dependencies for these platforms, two Slackware versions (Slackware ARM 14.2 armv6 SF and Slackware ARM -current armv7 HF), the FFMpeg compilation - that should actually be the subject of the Kodi build scripts (had no time to read and understand those quite complex internal Kodi build scripts and why are they failing on Slackware) and then there is an issue with the JDK7 for armv6 (Pi1/0), there's nowhere I could find it online anymore. OpenJDK might work too, never tried it, I just fear that it'll take ages to get it compiled on a Pi1/0.
Covering the different platforms and the dependencies could be achieved with some conditional checking in the script, but it'll get pretty complex and the guide from post #1, together with the updates from this thread, are maybe the more appropriate solution. TBH with you I'm also using the stuff I posted here for my own needs, always knowing where to find what I need when building FFMpeg+Kodi for Raspberry under Slackware ARM
 
Old 08-28-2018, 07:15 PM   #38
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,076

Rep: Reputation: 153Reputation: 153
Quote:
Originally Posted by abga View Post
I was also considering writing a generic Raspberry-focused SlackBuild for Kodi, but I needed to cover 3 platforms (Pi1/0,Pi2B,Pi3B), the dependencies for these platforms, two Slackware versions (Slackware ARM 14.2 armv6 SF and Slackware ARM -current armv7 HF), the FFMpeg compilation - that should actually be the subject of the Kodi build scripts (had no time to read and understand those quite complex internal Kodi build scripts and why are they failing on Slackware) and then there is an issue with the JDK7 for armv6 (Pi1/0), there's nowhere I could find it online anymore. OpenJDK might work too, never tried it, I just fear that it'll take ages to get it compiled on a Pi1/0.
Covering the different platforms and the dependencies could be achieved with some conditional checking in the script, but it'll get pretty complex and the guide from post #1, together with the updates from this thread, are maybe the more appropriate solution. TBH with you I'm also using the stuff I posted here for my own needs, always knowing where to find what I need when building FFMpeg+Kodi for Raspberry under Slackware ARM
I think I would just support -current and rpi3. That IS a lot of work. I don't see why it wouldn't work on rpi2. I wouldn't try to compile software on the other platforms as I don't think they have the horse power for that.
 
Old 08-28-2018, 08:41 PM   #39
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 721

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
Quote:
Originally Posted by stormtracknole View Post
I wouldn't try to compile software on the other platforms as I don't think they have the horse power for that.
Oh, they do! The Pi Zero for instance is a wonderful little toy for Kodi, well, without the fancy artwork that you like so much.
For 5EUR (plus 5EUR the case and 5EUR the Ethernet adapter), that's 15EUR, I have a multimedia system under my desk, providing me with "ambient" music, satellite radio, news, DVB playback (1080p 50Hz) + whatever I imagine as multimedia needs. Security-wise it's isolated from my work network, so I don't mind if anyone is hacking it (Kodi). It has an uptime for some months now and Kodi is always running.
Installing Slackware ARM, compiling FFMpeg + deps + Kodi takes around 4 hours on a Pi Zero.
https://www10.zippyshare.com/v/LH9W58P1/file.html
(the audio+ir is built upon a PATA 40 pin female connector that I just attach to the Pi0 board, the whole system sits on the top of the woofer - a perfect place to put electronics, especially connectors, the high intensity low band vibrations are definitely beneficial - Don't Do It At Home! )

P.S.
And, I don't need a dust sucker under my desk. If they don't consider doing something with the SoC on the upcoming Raspberry Pi 4, maybe using some lower frequency octa-core that doesn't need active cooling, then it's game over for me...
https://www.raspberrypi.org/blog/int...ernet-poe-hat/

Last edited by abga; 08-28-2018 at 08:57 PM. Reason: P.S.
 
Old 08-28-2018, 09:20 PM   #40
stormtracknole
Senior Member
 
Registered: Aug 2005
Distribution: Slackware, RHEL
Posts: 1,076

Rep: Reputation: 153Reputation: 153
Quote:
Originally Posted by abga View Post
Oh, they do! The Pi Zero for instance is a wonderful little toy for Kodi, well, without the fancy artwork that you like so much.
For 5EUR (plus 5EUR the case and 5EUR the Ethernet adapter), that's 15EUR, I have a multimedia system under my desk, providing me with "ambient" music, satellite radio, news, DVB playback (1080p 50Hz) + whatever I imagine as multimedia needs. Security-wise it's isolated from my work network, so I don't mind if anyone is hacking it (Kodi). It has an uptime for some months now and Kodi is always running.
Installing Slackware ARM, compiling FFMpeg + deps + Kodi takes around 4 hours on a Pi Zero.
https://www10.zippyshare.com/v/LH9W58P1/file.html
(the audio+ir is built upon a PATA 40 pin female connector that I just attach to the Pi0 board, the whole system sits on the top of the woofer - a perfect place to put electronics, especially connectors, the high intensity low band vibrations are definitely beneficial - Don't Do It At Home! )

P.S.
And, I don't need a dust sucker under my desk. If they don't consider doing something with the SoC on the upcoming Raspberry Pi 4, maybe using some lower frequency octa-core that doesn't need active cooling, then it's game over for me...
https://www.raspberrypi.org/blog/int...ernet-poe-hat/
Well how about that? I didn't know they were that powerful. I may have to grab one to play around with. I already have like 6 raspberry pi's and one orange pi.
 
Old 08-28-2018, 09:50 PM   #41
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 721

Original Poster
Rep: Reputation: 401Reputation: 401Reputation: 401Reputation: 401Reputation: 401
Have a look here:
https://www.youtube.com/watch?v=Q8GZr2fyUY0
It's showing Kodi 16 on Pi Zero and I can confirm that Kodi 17 is working fine on it too. He has some good points in the video, telling that it's usable if you know what you want and don't play around too much back and forth through the menus. I'm keeping the UI lightweight, no artwork, no fancy visualization add-ons, just the basics/defaults. You'll need the Oracle JDK7 for armv6 SF (the links from post #1 expired) if you want to go through the Kodi compilation&installation and I'll be able to upload it for you if you need it, just let me know.
I did provide some wrong info about the performance of the Pi Zero in my first post and I'm sorry for that, at that time I was not sure if the Pi Zero is powerful enough to play DVB streams in FullHD at 50fps (they're the most demanding) by also outputting analogue audio over the audio schematics that I cloned from the Raspberry Pi3B by using the OMX acceleration/player. It works well, but you'll need to build that sound adapter on your own and connect it to the GPIO (get/reroute the PWM streams from the SoC). Getting the digital audio out on HDMI has no performance impact, it should work with both OMX/MMAL, OMX being way more efficient. It's definitely not powerful enough for playing DVB streams in FullHD at 50fps by using and external USB sound card and the MMAL acceleration, it drops frames and finally freezes.
I'm also not very pleased by the quality/performance of the onboard WiFi adapter that comes with the Raspberry Pi0 W, therefore I opted for the simple Pi0 and bought external USB Ethernet adapters (5-6EUR/USD).

Last edited by abga; 08-28-2018 at 10:34 PM. Reason: typo
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Slackware ARM Raspberry Pi - armv6 and armv7 - optimized FFMPEG with HW Acceleration abga Slackware - ARM 28 08-19-2018 04:45 PM
Raspberry PI 3 + Slackware 14.2 Arm + Kodi tb404 Linux - Software 16 02-05-2017 12:26 AM
Elementary OS on Raspberry Pi3 (arm processors) ?? Marv_Mark elementary OS 3 12-14-2016 07:04 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 04:56 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration