+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: [i.MX6] XBMC running on Freescale SoC's (/showthread.php?tid=161793)
RE: [i.MX6] XBMC running on Freescale SoC's - CruX - 2014-02-20
Okay, if you say so thats probably right.
I'm really excited by the current development
Thanks for all the work you guys do, I'll try to keep up in packaging for ArchlinuxARM
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-20
OTOH, the fact that sysfs is 644 root:root is bugging.
You surely do not want xbmc to run as root, as it opens your system wide to addons.
Any ideas?
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-20
(2014-02-20, 01:23)wolfgar Wrote: OK I note it : Always rebase vs xbmc master so that at the end the whole patch will apply on head, right ?Right. I you need "stable" hashes for buildroot, right?
Does it mean that our master branch will always be in an "unreliable" state ?
I mean : if we want to use a commit or a tag as a reference for a distro build, we should use another branch, right ?
If so, we can merge in master and later create a specific branch for the PR.
Beware though that rebasing can become a nightmare, then.
For example, it was practically impossible to rebase you original work, with commits > 6 months old... I had to to a diff and create a new commit
RE: [i.MX6] XBMC running on Freescale SoC's - Thecko - 2014-02-20
(2014-02-20, 11:49)Koying Wrote: I don't see what is dirty in using sysfs (from inside xbmc, obviously)
sysfs is great if you're a system administrator with elevated (root) privileges to hack around and change configs, perhaps even set startup scripts to be run. You don't really want to be accessing /sysfs directly from non-privileged userspace though - as I understand it, sysfs does not have an equivalent of udev's ability to change user/group ownership/permissions on objects.
The only 'clean' solution (you really don't want to be shelling out to sudo on the command line) I can think of is to have the device respond to ioctl commands for screen blanking and mode changes.
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-20
(2014-02-20, 12:51)Thecko Wrote: The only 'clean' solution (you really don't want to be shelling out to sudo on the command line) I can think of is to have the device respond to ioctl commands for screen blanking and mode changes.Right.
Now the question is: How to extract FBIOPUT_VSCREENINFO parameters from the output of /sys/class/graphics/fb0/modes, i.e. available resolutions/refresh rates?
Example of /sys/class/graphics/fb0/modes
Code:
S:1920x1080p-30
S:1920x1080p-25
S:1920x1080p-24
S:720x576p-50
S:720x480p-60
S:1280x720p-50
S:1280x720p-60
S:1920x1080p-50
S:1920x1080p-60
V:640x480p-60
D:1920x1080p-60
V:640x480p-60RE: [i.MX6] XBMC running on Freescale SoC's - Thecko - 2014-02-20
The Enlightenment devs use the file /etc/fb.modes (exists on my Pi, the cubox-i isn't booted up so I can't check if it's delivered on geexbox) as a hint for the relevant information.
See the method fb_list_modes here
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-20
/etc/fb.modes is static, i.e. it isn't generated based upon the HDMI EDID information, so can probably burn your TV
RE: [i.MX6] XBMC running on Freescale SoC's - Thecko - 2014-02-20
No, what I mean is you can retrieve the available modes by reading from sysfs, and then use the matching info from /etc/fb.modes to determine the correct parameters.
Perhaps I'm misunderstanding what information /etc/fb.modes actually provides.
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-20
Well not sure either, but I think the clockings are monitor dependent, aren't they?
RE: [i.MX6] XBMC running on Freescale SoC's - emveepee - 2014-02-20
(2014-02-20, 09:16)Koying Wrote: Apparently, the location of the vivante extension definitions is toolchain dependent.
I'll hardcode the functions definition and get the address via eglwrapper.
Great, I tried with your recent commit and it builds now. Thanks a lot!
Martin
RE: [i.MX6] XBMC running on Freescale SoC's - Koying - 2014-02-20
(2014-02-20, 15:00)emveepee Wrote: Great, I tried with your recent commit and it builds now. Thanks a lot!Cool, but beware that you must assume my repo is in perpetual unstable state, so zero guarantee, there.
I'm doing back-and-forth between my dev machine for coding and the imx6 for building
RE: [i.MX6] XBMC running on Freescale SoC's - Thecko - 2014-02-20
(2014-02-20, 14:43)Koying Wrote: Well not sure either, but I think the clockings are monitor dependent, aren't they?
I think you may be right but video / display protocols aren't really my area (hence I'm not contributing code to xbmc
). When setting the display mode in the kernel boot flags does the driver determine the correct clocking by parsing the EDID? If so, is there a way to get the EDID raw data and parse it yourself ?
RE: [i.MX6] XBMC running on Freescale SoC's - ProsjektX - 2014-02-21
(2014-02-20, 14:43)Koying Wrote: Well not sure either, but I think the clockings are monitor dependent, aren't they?No, as far as I know. The HDMI specs refer to CEA 861 which define the timings for all standard modes, some modes any display must support to be hdmi compliant (stated in the hdmi spec) and some are optional. google for the CEA 861 specification. There you'll find all modes including all timing parameters.
RE: [i.MX6] XBMC running on Freescale SoC's - noggin - 2014-02-22
(2014-02-20, 14:43)Koying Wrote: Well not sure either, but I think the clockings are monitor dependent, aren't they?
Don't think the "TV" video modes vary by monitor, as they are effectively linked to the broadcast studio specs which are very tightly defined. (You can convert HDMI to HD-SDI - studio broadcast interconnect - without using any frame buffers and with very low delay)
I'd expect there to be 4:2:2 YCrCb, 4:4:4 YCrCb and 4:4:4 RGB modes with standard clock timings for the following resolutions :
720x576/50i (possibly implemented as 1440x576 with pixel repetition to keep a high enough clock rate)
720x480/60i (possibly 1440x480 with pixel repetition for the same reason as above)
720x576/50p
720x480/60p (and 59.94p)
1280x720/50p
1280x720/60p (and 59.94p)
1920x1080/50i
1920x1080/60i (and 59.94i)
1920x1080/50p
1920x1080/60p (and 59.94p)
1920x1080/24p (and 23.976p)
(25p and 30p formats are a bit odder and possibly less standardised)
I would also expect to default to ITU 601 16-235 colour space for 480 and 576 line output formats, and default to ITU 709 16-235 colour space for 720 and 1080 line output formats - unless told to do otherwise.
Where stuff may be a bit less clear-cut js some of the non-TV formats like 1440x900, 1680x1050, 1920x1200 etc. AIUI some of these fiddle with blanking timings and there may be multiple versions of them. However the TV standard specs are pretty set in stone in pixel clock, active line width etc. terms.
(Total line counts for the two SD and SD progressive formats are 525 for 480 line systems, 625 for 576 line systems respectively - and like vertical resolution thus vary with frame rate as a result. The total line count for the HD formats is the same across frame rates and is 750 for 720 line systems and 1125 for 1080 line systems.)
RE: [i.MX6] XBMC running on Freescale SoC's - emveepee - 2014-02-23
(2014-02-19, 02:17)wolfgar Wrote:(2014-02-18, 11:56)Koying Wrote: I *think* it is 3.10.9-1.0.0 alpha. It come from http://jas-hacks.blogspot.co.uk/2013/12/imx6-debian-jessie-gpuvpu-3109-100.html via http://imx.solid-run.com/forums/viewtopic.php?f=8&t=326Thanks will check against my own version...
Stéphan did you find out? I expect you are running a flavour of 3.0.5 with your utilite patches?
Now that 3.10 is up to beta I hope the manufactures all start will start moving to it too.
Martin