search

dnschneid / crouton

Chromium OS Universal Chroot Environment
https://goo.gl/fd3zc?si=1
BSD 3-Clause "New" or "Revised" License
8.58k stars 1.24k forks source link

XBMC Very slow on samsung arm ? #376

Closed YanouHD closed 9 years ago

YanouHD commented 11 years ago

Hi ! So, i tried xbmc but it's terribly slow can't we run it smooth ? Like other softs and games ? Thanks !

dnschneid commented 11 years ago

XBMC currently runs inside of Xephyr on ARM, which means no hardware acceleration. It doesn't have to though; it could be launched directly using host-x11 and perhaps perform better, a la #204.

Try the following: sudo enter-chroot -t xbmc exec sh -c 'croutonwm & exec host-x11 xbmc' and see if that does what you'd expect. If so, and if performance is significantly better, it's worth considering using that by default on ARM.

YanouHD commented 11 years ago

Thanks for commenting, but after typing this command, i got this : Entering /usr/local/chroots/precise... open /dev/sequencer or /dev/snd/seq: Permission denied

And it's always laggy. Any other suggestion ?

drinkcat commented 11 years ago

XBMC will be tricky to get working with hardware acceleration on the Samsung ARM, but it should be doable as some people as using it on the Raspberry Pi...

I just tried to start it on precise, and it fails on startup (it says it needs OpenGL hardware acceleration), how did you even get it to start?

As far as I can tell, XBMC packaged with Ubuntu (and Arch) only comes with OpenGL support (--enable-gl), but the Samsung ARM does not have OpenGL support, only OpenGL ES. So you'd need to recompile it with --enable-gles (which apparently can take a very long time and a lot of memory).

You could try some prebuilt packages (maybe this one: http://michael.gorven.za.net/raspberrypi/xbmc, but it's a bit outdated now). Then copy over the OpenGL ES libraries from Chrome OS to the chroot (/usr/lib/libEGL*.so* and /usr/lib/libGLES*.so*, and maybe something in /usr/lib/xorg/modules/, I can help with more detailled instructions if you want to try this).

Not for the faint of heart I'm afraid ,-)

@dnschneid : We may want to disable XBMC by default on ARM... Same problem as gnome & cinnamon...

drinkcat commented 11 years ago

Oh, and this error: open /dev/sequencer or /dev/snd/seq: Permission denied may be fixed by installing the audio target (that's the preferred solution). If not, adding your user to the hwaudio group will surely work (you'll lose CRAS forwarding, though).

rhpijnacker commented 11 years ago

Because I would also love to run xbmc on my Samsung Arm chromebook, I decided to see how far I would get.

The last view days I've been trying out various versions of ubuntu distributions, recompiling xbmc from sources (--disable-gl --enable-gles). I'm using the Chrome OS versions of libEGL* and libGLESv2* as described above.

I am happy to report that today I was able to run xbmc 11 in Ubuntu 13.04 (raring) using the older xbmc packages as described by https://wiki.ubuntu.com/Nexus7/UsingTheDevice#Nexus_7_with_Ubuntu_getting_useful:_Media_Player.

Unfortunately the complete system freezes regularly, requiring a forced cold boot and sound does not work. On the bright side: I was able to watch a video, which ran nice and smooth.

I'll be trying some more variations in the coming few days. When I get something running that does not freeze, I will post more detailed 'installation instructions'.

dnschneid commented 11 years ago

Awesome work! Looking forward to seeing what you come up with.

rhpijnacker commented 11 years ago

Today I installed a fresh xbmc+audio target for saucy and recompiled the xbmc v11 in that. After some fiddling with the ubuntu package, I got all dependencies figured out and it actually built. Now the audio works, but video is staggering... ;( The reason I tried saucy was to avoid a problem with libudev0 that I had in raring. This problem seems to be solved, but still the system freezes after a while.

I would like to investigate this further, but unfortunately there is no useful logging (or I do not know where to look). Ofcourse, it is to be expected that you do not get logging for a freeze, since the system... well... freezes.

Do you have any ideas where I could start asking questions?

One thing I would like to do is see if other GLES programs suffer from the same problem. es2gears runs fine, but probably does not do that much interesting. The unity target refuses to install because of the lack of gles. Might be fun to run it on the host X server, though... Which other programs that use GLES would be worthwhile checking out?

dnschneid commented 11 years ago

@rhpijnacker: if you extract the crouton installer with -x (cd ~/Downloads; sh -e crouton -x), you can modify crouton.unbundled/targets/unity to remove the release restrictions, then run installer/main.sh like you would the crouton installer to install the unity target. If Unity works correctly in the host X server with this method, that's quite the breakthrough for ARM crouton.

As for other GLES applications; I believe SDL can be compiled with a GLES backend, in which case most 2D SDL games that use SDL's rendering primitives and not OpenGL directly will be a good test. I'm not sure what 3D games are compiled for GLES.

rhpijnacker commented 11 years ago

I already tried to apt-get install unity in the xbmc chroot, which frooze, just like xbmc. To be sure I installed the unity target as you specified, but the result is the same: a frozen system. It looks like using libEGL* and libGLES* like this might just not work, but it would be interesting to know what causes the problem.

drinkcat commented 11 years ago

@rhpijnacker: I had similar issues with sample OpenGLES apps, and playing with weston/wayland, so it's not really a surprise to me (it would work for a while, then freeze)...

I didn't try to dig much further, is there something in /dev/pstore/console-ramoops after a forced reboot?

Have you tried on different Chrome OS channels (dev?)?

ARM just released some updated drivers (http://malideveloper.arm.com/develop-for-mali/features/graphics-and-compute-development-on-samsung-chromebook/), hopefully they will trickle down the official Chrome OS releases soon (if these new drivers fix the problem: not guaranteed).

rhpijnacker commented 11 years ago

@drinkcat:

I didn't try to dig much further, is there something in /dev/pstore/console-ramoops after a forced reboot?

Yes there is. I would not know what to do with it though, it seems to be binary data.

2013/10/28 drinkcat notifications@github.com

@rhpijnacker https://github.com/rhpijnacker: I had similar issues with sample OpenGLES apps, and playing with weston/wayland, so it's not really a surprise to me (it would work for a while, then freeze)...

I didn't try to dig much further, is there something in /dev/pstore/console-ramoops after a forced reboot?

Have you tried on different Chrome OS channels (dev?)?

ARM just released some updated drivers ( http://malideveloper.arm.com/develop-for-mali/features/graphics-and-compute-development-on-samsung-chromebook/), hopefully they will trickle down the official Chrome OS releases soon (if these new drivers fix the problem: not guaranteed).

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/376#issuecomment-27186315 .

drinkcat commented 11 years ago

The beginning should be plain text (kernel log), and the rest is all zeros (IIRC).

dnschneid commented 9 years ago

I don't think this will be getting any faster unless freon brings native xorg on ARM platforms.