| 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:04 |
|---|---|---|
| rlameiro | here they say its only i386 and AMD64 | 00:05 |
| rlameiro | jo-erlend: are you there? | 00:07 |
| 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 | 00:26 |
| === freeflyi1g is now known as freeflying | ||
| 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:23 | |
| GrueMaster | Ok, found it. Bug 643791. | 01:42 |
| 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. | 01:43 |
| 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:50 |
| DanaG | And there's also no generic battery support. | 02:52 |
| persia | Is there non-generic support? What needs to be generalised? | 02:54 |
| 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:55 |
| persia | That's relatively easy then, as it only needs be done once. | 02:56 |
| DanaG | And the beaglejuice thing doesn't seem to provide any way of monitoring (such as I2C or SPI). | 02:58 |
| persia | No monitoring is a bit more annoying. | 03:00 |
| 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:02 |
| 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. | 03:11 |
| DanaG | Heck, it'd even be reasonable (maybe) to add some modeline-like syntax for the kernel parameters. | 04:03 |
| 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:27 |
| persia | Oughtn't be that hard, really. | 04:29 |
| 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:30 |
| 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:33 |
| DanaG | I'm not sure the LCD-controller pins even have a way to do EDID. | 04:39 |
| 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:42 |
| 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:44 |
| persia | Then this needs to be reported to userspace in some useful manner. | 04:45 |
| DanaG | I see... LCD header DOES have i2c3_sda line. | 04:46 |
| DanaG | But only SDA. | 04:47 |
| DanaG | iSN'T there also supposed to be a clock? | 04:47 |
| persia | There's always a clock, but it's not always exposed as a clock. | 04:49 |
| === ericm_ is now known as ericm|ubuntu | ||
| === hrw|gone is now known as hrw | ||
| hrw | morning | 08:08 |
| Baybal | evening | 08:49 |
| === JamieBen1ett is now known as JamieBennett | ||
| === asac_ is now known as asac | ||
| berco | persia: ping | 11:14 |
| persia | berco, Good day. | 11:14 |
| 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:15 |
| persia | How are the settings being set? | 11:16 |
| berco | we finally have an /usr/share/alsa/cards/SDP4430.conf file | 11:16 |
| berco | this file is being read now with our changes in the kernel | 11:17 |
| 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:18 |
| lool | Hmm is there a need for two x-loader source packages? | 11:19 |
| 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:31 |
| persia | berco, Look at the restore_levels() and preinit_levels_on_card() functions | 11:32 |
| 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:33 |
| persia | I'm not sure how that will help in this case. | 11:34 |
| persia | echo_card_indices() ought be sufficient to detangle load order issues. | 11:35 |
| berco | persia: I will investigate. Going to lunch now :-) | 11:42 |
| persia | Enjoy. | 11:43 |
| rlameiro | rsalveti: jo-erlend there is now an IRC channel for igep, #igep | 12:46 |
| lool | Hey rlameiro | 12:47 |
| rlameiro | lool: hey :D | 12:47 |
| lool | rlameiro: It's great to see you on IRC; I've been looking for an #igep when I got the board! :) | 12:48 |
| avinashhm | hi, if anyone uses ddebug , does dynamic debug [ddebug] support multiple files ..??? | 13:04 |
| rsalveti | gm | 13:10 |
| === rgreening_ is now known as ghost | ||
| === ghost is now known as rgreening | ||
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 | |
| 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:06 |
| rsalveti | annoying, but useful | 16:07 |
| ogra | its not that annoying if the board sits idle :) | 16:07 |
| rsalveti | yeah, true | 16:08 |
| * rsalveti out for lunch | 16:17 | |
| GrueMaster | My system has been up now for almost 20 hours. No hangs to report. | 16:20 |
| GrueMaster | This is the 20100927 image. | 16:21 |
| ogra | that's so yesterdayish | 16:22 |
| ogra | but good to hear :) | 16:22 |
| === zyga is now known as zyga-dinner | ||
| GrueMaster | Well, there is no image yet for today (that I have seen). | 16:22 |
| GrueMaster | And it is updated. | 16:22 |
| ogra | i wasnt serious :) | 16:23 |
| 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:35 |
| 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:36 |
| mpoirier | to change the console.. | 16:37 |
| mpoirier | what does that mean exactly ? | 16:37 |
| 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:38 |
| mpoirier | humm... | 16:39 |
| mpoirier | never done this before, let me try... | 16:39 |
| 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:40 |
| 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:41 | |
| 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:42 |
| 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:43 |
| * GrueMaster isn't going anywhere soon. | 16:44 | |
| === zyga-dinner is now known as zyga | ||
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| mpoirier | GrueMaster: have you done the same test on those platform ? | 16:51 |
| === hrw is now known as hrw|gone | ||
| GrueMaster | They are all on the same switch/monitor. | 16:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| GrueMaster | Haven't seen an issue with beagle changing resolution. | 16:55 |
| mpoirier | had there been one, would you have hit it ? i.e has a beagle ever been in teh same setup ? | 16:56 |
| 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:57 |
| 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... | 16:59 |
| GrueMaster | Well, one way to find out. Give me a few minutes. | 17:00 |
| mpoirier | cool. | 17:02 |
| ynezz | how do you set the resolution if not in u-boot? | 17:03 |
| ynezz | as I understand it, fb_ddc is not working on omap yet, so the kernel will fallback to some default | 17:04 |
| 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:06 |
| ynezz | mpoirier: it's the tree with this EDID parsing for omap4 available somewhere? | 17:07 |
| mpoirier | ours does it. | 17:07 |
| 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:08 |
| mpoirier | yes. | 17:09 |
| ynezz | gotta find it | 17:09 |
| mpoirier | find what, the ubuntu kernel ? | 17:09 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| rsalveti | ynezz: cool, nice to see more people interested on that | 17:22 |
| bjf | GrueMaster, sorry was a little premature there | 17:22 |
| 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:23 |
| 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:24 |
| mpoirier | GrueMaster: how's your testing going ? | 17:27 |
| GrueMaster | System is in the middle of a package update. Should be able to try testing in 10 minutes or so. | 17:28 |
| 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:29 |
| rsalveti | I tried to use it on my patch the most I could | 17:30 |
| rsalveti | so we'd avoid having duplicates | 17:30 |
| 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:31 |
| GrueMaster | The gdk-pixbuf issue appears to just be a flood of warnings. | 17:33 |
| mpoirier | persia: you on ? | 17:34 |
| GrueMaster | It is 1:35am his time. Doubtful. | 17:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| mpoirier | as you please. | 17:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| === 50UAAQ1AI is now known as ian_brasil | ||
| 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:54 |
| rsalveti | give me just a min and I'll show you what I did | 17:55 |
| ynezz | cool | 17:55 |
| 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:57 |
| mpoirier | GrueMaster: thanks - it confirms my suspicion. | 17:58 |
| mpoirier | I'll check with TI before opening a bug... | 17:58 |
| 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:01 |
| 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:08 |
| 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:09 |
| rsalveti | ynezz: and then the dpi_check_timings will try to adjust the timings to be ok with the pck | 18:10 |
| 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:11 |
| 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:13 |
| rsalveti | yup, a little bit similar, but he register an i2c device | 18:17 |
| rsalveti | with my patch I get Best Mode: 1280x1024@56 from my monitor | 18:18 |
| rsalveti | it's the same one you'll get when using 1280x1024MR@60 | 18:19 |
| ynezz | cool, will try it on my TV :) | 18:19 |
| 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:20 |
| ajay | hi i all i am not able to get uboot prompt over minicom | 18:25 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| rsalveti | cool, good to know | 18:32 |
| 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:45 |
| GrueMaster | No, but I can in a second. System is available & idle. | 18:46 |
| mpoirier | cool | 18:46 |
| GrueMaster | sorry, network is running a bit slow. Mirror must be updating. | 19:01 |
| 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:07 |
| mpoirier | GrueMaster: before and after what ? | 19:08 |
| 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:09 |
| GrueMaster | File is at http://members.dsl-only.net/~tdavis/beagle-audio.tgz | 19:10 |
| GrueMaster | running amixer by itself will dump the current mixer settings/levels. Then alsamixer can be used to visually change them. | 19:11 |
| mpoirier | GrueMaster: you just typed "amixer" on the cmd line ? | 19:12 |
| GrueMaster | yes | 19:12 |
| 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:13 |
| mpoirier | The "alsamixer used to visually change them" part, is that through graphic interface ? | 19:14 |
| 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:15 |
| mpoirier | yes, just wanted to make sure we're on the same page. | 19:16 |
| mpoirier | GrueMaster: I've been playing with sound for a while now thanks. | 20:44 |
| GrueMaster | ok | 20:44 |
| 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:45 |
| mpoirier | AH ! | 20:46 |
| GrueMaster | Speaker-test will run untill <ctrl>-c. | 20:46 |
| 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 | 20:47 |
| Heff01 | Hi, can anyone help enable svideo in Maverick Meerkat beta, on Beagle XM, over minicom | 21:10 |
| GrueMaster | Heff01: I don't know if that has been tested or even enabled. Not something that is easy to test here. | 21:14 |
| 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:15 |
| 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:16 |
| Heff01 | had svideo lying around | 21:17 |
| Heff01 | I guess it could be enabled thru xorg when booted | 21:18 |
| Heff01 | #android-arm | 21:20 |
| === JaMa is now known as JaMa|Zzz | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!