Graphical front panel display

bossanova808 · 15 January 2021 01:23

Ah, ok, thanks for the tips. I’m currently at the scoping it out stage, i.e. no hardware yet as such (well I do have a Pi 2 around here somewhere but that is in use as a Pi-Hole IIRC) - so really at this point just working out best options, before I buy. I’ll have a look on the weekend at setting up a demo on my desktop to try it out.

I guess I can use the kodi_panel_demo.py approach (with the right resolution) and size that on screen to the physical size (about 16cm wide) - of the screen, to get a quite good sense of how it will look.

And then can play with the various artwork/text options as well. Personally I’d like to see some clearart type images but I presume once I have the demo working it won’t be too hard to hack in some extra artworks/labels as needed.

Fun! Then, assuming I can get it to a point where I like it all, I can just buy the hardware and sub that in. I’m not worried about touch, it’s not for control, just for info.

Backlighting is an issue as it needs to readable but not distracting, ideally…but if it’s as simple as writing to the sysfs file that sounds very do-able, though, indeed. Ah - this looks like only on/off, not brightness control. Is brightness control possible with any of these I wonder?

The other thing that concerns me, then, I think is the non square pixels - that seems a really odd decision?! I can see distorted artwork being really irritating. Looks like it can be fixed at the framebuffer level in config.txt - but not sure if that would work with pygame or not, it may directly write and bypass that sort of thing, I’d guess?

I don’t think I will use a Pi4 - seems like those things get needlessly hot for this sort of scenario. I am thinking a Pi 3B might be the best combo of performance vs coolness. Absolutely, definitely, don’t want a fan, but do want it to be fairly quick on the responsiveness side of things…

mblovell · 15 January 2021 14:17

I should clarify that pygame only gets used when luma is emulating a display.

The kodi_panel_fb.py and two kodi_panel_ili*.py scripts employ luma.core updating a Linux framebuffer file or luma.lcd driving a SPI-attached display, respectively. Those scripts don’t make use of pygame – or X for that matter.

The non-square pixels are… um, unique! I thought those largely went away with the advent of VGA. If cost is not an obstacle, and you have the room, perhaps you should check out the 7- and 10-inch HDMI-attached IPS displays from WaveShare.

Finally, this page

Raspberry Pi Touch Display,

under Specifications, does state

PWM backlight control and power control over I2C interface

I’m not quite sure what the “over I2C interface” part means, though!

The WaveShare displays usually seem to provide PWM control of the backlight via a GPIO pin, which is perfect for RPi’s hardware PWM. Some rework (e.g., moving a resistor) is common, though. Sometimes WaveShare documents the details on their wiki, but (so far) they have also been quite responsive when I’ve contacted them via email.

nico1080 · 15 January 2021 17:15

I did it last weekend and longest step was to do a fresh unstall of unbuntu on an old desktop computer.
You just have to comment in the import section of kodi_panel_display.py as you will not have gpio from the raspberry pi

#try:
   # import RPi.GPIO as GPIO
#except ImportError:
 #   pass

The only thing is that the fb method don’t work, but emulator run fine (I guess it is because ubuntu have graphical interface loaded

To play with the various artwork/text options you just have to add infolabel in the TOML file and in the Retrieve InfoLabels section that does the music (line 1460)/video (line 1375)/status (line 1340) JSON querry

A list of all available info label can be finded here:
https://kodi.wiki/view/InfoLabels

You can also check the info label result by entering http request in your browser.
Eg for VideoPlayer.Duration info label:
http://192.168.1.111:8080/jsonrpc?request={“jsonrpc”:"2.0”,"method”:“XBMC.GetInfoLabels”,“params”:{“labels”:[“VideoPlayer.Duration”]},“id”:1}

It will show something like
{"id":1,"jsonrpc":"2.0","result":{"VideoPlayer.Duration":"01:29:59"}}

@mblovell, @noggin what OS do you use on your raspberry? I already have a RPI 3B+ in my home theater system that run hyperion (ambilight clone) installed on raspberry OS and I find the boot time too long (arround 30s, longer than my TV, AVR or kodi box)

I tried with two microSD: no significant difference (Transcend 32GB class10 and noname 8GB class8, the noname card seem to be a little faster)

Regarding the display, I found on ebay 5.5 lcd ips module with hdmi interface they look good but are 1440p (2K) any thought on CPU usage with these high definition?

mblovell · 15 January 2021 19:00

As mentioned in the installation discussion from README.rst:

for the Odroid C4, when I was driving a SPI-attached display, CoreELEC 9.2.5; and
for the Rpi Zero W, 3, and 4 that I’ve now tried, the Buster version of Raspberry Pi OS.

I’ve always left Kodi on the Odroid running 24/7. I now do the same with the RPi Zero W that’s driving the display.

Regarding the display, I found on ebay 5.5 lcd ips module with hdmi interface they look good but are 1440p (2K) any thought on CPU usage with these high definition?

No promises, but I think if you’re driving the display with a RPi 3 or 4, it could be fine. For the 800x480 display I’m currently using with the RPi Zero, one can see the artwork getting filled in, but elapsed time updates are then snappy. The linux_framebuffer code within luma.core only updates the framebuffer with changes from the Pillow image.

Even with that, though, using Python to move image data will run out of horsepower for larger displays. I don’t really know where that cut-off exists, though (and it likely varies with personal preference). The cutoff will also differ depending upon the display interconnect. The 480x320 SPI-attached panel I played with via a RPi 4 seemed to update about as quickly as the 800x480 framebuffer / HDMI display driven from the Zero. The SPI interface was the limiting factor, of course.

nico1080 · 15 January 2021 19:37

My idea is to use my raspberry pi 3B+ to run both Hyperion and kodi panel display.
Hyperion use little cpu power so it should be OK.

Anyway I think I will install it on my RPI (hope it will will not interfere with the GPIO) and see how it work. I have an old 6" vga monitor to test small resolution and also a 1440p monitor to see how much CPU power it use

Just had to fine some time to test it

noggin · 16 January 2021 09:39

The official Pi Touchscreen uses an I2C (which is a standard bus used extensively on various Pi hats) interface to control backlight I believe - There’s an I2C bus on the DSI connector from the A+ and B+ onwards (the first gen Model B and A devices don’'t have this so there are headers on the display board to let you attach them to I2C GPIO pins on the 26-pin GPIO header of original versions instead). I2C is a useful - relatively low data rate 2-wire bus, and multiple devices can hang off the same I2C bus, with each device having a unique address. I guess the backlight control is just on a specific I2C address on one of the I2C buses the Pi offers, and you push values to it to change the brightness?

Officially registered Pi HATs all have I2C readable EPROMs on them I believe that allow for the correct Device Tree for the connected HAT to be loaded automatically at boot-up for instance, but lots of simple devices like temperature and humidity sensors, light sensors etc. can be hung from the Pi I2C buses, and a lot of devices use I2C to allow configuration registers on peripherals to be read and written to.

noggin · 16 January 2021 09:45

I’ve used a couple of different displays so far - mainly DPI-connected IPS TFTs from Pimoroni - Hyperpixel square (720x720) which is a nice fit for a Pi 3A+ (using WiFi), or a Hyperpixel 4.0 which is 800x480. Both are really nice displays, but quite small.

I have a couple of Waveshare, Pi-sized, HDMI displays (800x480) - but their quality isn’t as good as the Pimoroni ones (though they have mounting holes which may make them easier to house)

I also have a few SPI 320x240 LCD, and 160x160 OLED tiny displays - which are very nice but a little too small and low-res for this application.

noggin · 16 January 2021 09:47

I’m running Raspberry Pi OS as my main OS and booting to the command line, not to the GUI (which is a raspi-config option). I like Ubuntu, but for Pi stuff I find the Pi OS a bit more ‘standard’ when it comes to Pi stuff.

nico1080 · 16 January 2021 11:04

I installed kodi panel on my raspberry pi along hyperion on Raspberry Pi OS (buster). Everything work fine.

In my case in had to put the kodi_panel.service file in /etc/systemd/system/ and not /etc/systemd/service as suggested in the file (the service folder is not present)

One weird issue though, I still have the output from the console and the blinking cursor, and the silent boot solution does not work every time (I Think I have some issue with my cmdline.txt)

Silent boot on Raspian Stretch in Console Mode
https://scribles.net/silent-boot-on-raspbian-stretch-in-console-mode/ 2

Remove Raspberry Pi logo and blinking cursor
3-1. Open “/boot/cmdline.txt”.

sudo nano /boot/cmdline.txt

3-2. Add below at the end of the line.

logo.nologo vt.global_cursor_default=0

Regarding CPU usage, running kodi panel with an attached 640x480 lcd + hyperion + webmin + RPI-monitor I am around 40% CPU load.

The kodi panel processes is reported at 5-6% CPU load.

Now I will have to test with a high resolution monitor.

mblovell · 16 January 2021 14:36

Adding the argument you point out to end of the command line specified in /boot/cmdline.txt served to turn off the console’s blinking cursor for me on the RPi Zero:

vt.global_cursor_default=0

The full set of additional arguments for passing to the kernel is still just a single line of text; I don’t know if it can become multi-line or if there’s any comment support. Here’s my complete cmdline.txt file:

console=serial0,115200 console=tty1 root=PARTUUID=b0373d09-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait vt.global_cursor_default=0

The elevator option is likely not needed; it’s a remnant from a previous experiment.

The console for the RPi Zero is visible during boot, up to the point where the PWM module gets loaded. I figured it would be good to leave on, in case there’s some early problem during power-on.

I’ll update the installation notes to point out that the systemd service files may reside in different locations, depending upon OS.

nico1080 · 16 January 2021 16:14

It did the trick my cmdline.txt contained several lines. Thank for the hint

Il also worked on PVR detection, the following code will detect recorded TV, live TV, tv show (library) and movies

# if enabled via settings.
if VIDEO_LAYOUT_AUTOSELECT:
    if info["Player.Filenameandpath"].startswith("pvr://recordings"):
        layout = VIDEO_LAYOUT["V_PVR"]     # PVR TV shows
    elif info["Player.Filenameandpath"].startswith("pvr://channels"):
        layout = VIDEO_LAYOUT["V_LIVETV"]     # live TV
    elif info["VideoPlayer.TVShowTitle"] != '':
        layout = VIDEO_LAYOUT["V_TV_SHOW"] # Library TV shows
    elif info["VideoPlayer.OriginalTitle"] != '':
        layout = VIDEO_LAYOUT["V_movie"] # movie
    else:
        pass  # leave as-is, assumed good for other type (file, addon, musicvideo, etc)

Of course corresponding video layout have to be defined and needed infolabel to be retrieved.

I also made a specific progress bar calculation for PVR to eliminate the start and stop offset of the PVR (my PVR start/stop the recording 10min before/after the actual program schedule)

def calc_progress_pvr(time_str, duration_str):
if (time_str == “” or duration_str == “”):
return -1
if not (1 <= time_str.count(“:”) <= 2 and
1 <= duration_str.count(“:”) <= 2):
return -1

cur_secs   = sum(int(x) * 60 ** i for i, x in enumerate(reversed(time_str.split(':')))) - 600 #remove pvr start offset
total_secs = sum(int(x) * 60 ** i for i, x in enumerate(reversed(duration_str.split(':')))) -1200 #remove pvr start and stop offsets
if (total_secs > 0 and cur_secs > 0 and cur_secs <= total_secs): #recording finished, show progress bar
    return cur_secs/total_secs
if (cur_secs < 0 or total_secs < 0 ): #recording just started, hide progress bar
    return -1
if (cur_secs >= total_secs): #recording ongoing show full progress bar (100%)
    return 1
else:
    return -1

And you have to specify when you want to use it:

    try:
        video_info = response['result']

        # See remarks in audio_screens() regarding calc_progress()
        if video_info["Player.Filenameandpath"].startswith("pvr://recordings"):
                    prog = calc_progress_pvr(video_info["VideoPlayer.Time"], video_info["VideoPlayer.Duration"])
        else:
                   prog = calc_progress(video_info["VideoPlayer.Time"], video_info["VideoPlayer.Duration"])

mblovell · 16 January 2021 17:21

You and @noggin are the only ones thus far to try out the auto-selection. If there’s agreement that Player.Filenameandpath, then TVShowTitle, then OriginalTitle is a good heuristic to use, I can update to that. I’ll likely also modify how the checking occurs to ensure that the desired VIDEO_LAYOUT entry exists.

I’ve been thinking of a modification to permit additional InfoLabel requests to be specified in the setup.toml file, with one array for audio and one array for video. There would be a set of “core” InfoLabels that are always fetched, with the setup able to specify additions. That should permit for less editing of kodi_panel_display.py itself.

I think the main added functionality of calc_progress_pvr() is

the check for negative values of cur_secs and total_secs
capping the return value at 1, should cur_secs > total_secs

Is that summary correct? If so, seems like those changes could just be folded into the existing calc_progress() function. Again, I don’t have any TV or PVR functionality locally, so I have no means of testing these aspects.

If anyone is feeling adventurous, remember that you can create a fork of the project on github and submit pull requests for code changes.

Thanks!
Matt

nico1080 · 16 January 2021 19:46

@mblovell, For auto-selection heuristic, it should work with all version of kodi and not be dependent of the PVR backend. Lets wait for @noggin feedback
Video addon detection should also work with path start with addonxxxxxx and musicvideo detection with VideoPlayer.Artist but I do not use it so I can’t check it.

With this heuristic, one could end up with many layout that are not needed, one solution could be to add a table in the setup.toml file that specify which layout to use.

Eg in my case:

PVR--> pvr layout (but some users could want a TV layout used for PVR and live TV)
live TV--> live tv layout (but some users could want a TV layout used for PVR and live TV)
TVshows--> tv show layout
movie--> movie layout (but some users could want a "other" layout)
addon--> default layout (I don't plan to use it)
music video--> default layout (I don't plan to use it)
other -->default layout

Of course all the used layout would have to be checked to make sure they exists

Also it could be interesting to have fields that apply to multiple layout (eg: my elapsed time will be in the same position for many of my videos layout) it will avoid having multiple field that are almost identical.

For the calc_progress_pvr() the added functionality is to correct the progress value according to pvr offset.
PVR offset is used as program could be early/late so recording need to be longer

My PVR gave a 10minutes (600sec) offset at the begening/ending of each recording. so I removed 600s to cur_secs and 1200s to total_secs.

Example; when I recorde a 10min program, my recording will be 30 min long (10min offset at the beginning and 10min at the end)
With the standard progress bar the progress value will be 33% at the beginning of my program and 67% at the end.
With the calc_progress_pvr() progress bar will begin a 0% and finish at 100% of the program (if program schedule is respected)

Idealy the setup.toml should have a section to define PVR start offset and PVR end offset

The heuristic on negative value and cur_secs > total_secs is for when I start watching a recording before program or recording is finished. (Eg, I start watching 5min after my program is started, and the recording is ongoing)

In that case it is not possible to calculate actual progress as total duration is unknown (I did not find info label that give this info) but we just get some value to indicate if we are near the beginning of the recording (0% progress bar) or the end (100% progress bar)

I am not sure this heuristic cover all the possible cases but most of them should be covered.
Others users will probably have different opinion of what to do in that case.

mblovell · 16 January 2021 20:15

I just posted kodi_panel v1.18 to github. Please read the release notes, which I’ll copy below for convenience.

@nico1080, I didn’t notice at first the subtractions that you were performing in your PVR-modified calc_progress(). Those PVR offsets would indeed be best as user-specified values.

Let me know if any of you want to be listed in the contributors file.

v1.18 Release Notes

Take caution if upgrading an existing installation in-place!

Added STATUS_LABELS, AUDIO_LABELS, and VIDEO_LABELS lists at the start of kodi_panel_display.py. Each list can be augmented using setup.toml using a similarly-named array. This change permits new InfoLabels to be retrieved (and used in screen layouts) without directly modifying the script.

If you have modified the JSON-RPC calls made in update_display(), consider making use of the new lists in setup.toml instead. A large comment block was added to each example explaining the new feature.

Modifications were also made to the heuristic used for video mode auto-selection. Entries within the VIDEO_LAYOUT dictionary are checked [just] prior to using the auto-selection, so users don’t have to populate all of the various layout selections. As of this writing, the heuristic used is one suggested by @nico1080 on CoreELEC forums:

Playing a pvr://recordings file, use V_PVR layout (if that layout exists)
Playing a pvr://channels file, use V_LIVETV layout
VideoPlayer.TVShowTitle is non-empty, use V_TV_SHOW layout
VideoPlayer.OriginalTitle is non-empty, use V_MOVIE layout

If one falls-through the above heuristic, than the default layout just gets used.

Minor changes to the checks in calc_progress() were also made. These changes, however, still do not attempt to account for PVR recording offsets.

mblovell · 16 January 2021 20:26

While I don’t disagree that the above would be nice, there’s a limit to what is possible using TOML as the “language” for the configuration file.

If one was still using native Python for the setup, then re-use of entries would be pretty straightforward. I’ll ponder whether the fixup_layouts() function could figure something out, but repeating info in the TOML file doesn’t seem too burdensome for the moment.

Cheers,
Matt

bossanova808 · 17 January 2021 01:42

I haven’t had a chance to get into this this weekend (too many kid things to tend to before school starts again!) - but I did find myself idly thinking…

I have a bunch of retired Android tablets. Nothing fancy (a Nexus 7 2013, and two Samsung things and a Lenovo whatever)…all of those have 7" screens or thereabouts. If one could root & install linux on any of those, that would be another option for this sort of thing, I suppose?

In the end, one needs a working linux install and python, right, plus access to the framebuffer?

nico1080 · 17 January 2021 11:07

@bossanova808 Great idea I am currently looking into abordable LCD display and I am not fully convinced by chinese cheap module.

After I quick look it seem easy to install linux distro on android device.
https://github.com/meefik/linuxdeploy

Kodi panel should work on that, You only have to remove reference to raspberry pi GPIO . (I did it to test kodi panel on a desktop computer).

However I dont know how a tablet will behave regarding powering up/down as it have internal battery.

On my home theater I have a master/slave power socket that power up/down my raspberry pi/ hyperion system when I start/stop my home theater. (actually it is just a 5v relay module connected to the usb port of my TV)

There is some risk of SD card corruption as the raspberry is not properly shut down (it just cut the power without any warning) But I have been using it over a year without any issue.

I have in mind to add an hdmi-monitor powered by the same master/slave socket

mblovell · 17 January 2021 18:03

I’ll ponder whether the fixup_layouts() function could figure something out…

@nico1080, I think I have an idea that could work. The fixup_array() function is responsible for processing the array (list) of text fields within each layout. Right now, as it encounters each dictionary within the array (i.e., each textfield that is listed), it just recurses back to fixup_layouts(). I could check the name key within the dictionary before taking that step, though.

The name could then reference an entry in some separate dictionary.

Making this more concrete, one could define a list of shared fields within setup.toml as below. The fields are “shared” in the sense that multiple layouts could make use of them. Let’s suppose that all layouts want to display the elapsed time and album name in the exact same location:

[shared_fields.elapsed_time]
name = "MusicPlayer.Time"
posx = 420
posy = 29
font = "font7S"
fill = "color_7S"
dynamic = 1

[shared_fields.audio_album]
name  = "MusicPlayer.Album"
posx  = 420
posy  = 280
font  = "font_sm"
fill  = "white"
wrap  = 1
max_width = 375
max_lines = 3

The shared_fields table / dictionary would have to be declared in setup.toml prior to layouts that make use of them.

In a particular layouts, one would then indicate a shared field via the name. The examples below make use of both shared fields in the A_DEFAULT and A_OTHER layouts. Only the name has to be specified, triggering the “fixup” I just described.

[[A_LAYOUT.A_DEFAULT.fields]]
name = "shared_fields.elapsed_time"

[[A_LAYOUT.A_DEFAULT.fields]]
name = "shared_fields.audio_album"

...

[[A_LAYOUT.A_OTHER.fields]]
name = "shared_fields.elapsed_time"

[[A_LAYOUT.A_OTHER.fields]]
name = "shared_field.audio_album"

I think this accomplishes the desired sharing.

The new functionality would only apply to text fields. I would need to think a bit more how to handle “top-level” dictionary elements like the progress bar and artwork. (The key name for those elements is special, since it triggers specific code.)

Matt

mblovell · 17 January 2021 23:53

I’ve posted kodi_panel v1.20 to github. It provides the ability to share screen elements across different layouts, defining all the relevant details once. Note that the syntax I settled on is slightly different than my post above.

kodi_panel v1.20

Add ability to share screen elements (with details identical) across different screen layouts. See the large “Shared Elements” comment block added to any of the example setup TOML files.

Such sharing is entirely optional. All existing setup.toml files should continue to work as-is.

Thanks to @nico1080 for the suggestion.

bossanova808 · 18 January 2021 00:20

For power I’d probably just go USB power as these are old tablets, no idea how the batteries in them would work at this point - and the power usage is very low I’m sure, so I wouldn’t mind it staying on permanently - as long as I can find a way to turn the display on an off via python…

I am thinking/hoping that something like

subprocess.run(["xset", "-display", ":0.0", "dpms", "force", "off"])

to turn off when Kodi is not running / reachable, and then the reverse to fire it back up when it is…

But of course there may well be limits on what linux-on-android can do. There are some other options, like Ubuntu Touch on the Nexus 7 - that would probably offer more control etc.