ORANGE PI PLUS - fully working.


Jean-Philippe Theroux
 Share

0

Recommended Posts

my orange pi plus is operational thanks to you guys

 

whats working:

 

gc2035 and guvcview-h3

smtube compiled by me for perfect youtube 1080p playback (even fullscreen)

bluetooth ad2p works, i connect a creative muvo 10 on it, wow.

yamaha portable grand midi usb keyboard works, in lmms

and my novation drums pads too (yay)

 

shut off console output

have a bootlogo (soon a real boatload animation or a video with omx)

well

 

thanks everyone

 

only thing interface is greyed in guvcview and i load manually gc2035 camera driver and vie_v4l2

 

thanks again tkraiser, igor 

 

 

jean-philippe

 

 

 

 

Link to post
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

Glad to hear it works. But can you please elaborate what's different to an 'apt-get install youtube-dl smtube'? In Armbian we include an optimized mpv package that makes use of HW accelerated video decoding and I believe it would be good to incorporate possible improvements into our basic (desktop) builds as well.

 

At least for me Armbian is more than a couple of OS images and a build system. It's also an attempt to fight fragmentation of both community and development efforts (see the awesome work regarding camera support done by a few users!). Every improvement built into Armbian automagically helps projects using Armbian as foundation. Let's collect improvements in one place please! :)

Link to post
Share on other sites

i'll make a small how to.

Please have a look at https://github.com/igorpecovnik/lib/tree/master/extras-buildpkgs

 

A how-to would be better than a .deb in case it would be necessary to build an own smtube package. BTW: In the meantime Armbian dropped own mpv and ffmpeg packages and will provide only optimized configuration for the stock package. But HW accelerated video decoding will still be provided by our own packages.

Link to post
Share on other sites

smtube stop at version 'X' and needs to be compiled from the updated source code, d you want the smtube_armhf.deb file?

"smtube stop at version 'X'"

 

What do you mean ?

 

I use(d) a "legacy" Intel host to play youtube video, but the sound card seems to be dead (waiting for an usb dac). I didn't know smtube but it seems to cover my needs. Is that simply a problem of version or do you need config options or patches ?

Link to post
Share on other sites

I use(d) a "legacy" Intel host to play youtube video, but the sound card seems to be dead (waiting for an usb dac). I didn't know smtube but it seems to cover my needs. Is that simply a problem of version or do you need config options or patches ?

SMtube is just a simple Youtube browser, it user SMplayer or any other player to play a video. You can always play video by URL copied from browser directly.

Link to post
Share on other sites

But can you please elaborate what's different to an 'apt-get install youtube-dl smtube'?

 

I built an Armbian Xenial desktop image out of curiosity, adjusted HDMI resolution and installed smtube the usual way:

h3disp -m 1080p60 -d -c1
apt-get install youtube-dl smplayer smtube

Works as expected, HW accelerated video decoding and so on. Currently Armbian seems to have also fastest 3D acceleration (I rely here on others and don't know really but we increased Mali400 GPU cockspeed from 250 to 600 MHz some time ago and got reports about nicely improved gaming fps rates) and since a new Allwinner 3.4 BSP variant has been spotted last week with proper licenses for display/audio stuff and @jernej also said he's close to implement proper HDMI EDID support future audio and display improvements will be available soon... when relying on jernej's OpenELEC fork or Armbian (both projects share patches where applicable)

 

A short history of various kernel sources for H3 devices (and why that matters) can be found here: http://forum.armbian.com/index.php/topic/1351-h3-board-buyers-guide/?p=10144

 

Given the soon available further improvements regarding display and audio it seems really absurd to rely on outdated OS images that receive no updates any more.

Link to post
Share on other sites

My HDMI changes can be found here: https://github.com/jernejsk/linux/tree/hdmi_wipBut I stopped a bit because I currently don't have display which isn't 1080p native. I confirmed that timings are correctly calculated for 1080p but with current progress that's about it. I need a result from a display with another aspect ratio in order to confirm that everything is working. Is anyone interested here in helping me with testing?

Link to post
Share on other sites

@zador,

 

that would be the easiest. Here you can find the patch: https://transfer.sh/3tyen/hdmi-edid.patch
 

Due to a yet unfixed bug, HDMI EDID mode is always on. All you have to do is to make sure that HDMI cable is connected before kernel starts to boot or else it will fall back to a kernel argument or script.bin setting. You can now also use kernel argument like "disp.screen0_output_mode=EDID:1280x1024p60". As I said, EDID is always on for now, even if not present. Please also include dmesg output in your response in both cases.

Link to post
Share on other sites

Thanks.

 

It's weird. Some informations are missing. Does Armbian suppress "info" loglevel after userspace starts to execute? Can you try at least one with "ignore_loglevel" as kernel argument? TV reported 720p prefered. It seems that resolution is not properly propagated. Let me take a look.

 

I guess 1080p monitor worked ok?

Link to post
Share on other sites

Well, EDID info is always parsed. During parsing, it is always marked which modes are supported. Unfortunately, this info in current driver servers only as info to a userspace if requested over ioctl but otherwise is ignored. Once EDID mode will be properly implemented, it will automatically use only supported modes.

Link to post
Share on other sites

Well, then something else is wrong. Please check my example of output: http://sprunge.us/HPFVImportant parts are right after EDID parsing, from line "waited 760 ms for EDID info" onwards. Also something weird is going on with kernel mode resolution setting. My dmesg http://sprunge.us/eRAj clearly states "disp: edid mode for type 4 and disp 0 is set".

 

I desperately need some non standard display to work on this code. I will try to obtain it...

Link to post
Share on other sites

Here is OPi PC image: https://transfer.sh/oj6zQ/openelec-h3.arm-7.0-devel-20161018225654-r23108-g97f809b-opipc.img.gz It reboots automatically at first boot and ssh must be enabled in wizard at first Kodi run, but you can easily use UART console. Dmesg can be uploaded by "dmesg | pastebinit".

 

I noticed that edid parser produces weird modes on 1280x1024 monitors. Can you please upload "/sys/class/hdmi/hdmi/attr/edid" somewhere? is 1280x1024 mode confirmed working on Armbian? Hopefully all that info will be enough to resolve any discrepancies between Armbian 1280x1024 patch and my EDID parsing. BTW, image on 1280x1024 will be scrambled due to incorrect framebuffer size, but nevertheless, it should show something.

Link to post
Share on other sites

 

Thanks. Timings seem to be calculated correctly. However, EDID dump is a bit misterious (a bit short comparing to dmesg edid output), but this may be bug in the driver. I guess that interlaced resolutions may need multiplication, but first let's make prefered EDID mode working.

 

Edit: I didn't test 1280x1024 in Armbian, and BTW 720p mode produces "broken" picture too

 

That is to be expected, because default framebuffer size is 1920x1080 and this is not fixed yet. I never saw your explicit confirmation: Is there any video ouput, albeit broken, on 1280x1024 monitor? If it is, we need to fix only framebuffer size and timings, I guess.

 

Yes OpiPc works with armbian 5.20 on 1280x1024, I have it running, see here:

http://forum.armbian.com/index.php/topic/752-tutorial-h3disp-change-display-settings-on-h3-devices/page-2#entry17461

 

If you like, I could try an image, but need instructions what to do or record.

Thanks, gnasch

 

Thanks for confirmation. I received enough informations for now and I have to fix few things before next try is needed.

Link to post
Share on other sites

Guest
This topic is now closed to further replies.
 Share

0