+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Help and Support (/forumdisplay.php?fid=33)
+--- Forum: XBMC General Help and Support (/forumdisplay.php?fid=111)
+---- Forum: Linux and Live support (/forumdisplay.php?fid=52)
+---- Thread: XBMC Linux port questions and answers... (/showthread.php?tid=26097)
- nate12o6 - 2007-05-07 15:43
Cant wait!
Wow - deeceefar2 - 2007-05-08 06:30
I never thought this day would come; keep up the good work everyone. I'm really in awe this is actually happening. I'll be happy to help beta test if you need.
- t029248 - 2007-05-08 18:03
deeceefar2 Wrote:I never thought this day would come; keep up the good work everyone. I'm really in awe this is actually happening. I'll be happy to help beta test if you need.
I agree, when it's available for testing i will we happy to do so, including providing feedback... I hope it stays easy to config, Media Portal Config is nerve wrecking.
Linux port questions... - Gamester17 - 2007-05-09 15:30
These questions goes out to Yuvalt however if anyone else care to fill me in then please do:
Question-1: I read that you deviced not to change all the Win32 API calls, but rather implement them in Linux. How do you handle that? Have you implemeneted a re-usable wrapper or common library based on code from the WINE project, or? if not (yet) would that be good idea (to borrow code or library parts from the WINE project)?
Question-2: How do you handle DirectX API calls (2D/3D video, sound, input devices, etc.), have/will you implement those in Linux or SDL or change them in XBMC? Again maybe add a wrapper from selected code parts or libraries from the WINE project? There are also other open source projects with related wrappers like for example http://sourceforge.net/projects/dxglwrap/ (a DirectX to OpenGL wrapper), though the WINE project is probebely more up-to-date(?).
Question-3: Does the OpenGL renderer handle overlay for video (overlay texture like for example the menu on top of video)
Question-4: How do/will you now handle multiple output modules/renderers (auto-detect or static on build)? By the way, please keep API open for future Video Acceleration possibilities (for GPU assisted video decoding).
Question-5: How do you handle the skin texture compression format? can the same packed/compressed xpr skin-files be used under both Linux and Xbox/Win32? If not should we plan to migra to a other texture compression format that can be compatible under all operating-system and be decompressed/unpacked xpr using both DirectX and OpenGL?
Questsion-6: How do you handle the out the multiple modules (ALSA vs. OSS vs. DirectX DirectSound? auto-detect or static on build, or does SDL handle it?
Question-7: How well does the DLL loader in XBMC handle loading players such as paplayer, mplayer and the dvdplayer under Linux? Does the players (or the DLL loader) have to be modified or can they be loaded 'as is' under Linux? Maybe a common Win32 registry emulator is needed as well?
Question-8: Have you already implemened IR (infrared) remote support under Linux?, if not may I recommend Lirc and Wlirc (maybe add as a library/module to libSDL?). If possible maybe even replace the Xbox IR library (from the XDK) with a ported version of lirc/wlirc to stay consistant across platforms.
Questions-9: Have you already looked into using Valgrind for debugging under Linux? (see http://valgrind.org and http://wiki.winehq.org/Wine_and_Valgrind). It can probebely help find memeory-leak bugs, etc. indirectly for XBMC on the Xbox as well, (ie. fix them for Linux and they will be fixed on the Xbox and Win32 as well).
Question-10: Have you/we decided on any Linux porting guide-lines?, like for example:
* Code documentation (DocBook, rst, or doxygen for the code documentation steps)
* Modular design (independent modules made upp by localized/isolated code libraries without dependcies)
**XBMC should still compile and run if a module is disabled/removed
* Cross-platform / cross-compiling; aim to compile and run on at least, Xbox, Win32 (Windows XP) and Linux
* Aim for the GUI/interface to run smoothly on a low spec computer (less than 1Ghz)
* Avoid harddisk trashing (access read/write), utilize RAM memory, no harddrive paging. Aim to run on Solid-State (CompactFlash)
* Fast load and boot times for end-user perception (other thing can still run/start in the background without the user knowledge)
**15-seconds or less from when the end user press the power-button on the computer til he/she can browse the GUI
PS! Great stuff with the Linux port so far, keept it up
- yuvalt - 2007-05-09 19:50
Gamester! Great to have you back... long time no see
Regarding your questions:
1. No, we have implemented by ourself the missing functionality. I looked into the Wine source (and in fact ran the Win32 skinning tool with Wine). One thing I can say - Wine is a big mess and I couldn't actually take anything from there since the code is so complex.
2. We didn't implement DirectX, instead we ported all the GUI stuff under guilib to SDL. We are still uncertain of the performance of this and we may end up porting the code again to OpenGL (although I doubt we'll do it). Again, I looked into Wine and it was extremely complicated.
3. We didn't implement this yet. We are still discussing what's the right thing to do and how to do all the conversions efficiently.
4. As I said video rendering is not done yet. We will need to look into Xv which is the X11 extension for video output, which is accelerated to some extent for NVidia and ATI.
5. Just ported the XPR unpacking code. Nothing too much about it.
6. Currently we use SDL_mixer but this is for the GUI sound. I think SDL_mixer uses ALSA. We'll need to see if this is enough, especially for digital output.
7. Still not implemented.
8. That is my plan as well. From looking into lirc, all I can say is that is quite complicated.
9. I used it once to find a memory leak and it indeed worked. Some devs use Kdevelop, which is integrated with Valgrind.
We have not decided on any guidelines. I think we are currently experimenting. So far the GUI seems a bit slow since it's really build to be run with 3D acceleration. We will either need to disable some features or support OpenGL or both.
One of my goals is to have this run from a USB flash memory with paging disabled.
sandbox? - Gamester17 - 2007-05-09 21:37
Very cool! I apologize for all the newbie questions, just very exited about the future potential this inititive could bring, so got a few more:
How about creating a sandbox (isolated runtime enviroment) which XBMC can play in alone so it does not mess with other applications running on the same system. The good thing about that is that it will proactivly solve many future compatibitiy issues, on the other hand it would limited the possibility of XBMC interacting with other software application and hardware devices (unless a function is specificly opened/created for that purpose, which as example it should be for the My Program section by default to allow it to launch other executables/programs). This would create like a virtual system and that combined with SDL will make the envioment very close to the Xbox platform and thus make development easier as the sandbox looks and is limited the same way on all systems with the same parameters.
http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29
Kind of like an game-console emulator, the hardware underneath does not matter for debugging as all 'ROMS' uses the same libraries. Maybe even checkout the unfinished Xbox emulator for ideas, (now I'm not suggestion to copy that stright off, I mearly refering to the concept of running everything within a virtual machine)
http://www.caustik.com/cxbx/
An alternative to a sandbox could be to limited the hardware platform that end-user will be allowed to use, like the Xbox 360, PS3, AppleTV, and/or one chipset like VIA Embedded serie of EPIA motherboards
http://www.via.com.tw/en/products/mainboards/
http://www.via.com.tw/en/products/embedded/
yuvalt Wrote:I hadly know anything about Linux (I always been a Microsoft Windows user) so I probebely not comment on this, however I will but I hope you will excuse my ignorance (I am probebely completly wrong here): Maybe it is my missunderstanding based on the screenshot you posted in a other thread showing XBMC GUI running under X Window System (Linux graphical interface, commonly X11 or X); if you are aiming for fast initial startup from a cold power-on boot then isn't X bloat when you will normaly only be running the XBMC GUI in full screen as the sole application running on the computer? I mean you will you have to run X to run XBMC on Linux?, should it not be able to load/run directly the command line? According to wikipedia.org Xv (X video extension) is outdated today and has not been updated updated since December 1994(?)Gamester17 Wrote:Question-4: How do/will you now handle multiple output modules/renderers (auto-detect or static on build)? By the way, please keep API open for future Video Acceleration possibilities (for GPU assisted video decoding).4. As I said video rendering is not done yet. We will need to look into Xv which is the X11 extension for video output, which is accelerated to some extent for NVidia and ATI.
yuvalt Wrote:Emulation of the Xbox DirectX functions may also be interesting for the .vis (visualizations) and .scr (screensavers ) DLLs to be able to run them 'as in' under Windows, (not sure if this DirectX to OpenGL wrapper could be of any help there; http://sourceforge.net/projects/dxglwrap/). Alternativly rewrite each of those induvidual visualizations/screensavers DDLs so that they also support OpenGL (and can detect which type of platform they are running on).Gamester17 Wrote:Question-7: How well does the DLL loader in XBMC handle loading players such as paplayer, mplayer and the dvdplayer under Linux? Does the players (or the DLL loader) have to be modified or can they be loaded 'as is' under Linux? Maybe a common Win32 registry emulator is needed as well?Still not implemented.
yuvalt Wrote:Would it be best to implement it through the SDL library, (building it into a plugin module/extention), so that lirc/wlirc talks only to SDL and then translate/parse it to XBMC (so that XBMC do not have to talk directly to lirc/wlirc)?Gamester17 Wrote:Question-8: Have you already implemened IR (infrared) remote support under Linux?, if not may I recommend Lirc and Wlirc (maybe add as a library/module to libSDL?). If possible maybe even replace the Xbox IR library (from the XDK) with a ported version of lirc/wlirc to stay consistant across platforms.That is my plan as well. From looking into lirc, all I can say is that is quite complicated.
yuvalt Wrote:So far the GUI seems a bit slow since it's really build to be run with 3D acceleration. We will either need to disable some features or support OpenGL or both.I believe OpenGL can accelerate both 2D and 3D.
http://www.libsdl.org/opengl/index.php
http://www.libsdl.org/cgi/docwiki.cgi/Using_20OpenGL_20With_20SDL?action=highlight&value=opengl
However according to wikipedia.org, also Xv feature hardware scaling and YUV acceleration (2D hardware acceleration), Xv also XVideo feature hardware overlays, and XvMC support motion compensation and iDTC for video decoding.
http://en.wikipedia.org/wiki/X_video_extension
http://en.wikipedia.org/wiki/XvMC
SDL for XBMC_PC as well? - Gamester17 - 2007-05-09 21:52
Slightly of topic; would it be a good idea to implement SDL in XBMC_PC (XBMC for Win32) in the same way for consistancy?
- spiff - 2007-05-10 13:33
opengl can only do 3d. opengl es can do 2d as well.
however that's not a big issue at all - after all we use direct3d already on the xbox.
yes xv is nice, however xv will be the equivalent of using the hardware overlay renderer on the xbox now - no transparencies.
- stickman - 2007-05-11 04:11
I've built and tested what's ready so far and I'm astonished you managed to get this thing working.
Even though it doesn't do anything so far, it looks promising. I neve though I'd see the xbmc interface working in a computer.
I'll be building it everyday to check for improvements. I think it's really worth it
- dogk1cker - 2007-05-11 04:30
This is AWESOME, even if I am the last one to say it. I give my toast and will further drink to these guys. If they ran for president, I'd vote for them!
Ok, since my sucking up is done I can offer some humble requests/opinions. First, I really like my xbox and the major reason is that it is an appliance. I push a button and it turns on and the OS doesn't get infected or needs patching every other day. Technically, it's a static hardware state and all the insides are all the same from one to another xbox. Now we are all looking for the XBMC 2 platform.
I am a lover of linux but I dread the fact that I'd have to build another machine and find all the required hardware including the HDMI card(which is a must). Seems to me, to further continue the appliance idea with all the necessary components in one nice package, it should be another gaming platform or the iTV.
Whatever you guys choose, it should have HDMI because that's what I am missing from the current xbox running XBMC. But, looking at the options the iTV is the cheapest of the appliance solutions. The only draw back is that you can't play hacked games on it. For me, I bought my 6 Xboxs' so I could put XBMC on it, not to play games.
Love me or flame me.. I am stickin to it!
Dogk1cker
------------------
-Dooood you take my bone?!