Posts by LuRu

    First of RPi.GPIO is EOL and does not support RPi5 and has problems with recent kernels.

    Yes, I am aware of the EOL situation. But I (and surely many other users) don't have an RPi5 and for the RPi4 the RPi.GPIO library works FOR NOW...
    I just wanted to use the Raspberry Pi Legacy Tools to help myself (and perhaps other similarly affected users) give some time to the final solution.
    But okay, there's another option. It is also a workaround, but probably with a much longer perspective than the previous solution.
    The other option is rpi-lgpio.
    I tried to integrate it into Raspberry Pi Tools and it works!
    I am attaching both the finished add-on and the modified sources.

    I would like to know the reasons why the RPi.GPIO library was dropped from the Raspberry Pi Tools add-on. In my opinion, this is a mistake. I'll explain. I am the author of the OLEDproc plugin. It depends on several libraries, including the luma.oled and luma.core libraries. And therein lies the trouble. The luma.core library needs the RPi.GPIO library to work. I am convinced that it is unthinkable and also pointless for me to create some clone of the luma.core library, which would use, for example, gpiozero instead of RPi.GPIO. So, as it stands, the OLEDproc add-on user could not upgrade their system to LE12, otherwise their OLED display would stop working. It occurred to me that it was possible to go another way. I tried to reincarnate the Raspberry Pi Tools add-on to include the necessary RPi.GPIO library. The result is the "new" add-on Raspberry Pi Legacy Tools.
    And it really works!
    I know there are more similarly affected add-ons (dependent on Raspberry Pi Tools/RPi.GPIO). If their users couldn't upgrade to LE12 because of this, now they can! It is really easy. You only need to do two steps:
    1. Install the Raspberry Pi Legacy Tools add-on
    2. Make a simple edit to the addon.xml file of the dependent addon. As an example, I present an excerpt from the addon.xml file that belongs to the OLEDproc add-on:
    Original version:
     <requires>
       <import addon="xbmc.python" version="3.0.0"/>
       <import addon="script.module.luma" />
       <import addon="script.module.cbor2" />
       <import addon="script.module.smbus2" />
       <import addon="script.module.spidev" />
       <import addon="virtual.rpi-tools" />
     </requires>

    Modified version:
     <requires>
       <import addon="xbmc.python" version="3.0.0"/>
       <import addon="script.module.luma" />
       <import addon="script.module.cbor2" />
       <import addon="script.module.smbus2" />
       <import addon="script.module.spidev" />
       <import addon="virtual.rpi-legacy-tools" />
     </requires>

    I don't exactly understand your question. So I will try to give more detailed instructions for installing the "Orange Pi Cooling Fan" add-on.

    The mentioned add-on cannot work without "Orange Pi Tools" add-on (it's a dependency).

    Proceed as follows:

    1. Unzip the file "Compiled_addon_virtual.opi-tools-003.zip" This contains two files virtual.opi-tools-10.0.0.003.zip. One is for H3 processors, the other is for H6 processors. Choose the one you need.

    2. In Kodi, go to the Add-ons menu - Install from zip file (you may have to allow installation from unknown sources) and select the file "virtual.opi-tools-10.0.0.003.zip". The "Orange Pi Tools" add-on will be installed.

    3. Go to the Add-ons - Install from zip file menu again and select the "service.fan.orangepi-0.0.2.zip" file. The "Orange Pi Cooling Fan" add-on will be installed.

    4. It's almost done. The "Orange Pi Cooling Fan" add-on must of course be set up. It is simple. Go to the menu Add-ons - My add-ons - Services - Orange Pi Cooling Fan - Configure.

    May be I don't execute this command and take file virtual.opi-tools-10.0.0.003.zip from Compiled_addon_virtual.opi-tools-003.zip

    After this I must in kodi insall 2 plugin
    virtual.opi-tools-10.0.0.003.zip

    service.fan.orangepi-0.0.2.zip

    just like i usually install kodi plugins.

    Please write if I understand the sequence of actions correctly?

    Yes, that's all you need. You (most likely) don't need to compile your own version of the "Orange Pi Tools" plugin (virtual.opi-tools).

    Quote from harrysmith63

    And where find this directory ../http://LibreELEC.tv/packages/addons/

    You will not find this directory unless you follow the instructions in the "Building (Basics)" chapter of the LE wiki..

    I have to apologize, but I guess I didn't fully understand your posts.

    However - maybe this will help you:

    It is possible to set the scrolling speed. This is done in the settings of the XBMC-LCDproc add-on.

    If you set the value to "0", the scrolling will stop.

    1. Can you please tell me if version 104 (for CM4) works without problems?

    2. Of course, LibreELEC has a folder with fonts. The path to them is /usr/share/fonts/liberation

    3. If version 104 works and the font selection also works, you can normally (using the configuration dialog) also select a font from the above folder (via the Root filesystem)

    4. Obviously, not every font that looks good on a monitor or TV screen looks equally good on an OLED display. That's why I think that the option to add more fonts to the menu will be useful (for example, I personally liked the Ubuntu font the most so far).

    I did change the font with arial bold, it is better now.

    On the one hand, this is very subjective, and on the other hand, there are copyrights. I hope you understand that I cannot (as part of my product) distribute the fonts covered by these rights.

    However, your initiative led me to one idea - to make the font not fixed, but user selectable. This means that each user can copy any number of fonts to the appropriate folder and then choose which font to use in the configuration dialog. I don't care where the user gets these fonts from.

    It is really easy:

    1) Create a fonts folder in the /storage/.kodi/userdata folder

    2) In the /storage/.kodi/userdata/fonts folder, create two subfolders regular and mono

    3) In the /storage/.kodi/userdata/fonts/regular folder, copy the regular fonts you want to try

    4) In the /storage/.kodi/userdata/fonts/mono folder, copy the fixed-width fonts you want to try

    5) In the configuration dialog of the add-on, select the fonts you want to use

    6) The change on the display will take place immediately (the add-on will automatically restart)

    Note:

    I tried it on an Orange Pi PC board (I have it with me on vacation). I don't have an RPi with me, so I couldn't try the CM4 version. There were quite a lot of changes, so it's quite likely that I forgot about some change in the CM4 version.

    Yes, display content is configured using LCD.xml. So it should be possible to add some information and thereby expand the text.

    The second option is to reduce the number of emulated lines in the addon configuration. This will make the font bigger.

    As everything is concentrate on left side of the display, maybe some changes are required to extend the texts to all the space available.

    I was worried that it might happen. Although during development I tried to do it independently of the specific resolution of the display, I probably still made a mistake, and somewhere the fixed width of 128 pixels is still calculated. I'll look into it, it shouldn't be hard to find.

    Edit:

    Now I looked at the picture from you more carefully and it's probably not like that. According to the time, the movie is about one quarter and the progressbar also occupies about one quarter of the display.

    Can you confirm that when there is some longer text than half of the display, it behaves normally and the text occupies the other half of the display as well?

    Scrolling should only occur if the text is longer than the full width of the display.

    There isn't much you can do with the font. It would look very unnatural if the width of the letter was the same as its height.

    Congratulations - good job!

    I would probably figure it out in time too - I was actually getting close to it. Obviously, if I had a grayscale display available, it would be much faster.

    I still have a question for clarification - if you change the relevant line like this:

    self.device = driver(serial, width, height, rotate, mode = '1')

    then there is no need to comment the lines that are used to display the LE logo (as I wrote in the last post) and the LE logo is also displayed when the add-on is started?

    It looks like there is some problem with the luma.oled library, specifically with greyscale devices (SSD13xx). It's probably a glitch when we want to display the LE logo, which is only black and white. You can try commenting the lines in the service.py file according to the following code snippet.

    Code
    Thread(target = self.runserver).start()
    Thread(target = self.runqueue).start()
    #logopath = join(images_dir, 'Logo%i.png' % self.h)
    #logo = Image.open(logopath).convert("1")
    #posn = ((self.device.width - logo.width) // 2, 0)
    #self.image.paste(logo, posn)
    #self.device.display(self.image)

    Or you can try the following modification (I can't test it, I don't own a greyscale device):

    Code
    logopath = join(images_dir, 'Logo%i.png' % self.h)
    logo = Image.open(logopath)
    logo = ImageOps.grayscale(logo)
    posn = ((self.device.width - logo.width) // 2, 0)
    self.image.paste(logo, posn)
    self.device.display(self.image)

    In case it works, I would also be interested in this modification:

    Code
    logopath = join(images_dir, 'Logo%i.png' % self.h)
    logo = Image.open(logopath)
    posn = ((self.device.width - logo.width) // 2, 0)
    self.image.paste(logo, posn)
    self.device.display(self.image)
    Code
    Error Contents: BOARD numbering system not applicable on compute module

    Ah, so that's a surprise for me. And I also understood why you used BCM numbering (it's impractical for me - BOARD numbering still applies not only across versions, but even for Orange Pi). I have never seen CM and had no idea about this limitation. But never mind, we'll deal with it somehow. I'll probably have to make a special version for CM. Sorry, but this will take some time...

    First I'll just do a test version where the DC and RES pins will be hardwired by software (other pins are HW controlled so it's always hardwired). Later I will add the option to choose DC and RES in the configuration dialog. Do you have any preferences as to which GPIO the DC and RES pins should be connected to in the first stage?