[04:24] <MrCurious_> installing 11.10 on a pandaboard, i am stuck in a loop asking language, location, ...
[04:24] <MrCurious_> anyone have any hints/clues?
[04:32]  * MrCurious_ takes his 4th trip through system configuration
[04:34] <MrCurious_> nice success sorted itself out
[06:22] <rsalveti> ogra_: infinity: can any of you review bug 978563?
[06:22] <ubot2> Launchpad bug 978563 in jockey "FFe: jockey support for pvr-omap4 (Pandaboard)" [Undecided,New] https://launchpad.net/bugs/978563
[06:22] <rsalveti> I just want to have another opinion on how to proceed with it
[08:39] <ogra_> rsalveti, oh, wow !
[08:43] <ogra_> rsalveti, has the second variant been tested ? i would prefer the second one, since we might want an nvidia-common on arm thats totally different from the x86 one at some point (for tegra)... and to not seed unneeded x86 packages indeed
[08:54] <lilstevie> whats this about with nvidia-common?
[08:57] <ogra_> read the bug :)
[08:57] <ogra_> it carries board definitions for nvidia and other drivers on x86
[08:57] <lilstevie> ah
[08:57] <lilstevie> reading bug now
[08:59] <lilstevie> when is unity 3d getting a GLES version :p
[09:00] <steev> i though it existed already
[09:01] <lilstevie> well I keep hearing that but never see it
[09:02] <XorA> I saw it mis render lots on omap4 a year ago
[09:02] <lilstevie> lol
[09:02] <steev> something something office of the something linaro executive summary iirc
[09:02] <steev> maybe it was the graphics wg mail
[09:02] <steev> something about it's in bzr, but as a branch
[09:03] <XorA> why anyone wants Unity 3D considering the terrible state of linux 3d no-one can answer :-D
[09:03] <steev> https://code.launchpad.net/~linaro-graphics-wg/unity/linaro-gles2
[09:03] <steev> XorA: since when?
[09:03] <steev> works fine here
[09:04] <suihkulokki> I'm pretty sure the current Linaro Ubuntu Desktop builds for pandaboard and snowball come with unity3d running :)
[09:04] <XorA> I have 3 computers, tried 4 different GPUs Unity 3D always runs so slow I can see individual frames render, then it tends to render some nonsense then crash
[09:05] <steev> XorA: were they modern gpus?
[09:05] <XorA> steev: moderns radeons, nvidia, intel and old intel
[09:06] <XorA> heh, maybe Im just pickier than average Linux user :-D
[09:07] <suihkulokki> and better bug reporter as well? ... ;)
[09:08] <steev> dunno, i'm not much a fan of intel cards (and the only one i have here is an 815 which isn't even remotely close to being considered modern), i have an APU system, which, well, sucks hard with ATi/AMD's drivers (seriously, did they just move the same team to AMD? wish they'd hire some people who knew wtf they were doing) but is decent with the opensource driver, quite usable, though there are issu
[09:08] <steev> es, but it's a fairly new platform.  all my nvidia cards work fine with nouveau.  i have a 7800, 310M, G210, 450, 580
[12:24] <ogra_> lilstevie, the gles version of unity should work in 12.04 since last week
[12:28] <janimo> ogra_, is the gles/unity in the archives already>
[12:28] <janimo> ?
[12:29] <ogra_> janimo, yes, broken with the next upload again though (since -desktop decided to go with a new upstream version tomorrow) ... i'm working on fixing it
[12:29] <ogra_> jockey support for pvr is uploaded too, sitting in the queue waiting for approval
[12:30] <janimo> ogra_, is the runtime selection part left for post 12.04 ?
[12:30] <ogra_> runtime selection ?
[12:31] <ogra_> of what
[12:31] <janimo> gles/opengl
[12:31] <rsalveti> ogra_: I tested the second version alredy, and worked as expected
[12:31] <ogra_> i dont think that bit made it into our paqtch yet
[12:31] <janimo> for x86 where both are possible depending on hw
[12:31] <janimo> ok
[12:31] <ogra_> rsalveti, thats good, since its already uploaded ;)
[12:32] <rsalveti> ogra_: oh! :-)
[12:32] <ogra_> janimo, and thats rather something to have in upstream
[12:32]  * rsalveti just woke up
[12:32] <ogra_> i dont want to touch any x86 related code with the arm patches in precise
[12:32] <ogra_> so that bit has to wait
[12:33] <marvin24> janimo: I updated the ac100 kernel tree during the weekend
[12:34] <janimo> marvin24, yes, seen that yesterday, did not get around to making a new package though yet. thanks for the reminder
[12:34] <marvin24> janimo: thanks, please also update the cpu errata settings
[12:35] <janimo> marvin24, I'll just sync up with the erratas you have in defconfig right?
[12:35] <marvin24> yes
[12:35] <marvin24> or disable CONFIG_PL310_ERRATA_588369
[12:36] <marvin24> and enable CONFIG_PL310_ERRATA_... eh
[12:36]  * marvin24 reads backlog
[12:36] <marvin24>  CONFIG_PL310_ERRATA_727915
[12:37] <marvin24> looks like omap has 588369 enabled, but I think tegra is not affected
[12:37] <marvin24> at least that is the conclusion on the tegra ml ...
[12:50] <lilstevie> ogra_: ok I should update my install then
[13:52] <janimo> slangasek, dpkg --assert-multiarch on precise prints an error. According to a linaro wikipage it should tell you if dpkg supports multiarch and that should be the case since natty
[14:00]  * ogra_ curses the compiz branch mess once again
[14:34] <slangasek> janimo: according to the source, it's --assert-multi-arch
[14:36] <janimo> slangasek, ok so just wiki typo
[14:36] <janimo> thanks
[14:36] <janimo> slangasek, do you know if the cross-build capable sbuild has any blockers from going from linaro ppa to precise?
[14:36] <slangasek> well, there's feature freeze :)
[14:37] <slangasek> I don't know anything about the code though, generally
[15:49] <rsalveti> ppisati: were you able to find the issue related with the lack of display after applying the stable updates?
[16:03] <ppisati> rsalveti: got the board today, i'm debugging it
[16:03] <rsalveti> ppisati: ok
[16:03] <rsalveti> ppisati: would you mind also taking a look at bug 924419
[16:03] <ubot2> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Medium,Incomplete] https://launchpad.net/bugs/924419
[16:03] <rsalveti> ?
[16:04] <rsalveti> ppisati: I believe we'd just need to disable CONFIG_MACH_OMAP4_PANDA_CAMERA_SUPPORT
[16:04] <rsalveti> if that is pushed, remember that this fix needs to land before the release, otherwise the pre-built images would still be using the older kernel
[16:04] <ogra_> i thought that was the concclusion we came to months ago
[16:05] <rsalveti> ogra_: yup, but it seems it still not fixed
[16:05] <ogra_> aww
[16:05]  * rsalveti just installed latest daily
[16:05] <ogra_> well, then we should make sure to have it disabled with the next kernel at least
[16:05] <ogra_> not sure there will be any uploads before release though
[16:06] <rsalveti> ogra_: yup
[16:06] <ogra_> so it wont help with the installer
[16:06] <rsalveti> ogra_: that's why I was concerned about it
[16:06] <ogra_> yep
[16:06] <rsalveti> because the main issue is related with the user experience with the isntaller
[16:06] <ogra_> right
[16:06] <ogra_> there are two ways to fix it indeed ... make ubiquitys cam detection better would be the other one
[16:07]  * ogra_ tries to find out where the pvr upload went
[16:08] <infinity> There should be one more kernel before release, re-based on the current linux upload.
[16:08] <rsalveti> I think if we just change ubiquity to open the camera device first, it might already be useful
[16:08] <infinity> ppisati: confirm/deny?
[16:08] <GrueMaster> Actually, having the driver detect and enable/disable would be better.  It isn't just Ubiquity that will fail, all apps that detect a camera will get a false feed.
[16:08] <rsalveti> but that would be a change for all archs
[16:09] <ogra_> heh, funny, so https://launchpad.net/ubuntu/precise/+queue?queue_state=3&queue_text=pvr tells me pvr source went to restricted .... but binaries ended up in universe
[16:09] <rsalveti> that's true
[16:09] <rsalveti> other softwares will also show an error saying the device is invalid
[16:09] <ogra_> (where they arent actually)
[16:09] <rsalveti> because it's the first and the default one, even when plugging a usb device
[16:09] <rsalveti> and I don't think we have folks with cameras around, I only saw it once, and that was robclark :-)
[16:09] <ogra_> rsalveti, still, GrueMaster has a point ... the driver shouldnt expose capabilities if there is no device to use them
[16:10] <ppisati> infinity: a new upload? if release team accept it, yes
[16:10] <infinity> ppisati: Consider it done.
[16:10] <ppisati> infinity: ok
[16:10] <infinity> ppisati: We just had linux/lbm/meta yesterday.
[16:10] <rsalveti> cool, so disabling the option would probably be the faster and easier way to get this fixed
[16:10] <infinity> ppisati: I would have assumed you'd rebase ti-omap4 to match.
[16:10] <infinity> ppisati: And if you can fix rsalveti's issue at the same time, cool.
[16:11] <ppisati> ok so, i'll disable panda camera too, ack
[16:11] <rsalveti> ppisati: thanks
[16:11] <robclark> fwiw, camera boards are available to the public, as are sensors..  not necessarly easy to get, but doesn't mean no one has one
[16:12] <rsalveti> robclark: wouldn't be a way for the kernel to check if the camera is available before exporting the interface?
[16:12] <GrueMaster> robclark: The idea is to support the lowest common denominator.  If a user has a camera, they can rebuild the kernel with the module.
[16:12] <rsalveti> always exporting the interface seems wrong
[16:12] <rsalveti> GrueMaster: +1
[16:13] <GrueMaster> I'd say to disable it for now, and revisit in 12.10.  No time to do a proper fix +testing (even if I were still testing it).
[16:13] <infinity> Well, v4l not sucking would be nice.
[16:13] <infinity> But disabling the driver seems simpler for now.
[16:13] <robclark> rsalveti, not sure
[16:14] <ogra_> is it actually a module ?
[16:14] <robclark> the bigger probably is probably none of you have a camera to test w/
[16:14] <ogra_> we could buuild it and ship a blacklist file for it by default
[16:14] <ogra_> so you dont need to recompile
[16:14] <rsalveti> not a module
[16:14] <infinity> Oh, indeed.
[16:14] <robclark> btw, what is the issue the camera is causing?  I guess I missed some of the discussion..
[16:15] <GrueMaster> robclark: That is true, but easily resolvable, if the camera is removable.
[16:15] <infinity> Could it be a module?
[16:15] <rsalveti> robclark: bug 924419
[16:15] <ubot2> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Medium,Incomplete] https://launchpad.net/bugs/924419
[16:15] <robclark> hmm
[16:15] <GrueMaster> robclark: What ends up happeneing, is on systems w/o a camera, it is using a screen capture or some other feed.
[16:16] <GrueMaster> *happening
[16:16] <robclark> if it is using the MCF based driver, the issue is that the sensor is a separate driver..
[16:16] <robclark> /dev/video0 is the output.. the ISP exists.. only the sensor does not ;-)
[16:16] <robclark> anyways time is limited so I guess folks w/ a camera can rebuild kernel, or modprobe or whatever
[16:17] <robclark> but I wonder what happens when MCF becomes more common..
[16:17]  * ogra_ would be for modprobing but that requires the driver to be a module 
[16:17] <robclark> and that doesn't work?
[16:17] <ogra_> no idea
[16:18] <XorA> sounds like it needs a subsystem like ASoC where video device is not instantiated until all parts on the path are
[16:18] <robclark> anyways, at some point the camera will probabably support some memory-to-memory modes too.. so probably some day oem-config needs to get more MCF saveey
[16:18] <rsalveti> robclark: it's fine to fix this after the release
[16:18] <rsalveti> the issue is with the released kernel
[16:18] <robclark> because really it should care about if the *sensor* exists, not the /dev/videoN device exists
[16:18] <rsalveti> as the pre-built images would have the bug at oem-config
[16:19] <robclark> right.. anyways, I think it is ok to not enable the camera.. we can add it in our PPA or whatever..
[16:19] <robclark> (but some day oem-config would have to deal with this ;-))
[16:19] <rsalveti> so that's why disabling it for now might be a good workaround, and then if it's the case of the device becoming common, or even another fix is around, we can simply just enable it again
[16:19] <rsalveti> with the proper support
[16:19] <ppisati> guys, do you have an LP bug for the camera?
[16:19] <rsalveti> ppisati: bug 924419
[16:19] <ubot2> Launchpad bug 924419 in ubiquity "oem-config detecting camera where no camera exists" [Medium,Incomplete] https://launchpad.net/bugs/924419
[16:20] <rsalveti> robclark: sure, but I wonder if we could have it generically enough to make it compatible with any app trying to access the camera devices
[16:20] <rsalveti> the only thing oem-config does is to check for devices exporting the proper capabilities
[16:21] <rsalveti> and guess that's also what is done with any other camera-based application
[16:21] <robclark> maybe if the app uses libv4l?  Probably a better question to ask the linux-media folks
[16:21] <robclark> right
[16:21] <GrueMaster> I believe other apps may work that way too.
[16:21] <rsalveti>  g_udev_enumerator_add_match_property (enumerator, "ID_V4L_CAPABILITIES", ":capture:");
[16:21] <ogra_> it just uses a gstreamer qeury for the capture capability
[16:21] <robclark> I think the v4l folks goal was the bury the sophistication in libv4l rather in the kernel..   but I'm not the MCF expert
[17:47] <rsalveti> ogra_: just installed the daily image, updated jockey and installed the pvr driver with jockey's interface
[17:47] <rsalveti> all went well :-)
[17:47] <rsalveti> and now with just a few clicks I got gles support ;-)
[17:47] <GrueMaster> rsalveti: Cool.  I may actually try it (just for personal gratification).
[17:48] <rsalveti> GrueMaster: :-)
[17:49] <infinity> rsalveti: Did you write automagic detection in (ie: does the jockey icon pop up in the notification area on Pandas and offer you the drivers, or do you need to manually run it?)
[17:50] <rsalveti> infinity: I thought jockey would automatically do that, but it seems this is not the case
[17:50] <ogra_> it should
[17:50] <rsalveti> infinity: do you know what needs to be changed to get it to work in that way?
[17:50] <infinity> Well, if you've given it detection patterns, wherever that happens, it probably already does work that way.
[17:51] <infinity> And the only reason you wouldn't have seen it is because you booted with a version that didn't.
[17:51] <rsalveti> if I open the interface, it'll try to detect the drivers and it'll then work as expected
[17:51] <rsalveti> but I'm not sure what needs to happen in order for it to automatically detect the drivers at the first boot
[17:51] <rsalveti> infinity: could be
[17:52] <ogra_> lets see what happens once its actually in the image
[17:52] <rsalveti> yup
[17:52] <ogra_> do you get unity 3D ?
[17:52] <rsalveti> ogra_: didn't yet check, let me give it a try
[17:52] <ogra_> theoretically that should wrok too now
[17:56] <rsalveti> ogra_: seems nux is still not building for gles on arm
[17:56] <ogra_> gar
[17:56] <rsalveti> ogra_: I might easily get the patch for it, let me check
[17:56] <ogra_> well, compiz and unity patches are in at least
[17:56] <ogra_> i'm just finishing the testbuild with an updated patch for compiz-plugins-main
[17:56] <rsalveti> should be the last part then
[17:57] <GrueMaster> If those aren't building, wouldn't that hold up image builds?
[17:57] <rsalveti> ok, meanwhile will enable nux and test
[17:58] <ogra_> GrueMaster, indeed
[17:58] <ogra_> thats why i do testbuilds :)
[19:16] <carli2> hi
[19:16] <carli2> I have a pandaboard and only a dvi plug.
[19:17] <GrueMaster> Use a DVI<>HMDI cable or converter.  Should work fine.
[19:17] <carli2> :o
[19:17] <carli2> my monitor is not able to display the hdmi content
[19:17] <carli2> and when I plug it into the dvi connector, it dosen't show anything
[19:17] <GrueMaster> HDMI is essentially the same video signal as DVI-D (Digital).
[19:18] <GrueMaster> Use the HDMI connector.
[19:18] <GrueMaster> The connectors on the panda are the same.
[19:18] <carli2> it dosen't work. the monitor tells me "input not supported".
[19:19] <carli2> did I choose a wrong resolution? (my monitor can only display a few)
[19:19] <GrueMaster> What resolutions does your monitor support?
[19:19] <GrueMaster> The panda driver should autodetect.
[19:19] <carli2> 1920x1080 and some spare other resolutions
[19:20] <GrueMaster> What model monitor do you have.  Might be easier for me to look at the specs for it.
[19:20] <GrueMaster> It should be fine with 1920x1080.  That is standard HD resolution.
[19:20] <ogra_> bug 897390
[19:20] <carli2> acer g225hqv
[19:20] <carli2> should I try an other version of ubuntu?
[19:22] <GrueMaster> ogra_: That bug doesn't exist.
[19:24] <GrueMaster> carli2: Which release are you running, and which rev Panda?
[19:25] <carli2> GrueMaster: 12.04 beta2, pandaboard ES
[19:32] <carli2> do I need a serial cable to get the pandaboard running?
[19:33] <MrCurious> http://www.kickstarter.com/projects/597507018/pebble-e-paper-watch-for-iphone-and-android
[19:33] <GrueMaster> Not for the desktop image.  I'm looking up your monitor info now (had an interrupt).
[19:36] <GrueMaster> The manual I found is too generic.  It lists VGA and possibly DVI and possibly HDMI capabilities.  Not specific enough for me to go on.
[19:36] <GrueMaster> I would suggest downloading the ubuntu server preinstalled omap4 image and booting it.  You will need a serial cable as it is setup through the serial console.
[19:37] <GrueMaster> Once setup, you can determine if it is detecting your monitor properly.
[20:10] <carli2> i'm using ubuntu 11.10 and 12.04 on pandaboard es, i have a hdmi-to-dvi converter I plug the hdmi part into both hdmi connectors on the pandaboard, in one the screen stays black, in the other, my monitor shows "input not supported"
[20:10] <carli2> what can I do?
[21:36] <rsalveti> robclark: got the following while trying to run xbmc on ubuntu:
[21:36] <rsalveti> [ 14547.411] PVR:(Error): PVRSRVMapDeviceClassMemory: Invalid params [1648, /bridged_pvr_glue.c]
[21:36] <rsalveti> [ 14547.481] (EE) pvr(0): [dri] PVRDRI2CreateFlipChain: Couldn't create flipchain
[21:36] <rsalveti> [ 14547.481] (EE) pvr(0): [dri] PVRDRI2AssignAndExportBuffers: Couldn't create flipchain
[21:36] <rsalveti> ro elevator=noop vram=32M mem=456M@0x80000000 mem=512M@0xA0000000 root=UUID=b518b2b6-8d08-41ad-b196-95a04e83657b fixrtc quiet splash
[21:37] <rsalveti> seems that using 32 as vram might not be enough here
[21:37] <robclark> right.. you need 40
[21:37] <rsalveti> robclark: any other value you'd suggest in this case?
[21:37] <robclark> fwiw, for new driver in 12.04 it no longer matters..
[21:37] <rsalveti> ok, then we need to change the default boot args at precise
[21:37] <robclark> no fixed/preallocated flipchains
[21:37] <robclark> yup
[21:38] <rsalveti> cool, nice to know
[21:38] <robclark> number of bootargs should be dropping significantly.. no more mem hole for syslink either, with the upstream rpmsg stuff
[21:38] <rsalveti> yeah, finally :-)
[21:45] <rsalveti> [   105.608] (EE) pvr(0): [dri] PVRDRI2CreateFlipChain: Created flipchain 1 (stride: 7680)
[21:45] <rsalveti> yeah, 40 made it work
[21:45] <rsalveti> infinity: ogra_: then we'd need to change the current vram argument at the pre-installed image, from 32 to 40
[21:47] <mkopack> Quick ? - has Unbuntu 12.04  for ARM been finalized yet? (i.e., full final release)… Soecifically images for PandaboardES ?
[21:50] <rsalveti> mkopack: we have daily images if you'd like to try
[21:50] <rsalveti> http://cdimage.ubuntu.com/daily-preinstalled/current/
[21:50] <rsalveti> final release is expected to happen at the end of this month
[21:50] <mkopack> Nah, not a fan of daily's… I'll stick with 11.10 until there's a full release version
[21:50] <rsalveti> the omap4 is compatible with panda and pandaES
[21:51] <mkopack> Ok, cool. I'll wait till then…
[21:51] <rsalveti> ok
[21:51] <mkopack> thanks, I just wasn't sure when the expected release was
[22:06] <infinity> rsalveti: I'm confused by robclark's statement that it's not needed for the "new driver in 12.04", and you just told me it is. :P
[22:08] <rsalveti> infinity: the new driver that TI will release on their own PPA
[22:09] <rsalveti> that will require the 3.3 kernel
[22:09] <rsalveti> so that's not part of the official precise release
[22:09] <rsalveti> would be optional for users once the PPA is in place
[22:09] <infinity> Ahh, check.
[22:10] <infinity> rsalveti: Can you file an RC bug about the command line needing to change, so I can point people at it when I fix it? :P
[22:10] <infinity> rsalveti: I'm not even sure how many places have that hardcoded.
[22:10] <infinity> flash-kernel and debian-cd both seem like likely candidates.
[22:11] <rsalveti> infinity: yeah :-)
[22:17] <rsalveti> I dream with the day where this will all be integrated at one single place :-)