Werner

Yeah I got that. Just provided an example and the config for 4.19 was the first I could think of to get my hands on.

We needed months to hopefully make it stable and usable which you obviously didn't even notice.
 

https://github.com/armbian/build#support
 

https://github.com/armbian/build#contribute
https://github.com/armbian/build#social
 

Yes, Jeedom should update their install scripts. 

Some bill printer device

Finally I got my lcd (some of them) to work with armbian on mainline kernel (5.4) using device tree overlay. It should be working on 4.19 kernel too.
I test mine on orange pi zero. The one I am able to get working is ili9341 and st7735 based lcd.
I'll add more detail later but for now I'd like to get this out.
 
edit 1 :
Adding ssd1306 and nokia 5110 overlay to the repo
 
device tree overlay

Anyone interested in RTD1295/RTD1296 platform would need to do something like this first
check out upstream mainline kernel at version 4.9.119 import changes from RealTek's kernel above (you then end up with one giant commit like this -- context) Now you can spend some days or weeks to have a look what's different, where security holes exist (remember Allwinner's 'rootmydevice'?) and what's not properly licensed If this step is skipped there exists no reason to trust into RealTek's 4.9 at all. Especially if this step is skipped it's impossible to start with Armbian support for RTD1295/RTD1295 devices since it would harm the project repeating mistakes like with Allwinner's H3 BSP kernel again (where something like rootmydevice was only discovered by accident).
 
We can't trust Android vendor's BSP kernels since those employees forced to hack driver support into something they're not interested in (the Linux kernel and its concepts) never worked with mechanisms like peer review or code quality control. If those employees would've started to submit patches upstream where all this stuff happens (Linux kernel community) then this would be something entirely different. But RealTek just like Allwinner and the majority of ARM SoC vendors has no interest in properly upstreaming their code so this code can't be trusted.
 
If their stuff is not properly licensed this will most likely prevent developing mainline drivers for the affected hardware (but I doubt anyone will do this anyway since so far only Suse's Andreas Färber worked on the platform -- tried to inform him via CNX but no idea whether he's aware that some RealTek kernel sources are now provided).
 
Having now sources does not mean everything's fine now. Next step is looking at the mess contained (if anyone wants to spend weeks of his life with something like this).
 
 

So I'm a bit of a dummy.
I did not know I could put in the interface name (wlan0) into the device portion of the network manager connections list.
When it made the entry for me it had <Mac address>(<ifname>) 
00:e0:4c:81:92:5a (wlan0) for instance..
I just removed the Mac address and the parentheses around wlan0 and now network manager is connecting my wifi on boot. I know this not the correct way to do this but this is all I needed.
Thanks for giving me a sounding board to reach this conclusion!
Cheers

On all Armbian image, it is like follows:
root
1234

Ok ! I passed the main hurdles ... The worst one was that many obsolete time32 helpers that are now definitively gone/erased, but we still need them for out-of-the-tree wifi drivers, so I had to put them back using timekeeping32.patch.
I will do few more test images for my different Allwinner boards, then I will be ready for commit ...

Beating your head is half the fun.   Glad you got it working and thank you for sharing your notes.

Me neither by a quick look. Just found a small typo in the first line of Common features: availble
 

I didn't realise I was on an unstable kernel. That makes sense now though. I'll keep poking around and see what I find.
 
Thanks for the comment.

38 views and one like. So at the moment the majority of people is for this change

Why ? I've better things to do, such as preparing the switch of Armbian DEV to 5.6.y ...
If it doesn't compile and you wish it to compile, it is up to yourself to look into output/debug/compilation.log for details and search for "error:" !
Don't ask other to do your own tasks for you !

Indeed. I tried to find templates to make them in no time ... I also support the change. If you wait for me - next week or more. My workstation is severely crippled and even small things takes lots of time.

Im indifferent. I think the biggest hurdle igor would have to updaye the graphic

Since - in my eyes - at least - there is a likelihood of confusion regarding the "Supporter" tag of members that actually (recurring) donating to the project. People could think "Supporter" means staff member that actually support people with their issues. The real staff rank, Moderator and Administrator to say, is "hidden" in their individual profiles. Since I like the idea of flat hierarchy I do not suggest to make the actual staff visible in forum postings but simply rename the Supporter to something like "Donator" to make it clear that these people donated to the project but are not necessarly involved into it.
 
Tell me what you think,

Since - in my eyes - at least - there is a likelihood of confusion regarding the "Supporter" tag of members that actually (recurring) donating to the project. People could think "Supporter" means staff member that actually support people with their issues. The real staff rank, Moderator and Administrator to say, is "hidden" in their individual profiles. Since I like the idea of flat hierarchy I do not suggest to make the actual staff visible in forum postings but simply rename the Supporter to something like "Donator" to make it clear that these people donated to the project but are not necessarly involved into it.
 
Tell me what you think,

38 views and one like. So at the moment the majority of people is for this change

I'm always willing to make a video about any subject you guys choose.
Give me the details of what you want to see/hear and I'll do my best with it. 

@Igor Are you at the next Fossdem in Brussels? If so we could try to meet for an interview.
You do not need to prepare for that. Just repeat a sentence when it didn't come out right. I cut and paste everything so nobody notices mistakes.
 
Otherwise I could make a question list(and you can add questions you want to answer). And you could film yourself with a smart-phone answering the questions. I can then use that video and cut/paste my questions in between.

I'm also not a good presenter, so live questions over internet would come out badly. I always have to redo my intros many times for my videos until I feel it's acceptable. I always got more blooper footage than useable video

It can be useful to have a system that is able to use the usb devices right from the first login, on a desktop configuration.
Adding the support of U2F usb security keys is straight forward on a system running udev already, it's just a text file.
I do not know how much it can be useful on server and headless installations, but again the udev rules file if tiny.
 
70-u2f.rules

Since - in my eyes - at least - there is a likelihood of confusion regarding the "Supporter" tag of members that actually (recurring) donating to the project. People could think "Supporter" means staff member that actually support people with their issues. The real staff rank, Moderator and Administrator to say, is "hidden" in their individual profiles. Since I like the idea of flat hierarchy I do not suggest to make the actual staff visible in forum postings but simply rename the Supporter to something like "Donator" to make it clear that these people donated to the project but are not necessarly involved into it.
 
Tell me what you think,

The reason that the OPi1+ doesn't clock higher than 1,48 GHz with the recent kernel versions isnt (just) the cpu opp table itself,
the entries for 1,8 GHz (and even 1,6 GHz in 5.4.20) exist.
The problem is that in the DTB, the max microvolt value for dcdca or vdd-cpu is lower than what's needed for the cpu to switch to 1,6 GHz or higher.
 
dcdca { regulator-always-on; regulator-min-microvolt = <0xc5c10>; regulator-max-microvolt = <0x107ac0>; (1080 mV) regulator-name = "vdd-cpu"; phandle = <0x6>; } opp@1640000000 { opp-hz = <0x0 0x61c06a00>; opp-microvolt = <0x11b340 0x11b340 0x11b340>; (1160 mV) clock-latency-ns = <0x3b9b0>; }; opp@1800000000 { clock-latency-ns = <0x3b9b0>; opp-hz = <0x0 0x6b49d200>; opp-microvolt-speed0 = <0x11b340>; opp-microvolt-speed1 = <0x10c8e0>; (1100 mV) opp-microvolt-speed2 = <0x10c8e0>; }; I tried this myself with my OPi1+ with kernel 5.5.0 by raising regulator-max-microvolt to 0x11b340 (1160 mV) and it successfully clocked to 1,8 GHz. YMMV. Sorry if this has already been mentioned elsewhere.

Can't access others terminals, need to boot from sd and mount eMMC to see the logs.
 
The problem was missing/corrupted libwayland_egl.so, so lightdm was aborting (missing something like  wl_window_destroy), copied the working library from sd and now OK again.

I've started the work of switching SUNXI-DEV to 5.6.y, as usual, few DT duplicates and fixes ...
But I've faced also a big change related to 'file_operations' been changed to 'proc_ops' in all places over the kernel, which cause that all our EXTRAWIFI needs to be fixed.
I hope to get it done by the end of this evening ...