Igor

@lanefu
 
 
I don't quite understand what you mean by that?  I guess I need vacations, since my brains are throttling   Just create topic and one of mods will pin it.
https://github.com/lanefu/armbianDocsAndProcess/blob/master/ArmbianTaskTracking.md 
This should once go to "user manual", when we finish with the technology issues.
 
@0x0
 
 
Well, design tuning is open for jump in. We are using XFCE desktop with different (stock) theme, icons and wallpaper. On some boards we are using Armbian boot logo and I think that's all regarding design & branding. Almost nothing. Peek how desktop is done now. 
 
If you are good in .css, here is another WIP. Recently we start to rework our documentations, since our current system was just a bunch of MD files withing script repository. Take a look at docs.armbian.com and check if you can fix .css to meet website design (Check tool site http://www.mkdocs.org/ for more info about custom css).

What about this way?
 
docs.armbian.com
 
mkdocs.yml 
site_name: Armbian Documentations theme: readthedocs markdown_extensions: - toc: permalink: True pages: - 'index.md' - 'User manual': 'user-manual.md' - 'Board special': - 'H3': 'boards/H3.md' - 'Allwinner': 'boards/Allwinner-hardware-conf.md' - 'build-manual.md' - 'Changelog.md'

Consider the page as WIP. I didn't make any more progress and will update it with our findings when done.
 
I guess the location of the documentation will be o.k. "docs.armbian.com" ?

Consider the page as WIP. I didn't make any more progress and will update it with our findings when done.
 
I guess the location of the documentation will be o.k. "docs.armbian.com" ?

What about this way?
 
docs.armbian.com
 
mkdocs.yml 
site_name: Armbian Documentations theme: readthedocs markdown_extensions: - toc: permalink: True pages: - 'index.md' - 'User manual': 'user-manual.md' - 'Board special': - 'H3': 'boards/H3.md' - 'Allwinner': 'boards/Allwinner-hardware-conf.md' - 'build-manual.md' - 'Changelog.md'

Just look at the screenshot, look how the URL is constructed. That's what mkdocs does for you after 2 minutes of 'tweaking'. Taking the structure that is present in the ckecked out .md documents and creating nice formatted HTML from it. URLs are called like documents, anchor names depend on internal structure. Everytime a clueless guy starts to edit wiki contents believing only wiki output would count everything breaks. It's that easy.
 
Defining 'internal' structure inside _Sidebar.md worsens everything even more since now you have to parse this file to modify MD documents prior to feeding it to mkdocs. IMO bad.
 
So by giving up on the 'presentation engine' in our github wiki and simply using a home page that states 'Do just edit the pages accessible on the right, don't change page titles, don't change section names, only add stuff and edit structure very carefully' you might get the wiki approach to work IF we want to postprocess the stuff therein (no idea if WE want that still)
 
By adjusting structure levels inside the individual .md docs and minimizing their count the postprocessing efforts are MINIMAL. Just choose the right mkdocs theme, disable search therein and feed the output to htmldoc. And you get a full PDF manual with links, index and so on. And using a different theme you can use HTML output from mkdocs on armbian.com (given that nobody uses the github wiki like a wiki and starts there editing like crazy -- that's the whole point. As soon as people start to use the wiki in the usual wiki way all our persistent links get fucked up automatically)
 
But since only @lanefu looked that much into (and might be able to understand me) I finally stop here since the whole discussion gets boring.

Yes, you are perfectly right about this. Nothing to add.
 
Well, beside that I added a sidebar document and rearrange few sections, we still have more or less the same thing. If we have an (open) wiki anyone can edit and we want that even we would need to fix things sometimes. Wiki is still just a little better than what we had until now. It's an lite presentation engine. Docs created with some serious tools (mkimage) looks much better / pro style and they can be created out of the wiki the exact same way. But this job is, like we are discovering, not strait / trivial so it will take some time.
 
Some decisions should be made, since things are floating in the middle, links were changed and might change more. Blog rendering does not work with Wiki, but normal github, links to H3 info @download page is still broken (will be fixed during a day), we have lib/documents and wiki containing the same stuff with some minor changes. 
 
One can be wrong if we (currently, until things are solved better way) refer people to www.armbian.com/documentation ... This can be redirected anywhere.

I discussed this problem with plugin author some time ago but he failed to find a solution. Yes, it's terrible.
 
Even when docs will be on the proper level, some people will fail to read them   Further I was thinking about some forum plugin / feature which will pop up some message "Have you read the manual" at posting if user is having less than 3 posts, was registered not long ago and if text "I am new to Linux|Armbian" is found in text
 
 
@lanefu (has RW Github access) @Tido @miked @Kriston @jeanrhum @vlad59 @Gravelrash - all who claimed or promised help around docs. It's your time to shine   
 
Note: latest documentation sources are lib.wiki but that location and structure just become irrelevant. 

For what it's worth: I managed to compile VICE (classic commodore computer emulators) on my roseapple pi board running Armbian. I could not find it in the repository, so I started fiddling myself.
 
This to address some nostalgic feelings which come by so now and then!
 
Recipe in the spoiler....
 
 
 
 
Screenshot:
 

@lanefu
 
Yes, something like this. Just push it to wiki and add to menu, let's say "Report a problem" in section "General".

Either eMMC or NAND can be enabled by default since they share pins.
Enabling eMMC in u-boot (via patch) should be safe, this is needed to boot from eMMC. Enabling eMMC in fex files by default can be done only for boards that don't have NAND variant. This is needed to see eMMC in OS. For mainline there will be separate DT file for Lime2-eMMC board.

True, image was corrupted on upload and was fixed few moments ago.
 
Thank you for reporting.

confirmed.
[gr@server1604:~] $ wget http://mirror.igorpecovnik.com/Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z --2016-06-27 14:07:40-- http://mirror.igorpecovnik.com/Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z Resolving mirror.igorpecovnik.com (mirror.igorpecovnik.com)... 185.94.112.69 Connecting to mirror.igorpecovnik.com (mirror.igorpecovnik.com)|185.94.112.69|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 176835029 (169M) [application/x-7z-compressed] Saving to: 'Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z' Armbian_5.14_Orangepi_Ubuntu_xenia 100%[================================================================>] 168.64M 11.1MB/s in 15s 2016-06-27 14:07:55 (10.9 MB/s) - 'Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z' saved [176835029/176835029] [gr@server1604:~] $ 7z t Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z 7-Zip [64] 9.20 Copyright (c) 1999-2010 Igor Pavlov 2010-11-18 p7zip Version 9.20 (locale=C,Utf16=off,HugeFiles=on,4 CPUs) Processing archive: Armbian_5.14_Orangepi_Ubuntu_xenial_4.6.2.7z Error: Can not open file as archive is there any issue with "Length: 176835029 (169M) [application/x-7z-compressed]"?

I would totally do that! It might also identify some easy-to-fix problems that could be a good place to start contributing code.

OK, let's use Github wiki as a base. I already done some rework. First part is more or less done, now going to script part and fine tuning on the top of it.
 
https://github.com/igorpecovnik/lib/wiki

OK, let's use Github wiki as a base. I already done some rework. First part is more or less done, now going to script part and fine tuning on the top of it.
 
https://github.com/igorpecovnik/lib/wiki

OK, let's use Github wiki as a base. I already done some rework. First part is more or less done, now going to script part and fine tuning on the top of it.
 
https://github.com/igorpecovnik/lib/wiki

OK, let's use Github wiki as a base. I already done some rework. First part is more or less done, now going to script part and fine tuning on the top of it.
 
https://github.com/igorpecovnik/lib/wiki

OK, let's use Github wiki as a base. I already done some rework. First part is more or less done, now going to script part and fine tuning on the top of it.
 
https://github.com/igorpecovnik/lib/wiki

I guess we forgot/failed to merge configuration. There is no other way than recompile kernel with proper configuration - to enable what's missing. I own one XU4 and that one is serving this forum so can't do the testing but will try to prepare a kernel update ASAP.

Few my ideas.
 
 
I think no need for this. I expect lot's of changes now, since we need to add few things and apply better structure to what's already done.
 
Let's see what do we have now:
 
"user faq" - This suppose to be "Getting Started: Everything you need to get Armbian up and running". It's close to that, except some things might be too advanced for novice user.
"enabling HW features" - is little more than this, but not many things present at the moment. Here we could add (move from) most important things: connecting spi / i2c displays, sensors, ... The main question remain "how far" should we go with all this?
"h3_mini_faq" - logbook and user faq only for H3. How to deal with per board stuff? Generally.
"geek faq" - how to deal with tools. We need 2-3 script user review to be done and merged into this documentation (can be claimed for board). Our / coder POW is not the best to write such manual. Basically one must start from scratch, test all functions and write down experiences, written in manual/howto style.
"fel-boot" - features within tools. The same. Someone from outside should review / rewrite the docs.
 
 
Current situation: docs sources are .md and they are rendered to .html within blog and there we can set permanent links per documents. This part is not that bad after all. "Getting started" and "Basic" is the same page just in case someone does not understand it properly. Next doc is "Building" aka "geek manual" and a log book.
 
One idea is, to merge all those sections into one .pdf file "Armbian handbook". First part basic stuff, than few howtos and building howtos, walk trough and perhaps logbook at the end.
 
Not necessarily but we can do that quickly in the future if needed. 
 
One more exposed link on the download page would help, agree. Elsewhere is not critical since the page offers pretty strait links: download, docs, sources and forum. I think main problem is that we don't have proper docs internal organization, few things are doubled, build script needs much more explanation, examples, ... where to put log of changes? We even have separate, more detailed for H3. 

Few my ideas.
 
 
I think no need for this. I expect lot's of changes now, since we need to add few things and apply better structure to what's already done.
 
Let's see what do we have now:
 
"user faq" - This suppose to be "Getting Started: Everything you need to get Armbian up and running". It's close to that, except some things might be too advanced for novice user.
"enabling HW features" - is little more than this, but not many things present at the moment. Here we could add (move from) most important things: connecting spi / i2c displays, sensors, ... The main question remain "how far" should we go with all this?
"h3_mini_faq" - logbook and user faq only for H3. How to deal with per board stuff? Generally.
"geek faq" - how to deal with tools. We need 2-3 script user review to be done and merged into this documentation (can be claimed for board). Our / coder POW is not the best to write such manual. Basically one must start from scratch, test all functions and write down experiences, written in manual/howto style.
"fel-boot" - features within tools. The same. Someone from outside should review / rewrite the docs.
 
 
Current situation: docs sources are .md and they are rendered to .html within blog and there we can set permanent links per documents. This part is not that bad after all. "Getting started" and "Basic" is the same page just in case someone does not understand it properly. Next doc is "Building" aka "geek manual" and a log book.
 
One idea is, to merge all those sections into one .pdf file "Armbian handbook". First part basic stuff, than few howtos and building howtos, walk trough and perhaps logbook at the end.
 
Not necessarily but we can do that quickly in the future if needed. 
 
One more exposed link on the download page would help, agree. Elsewhere is not critical since the page offers pretty strait links: download, docs, sources and forum. I think main problem is that we don't have proper docs internal organization, few things are doubled, build script needs much more explanation, examples, ... where to put log of changes? We even have separate, more detailed for H3. 

Usage: markdown-pdf [options] <markdown-file-path> Options: -h, --help output usage information -V, --version output the version number <markdown-file-path> Path of the markdown file to convert -c, --cwd [path] Current working directory -p, --phantom-path [path] Path to phantom binary -h, --runnings-path [path] Path to runnings (header, footer) -s, --css-path [path] Path to custom CSS file -z, --highlight-css-path [path] Path to custom highlight-CSS file -m, --remarkable-options [json-options] Options to pass to remarkable -f, --paper-format [format] "A3", "A4", "A5", "Legal", "Letter" or "Tabloid" -r, --paper-orientation [orientation] "portrait" or "landscape" -b, --paper-border [measurement] Supported dimension units are: "mm", "cm", "in", "px" -d, --render-delay [millis] Delay before rendering the PDF -t, --load-timeout [millis] Timeout before the page is rendered in case `page.onLoadFinished` isn't fired -o, --out [path] Path of where to save the PDF I am still working on but according to now:
- better code highlighting can be done with .css, since it's converted to HTML and than to PDF
- YouTube should be converted to link
- Line wraps. Probably doable with .css
- clickable TOC, have to study but I think not possible out of the box
- page numbers, currently no idea
 
Numeric prefixes, yes. I am currently creating 01-cover-page.md
 
Edit:
I am already happy even with this. One searchable document with simple TOC at start. It's also possible to create two main documents or one divided into two major section, user / geek and with different background color. That's possible to do fairly easy.
 
Edit: some structural changes
Armbian_5.14_documentations.pdf

Thank you, Thank you very much!!! Tkaiser.
I succeed to use 7 inch HDMI touch screen(800*480) on Orange Pi One.(Touch Firmware  STM32F103 hid-multitouch, 14 byte raw data,
moreover you don't need to write your uinput or uhid driver)
According to your advice(modprobe hid_multitouch --> insert module into /etc/modules) , usb touch module works.
 
One tip more: In fex file I modified following 2 lines.
====
[disp-init]
fb0-format=0
fb0-wwidth=800
fb0-height=480
====
After that, touch screen & HDMI all the same function nicely.
(Some body(igorpecovnik)
maybe added driver. --> cf.
https://github.com/igorpecovnik/lib/blob/master/patch/kernel/sun8i-default/0026-h3-hdmi-additional-mode-800x480p-from-lobodis-initia.patch)
 
Thank you, Tkaiser & Igor 

Hello,
 
I want to thanks armbian.
 
I installed armbian on my Orange Pi PC to build a music streaming platform, with digital crossover to perform active bi amplification.
 
armbian performed perfectly out of the box for that purpose. The thermal behaviour of the OPi PC is very good (much better than with the openelec version).
 
I had issues with my project, but none related to armbian or Orange Pi PC
 
I wrote a wrap up of my experiments here: http://www.diyaudio.com/forums/pc-based/293362-orange-pi-digital-crossover-2x-usb-amps-wrap-up.html
 
Best regards,
 
JMF