[09:24] hi, is there even theoretical change to get xbmc working on pandaboard? [09:25] i just started it after apt-get install and it is extremely slow, gui updates takes forever [09:27] i think linaro offers older xbmc images [09:32] ikke-t: http://rsalveti.wordpress.com/2012/07/29/pre-built-images-for-xbmc-ubuntu-12-04-based-with-hw-acceleration-finally-available-at-linaro/ [09:36] thanks, I'll give it a spin. === k1l_ is now known as k1l [12:14] infinity, http://paste.ubuntu.com/1152481/ how about that for finiding the root UUID ? [12:15] (for flash-kernel) [12:28] omap4+armhf Aug-17 image the install fails with a system error on pandaboard ES. also there is no desktop in the live image just the 2 icons. [12:29] expected, there are no 3D drivers on the image and unity-2d was dropped [12:29] ok thanks [12:30] thats unlikely to change in the short term [12:30] i will keep that in mind [12:57] but the "system error" sounds scary [13:02] ppisati, agreed [13:14] ogra_: i'm planning the 3.5 upload today, what's the state of the image? [13:14] server seems to be fine [13:14] desktop is dead and will stay so until we have the 3D driver [13:15] what?!?! [13:16] ppisati, see above [13:17] ubuntu doesnt ship any 2D capable desktop anymore since yesterday [13:18] so, no matter what we do, next omap4 desktop image is going to be broken [13:19] yes [13:19] until we have a working PVR driver [13:19] can't remember... [13:19] but i think i tried unity on omap4 without pvr driver [13:20] sure that wasnt unity-2d ? [13:20] no [13:20] but again [13:20] i could be wrong [13:20] i've my panda connected [13:20] let me try [13:20] ubiquity and the install should work (if there isnt a ubiquity bug indeed) [13:20] they both dont use 3D [13:21] but you wont be able to run a desktop session nor will you have a desktop after install [13:25] flag@panda:~$ dpkg -l | grep pvr [13:25] flag@panda:~$ uname -a [13:25] Linux panda 3.5.0-207-omap4 #13 SMP PREEMPT Fri Aug 17 13:02:27 UTC 2012 armv7l armv7l armv7l GNU/Linux [13:25] and i'm logged in a ubuntu session [13:25] on todays image ? [13:25] it's still P/omap4 userbase [13:26] precise automatically falls back to unity-2d [13:26] ps ax|grep unity-2d [13:26] ogra_: uhm no [13:26] qunatal dropped all fallback mechnaisms yesterday [13:26] ogra_: yes [13:26] ogra_: you are right [13:26] ogra_: it's unity2d [13:26] crap... [13:26] i.e no desktop from todays image on [13:27] dont tell me :) [13:28] is skaet aware of this? [13:31] ppisati, i would assume so ... will ask her in the release meeting today :) [13:36] ogra_: i'm just following up in the "Unity Going Forward" thread right now [13:37] fyi the plan is to get PVR on the image by default [13:37] all other arm desktops will have to swithc to something else [13:39] ppisati, also see the last paragraph here https://lists.ubuntu.com/archives/ubuntu-release/2012-August/001754.html [13:40] * ppisati is officialy sad... [13:41] ppisati, same here ... especially after rickspencer3 announced arm desktop should be a first class citizen .... we will lose all non panda testers [13:41] ogra_, unless the tegra driver ever gets fixed I am going to have to switch :( [13:42] grrrrrr [13:42] (and even the ones using panda will pretty quickly uninstall unity and go with something that doesnt block their video playback) [13:42] rickspencer3, why grr ? it is what it is [13:42] ogra_, I guess we can keep Unity 2d alive ourselves for the panda board (assuming that's what you were discussing) [13:42] ogra_, you are right [13:43] rickspencer3, well, i dont really want to have to special case official images ... [13:43] tbh, I don't blame them for dropping 2d under the circumstances [13:43] i was assuming unity-2d stays around in universe anyway and planning to probably switch ac100 to it ... [13:43] and beagle probably too [13:44] as i understand the panda image it should not differ from normal desktop if possible [13:44] so people will actually test 3D experience on arm [13:44] the prob here is that the GPU is already fully loaded when using unity on that device [13:45] if you want to play a full HD movie while compositing is enabled, the gPU goes to its knees [13:45] oh, and indeed the gstreamer hacks from TI dont allow to play any non HD movies anymore :) [13:46] so i fear people will rather have not such a positive experience even though we can demo the bling now [13:50] ogra_, the good news is that they are setting up Unity 3d with a mode where there are limited effects so that it can run ok in KVM [13:51] maybe this will work [13:51] might, depends on how much composite that will need [13:52] I wonder if we can hack it a bit to make it even lighter? [14:17] heh [14:17] * ogra_ just stumbled over lscpu [14:17] what a pointless tool on arm === suihkulo1ki is now known as suihkulokki [14:21] ogra_: going to pull 3.5 Q/omap4 about now... [14:22] \o/ [15:10] I still think 3D only Unity is an overall bad idea. Has it been tested with remote desktop instances? (not VNC) [15:12] * robclark wonders how well llvmpipe works on arm.. [15:12] ie. how much is it going to suck if you don't have 3d drivers [15:13] it doesnt work at all afaik [15:13] btw.. is there an easy way to disable apport? When I'm debugging x11 and gfx stuff and I know that things are crashing, it would be nice not to get flooded w/ "a problem has happend" dialogs [15:14] yeah, /etc/default/apport [15:14] cool, thx [15:14] hmm, no llvmpipe.. I wonder how well unity-3d would work out of the box when you have no 3d? [15:15] About as well as it does now. Not at all. [15:15] Users will be greated with a nice pretty blank (albeit orange & purple) screen. [15:15] heh.. well, I do have unity 3d working here now (on 12.04.. but w/ an special kernel [15:16] basically I need to do something a bit more extreme and bypass most of omapdss to solve the special effects that you get otherwise [15:17] this omap ppa for precise plus this kernel works fine w/ unity3d: http://people.freedesktop.org/~robclark/try9 [15:50] at least it seems that with the new compiz things are working way better than before [15:50] way faster [15:50] but would be indeed nice to check with llvmpipe [15:51] but don't know if people already tested for x86 [15:51] all i know about current llvmpipe status is that it simply dies on arm [15:51] not talking from experience though [15:55] but I don't yet know if it's functional at x86 still [15:56] it apparently is, but requires a ton of horesepower [16:10] ogra_, I wanted to ask you about the new kernel being pushed out for the arm images.. will it solve the not able to boot the desktop bug or no? [16:11] what are the plans for implementing a 3d driver or othewise getting support for unity3d on a pandaboard? [16:12] we have a 3D driver that we plan to put onto the images once it works [16:12] ogra_, is that timelined to happen this cycle or no? [16:13] its in TIs and linaros hands ... but i would asume so, yes [16:13] until it is there (and until the compiz GLES bits are actually in the package which they arent either) we wont have a desktop [16:14] yes, hopefully in the next few days [16:14] goal is before feature freeze :-) [16:14] right, but that doesnt give us compiz yet :) [16:15] when is compiz going to be pushed? [16:15] after feature freeze? [16:15] doesn't seems right :-) [16:15] no idea, i would assume before ... [16:15] but they know GLES is an essential bit this time [16:15] so they might delay for it and make it an FFe [16:27] Ooo, a 3.5.0 omap4 kernel. [16:27] Does it work? [16:27] works better than the 3.4 one [16:27] at least on panda ES [16:27] Shiny. [16:28] yeah [16:28] didn't have a freeze with 3.5, with 3.4 it was happening mostly on every boot [16:28] probably because of the powermanagement issues we had with it [16:29] ogra_: we're using the WIP compiz package at the linaro ppa, and it's working quite well already [16:29] my panda test install is running without issues since wed. [16:29] so I think they are getting closer to the point of actually pushing the new package to ubuntu [16:29] rsalveti, plain upstream ? [16:29] well, yes, i was quite pushy the last weeks :) [16:29] I think there are still a few minor pieces that are part of another branch, but most already got merged [16:30] but they were still drowning in gsettings issues until very recently [16:30] oh, ok [16:30] so probably blocked by some other generic issues then [16:30] well, as long as we have *any* desktop by release day i'm happy :) [16:30] :-) [16:30] * ogra_ starts to prepare an openbox fallback session ... just in case :P [16:32] rsalveti, oh, btw ... bug 1035407 [16:32] Launchpad bug 1035407 in pvr-omap4 "pvr-omap4 package doesn't declare a dependency on the corresponding X video ABI" [High,Triaged] https://launchpad.net/bugs/1035407 [16:33] do you want to fix that with your new upload or does it make any sese if i upload a fix with the current package from the archive [16:33] let's fix it with the new one [16:33] * ogra_ thought so [16:33] seems thats a new policy [16:34] I thought initially that the abi wouldn't be an issue because the driver is part of a hook at the -omap one [16:34] but it seems that both needs to match [16:34] for dependencies in any case [16:35] yeah [16:35] and isnt the driver also linked against the xlibs somewhere ? [16:35] or does -omap completely shield that off [16:35] would need to check, but it's probably linked to xlibs and dri as well [16:36] yeah, so thats bound to the abi then [16:37] Depending on the X ABI isn't even remotely a new policy, it's just that binary drivers got it wrong in the past. [16:37] And pvr-omap4's packaging was cargo-culted from nvidia or fglrx, so inherited the same wrongness. :P [16:37] yep [16:38] tegra has the issue as well ... but i'm waiting for nvidia for that one [16:42] infinity, soo, for flash-kernel i was thinking about something like this: [16:42] UUID=$(blkid -o value $(mount 2>/dev/null| grep "on /${1%/} " | tail -n1 | cut -d' ' -f1) 2>/dev/null|head -1) [16:42] do you think relying on the mount output is enough or should i also check other places (fstab etc) [16:42] rsalveti: 3.4 Q/omap4 was an exact photocopy of tilt/tilt-tracking back then, so you should have hit the same problem with both [16:43] probably [16:43] the latest 3.4 one behaves better as well [16:47] ogra_: fstab has no guarantee of being right. [16:47] yeah, i thought so [16:48] its just that it will complain (or find nothing) if /proc isnt mounted [16:48] ogra_: Well, especially in the case where, say, you've moved the filesystem and are re-running flash-kernel specifically to fix things. [16:50] ogra_: Relying on proc for bootloader functions seems perfectly reasonable for me. It should error out if [ ! -d /proc/1 ] or something. [16:50] yep [16:50] looking at that line above i should probably scatter a few more "2>/dev/null" over it :P [16:51] * ogra_ is embarassed [16:57] heh === Quintasan_ is now known as Quintasan === heathkid|2 is now known as heathkid