tony013

No worries. I am already an adult. To be more precise, I'm already over 60 years old. To use your words, I was scared by the tone and expectations of you developers. It's the first forum I've experienced that was designed for developers and not for users (3 of 18 sections are for users). A beginner has to come to terms with that first.
You constantly write about how much effort the development is and that you want support - but when one is ready to cooperate, he will be left out in the cold.

It is not yet 3 months since I bought my first rockpi4. Before that I had no contact at all with such small parts- and for so, I don't know anything about its requirements or handling.
 
From there - my question was meant seriously. But I also do not have to impose myself.
I have almost reached my goals, so I am quite satisfied.

Hey, that looks very good!

Hi,
 
I did some more tests and it turned out, that there is little difference between LE and armbian legacy for x264 or avc movies - but I found no movieplayer, that worked half as good as armbian legacy with vc-1 movies.
Don't have that many movies with vc-1 but some much-loved like inception ...
 
I already wrote, that I use rockpi as movieplayer together with a beamer, so session selection of armbian legacy is suboptimal for me, as about 10-15% on top and bottom of the screen are invisible (outside of screen). Lightdm/xfce is so dumb, that icons in topbar will not be scaled to bar height, which works fine for second bar ...
Sadly I didn't find any other greeter, that runs on armbian and is more attractive like lightdm-gtk-greeter.
So I started to build my own, which took lot more of time than expected ...
 
any way - I finally have a working sample:

 
is uses gtk too, so it works with armbian.
 
I check the available sessions and if there's no session definition for kody-gbm, the kodi-button will be disabled (as in the screenshot taken from my desktop computer).
Font- and button-size have been increased for a screen distance of 3m approximately.
 
Last login will be cached, so user will be prefilled and hitting ENTER in the password field will login to the last session. Left most button starts kody and right most button the desktop.
 

Hi,
 
I did some more tests and it turned out, that there is little difference between LE and armbian legacy for x264 or avc movies - but I found no movieplayer, that worked half as good as armbian legacy with vc-1 movies.
Don't have that many movies with vc-1 but some much-loved like inception ...
 
I already wrote, that I use rockpi as movieplayer together with a beamer, so session selection of armbian legacy is suboptimal for me, as about 10-15% on top and bottom of the screen are invisible (outside of screen). Lightdm/xfce is so dumb, that icons in topbar will not be scaled to bar height, which works fine for second bar ...
Sadly I didn't find any other greeter, that runs on armbian and is more attractive like lightdm-gtk-greeter.
So I started to build my own, which took lot more of time than expected ...
 
any way - I finally have a working sample:

 
is uses gtk too, so it works with armbian.
 
I check the available sessions and if there's no session definition for kody-gbm, the kodi-button will be disabled (as in the screenshot taken from my desktop computer).
Font- and button-size have been increased for a screen distance of 3m approximately.
 
Last login will be cached, so user will be prefilled and hitting ENTER in the password field will login to the last session. Left most button starts kody and right most button the desktop.
 

Thank you for showing your script.
Beautiful work! I love verbose coding :)
 
Thanks for that command!
Haven't read about fdtoverlay before.
That's a very nice way (with little additional scripting) to enable overlays for cases where dynamically overloading is not supported.
 
Good job!
This is by far the first reason for using "new" gpiod layer.
Your key sample didn't convince me. I prefer "my" way of button handling. But finding pins by pin-name is sexy :)
 
Do you mind to publish the source of your overlay?
I asked dtc for the source, and it looks terrible. Can't believe, that you had to write such ugly stuff.
 
Do you know about a way to find conflicts between muxed modules, which share the same pin?
A developer told me, that pwm-pin for the fan control of penta-sata-hat conflicts with hdmi sound (I2S ?).
I'd like to verify that. But I can't
I use both - the fancontrol on the same rockpi4 which generates the sound for my AVR (over HDMI) and I can't confirm any conflicts as I don't hear any problems.

In case its help i made a helper script for managing relays
 
https://github.com/lanefu/sbc-gpio-pcf857x

I had bought the kit because I got attracted by its compact size. I had problems with my old media pc so good opportunity to tackle something new.
I thought, my requirements for a media server would be quite low/easy to fulfill:
smooth playback of 1080p movies clean multichannel sound access to firefox  
After testing all avaliable images on the rockpi, it was clear, that actually only LE offers exciting movie enjoyment. I had to realize, that my ideas are quite demanding after all.
So it was clear, I had to get the driver from radxa working on LE.
 
Why?
well, hardware design of rockpi4 with extension HATs is somehow stupid. The flat cable needs to go from plugged board below systemboard to HAT above system board, so sdcard could not be changed any more.

 
and as shown here:
 
 
sd-card cannot be used together with the tower. Only emmc-support for boot. But emmc module is not exchangeable.
That is why I had to start this odyssey.
 
I tested the driver with officially supported images:
on debian (linaro) the driver could be installed and the fan runs. Neither button nor display works. on ubuntu driver install scripts tells, that nothing has to be done, but nothing works ootb. No fan, no button, no display on armbian or LE the install script reffers to the git archive.  
I started with self compiled LE, but I'm not skilled to port lowlevel libraries to unknown system. Quite hard going
 
Then I discovered posting of PetrozPL and JackR. Both scripts worked on armbian - well, I had some problems, getting into it, but ...
anyway: trying the scripts on LE showed - no way. LE has no bash and busybox does not support arrays ...
 
So I researched, how I could drive the fan using only tools avaliable at LE. Unfortunately LE has no reasonable interpreter for scripting. Only python :(
I never wrote a line in python before!
 
I first had to check, whether the kernel of LE supports fan control. LE has no dtb-overlay support for rockpi. So had to change dtb manually like this:
copy dtb-file to writable location decompile with dtc -I dtb -O dts -o rk3399-rock-pi-4a.dtb rk3399-rock-pi-4a.dts find sections named pwm@ff420000 and pwm@ff420010 change status "disabled" into status = "okay" recompile dts with dtc -O dtb -o rk3399-rock-pi-4a.dtb -b O -@ rk3399-rock-pi-4a.dts copy dtb file back to original location (/flash)  
After reboot, fan works as with armbian - so I could write my fan-driver. Now system was ready to assemble the tower.
I tested the driver with all other test images. Had to change code to work with older python releases and had some troubles with the button. But now driver runs stable and - as far as I can judge so far, where my driver does not run, other drivers will fail too.
 
Well, my work with LE had the background, that I could get multiboot into play. But that seems pretty impossible.
So I startet again researching, what could fulfill my ideas.
Multimedia legacy - kodi works, movies are enjoyable. But no button support armbian current - no kodi, vlc works fine. Fan control works with button support debian/ubuntu - Fancontrol works with button support, but video playback is disgusting twisterOS - kodi works, movies are enjoyable, but no fan, no button  
I like twisterOS and the gimmick with the circles, but the text was unreadable for me. So I tweaked the gimmick and now I have it usable on my desktop as well on plain armbian. Using armbian instead of twisterOS has the benefit, that I don't have to flood the boot media with rubbish I never use (like openoffice and all that gaming stuff)
 
Actually my armbian current looks like this:

 
or a bit busy with firefox:
 
So the open jobs (next steps) are:
get multiboot into play (then I could use LE together with armbian) get another kernel on twisteros, that supports pwm - then I could use twisteros get a recent kodi on current armbian, then I could forget about all others  

Ok, I created my first pull-request with a network section in troubleshooting guide.
 
With Jira - I don't know, seems not to work. I read, that communication about a topic should happen in Jira, so I created an account. But probably you have to grant me some permissions to enable participating ...
 
So how should I start with Jira topics? For example, AR-735 is a topic, that sounds interesting. I use that pwm overlay on armbian as well as patches at LE ...
What needs to be done?
 
by the way: we're quite off topic already. Where's the right place for this kind of questions?

Given the following comment posted in response to the new invalid message discussed above:
 
"Hi Werner, I didn't realise I'd posted this as a bug I'll post it elsewhere"
 
I took another look at the language in the big red warning message that is displayed for people posting new topics in the bug tracking forums.  While it would seem obvious to those of us on the inside what we are trying to communicate, to the novice user I think there is room to make it more clear.  To that end I have the following suggested wording changes:
 
Current text:
 
Wait!
To avoid common mistakes when opening issues use this form to make sure you have collected all necessary information and create your issue report at the correct place:
>> https://armbian.com/bugs <<
Issue reports that are not following these guidelines will be removed without further notice!
 
Suggested text:
 
Important Please Read Before Posting a New Topic (Bug Report)!
 
You are about to post a new topic in the Armbian Bug Tracker.  Armbian uses the sub-forums under "Bug tracker - supported boards and images only" as it's public facing bug reporting system. If you really intend to report a bug please fill out the following form to supply the necessary information for a valid bug report:
 
>> https://armbian.com/bugs <<
 
With limited resources the Armbian project is only able to spend time investigating bugs where all the requested information has been provided and for only the boards/images/software that are supported.  Your bug report will be considered invalid and receive no attention if you do not supply the requested information.
 
If you only have a question or are looking for help on something in general related to Armbian, you should be submitting your question in one of the "Community forums", such as "Common issues / peer to peer technical support" or "General chit chat", not in this bug reporting forum.

I don't see a problem with using the invalid label as it is invalid according to the directions the user has read (or not read).  What I think would improve this is giving the user more direction on what to do next.  I think some working changes in the post that closes the thread as invalid would be all that is necessary.  So instead of:
 
 
Your issue report is invalid for one or multiple reasons (non-exhaustive enumeration):
 
it has been stated at the wrong place
it lacks fundamental requested data
it could have been easily solved by a quick search and/or reading documentation
unsupported userspace/image/SBC
 
Since you refused to use the bug reporting form carefully and follow the information there as you have been asked for we have no intention to further investigate.
Please add missing information if applicable.
 
https://www.armbian.com/bugs
 
 
Something like:
 
Your issue report is not a valid bug report per the Armbian bug reporting instructions (https://www.armbian.com/bugs).  With limited resources the Armbian project is only able to spend time on issues where all the requested information has been provided and for only the boards/images/software that are supported.  Your report is invalid for one or more of the following reasons (non-exhaustive list):
 
- it is for an unsupported board or image
- it is for software that isn't supported (such as userspace modules installed on top of the core operating system)
- it has been logged in the wrong forum (for example requests for help that are not actual bug reports)
- it lacks requested data (armbianmonitor output)
- it could have been easily solved by a quick search and/or reading documentation
 
Please review what you have submitted and the bug logging instructions (https://www.armbian.com/bugs) and either add the required information or open a new topic in the correct forum (such as "Common issues / peer to peer technical support" or "General chit chat")
 
 
I think this softens the tone and tries to help the user do the right thing.  Which they likely still won't 
 
 
 

Well - not similar from assembly, but similar in use case
I have Sata Tower from radxa. I have 4 ssd attached, but I didn't run any benchmarks. I love the small form factor, and its going to be useful after I ported driver from radxa.

Thank you - that finally did the trick!