ORANGE PI PLUS - fully working.

[Jean-Philippe Theroux]

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

 

 

 

 

[tkaiser]

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!

[Jean-Philippe Theroux]

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

[Jean-Philippe Theroux]

i'll make a small how to.

[Jean-Philippe Theroux]

here the good sm tube i compiled.

 

works with your accellerated video stuff thanks,

 

smtube 16.7.2_armhf_.deb

 

https://www.sendspace.com/file/p8vgqx

[arox]

"bluetooth ad2p [a2dp] works"

 

with pulseaudio ?

[Jean-Philippe Theroux]

here the good sm tube i compiled.

 

works with your accellerated video stuff thanks,

 

smtube 16.7.2_armhf_.deb

 

https://www.sendspace.com/file/p8vgqx

 

oh it's really crystal clear =)

[tkaiser]

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.

[arox]

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 ?

[zador.blood.stained]

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.

[tkaiser]

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.

[jernej]

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?

[zador.blood.stained]

I need a result from a display with another aspect ration in order to confirm that everything is working. Is anyone interested here in helping me with testing?

If you make a test image for one of the boards listed in my signature, I can test it on a TV which has lower native resolution.

[jernej]

zador,

 

I guess it is enough if I just build kernel deb package and give you instructions how to change boot.scr? I will try to prepare something in following days.

[zador.blood.stained]

@jernej

Or you can just squash all HDMI changes into a single patch and I'll build default Armbian kernel with this patch and other HDMI patches disabled.

[jernej]

@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.

[zador.blood.stained]

Unfortunately TV reported 1080p on screen (and 720p in logs?) via EDID and both 1280x1024 old square monitors reported "Unsupported input" on screen

TV tested via direct HDMI connection, all 3 other monitors - via HDMI to VGA converter.

dmesg logs: https://www.dropbox.com/sh/xz4tgtsm5ak93gg/AAAGUoROvZ9jT7XLtr5D3fGja?dl=0

[zador.blood.stained]

Sorry, kernel command line was changed due to recent build script changes, and "disp.screen0_output_mode=1920x1080p60" was present (I just realized it now). I will retest everything and upload logs again

[jernej]

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?

[zador.blood.stained]

OK, now it's better. While I'm collecting the logs, do you think it's reasonable to disallow setting mode not supported by EDID if EDID info is available? This way exotic displays will work out of the box even if kernel command line forces 720p or 1080p

[jernej]

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.

[zador.blood.stained]

New logs uploaded to https://www.dropbox.com/sh/xz4tgtsm5ak93gg/AAAGUoROvZ9jT7XLtr5D3fGja?dl=0

Now 720p mode is forced to all 3 monitors (720p is default in script.bin). When I add disp.screen0_output_mode=EDID:1920x1080p60 to kernel command line, dmesg reports that mode string is invalid.

[jernej]

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...

[zador.blood.stained]

I have no idea why dmesg log is different (different script.bin settings? different kernel config?), but I can still test a full image.

[jernej]

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.

[zador.blood.stained]

OK, I'll try to do all this tomorrow.

[zador.blood.stained]

New logs and EDID sysfs files uploaded: https://www.dropbox.com/sh/xz4tgtsm5ak93gg/AAAGUoROvZ9jT7XLtr5D3fGja?dl=0

 

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

[gnasch]

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

[jernej]

New logs and EDID sysfs files uploaded: https://www.dropbox.com/sh/xz4tgtsm5ak93gg/AAAGUoROvZ9jT7XLtr5D3fGja?dl=0

 

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.

[zador.blood.stained]

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.

Sorry, yes, there is an output, monitor reports 1280x1024 in its menu, so looks like framebuffer size is the only issue.