2018-03-09, 18:43
Why even bother with clock throttling on RPi? The power savings are negligible (if any) but the "sliding" Estuary GUI is way more smooth when using "force_turbo=1"
(2018-03-09, 18:05)popcornmix Wrote: @J_E_F_F and this is which playing hevc? Is it keeping up okay?ok, I am seeing this, thanks for the explanation. I reinstalled 0305 and see it pegged at 1200/400 not overclocked and 1200/500 overclocked.
There is a change in behaviour over previous firmware.
Previously we just had the concept of "turbo mode" or "idle mode".
When the arm was busy (one core > 50% busy) we would enter turbo mode.
When the gpu was busy (e.g. with HEVC acceleration) we would enter turbo mode.
Turbo mode would boost the arm and gpu clocks to maximum (subject to temperature throttling).
Since the rewrite things are more fine grained. We can have just the gpu boosted if that is all that is required.
So, my guess is the HEVC file isn't loading the arm heavily, but is using the GPU.
So we boost the GPU clocks but leave the arm at the lower frequency (as it doesn't need the higher one).
The side effect is the reporting of the arm cpu percentage is relative to the arm clock rate.
Previously you were seeing ~40% CPU from a 1200MHz arm clock.
Now you are seeing ~80% CPU from a 600MHz arm clock.
The new behaviour is actually better from a power/temperature point of view, so if we are keeping up fine then there isn't a problem.
If we are dropping frames, then we could make the HEVC decode also boost the arm frequency.
Playing a harder file may trigger the arm to run at 1200MHz which will show a lower cpu percentage.
Also running with force_turbo=1 will show a lower cpu percentage (as you'll be fixed at 1200MHz).
(2018-03-08, 06:53)doug Wrote:@doug try stoping kodi first [code]systemctl stop kodi[/code[(2018-03-07, 10:34)lrusak Wrote: I need to get you guys to tell me what key isn't mapped. You have to do this via command line in an ssh session.
I only use long press with Enter. Here's the results. I noticed I needed an extra "-" in libinput-list-devices and libinput-debug-events
Code:Kodi-theatre:~ # libinput-list-devices
Device: flirc.tv flirc
Kernel: /dev/input/event0
Group: 1
Seat: seat0, default
Capabilities: keyboard
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: n/a
Nat.scrolling: n/a
Middle emulation: n/a
Calibration: n/a
Scroll methods: none
Click methods: none
Disable-w-typing: n/a
Accel profiles: n/a
Rotation: n/a
For the next step, I didn't see any results even though I was pressing buttons. Odd.
Code:Kodi-theatre:~ # libinput-debug-events --device /dev/input/event0
-event0 DEVICE_ADDED flirc.tv flirc seat0 default group1 cap:k
Tried evtest and got this:
Code:This device is grabbed by another process.
No events are available to evtest while the
other grab is active.
In most cases, this is caused by an X driver,
try VT-switching and re-run evtest again.
Run the following command to see processes with
an open fd on this device
"fuser -v /dev/input/event0"
(2018-03-09, 19:36)J_E_F_F Wrote: Looks like we have progressed to where overclocking isn't needed for hevc content which is nice, but would still be nice if it worked. I don't want to use force turbo.
(2018-03-09, 17:00)MidKnight Wrote: Using a logitech elite remote, the long press on the enter key used to bring up the context menu, but at some point past,
LibreELEC-RPi2.arm-9.0-Milhouse-20180218010737-#0217-gc2fd843
till the lastest release i just tried, it no longer working, but insteads just fires enter cmd untill button released.
how can i change this back?
thanks
(2018-03-09, 18:01)polo_joe Wrote: Latest build 0308 again works for me.
(2018-03-09, 20:52)J_E_F_F Wrote: OK, with bothSo, gpu_freq=500 is equivalent to:
over_voltage=2
gpu_freq=500
It played for a minute or so, and as soon as I skipped forward, it crashed. This also accepted a reboot command but was hung and required the plug to be pulled before it would reboot.