Backport to `LibreELEC 9.2.*` ???

jojobrogess / script.deskpifanservice

Libreelec Addon to install Deskpi Fan Service and Control Fan Speed

4 stars 0 forks source link

Backport to `LibreELEC 9.2.*` ??? #2

Open inspector71 opened 7 months ago

inspector71 commented 7 months ago

Hi @jojobrogess

I finally got around to looking into your superb code efforts. Making the GUI add on in particular, especially for someone who, I think you mentioned, had not had much experience writing Python or Kodi add-ons, is briliant.

I'm quite brain fried though, so it's a bit tricky for me to catch up with.

More to the point, I want to try and backport it to 9.2.* and thus Python 2.7.16 which seems to be the version bundled with that LE version of Kodi.

Why? Primarily I need VNC support and the direction Kodi has gone with video drivers means the venerable Raspberry Pi VNC addon no longer works in LE 10 and beyond. To support my users remotely, I can do a lot via SSH but as anyone who has used Kodi for a while probably realises, some thing - AFAIK - just have to be done via the GUI. Setting the content type for library sources - which is critical or else there's little point setting up a library source - being a prime example.

I know absolutely zilch about Python. I've avoided it for the same reason a lot of developers do: the absence of normal syntax.

Made some quick progress initially. Am away from my Kodi set up as I write, so some details I might have to correct/update later.

Changing the minimum Python version to 2.26.0 - the version the Kodi wiki states is supported by Kodi 18.9 Leia ... the version of Kodi LibreELEC 9.2.* uses - allowed me to install the addon and see the GUI which was super cool.

I was able to browse through the GUI settings and see the work you've done beyond the screenshots.

Not a big deal but the screen for dependencies was a bit foreign to me, I'm not sure I've seen that type of GUI in Kodi before. Was unsure what to do but tried selecting them and hitting OK on the remote. Likely due to issues with the backporting that were yet to be reviewed, nothing happened in the GUI, at least. No notification of a Python error.

I was able to install Raspberry Pi Tools (RPI-Tools) and System Tools (System-Tools) via the LibreELEC addons manager and pyserial via SSH.

The /storage/.kodi/temp/kodi.log tail told me the issues though.

With a Python tool I amazingly managed to install and run, called 3 to 2, I started tweaking. This tool seemingly converted a few bits and pieces, mainly prefixing strings with u for unicode compatibility. Unsurprisingly though, Several errors still appeared.

The path module is not available so the checks for deskpi.conf triggered errors but this seemed easy enough to replace with os.path.isfile().

subprocess.run() is not a method via installed versions of the module. This seems easy enough to replace with subprocess.call()

TBC

jojobrogess commented 7 months ago

More to the point, I want to try and backport it to 9.2.* and thus Python 2.7.16 I know absolutely zilch about Python.

That's going to be an issue. The subtleties between versions is difficult to perceive, and if you barely know anything it makes it even harder especially when the code still works in your editor. I had the same issue just going the opposite way. Using Pycharm as your text editor can help because you can set your python dependencies to whatever version you want. And it'll help with seeing and understanding the changes between Python 3vs2. Kodistubs might be a little weird tho, so you might have to select a downgraded version since I would assume it's been updated but idk off the top of my head.

I can do a lot via SSH but as anyone who has used Kodi for a while probably realises, some thing - AFAIK - just have to be done via the GUI. Setting the content type for library sources - which is critical or else there's little point setting up a library source - being a prime example.

Yeah I found that out as well, although you can replicate actions by putting the code into file format and running it that way, or just finding out what files get updated and making the changes yourself. From what I found, there is always another way of doing something. Regardless of what people tell you. It might not be the right way lol but you can do it.

I was never able to teach myself SQL to do stuff with Kodi that way, but you could always try but apparently it's not advised by anyone: https://kodi.wiki/view/MySQL https://kodi.wiki/view/HOW-TO:Update_SQL_databases_when_files_move

Changing the minimum Python version to 2.26.0 - the version the Kodi wiki states is supported by Kodi 18.9 Leia ... the version of Kodi LibreELEC 9.2.* uses - allowed me to install the addon and see the GUI which was super cool.

Interesting, afaik that shouldn't work.

Not a big deal but the screen for dependencies was a bit foreign to me, I'm not sure I've seen that type of GUI in Kodi before.

I had no idea what I was doing when I created the addon. There is just SOO MUCH information you have to learn to get into Kodi, especially when you're not versed in python and their years and years of tweaks/known bugs inside of it. It takes a while to digest it all. This whole project was a proof of concept turned insult. I was just trying to get it completed to prove a point. So to create something as basic and easy to understand as I could I did it step by step. Now I would probably write it as a complete service and delegate the install to a subprocess check, with the only user input being configurations.

The path module is not available so the checks for deskpi.conf triggered errors but this seemed easy enough to replace with os.path.isfile(). subprocess.run() is not a method via installed versions of the module. This seems easy enough to replace with subprocess.call()

Like I said earlier, I think I had the same issue taking Deskpi's code and updating it for Matrixv19 but backwards.

It might be easier to uninstall 3 to 2, and try to downgrade the code by hand rather than trying to see what it can't. It also might be easier to take the code I wrote for the SSH installer and downgrade that. Then when it works, take that and make all the changes from there.(the code is basically just injected into the addon)

I don't have ANY of this setup or running, but if you're still running into issue's I think I can try to see what I can do. let me know.

jojobrogess commented 7 months ago

I do want to add that I think I remember trying to do this but there was something about it getting the serial process or installer to work that was different or something, maybe had to with otg_mode=1 and not necessarily Python 2 being the problem but with leia and libreelec's Python library working with the serial library addon that I used. Which afaik is updated to python 3.

inspector71 commented 7 months ago

More to the point, I want to try and backport it to 9.2.* and thus Python 2.7.16 I know absolutely zilch about Python.

That's going to be an issue.

Yeah, it's stopped me trying a lot of possible handy Kodi Addon ideas, over the years, sadly :(

But I'm going to try a form of brute forcing, if you like / for want of a better term, through my barriers towards tinkering in Python. Wish me luck, I'll very much need it! :)

The subtleties between versions is difficult to perceive, and if you barely know anything it makes it even harder especially when the code still works in your editor. I had the same issue just going the opposite way. Using Pycharm as your text editor can help because you can set your python dependencies to whatever version you want. And it'll help with seeing and understanding the changes between Python 3vs2.

Thanks for the Pycharm suggestion! Will check it out. Is new to me.

Kodistubs might be a little weird tho, so you might have to select a downgraded version since I would assume it's been updated but idk off the top of my head.

I'm not familiar with Kodistubs. I'll read up about it.

I can do a lot via SSH but as anyone who has used Kodi for a while probably realises, some thing - AFAIK - just have to be done via the GUI. Setting the content type for library sources - which is critical or else there's little point setting up a library source - being a prime example.

Yeah I found that out as well, although you can replicate actions by putting the code into file format and running it that way, or just finding out what files get updated and making the changes yourself. From what I found, there is always another way of doing something. Regardless of what people tell you. It might not be the right way lol but you can do it.

Agree there seems like there's often a way to get some actions done. Not sure about all of them but I would love to find out if there's a way of triggering those library content types. It should be set in the XML, really.

I was never able to teach myself SQL to do stuff with Kodi that way, but you could always try but apparently it's not advised by anyone: https://kodi.wiki/view/MySQL https://kodi.wiki/view/HOW-TO:Update_SQL_databases_when_files_move

I don't know if SQL is a good idea for this. It's probably overkill. A simple config file is just as good.

Changing the minimum Python version to 2.26.0 - the version the Kodi wiki states is supported by Kodi 18.9 Leia ... the version of Kodi LibreELEC 9.2.* uses - allowed me to install the addon and see the GUI which was super cool.

Interesting, afaik that shouldn't work.

Well the strange thing is it did originally, but since then I cannot get a converted addon to install. I keep getting the error that Kodi could not parse the addon.xml file. So I'm quite confused about that.

Can't think of a good reason why it should not at least install the addon and then, if functions within the *.py files don't work, so be it. That's what happened on day one. Next thing I know, no luck! Thought maybe I had done the zipping different or something but I tried many ways and no luck yet.

That's a really important point. The development workflow for a Kodi addon surely cannot require continual re-zipping and GUI installation? There must be a better way. Surely? Maybe I need to read the Kodi Add-On Development wiki page(s).

All pointless if I cannot get a zip to install though! I dead certain it worked originally.

Not a big deal but the screen for dependencies was a bit foreign to me, I'm not sure I've seen that type of GUI in Kodi before.

I had no idea what I was doing when I created the addon. There is just SOO MUCH information you have to learn to get into Kodi, especially when you're not versed in python and their years and years of tweaks/known bugs inside of it.

I understand for sure. It can seem super intimidating. Again, that's one of the reasons I've never dove in and had a go. But, perhaps ironically, your efforts have given me the kick start I hope will help. I was always a bit more concerned about the GUI bits even though I suspect it was fairly straightforward. Their pages don't exactly offer a whole lot of GUI options such as drop down lists or whatnot. But I guess it's heavily oriented towards use with remote controls.

It takes a while to digest it all.

Yeah I can imagine and I'm not convinced I'll get anywhere with it.

This whole project was a proof of concept turned insult. I was just trying to get it completed to prove a point.

Absolutely and perfectly understand that motivation. Agree with it completely. Might not seem like the ideal motivation but it got the job done! Have you had feedback from many users?

So to create something as basic and easy to understand as I could I did it step by step. Now I would probably write it as a complete service and delegate the install to a subprocess check, with the only user input being configurations.

I'm still familiarizing myself with it but I don't think you need to be hard on yourself. It's quite good. I'm not sure what UX is supposed to happen on the dependencies screen but it doesn't hurt to have users interact with some extent of the nuts and bolts. You've more or less

The path module is not available so the checks for deskpi.conf triggered errors but this seemed easy enough to replace with os.path.isfile(). subprocess.run() is not a method via installed versions of the module. This seems easy enough to replace with subprocess.call().

Like I said earlier, I think I had the same issue taking Deskpi's code and updating it for Matrixv19 but backwards.

I wasn't aware the DeskPi people produced any Python 2 code.

Is this it what you are referring to:

https://github.com/DeskPi-Team/deskpi/tree/master/drivers https://github.com/DeskPi-Team/deskpi/tree/master/drivers/python

I may well definitely be better off trying that. I'll have a browse.

To be honest, I really do not care about the ins and outs in that I am not a Python zealot. I see the DeskPi people appear to have some C code as well:

https://github.com/DeskPi-Team/deskpi/tree/master/drivers/c

If there's some way to shoehorn that into a LibreELEC scenario, if that's easier somehow, I'm fine with that.

My preference is a nice GUI like you've produced. But worst comes to worst, I need the fan and power button working and am more than OK with just doing that via running a script in SSH. But I got the impression there's no reason that all this can't be done for 9.2. and recently, attempting to sort out an Argos unit that's not sitting around gathering dust for the moment, as an alternative that's failed so far, I recognized the full extent of the VNC issue for Kodi 10 onwards, on a Raspberry Pi. I need VNC for sure. So I'm sticking with `9.2.`, much to the annoyance of the hard working LE developer chewitt, for the reasons outlined here:

https://forum.libreelec.tv/thread/25514-libreelec-rpi4-arm-9-2-8-img/?postID=185412#post185412

It might be easier to uninstall 3 to 2, and try to downgrade the code by hand rather than trying to see what it can't.

I'm trying to do both. A bit of a leg-up with 3 to 2 and then checking for other issues via installing, running and the kodi log. I had a feeling I was close to getting the syntax issues sorted out for at least one script. Then I would move on to verifying the actual functionality if I could.

It also might be easier to take the code I wrote for the SSH installer and downgrade that.

Funny you mention that. I was unaware, or had forgotten, the full scope of your efforts. But then stumbled across that very effort.

Ultimately I feel the users of any hardware they've paid for should get an LE Add On grade of setup and support. So that's sensational that you've done that. But I primarily just want to get one instance working. At present, I got the the device using / booting from an SSD which is a big step beyond anything I've tried - hardware, software, user education / needs management - for solving the same use case in the past. But I really want that power button situation as smooth as it can be, along with the cooling for the processor. That's critical. Even the Raspberry Pi Foundation has finally recognized both needs with the Pi5 - and I don't believe that's merely because the Pi5 performance is 250% faster than the 4 and thus requires that much more cooling - but that's another story.

I'll definitely be taking a look at the SSH installer script. You're a legend for all the work you put into it. I still feel bad I wasn't in a headspace / place to help with it in tandem. Sorry about that.

Then when it works, take that and make all the changes from there.(the code is basically just injected into the addon)

I don't have ANY of this setup or running, but if you're still running into issue's I think I can try to see what I can do. let me know.

It would be sensational to work with you on it. However I do understand it's a commitment. I guess I was primarily hoping to get a little communication going to help me understand your exceptional efforts. Did DeskPi end up getting you some free hardware? I noticed there's DeskPi Pro v3 out. Hopefully they have sent you one of those but maybe not, although I of course recall remuneration was not your primary motivation.

inspector71 commented 7 months ago

I do want to add that I think I remember trying to do this but there was something about it getting the serial process or installer to work that was different or something, maybe had to with otg_mode=1 and not necessarily Python 2 being the problem but with leia and libreelec's Python library working with the serial library addon that I used. Which afaik is updated to python 3.

I think there might be details of that within this issue:

https://github.com/LibreELEC/LibreELEC.tv/issues/4722

I noticed you closed this issue. Does that mean I shouldn't add any more comments to it?

jojobrogess commented 7 months ago

I noticed you closed this issue. Does that mean I shouldn't add any more comments to it?

Yeah sorry about that I did it on accident. I think I pressed enter and instead of just commenting it it closed and commented.

I keep revisiting this. I don't know how to respond, there's just too much to say lol and I don't know that much so it's difficult to know what to suggest.

I've honestly written probably 10 paragraphs about nonsense already lol Which kind of makes me want to see if I can get it to work on that version of libreelec, would be cool to offer python 2 capabilities. As well as see if I can streamline the install process to not need to be installed by hand through the addon's settings gui.

But I don't want to steal your joy(and utter agony) of teaching yourself. As ridiculous as that sounds. The joy I felt the second I understood how everything worked was pretty awesome.

I can try to go line by line through the installer and/or the addon files to give you an idea of what everything does. Or at least through the parts that you're lost on. So you can try figure everything out on your own.

inspector71 commented 7 months ago

I noticed you closed this issue. Does that mean I shouldn't add any more comments to it?

Yeah sorry about that I did it on accident. I think I pressed enter and instead of just commenting it it closed and commented.

No worries. I had thought maybe you closed it quickly because your second reply represented your belief that it's not possible. Which, to be fair, may be true unless I'm able to go as far as compiling my own build. Not something I've done before.

I keep revisiting this. I don't know how to respond, there's just too much to say lol and I don't know that much so it's difficult to know what to suggest.

More than fair enough!

I've got to admit, I'm uncertain if it's possible. Maybe the otg_mode=1 suggestion might do the trick but I don't know. I'm not even really that clear on what OTG mode is. I think of it as a kind of 'host' mode but that's not all that clear.

I've honestly written probably 10 paragraphs about nonsense already lol

Classic! I know exactly the sort of experience you're referring to! Happens to me all too often.

Which kind of makes me want to see if I can get it to work on that version of libreelec, would be cool to offer python 2 capabilities. As well as see if I can streamline the install process to not need to be installed by hand through the addon's settings gui.

Personally I don't mind the latter. I think it's kinda cool to have that as a sort of 'control panel' interface. But I'm just a bit confused by the UX. That said, best case scenario might be to have both. Install script runs and is something goes wrong, the user can go into settings and confirm that with a quick 'dashboard' like glance. Possibly then see a few tips or actions to try and resolve the issue. I guess that's me, I always prefer two concepts with computing: don't require users to do anything out of their comfort zone / expectations; offer them the tools to take as much control of the situation as they feel comfortable with ... and/or enough to allow them to relay troubleshooting details to a helping hand person.

But I don't want to steal your joy(and utter agony) of teaching yourself. As ridiculous as that sounds. The joy I felt the second I understood how everything worked was pretty awesome.

I don't think I'd feel the same. It is good to use this as the impetus to get under the hood more, but my brain is quite fried from various health conditions so that's a sadly substantial limit. My joy would be more from collaborating as that's not something I've had for a very long time.

I can try to go line by line through the installer and/or the addon files to give you an idea of what everything does. Or at least through the parts that you're lost on. So you can try figure everything out on your own.

Yeah the latter could be great. I've had somewhat of a look. Keep getting distracted. Awareness of the bits and pieces, which I don't necessarily consider 'learning' per se, is kinda interesting. I didn't know that something as relatively meaningless as import xbmcaddon was a reference to code provided by the Kodistubs library. I just assumed that was internal to the Kodi addon API.

I think the question I have at present is just simply how to do something as simple as switch the processor fan to always on, all the time. I'm not currently sure that is possible. I'm not sure it's even possible to have a service on LE 9.2.6 that can communicate with the hardware. When it gets down to people questioning if the hardware can be used with the LE 9.2.6 kernel, which I think has been questioned (meaningfully or not, I'm unsure) then I start to wonder if it's over my head.

OTOH, I already have the unit running LE 9.2.6 off a SATA SSD via the daughter board's USB3 bridge adaptor. Have had for a long time. If the daughter board is not working at all, that wouldn't be possible. But the SATA interface on the daughter board is likely an entirely different circuit to the power button and fan.

jojobrogess commented 7 months ago

But I'm just a bit confused by the UX.

I think the reason why is because Kodi changed the syntax used for UI elements, so I would assume the gui confirmation windows that I used to show that something was actually happening as a verifier don't work or just bug out.

Unless I'm wrong on that, and you're confused about something else.

OTOH, I already have the unit running LE 9.2.6 off a SATA SSD via the daughter board's USB3 bridge adaptor. Have had for a long time. If the daughter board is not working at all, that wouldn't be possible. But the SATA interface on the daughter board is likely an entirely different circuit to the power button and fan.

I've got to admit, I'm uncertain if it's possible. Maybe the otg_mode=1 suggestion might do the trick but I don't know. I'm not even really that clear on what OTG mode is. I think of it as a kind of 'host' mode but that's not all that clear.

I think the question I have at present is just simply how to do something as simple as switch the processor fan to always on, all the time. I'm not currently sure that is possible. I'm not sure it's even possible to have a service on LE 9.2.6 that can communicate with the hardware. When it gets down to people questioning if the hardware can be used with the LE 9.2.6 kernel, which I think has been questioned (meaningfully or not, I'm unsure) then I start to wonder if it's over my head.

OTOH, I already have the unit running LE 9.2.6 off a SATA SSD via the daughter board's USB3 bridge adaptor. Have had for a long time. If the daughter board is not working at all, that wouldn't be possible. But the SATA interface on the daughter board is likely an entirely different circuit to the power button and fan.

whoops sorry, the otg_mode=1 thing is about getting the SATA interface usb boot thing working. You got that already.

The issue then, other than using different python/kodi/libreelec syntax, is this:

The Fan and power button, need a serial library to work. The deskpi controls the fan through PWM signal via serial port. And kodi/libreelec don't need that library to function so it has to be imported in.

I was going to do it by hand but THANKFULLY I was able to find a working version of the library that could be imported without any work. But I think it's in python 3. So the library might need to be downgraded to be able to work for 2. pyserial official = https://github.com/pyserial/pyserial a snapshot of the version I use https://github.com/jojobrogess/pyserial/

Without a working serial library, none of the code for the fan will work. This is the main code that controls the fan:

import sys
sys.path.append('/storage/.local/lib/python3.8/site-packages/')
import serial as serial
import time
import subprocess
port = '/dev/ttyUSB0'
baudrate = '9600'
ser = serial.Serial(port, baudrate, timeout=30)
try:
    while True:
        if ser.isOpen():
            cpu_temp = subprocess.getoutput('vcgencmd measure_temp|awk -F\'=\' \'{print \$2\'}')
            cpu_temp=int(cpu_temp.split('.')[0])
            if cpu_temp < 35:
                ser.write(b'pwm_000')
            elif cpu_temp > 35 and cpu_temp < 40:
                ser.write(b'pwm_025')
            elif cpu_temp > 40 and cpu_temp < 45:
                ser.write(b'pwm_0050')
            elif cpu_temp > 45 and cpu_temp < 50:
                ser.write(b'pwm_075')
            elif cpu_temp > 50:
                ser.write(b'pwm_100')
except KeyboardInterrupt:
    ser.write(b'pwm_000')
    ser.close()

I think the question I have at present is just simply how to do something as simple as switch the processor fan to always on

It wouldn't be simple, per se..: You'd have to install a working pyserial library. Then create a mock program to see if you can read/write code to the serial port. If you can, proceed further. If you can't there is zero point downgrading the installer/python/addon syntax to work in leia.

jojobrogess commented 7 months ago

Okay so i figured out what's going on. (i should have remembered)

compiled from various comments on this topic The normal RPi4 has an USB host controller on the PCIe bus, the DWC2 driver is required for the SoC internal USB host. So this isn't required for the ordinary RPi4.

By using otg_mode=1, this will give you an XHCI controller instead of the DWC2 one.

The kernel config option doesn't get introduced until libreelec 10(ish), I think my initial test was on LibreELEC-RPi4.arm-9.95.4. I wasn't able to get it to install on 9.0.0 , 9.2.6 , 9.2.7 , or 9.2.8 during that initial test.

So there are 2 options:

Option 1 you're using a build that you never updated from. Something between 9.2.8 and 10.0.4

I don't have that available to me, so you'd have to test to see if adding otg_mode=1 to your /flash/config.txt file gets this code: python -m serial.tools.list_ports to show /dev/ttyUSB0

How to modify config file, run in terminal:

mount -o remount,rw /flash echo "otg_mode=1" >> /flash/config.txt mount -o remount,ro /flash

The first and last commands Open and Close the filesystems write capabilities. The second command adds otg_mode=1 to the bottom of the config file, you can always do this part by hand. Ignore this if it's already in there tho, idk what would happen if you have multiple bits of code in that file.

If you can get this part to work, it will get interesting because like I said I don't have that build so we'd have to work together through only your machine lol Shouldn't be too hard tho.

Option 2 you're using the only official leia version which is 9.2.8. If you have this version, it's also about to get interesting.

You have to rebuild Kodi and add back in the code.

Someone made a comment saying:

I didn't recompile LibreELEC to remove the DWC2 driver but I verified in /sys that it is unused.

So I would assume that the capabilities are there, they were just removed from the config file.

So you'd have to teach me or yourself how to build Kodi. I have tried it before, but was completely confused and was never able to actually build anything or understand any of the changes. AFAIK I think you have to fork off the libreelec repo at the timeframe you want and then use that as the base for the rebuild. You just make your changes and then recompile it back together.

The longshot option, is being able to find an alternative config option that turns on the serial port.

I wish there was clear explaination as to what all of these do: dtoverlay=dwc2, dr_mode=host , otg_mode=1, CONFIG_USB_DWC2=y, and CONFIG_USB_DWC2_HOST=y

There's probably a kodi/libreelec doc in the github files somewhere that talks about them. but idk

jojobrogess commented 7 months ago

Oh I forgot to add, I just installed 9.2.8 and the power button worked without any modifications, so if yours doesn't either the button is broken or you hard shut it off. IF the button is red and pressing/holding it down does nothing it's probably the pin. IF it's off completely, then it's probably broken.

If it's colored, let me know and I'll take my case apart and try to take pictures of the pin thingy. Idk how old you are, but if you're old and been around computers since the 90's you probably remember hard drive master pins. It's that for the button, just find it and orientate it differently. if it's not apparent, don't mess with it.

But even then, an always off pin layout? that doesn't seem right.. I could be off about this lol sorry I'm all over the place

inspector71 commented 6 months ago

But I'm just a bit confused by the UX.

I think the reason why is because Kodi changed the syntax used for UI elements, so I would assume the gui confirmation windows that I used to show that something was actually happening as a verifier don't work or just bug out.

Definitely possible. I didn't see any dialog. Mind you, I only got the revised addon.xml accepted once by Kodi. Many subsequent efforts failed.

Unless I'm wrong on that, and you're confused about something else.

OTOH, I already have the unit running LE 9.2.6 off a SATA SSD via the daughter board's USB3 bridge adaptor. Have had for a long time. If the daughter board is not working at all, that wouldn't be possible. But the SATA interface on the daughter board is likely an entirely different circuit to the power button and fan.

I've got to admit, I'm uncertain if it's possible. Maybe the otg_mode=1 suggestion might do the trick but I don't know. I'm not even really that clear on what OTG mode is. I think of it as a kind of 'host' mode but that's not all that clear.

I think the question I have at present is just simply how to do something as simple as switch the processor fan to always on, all the time. I'm not currently sure that is possible. I'm not sure it's even possible to have a service on LE 9.2.6 that can communicate with the hardware. When it gets down to people questioning if the hardware can be used with the LE 9.2.6 kernel, which I think has been questioned (meaningfully or not, I'm unsure) then I start to wonder if it's over my head. OTOH, I already have the unit running LE 9.2.6 off a SATA SSD via the daughter board's USB3 bridge adaptor. Have had for a long time. If the daughter board is not working at all, that wouldn't be possible. But the SATA interface on the daughter board is likely an entirely different circuit to the power button and fan.

whoops sorry, the otg_mode=1 thing is about getting the SATA interface usb boot thing working. You got that already.

The issue then, other than using different python/kodi/libreelec syntax, is this:

The Fan and power button, need a serial library to work. The deskpi controls the fan through PWM signal via serial port. And kodi/libreelec don't need that library to function so it has to be imported in.

I was going to do it by hand but THANKFULLY I was able to find a working version of the library that could be imported without any work. But I think it's in python 3. So the library might need to be downgraded to be able to work for 2. pyserial official = https://github.com/pyserial/pyserial a snapshot of the version I use https://github.com/jojobrogess/pyserial/

Yeah I looked at that and tried to manually install pyserial which succeeded ... but I'm uncertain which version is installed.

The pySerial docs suggest pySerial works with Python 2.7 but I'm not sure if LE 9.2.6 actually can run Python 2.7 which is installed, seemingly, but Kodi Leia is only supposed to support2.26.0`

Is there a CLI binary I can use to get the version? I'm suspecting not because it's a library for using within a Python script.

Without a working serial library, none of the code for the fan will work. This is the main code that controls the fan:

Yeah it seems, loosely, there's (at least) two steps to communicating programmatically with the fan:

Enabling the xHCI device, which we hope is happening via an otg_mode=1 line in /flash/config.txt
Sending serial commands to the fan's (controller chip?) interface

Does that sound correct to you?

Regarding step 2, the DeskPi people have supplied example code in both the C and Python languages.

import sys
sys.path.append('/storage/.local/lib/python3.8/site-packages/')
import serial as serial
import time
import subprocess
port = '/dev/ttyUSB0'
baudrate = '9600'
ser = serial.Serial(port, baudrate, timeout=30)
try:
    while True:
        if ser.isOpen():
            cpu_temp = subprocess.getoutput('vcgencmd measure_temp|awk -F\'=\' \'{print \$2\'}')
            cpu_temp=int(cpu_temp.split('.')[0])
            if cpu_temp < 35:
                ser.write(b'pwm_000')
            elif cpu_temp > 35 and cpu_temp < 40:
                ser.write(b'pwm_025')
            elif cpu_temp > 40 and cpu_temp < 45:
                ser.write(b'pwm_0050')
            elif cpu_temp > 45 and cpu_temp < 50:
                ser.write(b'pwm_075')
            elif cpu_temp > 50:
                ser.write(b'pwm_100')
except KeyboardInterrupt:
    ser.write(b'pwm_000')
    ser.close()
I think the question I have at present is just simply how to do something as simple as switch the processor fan to always on

It wouldn't be simple, per se..: You'd have to install a working pyserial library. Then create a mock program to see if you can read/write code to the serial port. If you can, proceed further. If you can't there is zero point downgrading the installer/python/addon syntax to work in leia.

Yep, completely agree.

However, I'm also interested in hacking whatever solution it takes. So, if for example there's some manual way to send a signal to the fan, such as a BASH script, I'm interested in that as well.

That said, after all the excellent work you've done with the Kodi Addon support, it would be a shame not to have that going as a sweet GUI front end. So I'm still very interested in that objective.

Will check out your other posts very soon!

jojobrogess commented 6 months ago

Yeah it seems, loosely, there's (at least) two steps to communicating programmatically with the fan: Enabling the xHCI device, which we hope is happening via an otg_mode=1 line in /flash/config.txt Sending serial commands to the fan's (controller chip?) interface Does that sound correct to you?

Yes. I just spent the last couple days re-writing the whole addon pretty much start to finish, and can now remember a lot more of what I did initially and what's actually going on with the overall install, fan control and deskpi case.

However, I'm also interested in hacking whatever solution it takes. So, if for example there's some manual way to send a signal to the fan, such as a BASH script, I'm interested in that as well.

I re-looked at the pyserial installer, and checked it for myself, it can install the version necessary to run on leia(for python 2.7.16 i think). So the problem 100% is that the serial com port /dev/ttyUSB0 is never initialized so it's not available for use.

Without the code: python -m serial.tools.list_ports showing /dev/ttyUSB0, I don't think there's a way of controlling the fan.

If you can figure out how to rebuild kodi and re-add back in the configurations for the old methodology, because apparently the old drivers weren't removed completely they just removed them from the configuration files, so you can't activate it. Then you'd be able to see it to control it.

But unless you're willing to do that, or can find some other method of turning on that com port, or can find a custom built libreelec build with those conf flags already turned back on; I don't think this is something that can become a reality.

Which is why I think Deskpi never created a Libreelec script to begin with, they weren't able to reliably create a script for the main version at the time (leia) and would have had to wait for months until matrix was released on libreelec before they could test it. (random comments I've found of yoyoyacky and 1 other seem to suggest that they were searching for answers prior to the otg_mode=1 beta release of libreelec matrix and prior to the issue that was posted on their git) And the software development window for new hardware is pretty short. They can't pay to retain a programmer for that long, just for 1 OS. And companies RARELY ever look back at their previous projects. Especially to a project that probably barely made any money (they had to resend every preorder a second version of the daughter board), at least at that time.

And all for an OS that is very very specific which has a secondary "OS"(kodi) within it, and requires pretty intimate knowledge of the architecture and engine to be able to run things correctly. Not to mention all the rules you have to follow in order to get it added officially.
And then you have to support it, and with every major release they add in, change, and remove functionality. (now you know why there is a small amount of official skins)

SUPER CRAZY long shot: shouldn't be considered a solution, because it's not. It's a side step: You might be able to replace the deskpi fan with the argon fan or similar, it would take elbow grease and I'm not 100% if it would fit because of the heatsink. But that fan uses another connection method, and from what I can remember of the argon one install script, is a lot easier to code for.

inspector71 commented 6 months ago

Yeah it seems, loosely, there's (at least) two steps to communicating programmatically with the fan: Enabling the xHCI device, which we hope is happening via an otg_mode=1 line in /flash/config.txt Sending serial commands to the fan's (controller chip?) interface Does that sound correct to you?

Yes. I just spent the last couple days re-writing the whole addon pretty much start to finish, and can now remember a lot more of what I did initially and what's actually going on with the overall install, fan control and deskpi case.

That, good Sir, is absolutely outstanding work and a super effort. Thank you so very much for your enthusiasm and support towards this project of ours :) !!!

I'm determined that your efforts will not go to waste.

However, I'm also interested in hacking whatever solution it takes. So, if for example there's some manual way to send a signal to the fan, such as a BASH script, I'm interested in that as well.

I re-looked at the pyserial installer, and checked it for myself, it can install the version necessary to run on leia(for python 2.7.16 i think). So the problem 100% is that the serial com port /dev/ttyUSB0 is never initialized so it's not available for use.

Without the code: python -m serial.tools.list_ports showing /dev/ttyUSB0, I don't think there's a way of controlling the fan.

... in Python?

Maybe we could try the C code that DeskPi has produced? Is there a reason LE can't run C code?

I reckon, if LE just cannot do the job, I'm going to look at alternatives. The best thing about OSMC is it's a fuller / full Linux distro. My use case is to leave the unit always on so any additional boot time that a full(er) OS may add is not a problem. I can' think of another good reason not to try OSMC if LE is just not going to happen.

In fact, I'm almost certain, if I'm understanding this correctly, the Python version limits imposed by Kodi are not the key issue. It looks like my limited understanding, it's a OS-level issue in that, under the LE 9.2.x kernel(s) and it's BusyBox OS, it just cannot initialise the fan device. Is that correct?

If an older version of OSMC can be found and works with the fan controller, I'm very interested in researching that as a possibility.

If you can figure out how to rebuild kodi and re-add back in the configurations for the old methodology, because apparently the old drivers weren't removed completely they just removed them from the configuration files, so you can't activate it. Then you'd be able to see it to control it.

But unless you're willing to do that, or can find some other method of turning on that com port, or can find a custom built libreelec build with those conf flags already turned back on; I don't think this is something that can become a reality.

If learning to build LE is a necessity, I'm willing to try that. Whether I'm able to or not, well ... that may be another question :)

However, the OSMC option might also be worth investigation.

SUPER CRAZY long shot: shouldn't be considered a solution, because it's not. It's a side step: You might be able to replace the deskpi fan with the argon fan or similar, it would take elbow grease and I'm not 100% if it would fit because of the heatsink. But that fan uses another connection method, and from what I can remember of the argon one install script, is a lot easier to code for.

Definitely worth investigation of alternative fans. Not necessarily the Argon as I've read it's a relatively poor quality fan anyway.

Most logical fan that comes to mind is fiiiiiiiiiiiiiinally-a-thing Rasperry Pi Foundation fan released in conjunction with the RPi5. Just because it's associated with the RPi5, one would hope does not preclude it from use in other hardware solutions.

Hang about ... there is / was a Pi4 case fan as well? Hmmm, GPIO connected.

Hmmmm

Also the RPi5 "Active Cooler".

Both options come with more than just a fan but if the fans themselves are better quality and better supported at OS level, they could be worth looking at.

So far, I've no experience of the DeskPi fan running. Do you have a means of checking the RPM and so forth? Might not be able to hear it running if I only ever get it going on a low RPM setting, for example. Which I know is unlikely as if I can get it going at all, I can hopefully set it to loudest. But the fan is under the heatsink so we cannot see if it's running or not. Long term, it would be brilliant to get the processor temps and fan RPM outputting to the video player overlay screen. It has a more specific name than that, which I'll add in later. I know it's probably strange to be asking about such a means for checking if the fan actually runs. Under the exact scenario at present, we have nno Python-driven means to 'talk' to the device mount (/dev/ttyUSB0) but should I find myself almost falling asleep, in the dead of night (as it were) but having possibly found a way to 'talk' to that device mount, would be great to have a means of confirming the fan is running ... especially if the overhead split system A/C needs to be running so it will make the sound even harder to hear! Yes, at it's present location, temps are a non-issue really as I love cool room temperatures and the unit is directly under a split-system A/C head unit. But it's not this scenario I'm building for. The end user loves a bit more warmth than I do and their A/C, if on, is not over the top of the unit.

inspector71 commented 6 months ago

Oh I forgot to add, I just installed 9.2.8 and the power button worked without any modifications, so if yours doesn't either the button is broken or you hard shut it off. IF the button is red and pressing/holding it down does nothing it's probably the pin. IF it's off completely, then it's probably broken.

If it's colored, let me know and I'll take my case apart and try to take pictures of the pin thingy. Idk how old you are, but if you're old and been around computers since the 90's you probably remember hard drive master pins. It's that for the button, just find it and orientate it differently. if it's not apparent, don't mess with it.

But even then, an always off pin layout? that doesn't seem right.. I could be off about this lol sorry I'm all over the place

No need to apologise. Your enthusiasm and efforts are outstanding.

I'm familiar with messing around with GPIO-style pins and jumpers. No worries there.

I'll double check everything later today.

From memory, I never managed to get any shutdown script running, if that's necessary which it may not be. The way it works, again, if I'm remembering correctly but I'll double check later today ...

using the Kodi shut down option, Kodi and LE do shut down and the power button changes from blue to red
if I then tap the power button ... nope, I forget, will update later
if I then hold the power button ... nope, I forget, will update later
if LE/Kodi is frozen/locked up, and I hold the power button in (for what seems like at least 10 seconds but may be less) the hardware is powered down and thus causing the frozen LE/Kodi to disappear, of course. The power light will then go red.

For the scenario I have to meet, I think, the priorities for the power button are:

When LE/Kodi freezes (all software freezes at some point, it should be seen as inevitable) then "have you tried turning it off and on again" needs to be possible. In all previous Pi-based scenarios, that has only been possible by yanking the power lead or flipping the power switch, if you have one. Getting a case with a proper front-facing power button was therefore critical
Optimally, although it's going to be quite rare for the unit to be fully off, when it is shut down via Kodi, the light would turn off completely. I'm not sure there's any benefit to having it remain red but that sure creates some annoyances with the people who will be around / directly using the unit rather paranoid about stand by power consumption and also tend to use device lights / or visible state indicators, as one of the first things they check after a power outage. If the power comes back on and the DeskPi power button is red because it's got power and is defaulting to a power-available, but system is off, scenario, that's more than fine. That would be actually helpful. But other than that, I cannot think of a need to have the power button illuminated when the unit has power available but is not operating.

inspector71 commented 6 months ago

Okay so i figured out what's going on. (i should have remembered)

compiled from various comments on this topic The normal RPi4 has an USB host controller on the PCIe bus, the DWC2 driver is required for the SoC internal USB host. So this isn't required for the ordinary RPi4.

By using otg_mode=1, this will give you an XHCI controller instead of the DWC2 one.

The kernel config option doesn't get introduced until libreelec 10(ish), I think my initial test was on LibreELEC-RPi4.arm-9.95.4. I wasn't able to get it to install on 9.0.0 , 9.2.6 , 9.2.7 , or 9.2.8 during that initial test.

So there are 2 options:

Option 1 you're using a build that you never updated from. Something between 9.2.8 and 10.0.4

I don't have that available to me, so you'd have to test to see if adding otg_mode=1 to your /flash/config.txt file gets this code: python -m serial.tools.list_ports to show /dev/ttyUSB0

If you can get this part to work, it will get interesting because like I said I don't have that build so we'd have to work together through only your machine lol Shouldn't be too hard tho.

Well, I've added otg_mode=1 to /flash/config.txt and rebooted.

Then I ran lshw and compared it with the output before switching on otg_mode=1.

lshw sees new devices when otg_mode=1 is included in /flash/config.txt:

 *-usbhost:0
       product: xHCI Host Controller
       vendor: Linux 4.19.127 xhci-hcd
       physical id: 1
       bus info: usb@3
       logical name: usb3
       version: 4.19
       capabilities: usb-2.00
       configuration: driver=hub slots=1 speed=480Mbit/s
  *-usbhost:1
       product: xHCI Host Controller
       vendor: Linux 4.19.127 xhci-hcd
       physical id: 2
       bus info: usb@4
       logical name: usb4
       version: 4.19
       capabilities: usb-3.00
       configuration: speed=5000Mbit/s

... however, there is still no sign of /dev/ttyUSB0 :(

or

Option 2 you're using the only official leia version which is 9.2.8. If you have this version, it's also about to get interesting.

I'm using LE 9.2.6 ...

Operating system: LibreELEC (official): 9.2.6 (kernel: Linux 4.19.127)
Build: Kodi 18.9 (18.9.0) Git:leia_pi4_18.9-Leia
Compiled: 2020-10-24

That is according to Kodi System Information in Settings.

More than happy to try 9.2.8 if it likely to help. Have done in the past but AFAIK it's just a DRM module update.

Also:

cat /sys/firmware/devicetree/base/model

Raspberry Pi 4 Model B Rev 1.2

Unsure but that might be relevant.

You have to rebuild Kodi and add back in the code.

What code? A kernel config?

Someone made a comment saying:

I didn't recompile LibreELEC to remove the DWC2 driver but I verified in /sys that it is unused.

So I would assume that the capabilities are there, they were just removed from the config file.

So you'd have to teach me or yourself how to build Kodi. I have tried it before, but was completely confused and was never able to actually build anything or understand any of the changes. AFAIK I think you have to fork off the libreelec repo at the timeframe you want and then use that as the base for the rebuild. You just make your changes and then recompile it back together.

The longshot option, is being able to find an alternative config option that turns on the serial port.

I wish there was clear explanation as to what all of these do: dtoverlay=dwc2, dr_mode=host , otg_mode=1, CONFIG_USB_DWC2=y, and CONFIG_USB_DWC2_HOST=y

There's probably a kodi/libreelec doc in the github files somewhere that talks about them. but idk

Presumably otg_mode=1 means switch a USB port into On The Go (OTG) mode.

However, I took the daughter board off and had a look at the hardware again. There's only two wires going to the fan: positive and negative power wires. Can you confirm the fan actually works? Because I'm not sure how a USB-C port influences the fan speed via what is just two power leads. I know it uses PWM but does it simply lower the power to the fan, thereby lowering the speed? I've seen other fans with a third wire in the past. Always presumed that was for communicating with it. How many wires does your fan unit have?

inspector71 commented 6 months ago

I got the fan working :)

jojobrogess commented 6 months ago

I got the fan working :)

That's freaking awesome! You have to let me know how you did it

Like I said in one of my other previous comments, I started re-writing the addon. I'm on my 2nd or 3rd iteration now, and I still have a lot to go before it's completed but I've been able to learn a lot more about python in this attempt and I think I've created a better implementation than the original.

I can't seem to find a libreelec 9.2.6 download link, at least not for rpi4. The second I know I won't be sending you completely broken code, I'll send you the updated addon. Unless you want it now

TLDR; you don't have to read the next part, it's just talking about the functionality of the addon and some changes I've made.

#################################################################################################

Original: To install deskpi, user had to press install from settings page for every service(rpitools,systemtools, pyserial, deskpi). user set settings in setting page then had to run script, script would get user settings and then send them to the fan controller. (THIS DIDN'T WORK, the fan driver didn't work but the script would re-run the necessary code to get it to work so it ran and the fan driver didn't have bad code so it didn't throw an error; I don't think it dynamically controlled anything. User settings ran through driver once to get set and then never ran though again, so if the temp goes up or down fan speed didn't change.)

Re-write: Spent 2 days trying to create a window/windowdialog to be able to set user values to conf file without need to apply values or run a service to constantly check file/run getSetting(). Created bare bones window, noticed it was a couple hundred lines of code spanning 2 files and all I had was a black screen with 2 buttons and 1 slider. Gave up on that idea.

Completely removed shell code, re-wrote everything in python, changed file locations to addon_data dir. Addon ran a monitor to check installation, then ran the installer if not installed then integrity check after. Side services(rpitools,etc) all added into installer, removed individual install prompts. Addon then ran another service after installation check passed to repeatedly check user settings. when user set values in settings page, second service would then write new values to conf. fan driver read the conf file every 30 seconds and used those values. (That's 3 separate monitors, two running consecutively and one running concurrently.) (I think that's excessive, this is a stupid case fan addon, it doesn't need to be rocket science lol) (this is basically how argon wrote their addon)

still working on

RE-re-write: Remove all monitors except main driver, because that has to run as a service regardless. Add in "parser"(the thing that grabs user settings and saves them to .conf for driver use) to driver fan service, so user doesn't have to apply settings/separate service running beside driver service. Remove .conf, save settings to a list for function instead. (look into "threading" driver service into two parts) (possibly add in more dynamic fan logic) Change file locations to be addon dir only. (if I hurry through this, test timeit() outputs for coding snags.)

Remove installation_check as a service and Re-add to settings. Check re-written uninstaller, create uninstaller integrity check. Add in logic to remove old install file locations to installation_check

Add uninstaller to settings page(either next to installer or in "dev tools" page) Add in "Dev tools" settings page with advanced check options = check dekspi service status, check installation, uninstallation integrity. (don't know how to do this yet, but I'm almost sure I can pipe in the outputs to a notification/dialoag output)

Re-test IR functionality.(make sure I set the correct config flags...) (figure out how IR works lol, more than likely I'll skip this until after the addon is finished) Re-write settings.xml to new style. Replace screenshots in media.

Completely remove addon, reinstall libreelec. Test .zip install and addon mechanics from scratch.

Send it to you, check 9.2.6-9.2.8 for compatibility. (if it needs different code) Add in logic to check versioning, add in logic for different versions

Check 11.0.3 for comparability. (if it needs different code) Add in logic to check versioning, add in logic for different versions

Official Re-release. Update github and Update deskpi issue comment page and create/update libreelec forum post.

inspector71 commented 6 months ago

I got the fan working 😀

That's freaking awesome! You have to let me know how you did it

Well, I'm really sorry, you might be a little disappointed, maybe a lot.

But I realised that software was the very long way around.

There's a perfectly good power source right next door to the mega complicated DeskPi socket.

I just removed the DeskPi GPIO re-routing option as I'll likely never use it. In fact, that's where they put the IR receiver and I've never tried it but I cannot imagine it ever working effectively in that location. Plus, the GPIO pins exiting the case horizontally at the back does not seem like a very useful idea either. I guess someone could get a very short ribbon cable - if they exist but I've never seen one - and connect it to something that sits in the open on top of the case. But the rear exiting choice it's not HAT friendly, that's for sure. Regardless, I'll likely never need full GPIO access unless I go for a UPS, which may be on the cards, but I'll think about that down the track.

Nope, when there's perfectly fine pins and wires with female connectors on them, emanating from the fan, why bother powering it via the DeskPi board and all the software nightmare? Sure, will / would be good to vary the speed to adjust for noise. The sort of loads the system will be under should not require heavy cooling so excess noise is not ideal. But compared to no functionality at all, powering it via GPIO makes perfect sense.

So, I merely unhooked the fan, popped the wires out of their plastic female shroud, rotated the fan to give me more length on the wires to reach the GPIO pins, and connected them to the GPIO power source :)

Initially used the 5V pin 4 but the fan must have been running full speed, or high enough RPM to be more audible than I'd like. But it shed 15C off the processor temps :) From 45C down to about 30C. That was at idle and without utilising the dedicated h264 H/W acceleration. So the ARM cores were pumped a bit harder to churn through the x265 encoding. But I'm not talking about high bitrate, 4K video with many-channel audio. Nope, just 1080p, probably not that high bitrate, and many-channel audio. Nevertheless, that will be the sort of max content the unit will be playing, so it's representative.

Then I tried the 3.3V and it is significantly queiter for only a one or two degree reduction in cooling. Cores ran at about 33C instead of 30-31C. Which is perfectly acceptable and the noise is much better.

I don't know if your addon could be adapted for GPIO but I know there's the RPi.GPIO library. However, although it's not yet in action in the intended environment it will be operating in, and those temp readings are without the case surrounding the gubbins and no environmental room heating involved, I'm hopeful it's going to be at least much better than anything I've had in place before. Given there's been zero cooling involved in the past, that's not hard though :)

Like I said in one of my other previous comments, I started re-writing the addon.

I'm on my 2nd or 3rd iteration now, and I still have a lot to go before it's completed but I've been able to learn a lot more about python in this attempt and I think I've created a better implementation than the original.

That's sensational. I've been wanting to write some addon functionality for Kodi for a very long time. Different to hardware needs but still important.

For example, Kodi has no idea of how many episodes are in a series. No idea! Only how many episodes it's found and ingested into it's Library. That's not very helpful when users aren't all over their Sonarr or TVDB, and why should they have to be? So, assuming the Sonarr API provides this detail, which I think it does, I'd like to add that data into Sonarr. Therefore, if Sonarr misses episodes, as it can do, the user will have that information in the Kodi interface. Can probably do more from that point.

Another idea is allowing users to nominate if they want to continue watching a new show. Or maybe not, if it's not to their taste.

So it will be great to read about your efforts as I've not had any chance to connect with someone writing addons before and there's the issue of no Python experience, to date!

TLDR; you don't have to read the next part, it's just talking about the functionality of the addon and some changes I've made.

Absolutely will be reading up on this ASAP! Was hoping you would keep in touch :)

In the meantime / in parallel perhaps, I'm going to revisit your power button and front USB posts. My post about that was false. I didn't get it from memory so that needs correcting.

jojobrogess commented 6 months ago

Nope, when there's perfectly fine pins and wires with female connectors on them, emanating from the fan, why bother powering it via the DeskPi board and all the software nightmare?

haha. where there's a will there's a way

I don't know if your addon could be adapted for GPIO but I know there's the RPi.GPIO library.

I would assume there are multiple addons already built for libreelec considering most fans for the rpi4 are gpio.

But the one I do know of is the argon one: https://github.com/Argon40Tech/libreelec_package_argonforty-device/blob/master/source/resources/lib/argon.py#L49

idk how the RPi.GPIO library works and I can't seem to find direct docs for libreelec, you could try to copy out the addon and look at the code to see how it works. I would assume there is only 1 or two ways a fan can be powered through gpio. So you might not have to change anything from an already released addon. If anything all you would have to change would just be the gpio layout for power (or however it works).

But it could totally be added to the Deskpi addon, just add a boolean for serial vs gpio installation in settings.

Create settings.xml control id's for .getSetting() variable in driver, or use existing id's(temp1speed1**). Then create a driver that grabs .getSetting() variables and controls the fan speed based off of cpu temp. Create a very small service file to tell libreelec to autostart the fan and use that driver. Create an "installer" to move the .service files from addon directory to /storage/.config/system.d/ and change file permissions to 644 and enable start reload the new service.Then create an uninstaller to do the opposite. Add that to settings.xml as well.

Sounds worse than it is. You can do it in 4 files: installer, driver, service, uninstaller. Add in 2-3 more files: addon.xml, settings.xml, and maybe a strings.po. If you use strings.po for notifications, add in a utils.py file for that code. And it's a full fledged addon lol

In the meantime / in parallel perhaps, I'm going to revisit your power button and front USB posts. My post about that was false. I didn't get it from memory so that needs correcting.

From memory, I never managed to get any shutdown script running, if that's necessary which it may not be. The way it works, again, if I'm remembering correctly but I'll double check later today ...

using the Kodi shut down option, Kodi and LE do shut down and the power button changes from blue to red if I then tap the power button ... nope, I forget, will update later if I then hold the power button ... nope, I forget, will update later if LE/Kodi is frozen/locked up, and I hold the power button in (for what seems like at least 10 seconds but may be less) the >hardware is powered down and thus causing the frozen LE/Kodi to disappear, of course. The power light will then go red.

For the scenario I have to meet, I think, the priorities for the power button are:

When LE/Kodi freezes (all software freezes at some point, it should be seen as inevitable) then "have you tried turning it off and on again" needs to be possible. In all previous Pi-based scenarios, that has only been possible by yanking the power lead or flipping the power switch, if you have one. Getting a case with a proper front-facing power button was therefore critical Optimally, although it's going to be quite rare for the unit to be fully off, when it is shut down via Kodi, the light would turn off completely. I'm not sure there's any benefit to having it remain red but that sure creates some annoyances with the people who will be around / directly using the unit rather paranoid about stand by power consumption and also tend to use device lights / or visible state indicators, as one of the first things they check after a power outage. If the power comes back on and the DeskPi power button is red because it's got power and is defaulting to a power-available, but system is off, scenario, that's more than fine. That would be actually helpful. But other than that, I cannot think of a need to have the power button illuminated when the unit has power available but is not operating.

Since you can't communicate through the serial port, the power button LED switching itself after a software shutdown won't work, afaik. I can only get it to switch by creating a service to mimic a shutdown, (if you run it it shuts down libreelec), and then whenever there's already going to be a shutdown it runs to get the power button to go back to red. (It was Deskpi's implementation) But you have to have serial to get : ser.write(b'power_off') to work.

During all of my testing, and the current release, and up until just right now I never had serial properly imported for the power button:
https://github.com/jojobrogess/script.deskpifanservice/blob/625b0dd54f540c2927f98373ec2a2f4d0d412ba3/resources/lib/deskpi_installer.sh#L70 https://github.com/jojobrogess/script.deskpifanservice/blob/625b0dd54f540c2927f98373ec2a2f4d0d412ba3/resources/lib/deskpi_installer.sh#L136 I must have gotten it to work in testing but didn't check it prior to release. When I software shutdown now, it returns the LED to RED.

I think it's:

If off, single tap to power on.
If on, hold button for 3 seconds to power off.
If off but has Blue LED's, hold for 3 seconds to get Red LED's then tap.
I haven't experienced a freeze while using the device so I don't know how many seconds to restart a lockout.

(I don't even use this rpi or case fan at all, never actually used it with the case fan or libreelec.) (bought it on a whim lol )

I'm not sure there's any benefit to having it remain red but that sure creates some annoyances with the people who will be around

I completely agree. But I don't think that would be possible. It's fur sure hard connected in, so the internal firmware is listening for the power_off serial command. The unit is designed to be physically turned on and off and software is secondary.

inspector71 commented 6 months ago

GPIO-powered, heatsink-embedded, fan

Nope, when there's perfectly fine pins and wires with female connectors on them, emanating from the fan, why bother powering it via the DeskPi board and all the software nightmare?

haha. where there's a will there's a way

I'm actually embarrassed I didn't think about it earlier :)

There's also a header I noticed that I didn't know what there / hadn't remembered, which is curious. 4 pins just near the power button.

Overnight I left the reverse A/C above the (exposed, out of the case) DeskPi unit on heat to dry some clothes. Set to 21 degrees. I checked the core temp, admittedly it had been doing nothing, and it was still just low 30s !!! Even with the fan operating at a very quiet 3.3V power. More than pleased with that.

I don't know if your addon could be adapted for GPIO but I know there's the RPi.GPIO Python library.

I would assume there are multiple addons already built for LE considering most fans for the RPi4 are GPIO.

But the one I do know of is the argon one: https://github.com/Argon40Tech/libreelec_package_argonforty-device/blob/master/source/resources/lib/argon.py#L49

IDK how the RPi.GPIO library works and I can't seem to find direct docs for LE, you could try to copy out the addon and look at the code to see how it works. I would assume there is only 1 or two ways a fan can be powered through GPIO. So you might not have to change anything from an already released addon. If anything all you would have to change would just be the GPIO layout for power (or however it works).

To be honest, I'm not certain I will need to modify the speed of the fan. It will probably depend on the end user's preferences. If they are watching a bunch of slow, moody, quiet drama ... perhaps like murder mysteries ... and the fan is audible, that might not be ideal. But I doubt this will be the case. That's not to say I don't want some fancy JoJo addon goodness to give me that possibility though :)

Regardless of how and what I find, code wise, I would want to contribute it to the JoJo add-on goodness :)

Just have to get me some of that goodness after all your efforts!

I feel a bit like I've pulled the rug out from under your efforts but it didn't seem like I had a lot of choice, to be honest. I would have, and may in future, considered building my own custom LibreELEC 9.2.*, possibly with some advice/help of a good friend. I may still go that route. Especially if I cannot figure out how to enable the front USB ports, for example. However, I'm still considering the OSMC option as well. Having a full / proper Debbie foundation may or may not boot a little slower, take up more system resources, but as long as the Kodi experience itself works reasonably, is snappy enough, there's a couple of needs that would be more straightforward to build into a fuller Debbie base.

Thing is, as your work is both DeskPi and Kodi oriented, Fairly confident I can switch from LE (BusyBox) to OSMC (Debian) and still use / contribute to your addon!!! Brilliant :)

Honestly, getting a near-legit storage option on to a Pi has been the big deal I've been looking for since the platform was first created. I don't like USB as a bus. Just doesn't feel right despite the uasp mode. But short of grabbing a Pi5 and finding some other PCIe scenario, of which AFAIK I've not seen one yet, DeskPi is the way to go. Now that I finally have some sort of cooling scenario for cores that, after all, do actually run at 1.5 Ghz which is no slouch speed, options to turn this into somewhat more than a media centre alone, seem to have finally opened up!

But it could totally be added to the Deskpi

I think this needs a renaming to LibreELEC for DeskPi - powered by Jojo. Or maybe DeskPi for LibreELEC - powered by JoJo.

Anyway, something to give you well overdue credit. :)

addon, just add a boolean for serial vs GPIO installation in settings.

Create settings.xml control id's for .getSetting() variable in driver, or use existing id's(temp1speed1**). Then create a driver that grabs .getSetting() variables and controls the fan speed based off of cpu temp. Create a very small service file to tell libreelec to autostart the fan and use that driver. Create an "installer" to move the .service files from addon directory to /storage/.config/system.d/ and change file permissions to 644 and enable start reload the new service. Then create an uninstaller to do the opposite. Add that to settings.xml as well.

Oooh boy am I going to get into this soon as! Your headspace is deeply into this, perfect timing to leech all your knowledge, LOL.

Sounds worse than it is. You can do it in 4 files: installer, driver, service, uninstaller. Add in 2-3 more files: addon.xml, settings.xml, and maybe a strings.po. If you use strings.po for notifications, add in a utils.py file for that code. And it's a full fledged addon lol

Power button

My recall is completely vague but I started re-reading your thread in the Deskpi issue. It's a long'un!!! So I've yet to finish reading it. However, as the phrase goes, I could have sworn I read that you got the power button to behave as I want it to. So I'll keep digging to finish that.

In a previous post above, I completely messed up my description of the current scenario for me,. Here's what is currently happening.

Kodi shutdown function: power button remains blue.

Same as if LE is booted up and running. Not meaningful at all.

Holding the power button for a few seconds: switches the power button to red.

Seems to switch the unit into a different state. Power button turns red, internal Pi lights turn off.

Switch off the PSU at the power point: power button light turns off

I basically don't see the need for a the red light state. I would like the entire unit to shut down, like it does when the wall plate switch is flipped. All lights off.

For the scenario I have to meet, I think, the priorities for the power button are:

When LE freezes ( all software freezes at some point, it should be seen as inevitable ) then "have you tried turning it off and on again" needs to be possible. In all previous Pi-based scenarios, that has only been possible by yanking the power lead or flipping the power switch, if you have one. Getting a case with a proper front-facing power button was therefore critical

Optimally, although it's going to be quite rare for the unit to be fully off, when it is shut down via Kodi, the light would turn off completely. I'm not sure there's any benefit to having it remain red but that sure creates some annoyances with the people who will be around / directly using the unit rather paranoid about stand by power consumption and also tend to use device lights / or visible state indicators, as one of the first things they check after a power outage. If the power comes back on and the DeskPi power button is red because it's got power and is defaulting to a power-available, but system is off, scenario, that's more than fine. That would be actually helpful. But other than that, I cannot think of a need to have the power button illuminated when the unit has power available but is not operating.

Since you can't communicate through the serial port, the power button LED switching itself after a software shutdown won't work, afaik. I can only get it to switch by creating a service to mimic a shutdown, (if you run it it shuts down libreelec), and then whenever there's already going to be a shutdown it runs to get the power button to go back to red. (It was Deskpi's implementation) But you have to have serial to get : ser.write(b'power_off') to work.

Fair enough, thanks for that insight.

I am still interested in solving the mystery of how to get the USB-C port, and (virtual?) /dev/ttyUSB0 serial port, running and usable. I guess it's possible this would happen without any messing about if I try OSMC which may just include the driver(s) required by default. Hopefully I'll get a chance to test that today. Albeit I won't be sacrificing the functional-enough (for my needs, ATM, not the end user's so much) SSD-stored LE installation I have going nicely. Rather, I'll have to try OSMC from ye olde SD card. Don't expect that would be a problem though ... unless I can't get the Pi boot order flipped. That requires an entirely separate SD card image / installation, doesn't it? Ridiculous.

During all of my testing, and the current release, and up until just right now I never had serial properly imported for the power button:

https://github.com/jojobrogess/script.deskpifanservice/blob/625b0dd54f540c2927f98373ec2a2f4d0d412ba3/resources/lib/deskpi_installer.sh#L70

https://github.com/jojobrogess/script.deskpifanservice/blob/625b0dd54f540c2927f98373ec2a2f4d0d412ba3/resources/lib/deskpi_installer.sh#L136

I must have gotten it to work in testing but didn't check it prior to release.

Yeah, I have very poor memory these days but I swore you got it working at some point.

When I software shutdown now, it returns the LED to RED.

I think it's:

If off, single tap to power on.

Same here, but I Kodi software shutdown doesn't get me to that red state.

If on, hold button for 3 seconds to power off.

If off but has Blue LED's, hold for 3 seconds to get Red LED's then tap.

That's what I have to do after Kodi software shutdown fails to switch the light to red.

I haven't experienced a freeze while using the device so I don't know how many seconds to restart a lockout.

I've only experienced freezes very rarely. I think it probably takes upwards of 10 seconds of holding the power button to kill LE.

(I don't even use this rpi or case fan at all, never actually used it with the case fan or libreelec.) (bought it on a whim lol )

I'm not sure there's any benefit to having it remain red but that sure creates some annoyances with the people who will be around

I completely agree. But I don't think that would be possible. It's fur sure hard connected in, so the internal firmware is listening for the power_off serial command. The unit is designed to be physically turned on and off and software is secondary.

if that's the limitations, so be it. Will see how I go if I ever get my headspace right into it.

inspector71 commented 6 months ago

Investigations continue 😊

Overnight, tried latest OSMC to get a perspective of whether it's suitable for general Kodi use, relative to LE. Also to see for myself how another, more recent, kernel / kernel config works with the DeskPi hardware. To date, haven't experienced that in detail for myself.

Lots to report, including surprises like OSMC not including lshw or lsusb but apt install lshw usbutils took care of that. Nor Milhouse's bcmstat.sh.

More to come ...

jojobrogess commented 6 months ago

Investigations continue Overnight, tried latest OSMC to get a perspective

OSMC, oh that's awesome. I never thought about that version of Kodi.. I wonder how much different it is than libreelec.. I mean you said but apt install lshw usbutils took care of that which is crazy, I hope that means it's more open than Libreelec.

It would be pretty freaking cool to offer 2 OS's for this addon, ESPECIALLY if this can solve your issue with needing a VNC capable Kodi. Please keep me posted. This would be a serious win.

Ohh and Merry Christmas bro!

inspector71 commented 6 months ago

Investigations continue Overnight, tried latest OSMC to get a perspective

OSMC, oh that's awesome. I never thought about that version of Kodi.. I wonder how much different it is than libreelec..

Quite a bit. It's based on a full Linux distribution: Debian. Whereas LE is based on BusyBox. I mean you said but apt install lshw usbutils took care of that which is crazy, I hope that means it's more open than Libreelec.

It's a full distro that boots straight to Kodi. I've not used it as my 'daily driver' ever before but it might suit a related need I'd previously thought would have to be addressed separately. It would be pretty freaking cool to offer 2 OS's for this addon, ESPECIALLY if this can solve your issue with needing a VNC capable Kodi.

I can't think of any reasons why modding the add-on for OSMC would not be a lot easier. I'm not expert though. Please keep me posted. This would be a serious win.

Woohooo, glad you are fired up :)

About to flip over to running it again to identify what the actual driver is that is missing from LE. If, in fact, that's the context I need to investigate.

Ohh and Merry Christmas bro!

You too!!

inspector71 commented 6 months ago

To keep the existing, most familiar option of running LE, rather than, if using OSMC ...

Sourcing / packaging installing the dispmanx_vnc software separately
Sourcing / packaging some of the packages provided by the LE-built add-on bundles
Switching to a completely unfamiliar OSMC scenario
Shoehorning an appropriate version of Kodi, that supports the dispmanx API, in a previous OSMC build, into an installed scenario

I'm continuing to investigate compiling my own build.

On the replaced version of the lower DeskPi Pro board, the chip LE 9.2.* does not recognize is a WinChipHead CH340G. Made by Qinheng Microelectronics in Nanjing, Taiwan.

usb-winchiphead-usb-serial-ch340-ch341

Have found a reference to a CH341 ...

CONFIG_USB_SERIAL_CH341=m

... in the LE build files

Don't know why everyone was throwing DWC* references around because the USB hub chip on my replaced lower DeskPi Pro board is a Genesys Logic GL852G. Perhaps the DesignWare Core drivers work with the GL852G well enough. However I would be preferring a driver made specifically for that chip. That said, it does not seem to be a problem we have to think about because, thankfully, otg_mode=1 sorts that out ... even in LE 9.2.*.

jojobrogess commented 6 months ago

^^^^^^^^^^^^^^^^ What? lol All of that is foreign to me.

... but I cannot copy/paste from the ruddy VM at present. VirtualBox, you're letting me down!

I get needing to vm into libreelec to watch stuff, but to code ssh would be best. Just use scp to copy the files from your computer over. AFAIK that should work. You might get an error if you try to save/create/write to anything outside of /storage.

I've tried multiple times but I can't seem to install OSMC, I'm guessing it's me or the case. The install process is weird.

I'm pretty sure I just finished rebuilding the addon.

I just have to re-install 10.0.4, and reinstall everything and test every option a 3rd time just to make sure I didn't miss anything.

inspector71 commented 6 months ago

I can test your shiny new add-on if you like?

inspector71 commented 6 months ago

^^^^^^^^^^^^^^^^ What? lol All of that is foreign to me.

Sorry about that. I was trying to determine which driver LE 9.2.* is seemingly missing so I can incorporate it into the custom build. One method I'd used before is to read the labels on the microchips.

Perhaps I failed to write a conclusion.

The 'serial convertor' device ...

Nevermind.

Sorry, maybe it was just off topic.

I've lost any confidence I might have had that I can make a custom build.

I'll help with testing your add-on, if I can.

jojobrogess commented 6 months ago

I can test your shiny new add-on if you like?

You'll be the first person other than me. I just keep breaking stuff by adding in checks and "features". The control driver is quite excessive now, and shouldn't break, but it's over 7kb of hand written code almost 200 lines. I might have to separate out the functions from the main class into a new file and import them directly above their respective modes(if that's even possible) so that everything doesn't have to get loaded in, just what's needed when it's needed. If not I still might have to cut down on the overall size by splitting it in two.

Beyond just the fan driver, I did stuff in this that I've never done before. And learned so much I'm actually amazed with myself and I'm not even done yet. It's funny looking back at the original code now. Mann did I do it wrongg. lol I don't know if I'm doing it right now, but I do feel better with what I'm about to release.

On what you were saying before, idk what dispmanx_vnc is. Or the chip that deskpi used, or about anything hardware related(or even software related as you can tell lol)

So I couldn't really follow:

On the replaced version of the lower DeskPi Pro board, the chip LE 9.2. does not recognize is a WinChipHead CH340G. Made by Qinheng Microelectronics in Nanjing, Taiwan. usb-winchiphead-usb-serial-ch340-ch341 Have found a reference to a CH341 ... CONFIG_USB_SERIAL_CH341=m ... in the LE build files Don't know why everyone was throwing DWC references around because the USB hub chip on my replaced lower DeskPi Pro board is a Genesys Logic GL852G. Perhaps the DesignWare Core drivers work with the GL852G well enough. However I would be preferring a driver made specifically for that chip. That said, it does not seem to be a problem we have to think about because, thankfully, otg_mode=1 sorts that out ... even in LE 9.2.*.

My understanding for the DWC stuff in the config files was due to the code already being in the original Deskpi install.sh for the raspberry pi os and I saw yoyo's posts asking questions about it. I think talking about XHCI or something. I'm a little too deep in my kodi/python man pages brain now to remember.. I think argon might have been using something similar as well, so I just followed suit.

Sorry about that. I was trying to determine which driver LE 9.2.* is seemingly missing so I can incorporate it into the custom build. One method I'd used before is to read the labels on the microchips.

From my understanding it's not missing a driver, it's missing the config flags meant to switch it to the the other driver. The driver was left in, but the config flags were removed so plebs like us couldn't try to use it(for a good reason more than likely).

The comment i saw were these:

kernel configs should be changed with make menuconfig or by running make oldconfig and answering the questions after changing some option(s). Often kernel options enable other options, eg when enabling CONFIG_USB_DWC2=y the full kernel config diff would look like this:

Or I could be wrong, he could have been implying that the user could import the new driver into the older system.

on Dec 6, 2020 I haven't tried this myself yet, but as the last beta bootloader added support for USB booting using the XHCI controller - see https://github.com/raspberrypi/rpi-eeprom/commit/3702e706aff73a0b0ad545223f9aa4b7d98aeb5c - chances are good that it might just work fine (at least on the latest master builds, which contain latest kernel and firmware)

https://github.com/raspberrypi/rpi-eeprom/commit/3702e706aff73a0b0ad545223f9aa4b7d98aeb5c 2020-11-24 BCM2711 xHC boot support - BETA

Add support for booting from the BCM2711 XHCI controller which is the USB-C socket on Pi 4B / Pi 400 and the type A sockets on Compute Module 4 IO board. The controller only supports USB 2.0 and the primary usage is for USB-MSD support on CM 4 boards without requiring a PCIe XHCI controller. To use this add '5' to the BOOT_ORDER in the EEPROM config for BCM_USB_MSD boot. This requires the latest rpi-update firmware. If start.elf is loaded via the BCM2711 XHCI (BOOT_ORDER 5) then the config.txt otg_mode setting will be set to 1 so that the OS can continue booting using the BCM2711 XHCI. This means that the device/gadget mode is not available when booted in this mode and there is no support for switching back to the DWC2 controller from the BCM2711 XHCI controller.

Both of those were from the same issue from 2020 issue: 4722

And then from pull 5249 :

With CONFIG_USB_DWC2=y and dtoverlay=dwc2,dr_mode=host added to /flash/config.txt the two USB host ports on the Raspberry Pi Compute Module 4 IO Board actually work. There doesn't seem to be a config.txt filter specific for the Compute module 4, so I didn't add the config.txt snippet to the image.

^^^ FOR COMPUTE CM4 BOARD

HiasofT The normal RPi4 has an USB host controller on the PCIe bus, the DWC2 driver is required for the SoC internal USB host. So this isn't required for the ordinary RPi4.

I'd highly recommend giving otg_mode=1 a try instead, this will give you an XHCI controller instead of the rather limited DWC2 one. See also here https://github.com/LibreELEC/LibreELEC.tv/issues/4722#issuecomment-739526268

on Mar 15, 2021@ HiasofT Indeed, just adding otg_mode=1 also makes the USB ports work. I didn't recompile LibreELEC to remove the DWC2 driver but I verified in /sys that it is unused.

This is about the extent of my knowledge on the subject.

Sorry, maybe it was just off topic. I've lost any confidence I might have had that I can make a custom build. I'll help with testing your add-on, if I can.

Not off topic, just outside of my range lol

Don't lose confidence just yet. I haven't gotten around to trying to do a build yet. And how'd the OSMC trial go? does it have that dispmanx_vnc thing?

I tried installing OSMC again, but still can't get past the install process while the deskpi is connected. I'm honestly starting to think that it's the micro sd card thing for the companion board, because I was able to install it on my other RPI but when I went to switch over the micro SD and usb to the deskpi RPI it never worked again, probably not a smart idea with the whole uuid stuff. My next try I will try with the caseless rpi and then put the case on that one, rather than switch. It just sucks because I can only get the installer to run once, after that I have to reinstall it and refresh my USB to get it to run again. idk what is going on.

What was you specific reasoning behind needing libreelec being on 9.2.* again? My understanding was that there was a vnc driver change that ruins your playback or something. Is that correct? I'm sure i've asked you this multiple times before, so sorry

jojobrogess commented 6 months ago

Took me a little bit to get everything sorted out, but I just updated everything. Let me know what you think if you get a chance to look at the code

inspector71 commented 6 months ago

Took me a little bit to get everything sorted out, but I just updated everything. Let me know what you think if you get a chance to look at the code

Sensational. I've been hammering away trying to figure out how to get LE 9.2.6 supporting this hardware. Friend and I have been relaying emails to and fro daily on it. Still looking into it. You know when you get so far into a project, you're not sure if it worth pursuing it further, but you're so far into the effort, you want some return? We're in that phase :) Congrats on your code. I'll absolutely take a look ASAP.

inspector71 commented 6 months ago

I can test your shiny new add-on if you like?

You'll be the first person other than me.

Woohoo!

I just keep breaking stuff by adding in checks and "features". The control driver is quite excessive now, and shouldn't break, but it's over 7kb of hand written code almost 200 lines.

I guess that's the nature of developing, to some extent. Breaking stuff teaches us how to tame these runtime beasts, haha. Nothing to beat yourself up about.

I might have to separate out the functions from the main class into a new file and import them directly above their respective modes (if that's even possible) so that everything doesn't have to get loaded in, just what's needed when it's needed. If not I still might have to cut down on the overall size by splitting it in two.

I admire your interest in optimising the structure of your code. Trick with that might be knowing when to let it sit as it is. Something I've always found difficult. People would look at me cleaning up the spacing of code as I read it. Column alignments, giving variables meaningful names when other failed to, and sometimes have a go at me about it. However, it was almost always easier for me to read properly, think more easily about it and I strongly expect the next dev to come along, if there would be one ever, would benefit. If that dev was me, excellent. Hard enough looking at code and having that "I wrote that?" moment ... until you re-familiarise with it.

Beyond just the fan driver, I did stuff in this that I've never done before. And learned so much I'm actually amazed with myself and I'm not even done yet.

Mate, that's fantastic! Excellent. Such moments don't necessarily happen all the time. Lap it up, you've earned it!

It's funny looking back at the original code now. Mann did I do it wrongg. lol I don't know if I'm doing it right now, but I do feel better with what I'm about to release.

I reckon it's similar to above. Knowing when to draw the line can be really hard. Great code is probably more often super iterative over stretches of time. However, I'm not advocating a release early and often model. Not convinced of that, either. Depending on the scenario, it's trying to find that skill of knowing when the code is ready.

On what you were saying before, idk what dispmanx_vnc is.

It's a server app providing VNC support via the RPI's undocumented DispmanX video API.

VNC allows you to connect to another computer and use it as if it was in front of you.

Or the chip that deskpi used, or about anything hardware related ( or even software related as you can tell lol

Well that's absolutely horse manure!

You've proven you can code in Python. You've given it a go and produced an end result within all the constraints of other people's APIs and parameters.

I can feel it's not necessarily your coding skills that are the tricky thing for you. It's confidence. A bit of self deprecation is probably good for the soul. Keeps us humble. However, if it gets in the way of giving ourselves due credit, possibly goes a bit too far?

)

So I couldn't really follow:

On the replaced version of the lower DeskPi Pro board, the chip LE 9.2. does not recognize is a WinChipHead CH340G. Made by Qinheng Microelectronics in Nanjing, Taiwan. usb-winchiphead-usb-serial-ch340-ch341 Have found a reference to a CH341 ... CONFIG_USB_SERIAL_CH341=m ... in the LE build files Don't know why everyone was throwing DWC references around because the USB hub chip on my replaced lower DeskPi Pro board is a Genesys Logic GL852G. Perhaps the DesignWare Core drivers work with the GL852G well enough. However I would be preferring a driver made specifically for that chip. That said, it does not seem to be a problem we have to think about because, thankfully, otg_mode=1 sorts that out ... even in LE 9.2.*.

How could you follow when it was more a matter of regurgitation of my thoughts, work in progress style? Haha.

I was just updating you on a stream of consciousness basis. No need to feel poorly if it was not overly clear.

My understanding for the DWC stuff in the config files was due to the code already being in the original Deskpi install.sh for the raspberry pi os and I saw yoyo's posts asking questions about it. I think talking about XHCI or something. I'm a little too deep in my kodi/python man pages brain now to remember.. I think argon might have been using something similar as well, so I just followed suit.

Yeah I noticed, after forgetting or trying to move on from dwc that using it is suggested in the DeskPi documentation. I had forgotten where I had seen it!

However, when it was not seemingly producing the results needed, My friend and I started looking elsewhere. Using more recent systems, with more recent dependencies like kernels etc, and simply adding otg_mode=1 to /flash/config.txt and then rebooting will enable the GL852G USB2 hub that seems to be wired to interface with the RPi4's USB-C port ... which usually just receives power from the PSU and does nothing else ... but can do more funky USB stuff. In the DeskPi Pro scenario, the RPi4's USBC-C port is being used to connect the GL852G USB2 hub chip, on the lower DeskPi Pro board, to the rest of the system.

This seems to be enough to enable the front USB ports in systems more recent than LE 9.2.6.

This also enables the CH340G USB to serial chip that is wired through the GL852G USB2 hub.

From there, I think the CH340G chip can be used to send commands to the power switch and the fan power port.

From my understanding it's not missing a driver, it's missing the config flags meant to switch it to the the other driver.

A module (driver) capable of supporting the CH340G chip - the USB to serial convertor chip enabling control of the fan (and perhaps power switch, I think) - is present in the LE 9.2.6 filesystem:

    modinfo ch341

                      filename: /lib/modules/4.19.127/kernel/drivers/usb/serial/ch341.ko
                      license:  GPL v2
                      alias:    usb:v1A86p5523d*dc*dsc*dp*ic*isc*ip*in*
                      alias:    usb:v1A86p7523d*dc*dsc*dp*ic*isc*ip*in*
                      alias:    usb:v4348p5523d*dc*dsc*dp*ic*isc*ip*in*
                      depends:  usbserial
                      intree:   Y
                      name:     ch341
                      vermagic: 4.19.127 SMP mod_unload ARMv7 p2v8

But the system doesn't seem able to use it which is not surprising because the only way the CH340G chip connects to the RPI system is via the GL852G USB2 hub that, for indeterminate reasons, LE 9.2.6 cannot use either.