[06:50] <xranby_ac100> whats the best way to determine at runtime if my code are running on a armel or armhf system?
[06:51] <xranby_ac100> i find myself in the situation that i have two librarys one armel and one  armhf and i must determine which of the two to open at runtime from a no-c based language
[06:52] <twb> compile an hf binary, if it crashes you're on soft float :P
[06:52] <xranby_ac100> well .. hehe
[06:52] <xranby_ac100> yes i was trying to avoid the crash at library load
[06:53] <twb> IIRC you can have hf and sf processes coeexisting on the same system
[06:53] <twb> Maybe the kernel has to support hf, but that would be all (that and the hardware, obviously)
[06:53] <twb> Hmm, I think I'm running a hf chroot without kernel support...
[06:54] <twb> /proc/cpuinfo isn't helpful
[06:54] <twb> Oh, yes, there's vfp in the feature list, that's hf right?
[06:54] <xranby_ac100> the kernel are identical so i cant ask it
[06:54] <xranby_ac100> vfp can be in the feature list on armel as well
[06:55] <xranby_ac100> its only the userspace abi that are different
[06:55] <twb> Hang on, are you saying that you have only one of the libraries installed on any given system?
[06:55] <xranby_ac100> i have a java application and i have   two native librarys one armel and one armhf
[06:56] <twb> I thought you were saying you had a mix of hardware, some hf and some sf
[06:56] <xranby_ac100> i have to determine at runtime which one to load
[06:56] <xranby_ac100> if i pick the wrong one i crash
[06:56] <xranby_ac100> the java application itself are platform independent and can run unmodified on armhf and armel so i cant figure out this part at compile thime
[06:58] <xranby_ac100> i assume python have similar issues
[06:59] <xranby_ac100> say you got python code that needs to load a native library
[06:59] <xranby_ac100> can gcc produce fat binarys?
[07:00] <twb> I don't know
[07:00] <xranby_ac100> if so then i would be able to load a fat binary with both armel and armhf
[07:38] <sveinse> I'm running natty and lately I'm always forced to run "sudo update-binfmts --enable qemu-arm" when I'm about to run armel code on intel. Is there a change in policy of late regarding this since it's constantly disabled?
[07:55] <twb> sveinse: one moment
[07:56] <twb> http://wiki.debian.org/QemuUserEmulation talks about how to do that
[07:56] <twb> IME it's always on, but I don't think I've tried it under precise...
[07:57] <twb> Pretty sure I was doing it under oneiric without troubles
[08:02] <sveinse> twb, I've been running qemu armel binfmt emulation for a while (years). It's just very lately that I need to run update-binfmts after _every_ boot to enable to execute armel binaries
[08:03] <twb> New one on me
[08:37] <ppisati> ogra_: could you test daily image for panda?
[08:43] <ppisati> janimo`: could you test daily image for panda?
[08:47] <ogra_> ppisati, i think pgraner did already (he asked questions about some desktopish apps in #ubuntu-release)
[08:52] <ppisati> ogra_: i've a problem with my test monitor here, could you double check?
[08:52] <ogra_> well, i'm currently busy with ac100 testing but later today i can probably test panda
[09:34] <ppisati> ok, so it's ether the video output of my board or my lcd...
[10:41] <ppisati> ogra_: not even P/omap4 beta1 gives me any vide output, so i'm realy starting to thing it's problem with my panda or with my lcd...
[10:41] <ppisati> *think
[10:41] <ogra_> did you try the other video output ?
[10:42] <ppisati> yes
[10:42] <ppisati> no output at all
[10:42] <ppisati> i tried with 3 different kernels
[10:42] <ppisati> and two preinstalled images
[10:43] <ppisati> among which the beta1
[10:43] <ppisati> no i'll do a last test with an O image
[10:43] <ppisati> after that i'll declare my panda badly wounded
[10:43] <ashiswin> hey guys, does anyone know which channel I can discuss general ARM processor stuff?
[10:45]  * ogra_ would try #linaro, there are at least a lot of arm employees in there
[10:47] <ashiswin> thanks ogra_ :)
[11:24] <ppisati> no video output even in O
[11:24] <ppisati> nice
[11:25] <ogra_> try another cable :)
[11:25] <ogra_> and power on the monitor ;)
[13:28] <jimerickson> got video ouput on my pandaboard ES with the latest image. thanks guys!
[13:34] <ogra_> great
[13:47] <martinald> hi guys
[13:48] <martinald> playing around with ARM in qemu
[13:48] <martinald> i've got a basic fluxbox install starting
[13:48] <martinald> but i can't seem to find a way to increase the oclour depth and/or resolution
[13:48] <martinald> i'm using the framebuffer driver AFIAK; anyone got any ideas?
[14:25] <Riddell> still getting my monitor/graphics driver issue (bug 961133) but found a new HDMI monitor that it does work with but only with HDMI output and only at 600x800 resolution
[14:26] <ubot2> Launchpad bug 961133 in linux "No video output from Ubuntu Desktop ARM Images on my Pandaboard to my DVI monitor" [Medium,Confirmed] https://launchpad.net/bugs/961133
[14:26]  * Riddell wonders why this channel exists instead of using #ubuntu-devel
[14:52] <hrw> Riddell: question is rather 'why you joined here instead of asking on #ubuntu-devel'
[14:52] <Riddell> hrw: because I think there is a need for arm communications still, that's why I've been arguing for an ubuntu-arm mailing list
[14:56] <hrw> there was ubuntu-mobile for that
[14:56] <hrw> and finally got dropped in favour of ubuntu-devel
[14:57] <Riddell> yes, so it's inconsistent
[15:00] <Riddell> robclark: I'm to nudge you towards bug 961133 again, still broken with my monitor (but worked with oneiric and works with that 3.3 one you showed me at) but works with an HDMI monitor at 640x480 resolution
[15:00] <ubot2> Launchpad bug 961133 in linux "No video output from Ubuntu Desktop ARM Images on my Pandaboard to my DVI monitor" [Medium,Confirmed] https://launchpad.net/bugs/961133
[15:03] <janimo`> Riddell, I think ARM  emails should be good for ubuntu-devel if they are developer oriented. ARM should get more and more widespread so bringing it in the discussions more visibly can't hurt
[15:05] <Riddell> what do I need to test omap (not omap4) images?
[15:05] <GrueMaster> A beaglexm platform.
[15:12] <ogra_> even though it might be funny to see kubuntu oin a beagle C4 or A8 *g*
[15:32] <Riddell> GrueMaster: so that's a beagle board?
[15:32] <Riddell> ogra_: what's funny about that?
[15:33] <GrueMaster> Riddell: http://beagleboard.org
[15:33] <ogra_> Riddell, A has 128M, C has 256M ... both will oops at some point running a full desktop
[15:34] <ogra_> you dont want to test kubuntu on that :)
[15:34] <Riddell> ogra_: so how do you test ubuntu desktop images?
[15:34] <ogra_> oh and they are 400 and 600 MHz
[15:34] <ogra_> Riddell, we use beagle XM, as GrueMaster stated
[15:34] <GrueMaster> Riddell: beagleXM.  See above link.
[15:34] <ogra_> 1GHz/512M
[15:35] <ogra_> any former revisions arent really for desktop use
[15:35] <ogra_> (XM is the "current" one)
[15:36] <Riddell> and while I'm asking what do you use to test mx5 and ac100?
[15:36] <ogra_> ac100 is teated on an ac100 :)
[15:36] <ogra_> mx5 is the freescale quickstart board
[15:36] <GrueMaster> Freescale Quickstart for mx5.
[15:37] <Riddell> and they're dev board that look a bit like this pandaboard?
[15:37] <GrueMaster> Although any you buy now are highly likely to not work due to a usb bug.
[15:37] <ogra_> Riddell, apart from the ac100 they all are dev boards
[15:37] <GrueMaster> yes, very similar in size.
[15:37] <ogra_> (ac100 is the little netbook i run around with at events)
[15:38] <Riddell> ah nice
[15:38] <ogra_> they are not produced anymore but you can get them chap at ebay or so
[15:38] <ogra_> like between 100 and 150€
[15:38] <Riddell> so why do we have images if they're not commercially interesting?
[15:39] <ogra_> because there is a big community for it
[15:39] <Riddell> that's very generous of us :)
[15:39] <ogra_> and the majority uses ubuntu on that device
[15:40] <ogra_> no, thats very helpful for us, the devs among them help with ubuntu on arm since thats a device they actually *use*
[15:40] <ogra_> opposed to a dev board ...
[15:40] <Riddell> ah hah
[15:41] <ogra_> we tend to get a good amount of bugs (and sometimes also fixes) from that side
[15:42] <Riddell> ogra_: where do bugs appear in arm?  linux sure and I know there are compiler errors if you don't do your real vs double right in qt but what are the other gotchas?
[15:42] <ogra_> well, sound servers that down work properly with alsa ... desktop bugs you dont encounter during a short test but that show up after a while of actually using an image etc
[15:43] <ogra_> just do give two examples
[15:43] <Riddell> I guess unity-2d gets more of a workout on arm
[15:43] <Riddell> that name makes me cringe each time I use it
[15:44] <ogra_> well, we're working on 3D for panda at least
[15:45] <ogra_> i should have a patch from linaro readily packaged next week or so for compiz
[15:45] <ogra_> so you can use 3D then
[15:46] <ogra_> but i doubt it will be fun to use ... will still be slow and slightly buggy
[15:46] <ogra_> its a start at least :)
[15:48] <Riddell> I have graphics accelaration on this pandaboard
[15:49] <Riddell> I don't see any need for unity-"3d" just overhead as far as I can tell
[15:49] <ogra_> on oneiric
[15:49] <ogra_> there is no driver for precise yet
[15:49] <Riddell> hmm I have fancy shadows on my windows which I can turn off when I tell kwin not to use accelaration
[15:49] <ogra_> sure
[15:49] <ogra_> SW rendered composite
[15:50] <ogra_> works even on xfbdev drivers ;)
[15:50] <ogra_> especially if the system can donate one core to all the SW stuff
[15:50] <Riddell> mm
[15:50] <ogra_> there are no drivers installed by default
[15:51] <ogra_> for oneiric they are in the TI PPA
[15:51] <ogra_> for precise they sit in NEW and wait for being moved to multiverse
[15:51] <GrueMaster> For precise, I think they are in -proposed, but I know they are at least waiting for beta freeze to lift before hitting the pool.
[15:52] <GrueMaster> Oh, new.
[15:52] <Riddell> -proposed isn't open, we haven't released yet
[15:52] <ogra_> -proposed is open
[15:52] <GrueMaster> I had thought they had enabled proposed for stuff to flow into during the freeze.
[15:52] <ogra_> compiz was built there during the freeze
[15:52] <Riddell> that's early
[15:52] <ogra_> right
[15:53] <ogra_> it is to avoid archive skew through package sets with close dependencies
[15:53] <GrueMaster> Makes sense.  Keep stuff flowing withouth disrupting beta.
[15:53] <ogra_> so they can be uploaded and built and once the freeze is lifted the binaries just get copied
[15:53] <Riddell> clever these archive admins
[15:59] <infinity> Riddell: We're getting more clever, anyway. :P
[16:24] <prpplague> GrueMaster / ogra_ any of you guys heard of anyone running ubuntu-arm over on some of the slower arm920's ? i.e. s3c2440?
[16:25] <ogra_> nope
[16:25] <GrueMaster> We only support armv7 core.  If they support it, our stuff should run.
[16:25] <infinity> Would be a neat trick, since they're not v7.
[16:25] <infinity> And GrueMaster beat me to it.
[16:26] <prpplague> ahh ok
[16:26] <ogra_> i think we had some back in jaunty or karmic though
[16:26] <prpplague> i'll probably look at some angstrom builds them, thanks
[16:26] <infinity> prpplague: Or Debian.
[16:26] <ogra_> ++
[16:29] <infinity> Someone still needs to retroactively rename all of the ARM core designs and ISAs to not confuse people.
[16:30]  * ogra_ votes for "frank" ... or "bill"
[16:30] <infinity> There.
[16:30] <ogra_> heh