LinuxMCE is all about control. Even the media support in LinuxMCE is nothing more than a consolidation point to figure out where to fire messages and for what reasons. The exception to this is of course the stuff needed to create the various data grids for media, but that's not relevant here.

In the end, you have two devices that must be made:

* a Media Stream plugin, which registers itself for media players of a given device template, and creates a MediaStream object for them (read src/Media_Plugin/MediaStream.h), describing the media playing, and its targets etc. The purpose of the plugin is to figure out where the stream needs to go (the target devices in an entertainment area), and what commands need to be done to make that happen.

* a Media Player, which is literally a target device that accepts commands to go do something (Play, Pause, ff, rew, change subtitles, etc..), and it sends events when something happens (Media is playing, a menu is on screen, etc.). It usually has no user interface of its own.

The commands that are sent from Orbiter, are sent to the Media Plugin, which send them to the Media Plugin providing the MEdia Stream for the target EA, which forwards them to the target player. This is actually done transparently, as long as you change one critical piece of code in ReceivedCommandForChild in the plugin. (instead of INVALID COMMAND, you send back INVALID DEVICE, oddly enough.)

Your task, with omxplayer, is to build a player, which has two threads:

* the DCE thread, which is already made, this is made by DCEGen, and it's literally fill in the blanks.* the media player thread, this literally, you spawn at some point during initialization (CreateChildren, and GetConfig are good choices here. Look at Xine_Player for this.)

You thread through a pointer to the DCE thread to the player thread, as a callback mechanism, and use that to pass back anything the media player stream needs to send back to DCE.

For communication with the media player thread, you of course pass through a pointer to the media player thread, and you use it...

you will notice the PLUTO_SAFETY_LOCK, this is a macro provided literally as a convenience, passing in a mutex, it literally locks the mutex, until the PLUTO_SAFETY_LOCK falls out of scope. This is needed because of course, the DCE stuff is a separate thread, and commands will be called asynchronously.

The other bits needed of course, the device data for the omx player device will have a device data called Name (look at Xine Player), this is literally a WM_CLASS.WM_NAME tuple, i.e. omxplayer.omxplayer .... use wmctrl -l -x to get this. Your player should explicitly set this, and it should match in the device data, this is so that Orbiter will grab the window appropriately.

Xine_Player does have additional window manager logic. You'll need to decide whether this is appropriate or not.

In the database, you just need to provide a mapping for DeviceTemplate_MediaType, so that your omxplayer player device is provided there, and that it is provided for type 4 and/or type 5 (in the mediatype table, 4 is audio, 5 is video.), and that these match what you're changing in your omxplayer plugin's Register method.

Once this is there, the stuff should at least START to work. Your job after this point is to literally provide something the media player can play, and to ferry back changes in the media player as needed. This is entirely up to you. an absolute file path is passed into MH_Play_Media, and in xine_player's case, this is passed in verbatim in most cases, unless you are of course streaming (sending to multiple EAs,) in which case the plugin starts the source player, and sends a fifo://source_player_address/ to the second player, AGAIN, THIS IS ARBITRARY! This is a URL that xine can understand, it knows how to do this, and the Plugin figures out what it needs to do, and sends the appropriate message to the players.

armel for now - AFAIR I need 64bit host for bcom toolchain cross to hfp. I didn't dig too far.I did download the new rasbian image today so might take that for a whirl.

-Coley.

I may go back and stick with armel for now - unless I compile my own qt5 _again_ for hardfp. And I feel that would involve getting dirty with some some qt config options. Although you can pass in Bsquask as a distro option, might be worth investigating... must add to list of things to do.

armel for now - AFAIR I need 64bit host for bcom toolchain cross to hfp. I didn't dig too far.I did download the new rasbian image today so might take that for a whirl.

Ah, yes the pi foundation tools. You can compile under qemu in a raspian chroot. I rolled an armel and armhf set for i386 with crosstool-ng. I'm building armhf in a cross compiled and a qemu compiled version right now to compare any differences afterwards. I can provide any of the pluto libs you may need for armel or armhf. It's been easy enough I may try an amd64 cross compile as well. That could mostly be built with a stock database.

I may go back and stick with armel for now - unless I compile my own qt5 _again_ for hardfp. And I feel that would involve getting dirty with some some qt config options. Although you can pass in Bsquask as a distro option, might be worth investigating... must add to list of things to do.

My list always seems to grow faster than it shrinks. Let me know if I can be of any assistance.

can you send me your .config files please, for hard and soft.I had looked at crosstool and buildroot when I started on this - but when I could just get the bcm toolchain from git I parked it.

Sure. They should be attached. I'm installing the raspian build on my pi now to see if everything works there or not. The squeeze build was already tested on the pi so it works. The squeeze build was done with crosstool-ng 1.13.3 and the raspian build was created with crosstool-1.15.3.

Thanks for those.After something you said and hari also in IRC - I dug around and now have a raspbian armhf chroot env set up, this has to be the most straight forward so far! - chroot into env - svn co ... - cd <package of interest> - make