[00:04] <rlameiro> rsalveti: I was trying to follow the advice that someon gave in the bug about usb, but https://wiki.ubuntu.com/Kernel/MainlineBuilds
[00:05] <rlameiro> here they say its only i386 and AMD64
[00:07] <rlameiro> jo-erlend: are you there?
[00:26] <persia> ndec, ogra: If a special version of gstreamer is required, in a version-independent way, give it a slightly different name, with Conflicts/Replaces/Provides.  This will break external versioned dependencies, but will ensure the requested version is always installed.
[00:26] <ogra_ac> hmm
[00:26] <rsalveti> rlameiro: I'd say this bug is probably not fixed upstream
[00:26] <rsalveti> currently the best supported kernel for igepv2 is the stock one
[01:23] <NCommander> GrueMaster: do we have bug numbers for the missing ubiquity icon and oem-config?
[01:23] <NCommander> (on dove?)
[01:23]  * NCommander has a mostly viable patch ready to roll
[01:42] <GrueMaster> Ok, found it.  Bug 643791.
[01:43] <ubot2> Launchpad bug 643791 in ubiquity (Ubuntu) "Installation icon missing from Dove live image. (affects: 1) (heat: 531)" [High,Triaged] https://launchpad.net/bugs/643791
[01:43] <GrueMaster> Google is my hero.
[02:50] <DanaG> Ultimate beagle gadget pack.... great, now how do you use the LCD?  Last time I'd heard, there wasn't generic kernel support for it.
[02:52] <DanaG> And there's also no generic battery support.
[02:54] <persia> Is there non-generic support?  What needs to be generalised?
[02:55] <DanaG> Beats me -- I don't have a battery to try.  A friend of mine tried to get an LCD working, and it was non-trivial -- required modifying kernel source files.
[02:56] <persia> That's relatively easy then, as it only needs be done once.
[02:58] <DanaG> And the beaglejuice thing doesn't seem to provide any way of monitoring (such as I2C or SPI).
[03:00] <persia> No monitoring is a bit more annoying.
[03:02] <DanaG> And the modifications to kernel would be different for each LCD.  Some have different timings.
[03:02] <DanaG> For example, 480x272 wasn't doable with stock mode db.
[03:11] <persia> I'm not fussed about needing to add to the stock mode db.  Breaking everything else would be bad, but that just means we have a target for generalisation.
[04:03] <DanaG> Heck, it'd even be reasonable (maybe) to add some modeline-like syntax for the kernel parameters.
[04:27] <persia> I'd much prefer having something that worked for autodetect.  Anything that requires passing kernel parameters seems like a workaround to me.
[04:27] <DanaG> yeah, autodetect would be awesome.
[04:29] <persia> Oughtn't be that hard, really.
[04:30] <persia> The main issue is ensuring that each bit of hardware either has a unique detection signature *OR* there exists some protocal (e.g. EDID) by which parameters can be requested.
[04:33] <persia> I'd guess 75% or so is just janitorial work on the code: avoiding cases where some family of controller chips ends up being hardcoded to always be a 382x160 LCD unless overridden, etc.
[04:39] <DanaG> I'm not sure the LCD-controller pins even have a way to do EDID.
[04:42] <persia> I don't think they do.
[04:42] <persia> I think we'd need a large sample set of returns from devices to build a detection routine.
[04:44] <persia> We can fairly reliably identify a controller chip, so the first stage is probably differentiating chips in the same family.  The next would be, for each chip, identifying responses to various probes: most ought implement some out-of-bounds checker, meaning that we ought be able to identify the size through that, and some bit depth error code if we go too deep.
[04:45] <persia> Then this needs to be reported to userspace in some useful manner.
[04:46] <DanaG> I see... LCD header DOES have i2c3_sda line.
[04:47] <DanaG> But only SDA.
[04:47] <DanaG> iSN'T there also supposed to be a clock?
[04:49] <persia> There's always a clock, but it's not always exposed as a clock.
[08:08] <hrw> morning
[08:49] <Baybal> evening
[11:14] <berco> persia: ping
[11:14] <persia> berco, Good day.
[11:15] <berco> persia: hello
[11:15] <berco> persia: one question for you. Do you know how asound.state is generated?
[11:15] <berco> persia: it seems this file overwrites our settings
[11:16] <persia> How are the settings being set?
[11:16] <berco> we finally have an /usr/share/alsa/cards/SDP4430.conf file
[11:17] <berco> this file is being read now with our changes in the kernel
[11:18] <berco> But even if we suppress the asound.state file in /var/... it still gets regenerated but with different values than in our SDP4430.conf file
[11:18] <berco> then amixer cget command reports the values from asound.state
[11:19] <lool> Hmm is there a need for two x-loader source packages?
[11:31] <persia> berco, Sorry for the delay (I'm also in a meeting).  It looks like it's a call into /sbin/alsa-utils that does it.
[11:32] <persia> berco, Look at the restore_levels() and preinit_levels_on_card() functions
[11:33] <persia> It's intended to save current state and then restore, but obviously something is going wrong.
[11:33] <berco> persia: also what I found out
[11:33] <berco> do you htink we need a udev rule?
[11:34] <persia> I'm not sure how that will help in this case.
[11:35] <persia> echo_card_indices() ought be sufficient to detangle load order issues.
[11:42] <berco> persia: I will investigate. Going to lunch now :-)
[11:43] <persia> Enjoy.
[12:46] <rlameiro> rsalveti: jo-erlend there is now an IRC channel for igep, #igep
[12:47] <lool> Hey rlameiro
[12:47] <rlameiro> lool: hey :D
[12:48] <lool> rlameiro: It's great to see you on IRC; I've been looking for an #igep when I got the board!  :)
[13:04] <avinashhm> hi, if anyone uses ddebug , does dynamic debug [ddebug] support multiple files ..???
[13:10] <rsalveti> gm
[16:01] <vstehle> Hi ogra, did you try the OMAP4 preinstalled image recently? I think I have instabilities on two different boards with today's image...
[16:01] <ogra> oh ?
[16:01] <ogra> i didnt try since last week
[16:02] <ogra> though you should wait for the RC buiold later today or tomorrow
[16:02] <vstehle> ogra: What I did was simply to install the image, let it resize, go through the installer and let it sit idle for some minutes.
[16:02] <ogra> there were 100s of bugfixes the last few days
[16:02] <rsalveti> vstehle: what errors did you get?
[16:02] <ogra> yeah, what did you see
[16:02] <rsalveti> yup, true
[16:03] <vstehle> rsalveti: I get freezes, that's what I get :) I thinks it is linked to activity on the USB keyboard... No more heartbeat led. Dead.
[16:03] <ogra> sounds like kernel
[16:03] <rsalveti> hm, yeah
[16:03] <vstehle> rsalveti, ogra: I'll wait for the rc and re-test. No hurry.
[16:03] <rsalveti> vstehle: do you have console?
[16:04] <rsalveti> maybe we got a trace
[16:04] <vstehle> rsalveti: No. I think that at some point, when I typed on UART it had an effect too!
[16:04] <vstehle> rsalveti: No trace, sorry. I can retry if you are interested.
[16:04] <rsalveti> that'd be good, but let's wait rc, probably better
[16:05] <vstehle> rsalveti: I have only the 6 layers board right now.
[16:05] <rsalveti> then we can test a better image
[16:05] <ogra> oh, i dont have my 6 layer anymore
[16:05] <vstehle> rsalveti: I retry with console on that one. But only once :)
[16:05] <rsalveti> vstehle: weird, the only 2 issues I got currently on 6 and 8 are the highmem and display issues
[16:05] <rsalveti> but no hang
[16:05]  * ogra too only sees the display issues
[16:06] <vstehle> I'll capture some traces and come back.
[16:06] <rsalveti> vstehle: cool :-)
[16:06] <rsalveti> and it turns out that the led is actually usefull :-)
[16:07] <rsalveti> annoying, but useful
[16:07] <ogra> its not that annoying if the board sits idle :)
[16:08] <rsalveti> yeah, true
[16:17]  * rsalveti out for lunch
[16:20] <GrueMaster> My system has been up now for almost 20 hours.  No hangs to report.
[16:21] <GrueMaster> This is the 20100927 image.
[16:22] <ogra> that's so yesterdayish
[16:22] <ogra> but good to hear :)
[16:22] <GrueMaster> Well, there is no image yet for today (that I have seen).
[16:22] <GrueMaster> And it is updated.
[16:23] <ogra> i wasnt serious :)
[16:35] <mpoirier> ogra: I just touched base with Tim on the 6 patches submitted by Enric Balletbo.
[16:35] <ogra> what did he say ?
[16:35] <mpoirier> ogra: there is next to no chance of getting them in before the release.
[16:36] <mpoirier> I will write SRUs for them and they will go in after.
[16:36] <ogra> i didnt expect them before release
[16:36] <ogra> cool !
[16:36] <mpoirier> me neither.
[16:36] <mpoirier> also,
[16:36] <mpoirier> in the TI meeting last week, you mentionned that when you hit the display problem,
[16:37] <mpoirier> to change the console..
[16:37] <mpoirier> what does that mean exactly ?
[16:38] <ogra> pressing ctrl-alt+f1 --- then ctrl-alt+f7
[16:38] <mpoirier> and what does that do for a living ?
[16:38] <ogra> it switches ttys
[16:38] <ogra> and if i return to tty7 my screen is back
[16:39] <mpoirier> humm...
[16:39] <mpoirier> never done this before, let me try...
[16:40] <mpoirier> ogra: I'm faced with a weird display problem on my panda.
[16:40] <mpoirier> the screen goes blank after a while and doesn't come back.
[16:40] <ogra> how does that manifest ?
[16:40] <ogra> yeah, thats the one
[16:41] <mpoirier> no error on the screen, unblanking won't work, nor the above little trick.
[16:41] <mpoirier> serial console is responsive...
[16:41] <ogra> ouch
[16:41] <mpoirier> I've hit something like that before... I think.
[16:41]  * ogra hanst seen that
[16:42] <mpoirier> I won't do anything about it just now.
[16:42] <GrueMaster> I think you are referring to bug 644714.
[16:42] <ubot2> Launchpad bug 644714 in linux-ti-omap4 (Ubuntu) "Screen corruption waking from screen blank if no monitor present (affects: 1) (heat: 526)" [Undecided,New] https://launchpad.net/bugs/644714
[16:42] <mpoirier> maybe...
[16:42] <mpoirier> just maybe.
[16:43] <GrueMaster> I think what is happening is the system is querying for edid each time.  I hit it the most with my hdmi switch box.
[16:43] <GrueMaster> Very reproducable.
[16:43] <mpoirier> I was looking at that bug too.
[16:43] <mpoirier> GrueMaster: I'll get back to you when I start investigating this bug.
[16:44]  * GrueMaster isn't going anywhere soon.
[16:47] <mpoirier> GrueMaster: I think just reproduced the proble you've described.
[16:47] <mpoirier> fixing it will be fun.
[16:47] <GrueMaster> Well, enjoy yourself.  :P
[16:48] <mpoirier> A potential solution will be to keep the highest resolution the system has seen so far and set it to that when EDID can't be read.
[16:48] <mpoirier> or maybe it this is how upstream has designed the thing...
[16:48] <mpoirier> if no EDID, set to lower possible resolution.
[16:48] <GrueMaster> That I think is the proper solution.  Not sure what other systems do, you might check dove & babbage solutions.
[16:49] <GrueMaster> I know it goes to 640x480, which I don't think it properly supports.
[16:49] <mpoirier> I don't have dove nor babbage so I can't test.
[16:50] <GrueMaster> You have source trees.
[16:50] <GrueMaster> And I have hardware.
[16:50] <mpoirier> Yes, but trying will be easier and much more reliable.
[16:50] <thalass> good evening
[16:50] <mpoirier> like finding needle in hay stack.
[16:50] <mpoirier> good evening.
[16:50] <GrueMaster> What I am implying is that these platforms have no kernel parameters (unlike beagle), yet they maintain their resolution settings.
[16:51] <mpoirier> GrueMaster: have you done the same test on those platform ?
[16:51] <GrueMaster> They are all on the same switch/monitor.
[16:52] <GrueMaster> And it is a 19" widescreen 1440x900.
[16:52] <mpoirier> and you see the problem on omap4 only ?
[16:52] <thalass> I'm curious about the ARM version of Ubuntu, and whether anyone has tried it on a Nokia N900. I'm getting one soon, and if Maemo support fades away after a while i might decide to go with ubuntu rather than this meego thing nokia are replacing maemo with.
[16:52] <GrueMaster> yes
[16:53] <GrueMaster> Now, babbage is set to 1024x768 it appears.
[16:53] <mpoirier> GrueMaster: how about omap3 - what is the behavior ?
[16:53] <GrueMaster> Omap3 has a kernel parameter at boot for video.
[16:54] <GrueMaster> omapfb.mode=dvi:1280x720MR-16@60
[16:54] <GrueMaster> So it should stay at a fixed resolution.
[16:54] <mpoirier> it *should*, but does it stay at a fixed resolution ?
[16:54] <GrueMaster> babbage may be hardcoded to run at 1024x768.  Not sure.
[16:55] <GrueMaster> Haven't seen an issue with beagle changing resolution.
[16:56] <mpoirier> had there been one, would you have hit it ? i.e has a beagle ever been in teh same setup ?
[16:57] <GrueMaster> Only recently have I added the panda to the hdmi switch.  I bought the switch specifically so I wouldn't have to buy more monitors.
[16:57] <GrueMaster> Beagle, XM, and babbage have shared this configuration all cycle.
[16:57] <mpoirier> has beagle ever been connected to the hdmi switch ?
[16:57] <mpoirier> ok.
[16:59] <mpoirier> it will be interesting to see if the resolution on omap4 stay the same if using "omapfb.mode=dvi:1280x720MR-16@60"  in u-boot...
[17:00] <GrueMaster> Well, one way to find out.  Give me a  few minutes.
[17:02] <mpoirier> cool.
[17:03] <ynezz> how do you set the resolution if not in u-boot?
[17:04] <ynezz> as I understand it, fb_ddc is not working on omap yet, so the kernel will fallback to some default
[17:06] <mpoirier> ynezz: to the best of my knowledge, in omap3 u-boot is the only place.
[17:06] <mpoirier> ynezz: on omap4, the driver parses the EDID and set resolution to highest possible.
[17:06] <ynezz> wow
[17:06] <GrueMaster> thalass: Do a google search.  From what I understand, there is documentation available on how to do that.
[17:07] <ynezz> mpoirier: it's the tree with this EDID parsing for omap4 available somewhere?
[17:07] <mpoirier> ours does it.
[17:08] <mpoirier> ynezz: sorry, ubuntu doesn it.
[17:08] <mpoirier> ynezz: sorry again, ubuntu DOES parse EDID.
[17:08] <ynezz> :)
[17:08] <ynezz> in kernel?
[17:09] <mpoirier> yes.
[17:09] <ynezz> gotta find it
[17:09] <mpoirier> find what, the ubuntu kernel ?
[17:11] <ynezz> yes, the source for omap4 kernel and look how it's done and possibly backport it to omap3/beagle
[17:11] <mpoirier> rsalveti: you on ?
[17:12] <mpoirier> ynezz: hold on.
[17:12] <ynezz> I've started some work with EDID parsing in u-boot already, but than have been told, that it would be better to have it proper place, in kernel
[17:13] <mpoirier> ynezz: that is the same conclusion ubuntu came with.
[17:13] <mpoirier> ogra: my buggy brain remembers rsalveti was doing something with EDID in omap3.  Do you recall ?
[17:14] <GrueMaster> bjf: You sent out a test request for lucid proposed kernel updates, but I am not seeing one for fsl-imx51.  Could you check to make sure it built and was published?
[17:14] <mpoirier> ynezz: ok, it's just you and me here.
[17:15] <mpoirier> ynezz: I was supposed to backport omap4 for EDID feature to omap3.
[17:15] <mpoirier> but, to the *best* of my recollection, rsalveti had started the work.
[17:15] <ogra> mpoirier, yes, but it didnt make it in
[17:15] <mpoirier> ogra: what do you mean ? technical problem or time constraints ?
[17:16] <ogra> time
[17:16] <bjf> GrueMaster, https://edge.launchpad.net/ubuntu/+source/linux-fsl-imx51
[17:16] <ogra> he took over from dyfet
[17:16] <bjf> GrueMaster, 2.6.31-608.20 went into proposed 3 hours ago
[17:16] <mpoirier> ogra: I'm talking about backporting omap4 EDID functionality to omap3
[17:16] <GrueMaster> Yea, well system isn't seeing it yet.
[17:17] <ogra> mpoirier, wes, he had two ideas, one was to just hack it into u-boot and the other was to do it properly in the kernel
[17:17] <ynezz> mpoirier: cool, found that [PATCH 0/2]OMAP:DSS:RFC for HDMI in OMAP4
[17:17] <ogra> mpoirier, buit there was time for neither
[17:17] <mpoirier> ogra: he should have told me... I can probably do something about it.
[17:18] <rsalveti> mpoirier: I'm now
[17:18] <mpoirier> rsalveti in the flesh - cool !
[17:18] <mpoirier> rsalveti: what's the status on backporting omap4 EDID thing to omap 3 ?
[17:19] <rsalveti> mpoirier: backporting is not actually the right thing right now
[17:19] <rsalveti> we should improve it first, try to use the common kernel api for edid
[17:19] <GrueMaster> bjf: Source is visible at http://ports.ubuntu.com/pool/main/l/linux-fsl-imx51/ but no .deb
[17:19] <rsalveti> and then propose a common solution
[17:19] <rsalveti> what I got is a patch that parse the edid and try to set up the default resolution for omap 3
[17:20] <rsalveti> the draft works, but will need improvements to send it upstream, and the omap 4 driver needs a lot more love
[17:20] <rsalveti> mpoirier: this bug is not related with edid I'd say
[17:20] <mpoirier> rsalveti: what bug ?
[17:20] <rsalveti> it's probably the bug I'm facing with my monitor, that I was planning to start debugging it today
[17:20] <rsalveti> the 640x480 on omap 4
[17:20] <ynezz> rsalveti: can you pls share your patch?
[17:21] <mpoirier> rsalveti: ynezz was asking about the backport of Rob Clark's work on the omap4 EDID.
[17:21] <rsalveti> ynezz: sure, will publish it at my tree and send you the link
[17:21] <ynezz> this is my beginning with EDID parsing in u-boot http://github.com/ynezz/u-boot-sakoman/commit/36ab7487e1b55ae54b44b02196c4ebfd8ebe1a58
[17:21] <mpoirier> that's when I told him about your work, hence this discussion.
[17:21] <GrueMaster> bjf: Nevermind.  Looks like it just started building.
[17:21] <ynezz> but I'll rework it to use the EDID parsing code in kernel
[17:21] <rsalveti> ynezz: yup, saw that, also did something similar when trying the edid parsing
[17:22] <rsalveti> ynezz: cool, nice to see more people interested on that
[17:22] <bjf> GrueMaster, sorry was a little premature there
[17:23] <GrueMaster> bjf: Heh.  No big deal.  I was just making sure it wasn't stuck in post-build limbo which has happened in the past.
[17:23] <rsalveti> ynezz: just give me some minutes and I'll publish it, cause I'm waiting a kernel built to finish on the same tree
[17:23] <ynezz> rsalveti: no problem, I don't need it today or tommorow :)
[17:23] <rsalveti> ynezz: what's your email? will send you explaning what I did and what is the state of the omap 4 implementation
[17:23] <ynezz> ynezz@true.cz
[17:24] <ynezz> but maybe it would be better to follow up on my email in beagleboard mailing list
[17:24] <ynezz> there are others interested in this
[17:24] <ynezz> thanks
[17:24] <rsalveti> sure, np
[17:27] <mpoirier> GrueMaster: how's your testing going ?
[17:28] <GrueMaster> System is in the middle of a package update.  Should be able to try testing in 10 minutes or so.
[17:29] <ynezz> rsalveti: I wonder if the omap4 patch makes it in, looks to me, it's duplicating a lot of code already available in fb_dcc
[17:29] <rsalveti> ynezz: yup, that's why it needs more work on it first
[17:29] <rsalveti> it's parsing it by hand
[17:30] <rsalveti> I tried to use it on my patch the most I could
[17:30] <rsalveti> so we'd avoid having duplicates
[17:31] <GrueMaster> Hmmm.  This is interesting.  While watching apt-get install packages, it will fill the screen with gdk-pixbuf errors (which I will need to file a bug on) and then it starts typing the last line 1 character at a time for about 20 characters before resuming full speed.
[17:33] <GrueMaster> The gdk-pixbuf issue appears to just be a flood of warnings.
[17:34] <mpoirier> persia: you on ?
[17:34] <GrueMaster> It is 1:35am his time.  Doubtful.
[17:35] <mpoirier> GrueMaster: he told me to poke him at any hours of the day...
[17:35] <mpoirier> I'm trying my luck...
[17:35] <mpoirier> GrueMaster: you panda,
[17:36] <mpoirier> do you boot it with DHCP or static IP ?
[17:36] <GrueMaster> Hey, lets not get personal.
[17:36] <ynezz> rsalveti: ok, I've found the thread on linux-omap mailing list about that EDID/HDMI/OMAP4 and I'll ask that guy some questions about OMAP3 support, as I see it would be wise to have some common functionality for both cores from start
[17:36] <GrueMaster> Oh.  DHCP.
[17:36] <rsalveti> ynezz: do you have the link or thread name?
[17:36] <mpoirier> ok. does it keep the same mac address after every boot ?
[17:37] <ynezz> rsalveti: http://www.spinics.net/lists/linux-omap/msg35867.html
[17:37] <GrueMaster> I'm not sure.  Have to check the logs.
[17:37] <rsalveti> ynezz: oh, about the hdmi, thanks
[17:37] <mpoirier> doing ifconfig -a will tell you.
[17:38] <rsalveti> ynezz: you can ask mythripk directly :-)
[17:38] <GrueMaster> Not very well.  I do image testing.  Meaning I have a new image almost daily.
[17:38] <mpoirier> also, if the mac changes, you *should* get a different ip address.
[17:38] <GrueMaster> I can more easily check my dhcp logs.
[17:38] <GrueMaster> one sec (requires monitor switch).
[17:39] <mpoirier> as you please.
[17:40] <rsalveti> ynezz: but I believe one thing is the hdmi driver, another is the edid parsing
[17:40] <rsalveti> for the only the edid parsing part could be common for both omap 3 and omap 4
[17:41] <ynezz> brb
[17:41] <GrueMaster> mpoirier: Doesn't look like it, but then again, I'm not sure.  I only have one entry in my server for panda8 (8 layer ES2.0), but 3 different mac entries for panda6 (6 layer ES2.0)
[17:42] <mpoirier> GrueMaster: are you doing anythign special with your panda8 right now ?
[17:42] <thalass> Gruemaster: Thanks. I didn't find much before i came in here, but it does seem promising. I doubt i'll attempt it while the phone is under warranty. But thanks!
[17:44] <GrueMaster> mpoirier: Not really.  I was mainly focusing on dove audio today while I await RC images.
[17:44] <mpoirier> is your panda8 up ?
[17:45] <GrueMaster> Not at the moment.  Ran out of spare power supplies (have to timeshare with my XM at the moment).
[17:45] <GrueMaster> I plan on getting another one today.
[17:46] <mpoirier> GrueMaster: ok, when you do bring it up, please do an ifconfig from the console and note the mac address.
[17:46] <mpoirier> from there reboot, and check the mac again.
[17:47] <mpoirier> mine changes from boot to boot.
[17:47] <ynezz> rsalveti: I don't know much about omap4 and its differences between omap3
[17:47] <mpoirier> GrueMaster: either driver issue or not MAC has been programmed in eeprom.
[17:48] <ynezz> rsalveti: as I understand it, on omap3 you can read edid using i2c3 and on omap4 using hdmi, right?
[17:48] <rsalveti> ynezz: http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.0_Public_TRM_vJ.pdf in case you want to know more about it
[17:48] <rsalveti> ynezz: right
[17:54] <ynezz> rsalveti: ok, so I think, that the right place to do that stuff would be using fb_ddc, just adding something like drivers/video/omap2/i2c.c for omap3 and drivers/video/omap4/hdmi.c for omap4 with code which will contain same functionality like for example drivers/video/nvidia/nv_i2c.c
[17:54] <ynezz> code for just reading edid and leave the rest on fb_ddc
[17:54] <rsalveti> ynezz: yeah, that's what I think
[17:55] <rsalveti> give me just a min and I'll show you what I did
[17:55] <ynezz> cool
[17:57] <GrueMaster> mpoirier: Yes, it appears to change.  Not sure if that can be "fixed" by setting a variable in the boot.scr.  I don't think this version of uboot supports the nic.
[17:58] <mpoirier> GrueMaster: thanks - it confirms my suspicion.
[17:58] <mpoirier> I'll check with TI before opening a bug...
[18:01] <GrueMaster> You may not get very far.  Dove has the same issue and there has been a bug on that for two cycles.
[18:01] <GrueMaster> Their answer was that they didn't want to cause conflict between two systems with the same mac.
[18:08] <rsalveti> ynezz: please check http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/omap3-edid-parsing
[18:08] <rsalveti> ynezz: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=a0ea712b64988ccd7984069b99864a1b4ac43881;hp=99372b26f533da4d9f6e59a744c67170a7d990d3
[18:09] <rsalveti> here you can find how I'm probing and parsing it
[18:09] <ynezz> ok, thanks!
[18:09] <rsalveti> I decided to first generate the modedb, like any other video driver we have, and then try to get the best one
[18:09] <rsalveti> it's dvi, but I'm only using CVT with reduced blanking
[18:09] <rsalveti> to get better timings
[18:10] <rsalveti> ynezz: and then the dpi_check_timings will try to adjust the timings to be ok with the pck
[18:11] <rsalveti> so if you have an example that has a higher pck (limit 86500), it'll try to adjust the vsync and hsync
[18:11] <rsalveti> so it can work at least from the omap perspective
[18:11] <rsalveti> but then you need to check if this is actually supported by the monitor, otherwise you'll easily get out of sync
[18:13] <rsalveti> ynezz: if you activate debug at drivers/video/fbmon.c you'll see all the modes and everything, quite cool
[18:13] <rsalveti> ynezz: I know the panel-generic is not the right place, was using it just to get a working model
[18:13] <ynezz> and another one from tomba http://groups.google.com/group/beagleboard/msg/bd988bdaa65b7d58
[18:13] <ynezz> :)
[18:17] <rsalveti> yup, a little bit similar, but he register an i2c device
[18:18] <rsalveti> with my patch I get Best Mode: 1280x1024@56 from my monitor
[18:19] <rsalveti> it's the same one you'll get when using 1280x1024MR@60
[18:19] <ynezz> cool, will try it on my TV :)
[18:20] <rsalveti> ynezz: but I also want to improve it to get the best one respecting the aspect ratio
[18:20] <rsalveti> 1280x720 looks better at my monitor
[18:25] <ajay> hi i all i am not able to get uboot prompt over minicom
[18:28] <ynezz> rsalveti: I've stolen a few EDID dumps somewhere http://github.com/ynezz/u-boot-edid/tree/master/test/
[18:28] <ynezz> rsalveti: parsing them and looking into the output seems quite interesting
[18:28] <rsalveti> ynezz: hm, lots of interesting ones, cool :-)
[18:29] <rsalveti> ynezz: do you have all these monitors to test? would be awesome
[18:29] <ynezz> nope :)
[18:29] <ynezz> jsut this one http://github.com/ynezz/u-boot-edid/blob/master/test/edid.lcd.tv.samsung32inch
[18:29] <rsalveti> got it :-)
[18:30] <rsalveti> that's the main reason I postponed this feature for maverick, lack of monitors to test at the moment
[18:30] <rsalveti> wanted first to be sure that we're not getting a bizarre result with some monitors
[18:31] <GrueMaster> ajay: What system are you using?  Do you have your serial port set to 115200?  Null Modem Cable?
[18:31] <ynezz> rsalveti: we've quite a few different 14-27", different vendors in the company, so I can test it, no problem
[18:32] <rsalveti> cool, good to know
[18:45] <mpoirier> GrueMaster: did you have time to dig up the few options needed to get beagle sound going ?   No big deal if you haven't...
[18:46] <GrueMaster> No, but I can in a second.  System is available & idle.
[18:46] <mpoirier> cool
[19:01] <GrueMaster> sorry, network is running a bit slow.  Mirror must be updating.
[19:07] <GrueMaster> mpoirier: http://paste.ubuntu.com/502238/ But the volume control labels were cut off by diff.  First is "DAC2 Analog" second is "Headset".  I will post a tarball with both amixer-before and amixer-after output shortly.
[19:08] <mpoirier> GrueMaster: before and after what ?
[19:09] <mpoirier> what's happening in between ?
[19:09] <GrueMaster> I ran "amixer>amixer-before.txt" to dump default settings, then made changes in alsamixer, and redumped.
[19:10] <GrueMaster> File is at http://members.dsl-only.net/~tdavis/beagle-audio.tgz
[19:11] <GrueMaster> running amixer by itself will dump the current mixer settings/levels.  Then alsamixer can be used to visually change them.
[19:12] <mpoirier> GrueMaster: you just typed "amixer" on the cmd line ?
[19:12] <GrueMaster> yes
[19:13] <GrueMaster> You do know how to use alsa utils, right?
[19:13] <mpoirier> I do but I need to undertand exactly what you did to reproduce properly.
[19:14] <mpoirier> The "alsamixer used to visually change them" part, is that through graphic interface ?
[19:15] <GrueMaster> It is a console tool.
[19:15] <GrueMaster> Open a terminal and try it.  It gives you direct control over the exposed audio controls through the driver.
[19:16] <mpoirier> yes, just wanted to make sure we're on the same page.
[20:44] <mpoirier> GrueMaster: I've been playing with sound for a while now thanks.
[20:44] <GrueMaster> ok
[20:45] <mpoirier> GrueMaster: how did you know it was "HeadsetL Mixer AudioL2" you had to un-mute ?
[20:45] <mpoirier> is there a trick ?
[20:45] <GrueMaster> Yea, open two terminal windows, start "speaker-test -c 2 -t wav" in one and tweak alsamixer controls in the other until audio is heard.
[20:46] <mpoirier> AH !
[20:46] <GrueMaster> Speaker-test will run untill <ctrl>-c.
[20:47] <mpoirier> I love brute force solutions - thanks.
[20:47] <GrueMaster> Well, I am a brute, so it's what I do.
[20:47] <GrueMaster> :P
[21:10] <Heff01> Hi, can anyone help enable svideo in Maverick Meerkat beta, on Beagle XM, over minicom
[21:14] <GrueMaster> Heff01: I don't know if that has been tested or even enabled.  Not something that is easy to test here.
[21:15] <Heff01> Stuck until I get hdmi to dvi d cable then
[21:15] <PhilM> I left one in my cube when I left TI
[21:15] <Heff01> doh
[21:16] <PhilM> :-)
[21:16] <Heff01> Only got board yesterday, just eager to get going
[21:16] <PhilM> Micro Center carries them for $10US
[21:16] <Heff01> I know, on GMT everythings shut
[21:17] <Heff01> had svideo lying around
[21:18] <Heff01> I guess it could be enabled thru xorg when booted
[21:20] <Heff01> #android-arm