[00:06] <jeramee> yeah
[00:06] <jeramee> I finally got a Qemu going and installed development packages in it
[00:07] <persia> Cool!  What are you building?
[00:07] <jeramee> and also I hacked a board I got from best buy installed the development package and wrote a few minor programs
[00:07] <jeramee> lol
[00:07] <jeramee> really
[00:08] <jeramee> I would like to make a touch screen puppy linux distro
[00:08] <jeramee> but maybe just use it for logging sensor and i/o streams
[00:08] <jeramee> and control a robot
[00:09] <jeramee> 800 mhz is plenty enough brains to clean my kitchen floor and maybe mow the grass
[00:09] <jeramee> lol
[00:09] <persia> Well, we can't help much with Puppy here, but robots are fun.
[00:09] <jeramee> especially because it is RISC
[00:10] <jeramee> are you really from Persia?
[00:10] <jeramee> yeah Puppy is nice distro and in my opinion would be great on tablet PC etc
[00:11] <jeramee> the newest is 125 mb
[00:11] <jeramee> the old school is like 98 mb and less
[00:11] <persia> I'm not from Persia, and I'm of the school of thought that calling a place "Persia" just reinforces an old insult.
[00:11]  * persia respects the concept of "Persian", which is completely different
[00:11] <persia> (and no, I'm not Persian either)
[00:12] <jeramee> full gui, burn CDs , stream music etc
[00:12] <jeramee> you do not need like gigs and gigs and gigs to do stuff lol
[00:12] <persia> Not at all, although I believe that all the distributions are about the same in terms of requirements.
[00:13] <persia> The useful question to ask about distributions is: which gives you the development environment you find comfortable?
[00:13] <jeramee> Gnome
[00:13] <jeramee> lol
[00:13] <jeramee> not Ubuntu
[00:13] <persia> As someone who does native development (yes, even on the beagleboard), I like Ubuntu.
[00:13] <jeramee> straight Gnome
[00:14] <persia> I'm talking about the lower-level tools.
[00:14] <persia> I thought the bug that kept one from running regular GNOME in Ubuntu was fixed.
[00:14] <jeramee> and XFCE deserves honorable mention
[00:14] <persia> If not, it ought be.  THere's bundles of folk who prefer GNOME Shell to Unity, and they ought be able to do as they like.
[00:14] <jeramee> it is
[00:14] <jeramee> and runs smooth
[00:15] <persia> We do XFCE just fine.  LXDE as well.
[00:16] <jeramee> I love XFCE just idk not easy to arrange stuff lol
[00:16] <jeramee> and some stuff still compatibility issues
[00:17] <jeramee> but doubt I will move to Unity
[00:17] <jeramee> so XFCE or Xubuntu I see those as future
[00:17] <persia> Heh, that's fine.
[00:17] <jeramee> lol
[00:17] <jeramee> seems like browsers, OS, etc, etc
[00:17] <jeramee> all make more bloat so you need better hardware lol
[00:18] <persia> In this channel, we tend to be concerned about the few things that make ARM special, and making sure all the packages in the archive work properly on ARM targets.  Specific desktop choice, etc. we leave to users.
[00:18] <jeramee> when will enough be enough
[00:18] <jeramee> so do Desktop fully compile?
[00:18] <jeramee> cause really command-line is all you need for many things
[00:19] <jeramee> but just curious
[00:19] <persia> I know of folk using kubuntu-desktop, lubuntu-desktop, ubuntu-desktop, and xubuntu-desktop on armel.
[00:19] <jeramee> wow
[00:19] <jeramee> nice
[00:19] <persia> I don't know of anyone using ubuntustudio-desktop on armel, but I suspect that works as well.
[00:19] <jeramee> yeah I am on studio atm
[00:19] <jeramee> running gnome
[00:20] <jeramee> and my slow PC has XFCE
[00:20] <persia> I don't know if anyone tested either of the edubuntu desktops, or the packages therein, but there's a good chance they work.  I had reports that Mythbuntu might not work so well, but no bug reports or specific complaints, so I can't be sure.
[00:21] <jeramee> yeah one thing I hate about XFCE is real bad media playing
[00:21] <jeramee> flash, etc
[00:21] <jeramee> but hey when you sit down to program no need to stream videos on Youtube lol
[00:21] <jeramee> just curious though
[00:22] <persia> Hrm?  I thought the media stuff got fixed.
[00:22] <jeramee> I ran all the patches
[00:22] <persia> And Flash shouldn't be different for different flavours of Ubuntu: we all use the same implementation.
[00:22] <jeramee> all the updates
[00:22] <jeramee> it doesn't crash
[00:22] <jeramee> system or player
[00:22] <jeramee> just seems a bit more choppy
[00:23] <jeramee> tried XFCE and Xubuntu
[00:23] <jeramee> same result
[00:23] <jeramee> so any of these distro's have touch screen functionality
[00:23] <jeramee> ?
[00:24] <persia> I thought parole was cleaner than that, but each person's experience may differ.
[00:24] <jeramee> well I am running 10.4 with RTAI
[00:24] <jeramee> so maybe makes a difference
[00:25] <persia> Ubuntu has touchscreen support, and so that is available for all flavours.  Precisely which applications take full advantage of that, and which just consider it as an X pointer, is more complicated (and building an exhastive list is likely impossible: things change faster than one can usefully test that many thousands of applications)
[00:25] <persia> Oh, yeah.  Media *production* works well with RT.  Media playing tends to work poorly with RT.
[00:26] <jeramee> wow good to know
[00:26] <jeramee> lol
[00:26] <jeramee> so you can build them better just not watch
[00:26] <jeramee> lol
[00:26] <jeramee> no wonder studio runs so smooth
[00:26] <jeramee> lol
[00:26] <jeramee> i dont even use it to make movies lol
[00:27] <jeramee> aren't some ARM OS RTOS
[00:27] <jeramee> like kernals?
[00:27] <persia> That's a software thing, independent of the hardware.
[00:28] <jeramee> was thinking maybe that would be better for automation
[00:28] <persia> We don'T have any realtime kernels in Ubuntu currently, so Ubuntu can't be configured as RTOS (although you could presumably create your own, if you want to forward-port the RT stuff, and we'd gladly use it if it was available).
[00:28] <persia> Depends on your needs.  If you need that level of timing control, it's better.  For most folk, most of the time, there's no point.
[00:28] <jeramee> lol
[00:29] <jeramee> compiling my own kernel is one thing
[00:29] <persia> I've seen folk get submillisecond reactions from things without RT, but sometimes there are scheduling bumps, and one ends up with 10s of ms.
[00:29] <jeramee> building lol
[00:29] <jeramee> is another
[00:30] <jeramee> yeah well technically
[00:30] <persia> For cleaning your kitchen, <100ms latency is likely to be fine, unless you have very expensive fragile cabinets, and a heavy robot with no padding.
[00:30] <jeramee> RTAI would be fine
[00:30] <jeramee> if all you are doing is talking to Microcontrollers
[00:30] <jeramee> they could keep the timing
[00:30] <jeramee> for you
[00:35] <persia> Oh, so you have your RTAI system that handles movement, cleaning, etc., and then your Ubuntu system that provides instructions, touchscreen, network access, etc.?
[00:35] <jeramee> nah not there yet
[00:36] <jeramee> but maybe I will try to build something of that nature
[00:36] <neko> how do I make my omapfb use a decent display mode after I install omap4-extras
[00:37] <neko> omappedia and elinux wiki are useless as is the ubuntu wiki... it seems like they're repeating very old info which isn't relevant as of today
[00:37] <persia> I thought we fixed the EDID issue: did that fix not get adopted in that PPA?
[00:37] <neko> I can't even find half these sysfs attributes it talks about, and nothing I edit boot.script to do seems to actually take effect (although /proc/cmdline reflects them, which is nice)
[00:37] <neko> I have absolutely no idea
[00:38] <neko> if I plug it into the edge HDMI port I get zip
[00:38] <jeramee> like for instance, real nice CNC machines have touch panels for calibration etc, and also another food for thought is I have 5 PC, plus 1 ARM.  Dedicate 1 to house automation, walk in room touch make coffee on the arm  and clean kitchen etc
[00:38] <neko> if I plug it into the HDMI port next to the USB slot I get 640x480
[00:38] <neko> which is nice. with pvr it runs like a hellcat
[00:38] <neko> I'd just rather it did 1600x900 like my monitor says it can do (and my efika supports nicely if I swap cables)
[00:39] <neko> the big pixels make my head hurt :D
[00:39] <persia> neko: Have you played with get-edid and parse-edid?
[00:39] <neko> never heard of them and a quick check confirms: not installed
[00:40] <neko> also, /sys/class/graphics/fb0 has no edid properties and nor does /sys/devices/platform/omapdss/whatever/in/here
[00:40] <persia> You'd have to install read-edid.  There's some stuff inside X that also does it, but I don't beleive the user interface to be as pleasing.
[00:40] <persia> That sounds like an EDID error then.
[00:40] <neko> X doesn't do anything
[00:41] <neko> what do you mean an EDID error
[00:41] <neko> omapfb sucks and cannot read from the i2c bus, or.. you're assuming I have a busted monitor?
[00:41] <persia> Failure to accurately collect EDID over HDMI, parse it, and set the screen correctly.
[00:41] <persia> I doubt the monitor has an issue, because you say it works with another device.
[00:42] <persia> I suspect either that there's an issue collecting the EDID with the current software stack *OR* that there's a failure to use the EDID data once collected.
[00:42] <neko> I tried 11 monitors, all of which work fine and report fine on the efika mx (and I get native res, or 1080p or 720p) - but every single one dumps to 480p. I can't imagine why it would not work on omap...
[00:42] <neko> all the wiki pages say there is some wicked awesome hdmi hotplug and edid grabbing stuff in sysfs and it's simply not there
[00:42] <neko> it's like, it's an old driver or something
[00:42] <persia> So, verify that you can get and read the EDID data.  If you can't, file a bug about that.  If you can, file a bug about not using the EDID data.
[00:43] <neko> 2.6.38-1208-omap4 seems to me to be totally brand new though
[00:43] <neko> eh I installed read-edid and .. nothing is installed? what am I meant to be running?
[00:43] <neko> problem here is I have no idea what I am looking for yet
[00:43] <persia> get-edid and parse-edid
[00:43] <neko> so a bug report is going to be totally useless
[00:44] <neko> get-edid: command not found
[00:44] <persia> Check your path.  If you installed the read-edid package, it should be in /usr/sbing/get-edid
[00:44] <persia> s/bing/bin/
[00:45] <neko> pfft, nope.
[00:45] <neko> I got lots of getkeycodes, getopt stuff but no get-edid anywhere
[00:46] <persia> Does `dpkg -L read-edid` show you a useful location?
[00:46] <neko> I just pulled in read-edid 2.0.0-3.1 which to my mind only works on PCs anyway
[00:46] <neko> even building it for armel, traditionally, has been a waste of cpu cycles... however someone could have added omap stuff to it in the past aeon :D
[00:46] <neko> so far I see nothing
[00:46] <neko> parse-edid is installed
[00:47] <neko> it needs a file as input. as I said nothing in sysfs...
[00:47] <persia> Right, that's what get-edid is supposed to output.
[00:48] <neko> yeah I think you are thinking of some other more awesome tool
[00:49] <neko> read-edid hasn't been updated since 2009 and I am damn sure nobody ever made it read edids from anything other than VESA BIOS calls or from /proc/device-tree
[00:49] <persia> No, but I'm relying on received hearsay that the framebuffer support got added, and am installing it on a natty/armel system in parallel to test for myself
[00:50] <neko> maybe I am using release of omap4-extras when I should be using trunk?
[00:50] <persia> I heard that "release" was the software TI wanted everyone to use, and "trunk" was where TI was doing their development work.  As a result, I suspect "trunk" of being unstable.
[00:51]  * persia gets annoyed at read-edid, and tries to figure out why it's broken
[00:51] <neko> well, compiling read-edid's "get-edid" part would be useless on anything but x86 or ppc or sparc right now
[00:51] <neko> and even if you got linux fdts on armel, it wouldnt have edid data in it, u-boot is too stupid to glue the data in
[00:52] <neko> so you have to assume the data is, like any reasonable driver, in /sys
[00:52] <neko> (it is on the efika, on any PC with a radeon.. comes in really handy)
[00:52] <persia> IS that how X's EDID parsing is implmented?
[00:52] <neko> no, X asks DRM CRTC for it
[00:53] <persia> And that gets it from?
[00:53] <neko> or, I should say, X asks the driver, and the driver implements a CRTC, which is usually hooked into a DRM CRTC on the kernel side
[00:53] <neko> it gets it from whatever i2c bus or whacked out method the HDMI controller or so implements
[00:53] <persia> Aha.  That makes sense.
[00:53] <neko> most of 'em just let you read address 0x50 on i2c and it passes the data back
[00:53] <persia> So I suppose what I really want to do is to have X expose this in some useful way, rather than fixing read-edid
[00:53] <neko> on the sii9022 on efika and mx53_loco, you have to ask the sii9022 for it
[00:54] <persia> (and I should stop relying on read-edid to be useful)
[00:54] <neko> X can't know unless the kernel knows
[00:54] <neko> the kernel, here, doesn't know
[00:54] <neko> which makes me think, super-old kernel, or simply super-broken kernel...?
[00:54] <neko> it probably works great on oneiric doesn't it
[00:54] <persia> There's a /usr/bin/decode-edid in i2c-tools, but if you're correct about i2c being nonfunctional, that won't help.
[00:54] <neko> maybe it just needs a backport
[00:55] <neko> well.. I dunno if there's anything nonfunctional
[00:56] <neko> I simply know that glued to the framebuffer driver, on the omapfb side of things, it has a little driver on i2c which is run after framebuffer is initialized, which would read edids, set the controller up for all manner of fancy stuff (like hdmi audio) and put them in a nice place
[00:56] <neko> that's just the only way to do it unless you're a DRM driver in which case, stuff gets reaaaally fancy and they have a slightly less braindead solution for it that is more like X does it
[00:56] <persia> Ah, but that's *after* framebuffer initialisation, so we already have a resolution.
[00:56] <neko> in any case, I don't see any dmesg output that says it has a monitor attached, it doesn't even parse my kernel commandline
[00:57] <neko> and that i2c driver can set whatever resolution it likes
[00:57] <neko> I spent enough time in the ipu3 framebuffer getting the sii9022 to work on the efika to know how it usually works.. and I've seen the omapfb code
[00:58] <neko> however, what is on this pandaboard right now.. doesn't seem to be the code I saw... it seems to be much, much older
[00:58] <neko> like May last year kind of older
[00:58] <persia> What's the last entry in the changelog for the package that provides it?
[01:00] <neko> uhh Bryan Wu, * [Config] Update to 2.6.38.2 kernel config and other changes
[01:00]  * persia grumbles at binaries without manpages
[01:00] <neko> 2.6.38-1208.11
[01:00] <neko> April 4, 2011
[01:01] <persia> Hrm.  That isn't quite last year, but that change doesn't look substantive.
[01:01] <neko> well the package may have been built in April but the actual code doesn't seem terribly up to date
[01:01] <neko> I think they might have missed a merge window
[01:02] <neko> what I was looking at that looked workable was like 2.6.39-rc3 or something.. that was way, way after April
[01:02] <neko> but I assume this stuff gets backported
[01:02] <neko> I assume wrong :D
[01:02] <persia> Assumptions are rarely safe.
[01:03] <neko> as a kernel developer and maintainer, product manager of an arm platform, I usually make pretty reasonable assumptions about what our customers want to see, and to be honest, 640x480 isn't it
[01:03] <persia> Some code gets cherrypicked, when it fixes a clearly obvious serious bug with little to no chance of regression as SRU.
[01:03] <StevenK> persia: Speaking of no man pages: http://pastebin.com/gct7GLW9
[01:04] <neko> that's why I bumped 1080p support into the genesi kernel, and kicked someone to write proper hdmi hotplug support.. it seems someone did that at TI too, it just didn't make it into Natty and nobody updated the kernel in an aeon
[01:04] <persia> Most backports are just backports entire, in the -backports repositories, but kernels and modules are almost never put there because of the potential for regressions if userspace fails to match kernelspace.
[01:04] <persia> StevenK: Heh.  Yeah.
[01:05] <neko> it makes me sad how quickly a release gets abandoned
[01:05] <persia> neko: Last update in April sounds like there's stuff needing doing.  I suspect there's some security fixes that *should* have been applied.
[01:05] <persia> If there's a known safe cherrypick to fix some other code, it might be able to get into the same place.
[01:05] <prpplague^2> neko: s/release/girlfriend
[01:05] <neko> 4th April is just squeaking in before Natty code freeze..
[01:05] <persia> Alternately, are you sure there isn'T a new kernel in natty-updates?
[01:06] <neko> well I spent 5 hours downloading and installing 100MB of new packages for the Panda
[01:06] <neko> if it was in updates, I downloaded it...
[01:06] <neko> maybe extras pissed over the top of it?
[01:07] <persia> neko: No, I have the same kernel as you, and I should also be up to date.
[01:07] <neko> hmm nope. but there is a unity update being held back
[01:07] <persia> Someone probably ought prepare an SRU for that, really.
[01:08] <neko> so I'm updated up to the point I can be updated..
[01:09] <neko> An effervescing elephant with tiny eyes and great big trunk once whispered to the tiny ear of one inferior that by next June he'd he'd die.. oh yeah! Because the tiger would roam...
[01:10] <neko> I think Ubuntu missed a trick by not having an Effervescing Elephant release
[01:33] <jeramee> lol
[01:33] <jeramee> Effervescing Elephant
[01:34] <jeramee> well neko any idea how to write programs to utilize touch panel
[01:35] <jeramee> any good links that you could recommend?
[01:35] <neko> absolutely not
[01:36] <neko> I am kind of a low level guy and very high level guy
[01:36] <neko> applications are inbetween, not my thing
[01:38] <persia> jeramee, You might take a look at the utouch package.  It is a metapackage that installs several libraries and tools for working with touch and gestures.
[01:47] <jeramee> nice that is likely all I would need as what I wish to use the touch panel for is not really that sophisticated.  I will check it out thanks for the talk guys.  Now back to circuit design.  Maybe I will full with the ARM some more this weekend.  Is kinda a side hobby.
[01:47] <jeramee> Nice talking to you guys, afk
[01:47] <prpplague> jeramee: as long as your touch panel driver is configure for standard events, it will work fine
[01:49] <persia> Depends what one wants to do, but yeah, for 90% of "touch enabled" applications, standard X pointer events are sufficient.
[01:53] <prpplague> adding fancy touch buttons and such are that hard
[01:54] <jeramee> and for double touch use QT seems
[01:54] <prpplague> doing it as a library or as a generic support, that can get tricky
[01:54] <jeramee> i had browser going other day
[01:54] <jeramee> but really need to build X
[01:54] <persia> What's your processor?  You may be able to just run Ubuntu's X.
[01:55] <jeramee> does utouch require more than basic X
[01:55] <persia> jeramee, "utouch" is just a collection of useful libraries for doing touchy stuff.  If your X and your applications use the same libraries, you get fancy stuff.
[01:56] <persia> If you just want a working touchscreen, that's a driver thing, and X will just do the right thing.
[01:59] <jeramee> I think it is a freescale
[01:59] <jeramee> kinda poor documentation
[01:59] <jeramee> I had a gift card from christmas
[02:00] <jeramee> and knew I could get 800mhz and 8" for like $35
[02:00] <jeramee> so was enough to get started
[02:00] <jeramee> later I will look into a more professional board
[02:10] <jeramee> Marvell’s Armada 168  any associated build problems?
[02:17] <persia> The Armada 168 isn't compatible with Ubuntu: we usually recommend Debian for that.
[02:17] <persia> Freescale's i.MX51x and i.MX53x SoCs should be compatible.
[02:26] <slangasek> anyone looking at the ghostscript build failure? :)
[02:41] <persia> slangasek, Apparently not specifically.
[02:43] <persia> Oh ugh.  Someone sync'd d-shlibs.
[02:43] <slangasek> clobbering an Ubuntu delta?
[02:44] <slangasek> yep, apparently
[02:45] <slangasek> hah, janimo has already identified the fix
[02:45] <slangasek> a new sync of d-shlibs needed
[02:45] <persia> Right.
[02:45] <persia> The d-shlibs patch was always a workaround, and was rightly rejected in Debian Bug #581258
[02:45] <ubot2> Debian bug 581258 in d-shlibs "d-shlibs: typo of the dynamic load library prevents build-dependent packages from building" [Important,Open] http://bugs.debian.org/581258
[02:46] <persia> pitti read that, and force-sync'd, without anyone having applied the real fix.
[02:47] <slangasek> doh
[02:47] <slangasek> well, syncing for bug #812155 now
[02:47] <ubot2> Launchpad bug 812155 in d-shlibs "Sync d-shlibs 0.47 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/812155
[02:47] <persia> Aha, and jonas discovered that Debian Bug #548626 was misfixed, causing the entire mess.
[02:47] <ubot2> Debian bug 548626 in d-shlibs "glibc-2.10 on armel introduces new dynamic linker and breaks d-devlibdeps" [Important,Fixed] http://bugs.debian.org/548626
[02:47] <persia> That ought do it.
[02:47] <persia> 0.47 includes the fix for 633933, which is the reapplication of 548626
[02:49] <persia> Mind you, I still think that the bug is really in glibc, but if jonas did it the other way, we may as well respect that.
[02:51] <jeramee> i have problems with glibc sometimes seems kinda buggy
[02:51] <jeramee> and dmks i think
[02:51] <jeramee> but resolved as of now
[02:52] <jeramee> until next time I find something they dont like
[02:57] <jeramee> seems my processor is running ARMv5 any suggestions on what to install on it
[02:58] <persia> Debian.
[06:47] <rsalveti> janimo: bug 812381 and bug 812110 are sync requests to fix arm ftbfs on ubuntu
[06:47] <ubot2> Launchpad bug 812381 in qutecom "Sync qutecom 2.2.1+dfsg1-1 (universe) from Debian sid (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/812381
[06:47] <ubot2> Launchpad bug 812110 in klatexformula "Sync klatexformula 3.2.4-1 (universe) from Debian testing (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/812110
[06:48] <janimo> rsalveti, I have no syncing powers
[06:48] <rsalveti> so need to wait an archive admin I believe
[06:48] <janimo> rsalveti, right, I think it happens daily as there are several adimns shifting
[09:48] <Spider-Pork> i would to get ubuntu on my gumstix overo fire. Is there a prebuild image?
[10:08] <infinity> rsalveti: Done and done.
[10:23] <rsalveti> infinity: great, thanks
[10:55] <jojo11> hey does anyone know if hardware encoders on BeagleBoard-xM are usable unlike the ones on PandaBoard
[13:08] <siji> persia, ping
[13:09] <mahmoh> if I swap out my SD on my panda, is there a way to rescan it like a scsi disk?
[13:34] <ppisati> have anyone used strace to trace a running process?
[14:38] <furibondox> hi guys
[15:53] <mahmoh> where was that bug about USB IO and pinging the ethernet, didn't that get fixed, persia, GrueMaster?  I remember talking about it but I cannot find the bug in question
[15:56] <GrueMaster> I'm not seeing anything in LP.  I think I read about it on the pandaboard mailing list.
[15:58] <mahmoh> we were talking about it last week I think
[16:11] <GrueMaster> mahmoh: http://jeffbastian.blogspot.com/2011/06/storage-speed-on-pandaboard-revisited.html
[16:14] <GrueMaster> mahmoh: Have you tested this recently?  If not, I'll do a quick spot check to see if the problem exists in 1309.14 and file a bug accordingly.
[16:34] <prpplague> GrueMaster: it appears to still be present 3.0-rc
[16:34] <GrueMaster> great.
[16:35] <prpplague> GrueMaster: it doesn't appear to be  lan9514 related
[16:35] <GrueMaster> I'm going to file a bug in our tracker so that we can keep abreast of it.  I'm rerunning jeff bastian's benchmark tests to attach to the bug report for our kernel team.
[16:36] <prpplague> GrueMaster: please detail how you run the test so that i can run them as well
[16:36] <GrueMaster> Has anyone filed a bug upstream?
[16:36] <prpplague> GrueMaster: mrcurious has been following the issue
[16:36] <GrueMaster> Yep.
[16:36] <GrueMaster> It will be in the bug report.
[16:36] <prpplague> GrueMaster: i'll check with him when he is back on irc
[16:38] <GrueMaster> I'll also try to fire up a Maverick install and copy it to a usb drive to see if it exists there as well.  If we can isolate it to a release, we can debug it more readily (in theory).
[16:40] <GrueMaster> prpplague: Do you remember the kernel cmdline for setting mac address?  I have a couple of pandas (A1 & EA1) that share the same die id (thus the same mac).
[16:40] <GrueMaster> Save me having to google for it.
[16:41] <prpplague> GrueMaster: i dont believe upatched kernel support the mac argument
[16:41] <prpplague> GrueMaster: think you have to apply a patch for it
[16:41] <prpplague> GrueMaster: check with robclark , he normally has a good patchset for ti
[16:41] <prpplague> it
[16:41] <GrueMaster> It is in the natty kernel already.
[16:42] <GrueMaster> I'll just look it up.
[16:42] <ppisati> guys, besides janimo, anyone else can test the new ti-omap4 kernel? it's here: http://people.canonical.com/~ppisati/ti-omap4-next/
[16:43] <GrueMaster> ppisati: Are you aware of this performance bug with USB drives & having to ping the ethernet port?
[16:44] <ppisati> GrueMaster: heard about it long ago
[16:44] <ppisati> GrueMaster: still there?
[16:44] <ppisati> GrueMaster: care to try the new kernel?
[16:44] <GrueMaster> Apparently.  I am trying the 1309.14 kernel on oneiric now.  As soon as I finish the comparison there, I can.
[16:45] <ppisati> cool
[16:45] <ppisati> i tried to fix an audio bug today, but it seems it's a pulseaudio problem
[16:45] <ppisati> so i won't wait anymore, tomorrow i'll push it
[16:46] <GrueMaster> ok
[16:47] <prpplague> GrueMaster: btw, i haven't confirmed it myself, but i was told that the issue presents itself on omap3 boards as well as on some arm9 based boards
[16:48] <GrueMaster> prpplague: If I get around to it, I can try it on an XM.  It would be interesting to see if it is also present on a beagle C4.
[16:48] <GrueMaster> sigh.  So many tests, so little time.
[17:16] <mahmoh> GrueMaster: I think this is the bug on the ping problem - bug 709245
[17:16] <ubot2> Launchpad bug 709245 in linux-linaro "panda: USB disk IO slow" [Medium,Confirmed] https://launchpad.net/bugs/709245
[17:18] <GrueMaster> interesting.
[17:26] <mahmoh> ppisati: you need that kernel tested, what are the fixes that you're looking to verify?
[17:38] <mahmoh> GrueMaster: 1309-14 - 0.2 MB/s vs. 4.0 MB/s w/ ping flood - the problem still exists, I would say this is higher than Medium too
[17:43] <GrueMaster> mahmoh: What are you running to produce these results?  We need to document them so that they are reproducible (which I am doing now and will add to the bug report).
[17:44] <mahmoh> pts/tiobench
[17:44] <mahmoh> I'm adding a comment to the original bug, and asking to raise the priority too
[17:45] <GrueMaster> Let me know when you have it filed.  I can raise priority and do other bug triage stuff from there.
[17:57] <mahmoh> GrueMaster: https://bugs.launchpad.net/linux-linaro/+bug/709245/comments/6
[17:57] <ubot2> Ubuntu bug 709245 in linux-linaro "panda: USB disk IO slow" [Medium,Confirmed]
[18:09] <Guest48215> Hi all, I am working with pandaboard trying to get a video conferencing application to be built on it
[18:09] <Guest48215> I am using ubuntu 10.10 as the 11.04 doesn't seem to contain hardware codecs
[18:09] <Guest48215> I see the panda board to have HDMI and DVI dual display capability
[18:10] <Guest48215> It seems like ubuntu 10.10 does NOT support dual display but the ubuntu 11.04 seems to have support...
[18:10] <Guest48215> Can I get pointer to the dual display patch which I can back port to ubuntu 10.10?
[18:10] <Guest48215> Please correct me if I am wrong in my assumptions
[18:23] <GrueMaster> mahmoh: If you test with the new kernel, use my test as it is quicker to setup and runs faster.
[18:23] <mahmoh> GrueMaster: which test?  I'm testing the new kernel now
[18:23] <GrueMaster> See comment 7 in the above bug.
[18:24] <GrueMaster> I also added the linux-ti-omap4 kernel to the bug.  If you reproduce it on the 3.0 kernel let me know so I can add it as well.
[18:27] <mahmoh> GrueMaster: yeah, the results appear to be the same on the 3.0.0-1 kernel
[18:30] <GrueMaster> Can you post benchmarks on the new kernel?
[19:55] <mahmoh> yes I can but it appears that they are the same a with the 2.6 kernel, no change in IO perf.
[20:00] <GrueMaster> ok
[20:01] <GrueMaster> Just note in the bug that you tried that kernel and I will add it to the top of the bug report.
[20:17] <GrueMaster> mahmoh: Check out http://lists.fedoraproject.org/pipermail/arm/2011-June/001412.html
[20:31] <mahmoh> yep, makes sense
[21:03] <mahmoh> so the 3.0.0-1 kernel looks ok - boots, runs IO performance fine - I'm running three boards with it and haven't seen any major issues as of yet
[21:07] <GrueMaster> Still has the USB performance issue though, right?
[21:38] <martyn> The performance of AoE is just POO on arm
[21:43] <GrueMaster> martyn: what are you testing with?
[22:13] <persia> Bug 709245
[22:13] <ubot2> Launchpad bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed] https://launchpad.net/bugs/709245
[22:14] <GrueMaster> persia: ??
[22:16] <persia> GrueMaster, Got a ping asking for a bug number in backscroll.  Wanted to verify the bug.  Seems like you found it already, looking at more backscroll.
[22:16] <GrueMaster> I'm currently testing to see if it affects Maverick as well.
[22:17] <persia> That's a neat idea.  Maybe it was introduced at some point, rather than being always present.
[22:17] <GrueMaster> I hope so.  Might make it easier to backtrack.
[22:19] <persia> Indeed.  If it was introduced, we can bisect it to the source.
[22:19] <persia> If it is a bug in the initial implementation, there's no guide to the specific code to be fixed.
[22:20] <Jack87|Away> anyone consider ubuntu arm on HP touchpad?
[22:21] <GrueMaster> Jack87|Away: What hardware does it have?
[22:21] <Jack87|Away> its a snapdargon not omap.
[22:22] <persia> Ought work, but someone needs to upload a kernel, as there are none supporting snapdragon in the archive.
[22:22] <Jack87|Away> http://h18004.www1.hp.com/products/quickspecs/14077_na/14077_na.pdf
[22:23] <Jack87|Away> by the way... they got xserver running as an app.
[22:27] <Jack87|Away> GrueMaster, check this out... http://yfrog.com/h0galnp
[22:28] <Jack87|Away> those desktop enviorments are an xapp runnin within the touchpad
[22:29] <GrueMaster> Cool.
[22:29] <Jack87|Away> you can see in card view :). I was just wondering if anyone has taken intrest in the device here
[22:31] <GrueMaster> I've been too swamped, and I have a Nook Color to get running ubuntu if/when I can get some spare cycles.
[22:34] <Jack87|Away> GrueMaster, hehe me to.
[22:53] <GrueMaster> Interesting resutls of testing bug 709245 on Maverick.  Not sure that I am doing this right.
[22:53] <ubot2> Launchpad bug 709245 in linux-ti-omap4 "panda: USB disk IO slow" [High,Confirmed] https://launchpad.net/bugs/709245
[23:16] <mahmoh> yes, 3.0.0-1 did not change the USB performance/ping issue
[23:17] <Neko> I think it's down to the hub chip in use
[23:17] <Neko> I suggested someone kick around the enhanced TT scheduler and turbo mode on the usb ethernet and it got ignored
[23:18] <Neko> because it has to be some kind of bug in the omap4, apparently.. and nothing to do with kernel options
[23:19] <mahmoh> if someone wants to put in the time, I'll test it for sure
[23:20] <mahmoh> persia: I thought we discussed the USB/ping problem before and someone mentioned that it was fixed in a later kernel - guess not?
[23:22] <infinity> mahmoh: Probably confusion about USB issues.  We had an issue with no USB at all, that's fixed.
[23:24] <mahmoh> it's possible