[13:10] <ogra_> ppisati, i see bug 1018907 with your 3.5 kernel as well, could we somehow not provide omapdrm if there is no backend attached to it ?
[13:10] <ubot2`> Launchpad bug 1018907 in plymouth "plymouth in quantal on arm does only boot with black screen" [High,Triaged] https://launchpad.net/bugs/1018907
[13:14] <ogra_> oh, apart from the fact that omapfb seems to be gone ... drat
[14:39] <ogra_> ppisati, so is there any reason to not upload the new kernel already ?
[14:42] <ppisati> ogra_: i'm fixing audio ATM
[14:42] <ogra_> well, even without audio it wuld be helpful to the PVR driver guys to have it
[14:49] <ppisati> ogra_: my target is end of week
[14:49] <ogra_> ok
[14:49] <ppisati> ogra_: if i can get audio working, good
[14:49] <ogra_> yeah, just upload what you have by then
[14:49] <ogra_> it already looks awesome
[14:50] <ppisati> ogra_: besides, i won't be around from 27th Aug to 8 Sept
[14:50] <ppisati> ogra_: vacation
[14:50] <ogra_> hmm, so we should do a test session in friday then
[14:50] <ogra_> oh, wait, 27th is still a week out
[14:52] <ppisati> yep
[14:52] <ppisati> if i have it in the archive by friday, we have one week for testing
[14:52] <ogra_> great
[15:53] <ogra_> robclark, do you have any idea about bug 1018907 (and why the plymouth kvm handler doesnt work with omapdrm)
[15:53] <ubot2`> Launchpad bug 1018907 in plymouth "plymouth in quantal on arm does only boot with black screen" [High,Triaged] https://launchpad.net/bugs/1018907
[15:56] <xnox> ogra_: mee too, but on amd64 with cryptsetup which mangles grub fb options (?!) stuff =)
[15:56] <ogra_> xnox, ouch
[15:56] <ogra_> though i doubt it is the same issue ... mine seems to be on the kernel driver level
[15:57] <ogra_> (or the missing peieces of libdrm)
[15:57] <xnox> ogra_: e.g. the new crypt stuff I did for desktop fails to reboot in a VM =(
[16:21] <robclark> ogra_, if you have the setup to reproduce that issue, maybe you can somehow grab kernel traces w/ drm.debug=7?
[16:21] <ogra_> robclark, will do, no prob, is it supposed to work ootb with the kvm driver of plymouth ?
[16:22] <robclark> I'd expect so, unless plymouth is trying to special case every drm driver
[16:22] <robclark> if it uses libkms like the drm test apps do, it should work fine
[16:23] <ogra_> no, i think it tries the opposite, but if a driver has special needs it seems to ship a HW specific libdrm-$hw
[16:23] <robclark> if it is trying to special case every drm driver, and only knows about desktop drm drivers, then plymouth might need some changes
[16:23] <robclark> it shouldn't even need libdrm_$hw
[16:23] <robclark> libkms will fall back to using the "dumb" (ie. not tiled) scanout buffer allocation
[16:23] <ogra_> well, it needs it for radeon and nouveau apparently ... thats what made me wonder
[16:24] <robclark> (if there is no libkm_$hw backend)
[16:24] <ogra_> right
[16:24] <robclark> it is possible that plymouth pre-dates the "dumb" buffer allocation ioctl.. that is why I was asking what plymouth is doing :-P
[16:24] <ogra_> ah, well, let me produce that log
[16:25] <robclark> if you point me at de codez, I can go have a look
[16:45] <rsalveti> ogra_: we'll need to fix it anyway, we need to use omapdrm
[16:45] <rsalveti> also, integrating xserver-xorg-video-omap will not solve anything
[16:46] <rsalveti> that helps later, and it's needed by pvr, but it's not used by default
[16:46] <rsalveti> it needs a xorg file just to load the driver, which is something we don't want
[16:46] <rsalveti> I sent an email yesterday to the xorg-dev ml about this issue
[16:49]  * robclark suspect issue should be easy to fix.. I just need to look at the plymouth code and then I should be able to send a patch
[16:50] <rsalveti> robclark: https://code.launchpad.net/~plymouth-dev/plymouth/trunk :-)
[16:51] <robclark> thx
[16:57] <rsalveti> robbiew: http://bazaar.launchpad.net/~plymouth-dev/plymouth/trunk/view/head:/src/plugins/renderers/drm/ply-renderer-libkms-driver.c#L288 where it fails
[16:58] <robbiew> robclark: ^
[16:58] <robbiew> ;)
[16:58] <robclark> rsalveti, hmm, that *should* work
[16:58] <rsalveti> sorry ;-)
[16:58] <robclark> maybe a libkms backend missing?
[16:58] <rsalveti> does it need a backend for omap?
[16:58] <robclark> no, the 'dumb' backend should work fine
[16:59] <robclark> (and I think they should all get built in to one .so.. /me just checking)
[16:59] <rsalveti> and we're using the latest libdrm code
[16:59] <rsalveti> 2.4.38
[16:59] <robclark> rsalveti, do you see the same issue if you try to run modetest from libdrm?
[16:59] <robclark> it should be working in exact same way
[17:00] <rsalveti> ogra_: when was the last time you reproduced the bug?
[17:00] <robclark> yeah, looks like there is nothing special to enable when building libdrm to have the 'dumb' backend
[17:02] <robclark> rsalveti, fyi, this is what modetest does, which works: http://hastebin.com/wucabeqike.avrasm
[17:02] <robclark> ahh, hah, I see the issue
[17:02] <robclark> remove these two lines:
[17:02] <robclark>   ply_array_add_uint32_element (attributes, KMS_PITCH);
[17:02] <robclark>   ply_array_add_uint32_element (attributes, (uint32_t) *row_stride);
[17:03] <robclark> then use: kms_bo_get_prop(bo, KMS_PITCH, stride);
[17:03] <robclark> the dumb backend will fail out if you try to pass KMS_PITCH into the constructor like that
[17:03] <rsalveti> hm, ok
[17:03] <rsalveti> row_stride is passed as an argument
[17:03] <robclark> probably nouveau, radeon, etc, don't check for that.. they have their own custom libkms backends
[17:03] <robclark> right, it shouldn't be like that
[17:04] <robclark> actually, looking at latest libdrm, I sort of think it should be failing on desktop too
[17:06] <rsalveti> for both radeon and nvidia they are using their own calls
[17:06] <rsalveti> like radeon_bo_open and such
[17:07] <rsalveti> now it'd be interesting to check on a generic use case as well on the desktop
[17:07] <rsalveti> brb, will test it in a few
[17:08] <robclark> ahh
[17:08] <robclark> plymouth should be able to use libkms for everything
[17:08] <robclark> and not have to special case for nouveau, radeon, etc (fwiw)
[17:40] <rsalveti> interesting, wonder why we have special cases for them
[17:40] <rsalveti> could be because libkms wasn't working properly at that time?
[17:43] <Matt_O> could anyone point me to some sample code that shows how to do fullscreen GLES2 on the beagleboard without running X ?
[17:44] <Matt_O> I went to google and typed in "beagleboard GLES2 sample" and a bunch of my own web sites popped up as the top matches lol
[17:53] <robclark> rsalveti, I'd guess maybe they pre-date libkms?  Not sure
[17:57] <prpplague> just fyi, we are still taking feedback on the PandaBoard-NC - http://groups.google.com/group/pandaboard/browse_thread/thread/74b5c6cc761d2e3c#
[18:32] <ogra_> rsalveti, this afternoon
[18:33] <rsalveti> ogra_: just tested here with the latest image and it seems that it worked just fine
[18:33] <rsalveti> http://cdimage.ubuntu.com/daily-live/current/quantal-desktop-armhf+omap4.img
[18:34] <rsalveti> let me check the logs
[18:34] <ogra_> you have a splash after install ?
[18:34] <rsalveti> maybe because of the latest libdrm package
[18:35] <rsalveti> hm, not yet after
[18:35] <rsalveti> but at the installer
[18:35] <rsalveti> during the first boot
[18:35] <rsalveti> unless the set of packages used by the installer is not the same
[18:35] <ogra_> you want to edit the cmdline in preEnv.txt btw, fki doesnt handle changing it yet
[18:36] <ogra_> (after install before firest boot)
[18:36] <rsalveti> yeah, noticed that
[18:36] <ogra_> i didnt have any splash after instaklll and nothing with the 3.5 kernel from paolo either
[18:36] <rsalveti> [ply-renderer.c]                      ply_renderer_open_plugin:could not query rendering device for plugin /lib/plymouth/renderers/drm.so^M
[18:36] <rsalveti> [./plugin.c]                                  close_device:closing device^M
[18:36] <rsalveti> [./plugin.c]                                 unload_driver:unloading driver^M
[18:37] <rsalveti> got another error here at the installer's splash
[18:37] <ogra_> weird
[18:38] <rsalveti> so that's why it worked
[18:38] <rsalveti> it gave up on drm, and went over framebuffer
[18:38] <rsalveti> but that's still not the desired behavior
[18:39] <rsalveti> let me finish the installer and will check what happens after that
[18:40] <ogra_> looks like i have 2.4.38-0ubuntu1 of all the libdrm bits here
[20:19] <Finlandia> Hello, I have a performance problem running Ubuntu 12.04 on my Pandaboard. When idle the load average is 0.5 or even 1.3 ish and when browsing or apt-get it goes to 2.0 or even 3.
[20:20] <Finlandia> as reference, what load average (command top), should I expect to have after a fresh intall and leave it idle for 15min?
[20:20] <Finlandia> I came to this step: http://omappedia.org/wiki/Ubuntu_PPA  the repositories were correct, but I didnt have the "Install OMAP4 addons" (is that outdated?), so i tried to install it via commandline. evertthing was installed, and when I rebooted it, the display to HDMI/tv was black and flickering...
[20:20] <Finlandia> I tried taht because I thought ubuntu wasnt hardware accelerated, so slow performance in the desktop.. but now I fear its something hardware related, as even a fedora console has a high load average when idle.....
[20:21] <infinity> Finlandia: If it's actually completely idle, then you should expect close to zero.  But "when I run stuff, the CPU gets used" isn't a performance problem..
[20:22] <Finlandia> mmm, when opening firefox and watch a youtube vid, it skips alots of frame, maybe 1 frame every 2s
[20:22] <Finlandia> its not usable, and i dare to say atm the rPi is even faster..
[20:23] <Finlandia> is a fresh install of Ubuntu 12.04 hardware accelerated?
[20:23] <Finlandia> or do i need to install the OMAP4 addons somehow...?
[20:24] <Finlandia> how can I find out what the cause of the slow performance is?
[20:25] <RoyK> Finlandia: load avg usually means i/o is slow
[20:25] <RoyK> Finlandia: and the i/o on a panda is rather on the slow side, especially with a cheap sd card
[20:26] <RoyK> s/load avg/high load avg/
[20:26] <Finlandia> so a class 10 card is useless?
[20:27] <RoyK> my "extreme pro" sandisk card has 95MB/s printed on it - it can do 20MB/s on a good day
[20:27] <RoyK> problem is the bus is 8bits 20MHz or so (IIRC)
[20:27] <RoyK> so with a slow card, it just gets worse
[20:28] <Finlandia> so what do you suggest? dont use the SD card and run ubuntu from USB stick?
[20:28] <RoyK> that's probably even slower
[20:28] <RoyK> USB 2.0 isn't very fast
[20:29] <Finlandia> ok, so what can I do to make it go faster
[20:29] <RoyK> seems USB 2.0 should be able to do 35MB/s - that's mostly theory - most USB sticks can't do that
[20:29] <RoyK> get a fast SD card
[20:29] <RoyK> the one I have works fine
[20:29] <Finlandia> I seen yt videos with a good performance ubuntu.
[20:29] <RoyK> it's still slow compared to most other systems, but it works
[20:30] <Finlandia> I got a class 10 card, and writing the image on SD card goes quick enough. Can't remember the actual MB/s anymore.
[20:31] <Finlandia> but even a 15min idle (fresh install and doing aboslutling nothing except command top), uses the SD card continous (read/write) and results in a slow performance. that can't be right....
[20:31] <RoyK> class 10 is 10MB/s
[20:32] <RoyK> meaning it can probably deliver half of that in practice
[20:32] <RoyK> IIRC I used a class 10 when I first setup my panda
[20:33] <RoyK> Finlandia: apt-get install sysstat - enable it in /etc/default/sysstat, start it
[20:33] <RoyK> that'll make "sar" give you info about how the system load is over time
[20:34] <RoyK> system load, cpu load, i/o load, whatnot
[20:36] <Finlandia> ok, i'll try that, atm puting a new image on it, writing to SD card with 13MB/s...
[20:37] <RoyK> probably faster than most USB sticks can do
[20:37] <Finlandia> also installing xbmc is a good test to see if the board performance is good?
[20:38] <Finlandia> I can remember that I couldnt even start xbmc few weeks ago...
[20:38] <Finlandia> let alone run a 720p or even a 1080p movie...
[20:39] <RoyK> even browsing with precise on a pandabiard in 1080p is a horror
[20:39] <RoyK> it's a small thing, not good for what a PC can do
[20:40] <Finlandia> yeah ok, but compared to a rPi, I would expect atleast hte same and tbh a better performance :P
[20:41] <Finlandia> pandaboard has a better CPU/GPU than the rPi, right?
[20:43] <RoyK> not sure - the panda has a better cpu, but the rPi may have a better GPU
[20:44]  * RoyK bought some crap PSUs on ebay "rated" 2A, giving 4V on measuring between TP1 and TP2 on the rPi
[20:44] <RoyK> so, haven't tested it too much yet
[20:45] <Finlandia> ok, cheers  for the help :)
[20:59] <rsalveti> ogra_: also, mem=456M@0x80000000 mem=512M@0xA0000000 is not needed anymore
[21:26] <jimerickson> after todays update on omap4+armhf there is no desktop. bug filed.
[21:37] <jimerickson> bug #1037306
[21:37] <ubot2> Launchpad bug 1037306 in xorg "after todays update there is no desktop on omap4+armhf on pandaboard ES" [Undecided,New] https://launchpad.net/bugs/1037306