•   
  • 1
  • 4
  • 5
  • 6(current)
  • 7
  • 8
  • 39
  •   
[i.MX6] XBMC running on Freescale SoC's
#76
Okay they're not working with other Linux images which means it's a power supply issue, interesting that it works with the original Android image though.

Sorry for jumping the gun here before I did some proper investigation. Thanks for your time dude Wink.
Reply
#77
Thanks alot Stephan! Nano works and I got yatse to work too (stupid fault, somehow my other xbmc standardly puts http control on 8080 and I hadn't seen this one was on 80 so it was just a matter of changing the port on my phone). Looking forward to the synergy option! BTW, I see some 'curtaining' at the bottom of my screen (1280x720) where it seems like the video just goes to row 700 and then the last 20 rows are just a copy of row number 700, creating lines downward from there to the bottom of the screen (sorry for my clumsy explanation, I hope it's clear). Any idea?

.
(2013-06-06, 00:17)wolfgar Wrote: Hi Toverkwark

I am also a user of this great remote "yatse" and it just works with my current build !
Yet, you have to enable the option "Allow programs on other systems to control XBMC" in the remote control options. Have a look at this wiki which explains the required setting...
Second, this image is a custom distro (built with a kind of factory called yocto which enables to build tailored distro with full control on the build process for embedded systems)
As you have remarked the package tool which is used is "zypper" (this tool is also used by opensuse by the way) and not apt-get.
The available packages are the ones I have built on my own server Wink

For nano, I have just built and added the package, just run :
Code:
zypper refresh
zypper install nano
And you will have your favorite editor ...

At last, I will have a look at synergy : Using this software is a really good idea (for now I am unsure it will be able to run as a client on my image but I will check for sure !)

Best regards
Stephan

Edit : I had a look at synergy : Well it relies on Xwindow to handle mouse/keyboard events and I don't use Xwindow... But it provides a convenient uclient library that I should be able to plug on Linux uinput so that I would get it to work fine out of the X world... If my explanations make no sense, no problem : It means that I need to develop a little piece of code but that I am confident I can make a synergy client run on my target Wink
Reply
#78
Hi Toverkwark,

Great to hear that everything is fine with yatse & nano
For synergy : I have made good progress in developing a little client for my image : Now, I always use synergy instead of a real usb mouse for my tests...
For CEC, I had a close look at it : I have to port libcec so that it can work with the imx cec driver : I should be able to do it quite easily (I only fear that at some stage being unable to read edid will prevent some features but lets develop and see ;-) ).
At last I understand the global meaning of your report : I think I have already observed this strange 'curtaining' and it may definitively be a bug in my code (I have to round several values when dealing with VPU & IPU for decoding and scaling : I may have some "incompatible" values which create this default, I will check... )

Best regards
Stephan
Reply
#79
Hi Wolfgar, thanks for your great work!
Just wondering - do you experience occasional hickups in video playback?
It happens even in the sample video that's included in your sd card image - it's mostly visible when the scene is rotating/shifting/moving to the viewer - there are several such scenes there.
Tried to play it with gplay from freescale and it seems to be ok.
Do you think you could fix that please?
It might be possible that it does not happen in your case as I am using different imx6q board (and therefore different build of imx6 kernel).
Might it be related to some forward caching of the video?
Or maybe the difference in fps of the video and refresh rate of the hdmi output?
Reply
#80
Hi j4ns

Please, have a look at item #2 of this post I made on another forum.
Just perform the test by removing any usb device and if it solves the issue then it is all good : The XBMC packaged in the next image will work fine...

Regards
Stephan
Reply
#81
Hi Stephan, I had only an usb key connected - tried to disconnect it (lsusb now shows just two root hub devices), but the occasional hickup is still there in xbmc, while it is not there when gplay is used (with xbmc running in the background). Could you please post a patch of xbmc which disables the test for hotplug devices? Or commit it in your github repository? Thanks.
Reply
#82
(2013-06-12, 02:03)wolfgar Wrote: Please, have a look at item #2 of this post I made on another forum.
Just perform the test by removing any usb device and if it solves the issue then it is all good : The XBMC packaged in the next image will work fine...

Thanks for the suggestion - even though I do not have any usb input device connected, the hickups seems really to be caused by that periodic check for hotplugged input devices - I've found the code, commented out CheckHotplugged() call and it seems to be smooth now. I have two /dev/input/eventX devices present there - number 0 is physically not connected android buttons available via gpio-keys driver and number 1 is provided by uinput driver used by lircd, which I've configured for my old remote connected to ttymxc0 serial line.

Thanks very very much again for your excelent work on xbmc support for imx6 codecs - it's already nearly possible to use for serious playback and if you could improve the stability a bit, it will be just perfect...
Reply
#83
Hi j4ns,

Sorry for my late answer (generally speaking I am able to answer on this forum from 21:00 to 01:00 UTC)
I am glad to learn that you managed to get rid of these periodic checks and that it solved your issue.
I have just pushed the commit in github but obviously it is too late to be useful for you...

If you experience some specific stability issues please do not hesitate to report them so that I can investigate and try to solve them...

When such issues happen, please try to :
- copy the xbmc.log (located in ~/.xbmc/tmp folder)
- issue a dmesg command a copy the ouput
and to submit these data using an online copy/paste service...

As you say the current version is mostly usable but I would like to make it even better...

Best regards
Stephan
Reply
#84
Hi Stephan,

I've finished creating a Kernel + Xubuntu rootfs based upon BSP 4.0.0. I'd like to test your latest build to see if there are any improvements in thermal stability and I think there are fixes for the VPU. Any suggestions on the best way of proceeding? I can change the rootfs to use the gpu fb drivers.
More A10/GK802/I.MX6 stuff on my blog
Reply
#85
Hi mtx512

I guess the best way is to compile my lastest XBMC version (on the imx6-ts branch) and to perform the few required changes to get it to work with X : It should be quite easy, I have not done them because I was busy with other subjects but I don't expect hard issues...
Moreover, I don't think the VPU API has changed in BSP 4.0.0 so no change should be required on this side (I will have a look at this)

I don't fully understand your proposal to switch to gpu fb as it does not make a lot of sense for your Xubuntu image but it could indeed be a first step to check that my XBMC version just works fine as it before performing the adaptations for X

Regards
Stephan
Reply
#86
Hi all,

I have setup a new image :

Most noticeable changes are :
- The kernel is configured to use scaling frequency with "ondemand" govenor
- There is a micro synergy client available (you have to edit the /etc/hosts file to set the IP of your synergy server) to get it to work
- Some additional python modules have been added as they could be needed for specific XBMC addons
- librtmp library and rtmpdump utility were added (V2.4 with latest patches -11/06/2013- from KSV)
- The XBMC build is now able to deal with RTMP protocol and will not exhibit the little hickups every 10 seconds when an input device is connected

Installation instructions
You can download it from here
It is a compressed (by xz) full raw image which will be around 2GiB when extracted.
Extract it and copy it on a sdcard with dd util on linux or *bsd or with win32 disk imager on windows

Have fun
Stephan
Reply
#87
(2013-06-15, 21:55)mtx512 Wrote: I've finished creating a Kernel + Xubuntu rootfs based upon BSP 4.0.0. I'd like to test your latest build to see if there are any improvements in thermal stability and I think there are fixes for the VPU. Any suggestions on the best way of proceeding? I can change the rootfs to use the gpu fb drivers.

Hi, I've also tried with bsp 4.0.0, unfortunatelly that looks like a step back to me - tested with Wolfgar's xbmc sources (fb egl backend) - there were lots of video playback issues (hickups, incorrect frame flashes) that do not happen with 1.1.0 bsp... But your results may be different, as I am using different board, different kernel and different rootfs - so I am interested in your findings.
In my opinion it does not make sense to port xbmc to X11 for imx6 while it is running already with opengl es - I would not expect any better gui performance.
Reply
#88
Hi again, has anyone encountered following error, which I mentioned earlier in this thread, but faced again even by using the latest imx6-ts branch:

CPP xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecIMX.o
In file included from DVDVideoCodecIMX.cpp:20:0:
/usr/include/linux/mxcfb.h:111:2: error: ‘uint’ does not name a type
make[1]: *** [DVDVideoCodecIMX.o] Error 1
make: *** [xbmc/cores/dvdplayer/DVDCodecs/Video/Video.a] Error 2

I was building natively on jas' xubuntu released in May.

Any fixes or solutions?
Reply
#89
(2013-06-17, 07:41)j4ns Wrote: Hi, I've also tried with bsp 4.0.0, unfortunatelly that looks like a step back to me - tested with Wolfgar's xbmc sources (fb egl backend) - there were lots of video playback issues (hickups, incorrect frame flashes) that do not happen with 1.1.0 bsp... But your results may be different, as I am using different board, different kernel and different rootfs - so I am interested in your findings.
In my opinion it does not make sense to port xbmc to X11 for imx6 while it is running already with opengl es - I would not expect any better gui performance.

Hi j4ns, thanks for your comments, my initial testing of 4.0.0 BSP reveals that the CPU loading is better distributed across applications when rendering the GUI, well at least on X11, although single application rendering is less performant. GStreamer seems to play some of my test files better in full screen at 1680x1050 without hickups.

Interested to know which board and rootfs you are testing against? I can provide a link to my rootfs if you want to test.
More A10/GK802/I.MX6 stuff on my blog
Reply
#90
Hi mtx512, I am testing with sabre lite board, boundary's 1.1.1 bsp kernel with few patches, rootfs based on openbricks. The board is unfortunately one of early samples, so that may be the reason for troubles with bsp 4.0.0.
Reply
  •   
  • 1
  • 4
  • 5
  • 6(current)
  • 7
  • 8
  • 39
  •   
 
Thread Rating:
  • 4 Vote(s) - 5 Average



Logout Mark Read Team Forum Stats Members Help
[i.MX6] XBMC running on Freescale SoC's54