**** BEGIN LOGGING AT Tue Sep 28 02:59:57 2010 Sep 28 03:04:23 Heck, it'd even be reasonable (maybe) to add some modeline-like syntax for the kernel parameters. Sep 28 03:27:50 I'd much prefer having something that worked for autodetect. Anything that requires passing kernel parameters seems like a workaround to me. Sep 28 03:28:19 yeah, autodetect would be awesome. Sep 28 03:30:11 Oughtn't be that hard, really. Sep 28 03:30:51 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. Sep 28 03:33:53 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. Sep 28 03:40:27 I'm not sure the LCD-controller pins even have a way to do EDID. Sep 28 03:43:00 I don't think they do. Sep 28 03:43:23 I think we'd need a large sample set of returns from devices to build a detection routine. Sep 28 03:44:52 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. Sep 28 03:45:44 Then this needs to be reported to userspace in some useful manner. Sep 28 03:47:23 I see... LCD header DOES have i2c3_sda line. Sep 28 03:47:33 But only SDA. Sep 28 03:47:46 iSN'T there also supposed to be a clock? Sep 28 03:50:07 There's always a clock, but it's not always exposed as a clock. Sep 28 07:09:11 morning Sep 28 07:49:57 evening Sep 28 10:14:51 persia: ping Sep 28 10:15:07 berco, Good day. Sep 28 10:15:38 persia: hello Sep 28 10:15:56 persia: one question for you. Do you know how asound.state is generated? Sep 28 10:16:13 persia: it seems this file overwrites our settings Sep 28 10:16:38 How are the settings being set? Sep 28 10:17:18 we finally have an /usr/share/alsa/cards/SDP4430.conf file Sep 28 10:17:36 this file is being read now with our changes in the kernel Sep 28 10:18:32 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 Sep 28 10:19:00 then amixer cget command reports the values from asound.state Sep 28 10:19:50 Hmm is there a need for two x-loader source packages? Sep 28 10:32:12 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. Sep 28 10:33:24 berco, Look at the restore_levels() and preinit_levels_on_card() functions Sep 28 10:33:39 It's intended to save current state and then restore, but obviously something is going wrong. Sep 28 10:33:52 persia: also what I found out Sep 28 10:34:24 do you htink we need a udev rule? Sep 28 10:35:19 I'm not sure how that will help in this case. Sep 28 10:35:46 echo_card_indices() ought be sufficient to detangle load order issues. Sep 28 10:43:19 persia: I will investigate. Going to lunch now :-) Sep 28 10:43:44 Enjoy. Sep 28 11:46:47 rsalveti: jo-erlend there is now an IRC channel for igep, #igep Sep 28 11:47:51 Hey rlameiro Sep 28 11:47:58 lool: hey :D Sep 28 11:48:32 rlameiro: It's great to see you on IRC; I've been looking for an #igep when I got the board! :) Sep 28 12:04:32 hi, if anyone uses ddebug , does dynamic debug [ddebug] support multiple files ..??? Sep 28 12:11:23 gm Sep 28 15:02:00 Hi ogra, did you try the OMAP4 preinstalled image recently? I think I have instabilities on two different boards with today's image... Sep 28 15:02:17 oh ? Sep 28 15:02:29 i didnt try since last week Sep 28 15:02:52 though you should wait for the RC buiold later today or tomorrow Sep 28 15:02:56 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. Sep 28 15:03:07 there were 100s of bugfixes the last few days Sep 28 15:03:12 vstehle: what errors did you get? Sep 28 15:03:24 yeah, what did you see Sep 28 15:03:25 yup, true Sep 28 15:03:57 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. Sep 28 15:04:13 sounds like kernel Sep 28 15:04:18 hm, yeah Sep 28 15:04:21 rsalveti, ogra: I'll wait for the rc and re-test. No hurry. Sep 28 15:04:24 vstehle: do you have console? Sep 28 15:04:48 maybe we got a trace Sep 28 15:04:50 rsalveti: No. I think that at some point, when I typed on UART it had an effect too! Sep 28 15:05:05 rsalveti: No trace, sorry. I can retry if you are interested. Sep 28 15:05:29 that'd be good, but let's wait rc, probably better Sep 28 15:05:33 rsalveti: I have only the 6 layers board right now. Sep 28 15:05:35 then we can test a better image Sep 28 15:05:57 oh, i dont have my 6 layer anymore Sep 28 15:06:01 rsalveti: I retry with console on that one. But only once :) Sep 28 15:06:09 vstehle: weird, the only 2 issues I got currently on 6 and 8 are the highmem and display issues Sep 28 15:06:24 but no hang Sep 28 15:06:25 * ogra too only sees the display issues Sep 28 15:06:32 I'll capture some traces and come back. Sep 28 15:06:39 vstehle: cool :-) Sep 28 15:07:11 and it turns out that the led is actually usefull :-) Sep 28 15:07:34 annoying, but useful Sep 28 15:07:48 its not that annoying if the board sits idle :) Sep 28 15:08:43 yeah, true Sep 28 15:17:35 * rsalveti out for lunch Sep 28 15:21:25 My system has been up now for almost 20 hours. No hangs to report. Sep 28 15:22:12 This is the 20100927 image. Sep 28 15:22:33 that's so yesterdayish Sep 28 15:22:44 but good to hear :) Sep 28 15:23:16 Well, there is no image yet for today (that I have seen). Sep 28 15:23:22 And it is updated. Sep 28 15:24:00 i wasnt serious :) Sep 28 15:36:01 ogra: I just touched base with Tim on the 6 patches submitted by Enric Balletbo. Sep 28 15:36:13 what did he say ? Sep 28 15:36:25 ogra: there is next to no chance of getting them in before the release. Sep 28 15:36:40 I will write SRUs for them and they will go in after. Sep 28 15:36:44 i didnt expect them before release Sep 28 15:36:50 cool ! Sep 28 15:36:50 me neither. Sep 28 15:37:00 also, Sep 28 15:37:23 in the TI meeting last week, you mentionned that when you hit the display problem, Sep 28 15:37:31 to change the console.. Sep 28 15:37:51 what does that mean exactly ? Sep 28 15:38:41 pressing ctrl-alt+f1 --- then ctrl-alt+f7 Sep 28 15:39:02 and what does that do for a living ? Sep 28 15:39:13 it switches ttys Sep 28 15:39:24 and if i return to tty7 my screen is back Sep 28 15:39:36 humm... Sep 28 15:40:12 never done this before, let me try... Sep 28 15:41:03 ogra: I'm faced with a weird display problem on my panda. Sep 28 15:41:18 the screen goes blank after a while and doesn't come back. Sep 28 15:41:18 how does that manifest ? Sep 28 15:41:26 yeah, thats the one Sep 28 15:41:47 no error on the screen, unblanking won't work, nor the above little trick. Sep 28 15:41:59 serial console is responsive... Sep 28 15:42:16 ouch Sep 28 15:42:24 I've hit something like that before... I think. Sep 28 15:42:29 * ogra hanst seen that Sep 28 15:42:46 I won't do anything about it just now. Sep 28 15:42:53 I think you are referring to bug 644714. Sep 28 15:42:54 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 Sep 28 15:43:24 maybe... Sep 28 15:43:28 just maybe. Sep 28 15:43:38 I think what is happening is the system is querying for edid each time. I hit it the most with my hdmi switch box. Sep 28 15:43:45 Very reproducable. Sep 28 15:43:54 I was looking at that bug too. Sep 28 15:44:25 GrueMaster: I'll get back to you when I start investigating this bug. Sep 28 15:44:41 * GrueMaster isn't going anywhere soon. Sep 28 15:47:37 GrueMaster: I think just reproduced the proble you've described. Sep 28 15:47:52 fixing it will be fun. Sep 28 15:48:23 Well, enjoy yourself. :P Sep 28 15:48:46 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. Sep 28 15:49:05 or maybe it this is how upstream has designed the thing... Sep 28 15:49:19 if no EDID, set to lower possible resolution. Sep 28 15:49:27 That I think is the proper solution. Not sure what other systems do, you might check dove & babbage solutions. Sep 28 15:49:56 I know it goes to 640x480, which I don't think it properly supports. Sep 28 15:50:19 I don't have dove nor babbage so I can't test. Sep 28 15:50:36 You have source trees. Sep 28 15:50:46 And I have hardware. Sep 28 15:50:57 Yes, but trying will be easier and much more reliable. Sep 28 15:51:14 good evening Sep 28 15:51:14 like finding needle in hay stack. Sep 28 15:51:20 good evening. Sep 28 15:51:27 What I am implying is that these platforms have no kernel parameters (unlike beagle), yet they maintain their resolution settings. Sep 28 15:52:07 GrueMaster: have you done the same test on those platform ? Sep 28 15:52:23 They are all on the same switch/monitor. Sep 28 15:52:44 And it is a 19" widescreen 1440x900. Sep 28 15:53:07 and you see the problem on omap4 only ? Sep 28 15:53:14 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. Sep 28 15:53:14 yes Sep 28 15:53:48 Now, babbage is set to 1024x768 it appears. Sep 28 15:53:58 GrueMaster: how about omap3 - what is the behavior ? Sep 28 15:54:18 Omap3 has a kernel parameter at boot for video. Sep 28 15:54:40 omapfb.mode=dvi:1280x720MR-16@60 Sep 28 15:54:53 So it should stay at a fixed resolution. Sep 28 15:55:22 it *should*, but does it stay at a fixed resolution ? Sep 28 15:55:25 babbage may be hardcoded to run at 1024x768. Not sure. Sep 28 15:55:43 Haven't seen an issue with beagle changing resolution. Sep 28 15:56:40 had there been one, would you have hit it ? i.e has a beagle ever been in teh same setup ? Sep 28 15:57:42 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. Sep 28 15:58:15 Beagle, XM, and babbage have shared this configuration all cycle. Sep 28 15:58:15 has beagle ever been connected to the hdmi switch ? Sep 28 15:58:22 ok. Sep 28 15:59:41 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... Sep 28 16:00:34 Well, one way to find out. Give me a few minutes. Sep 28 16:02:35 cool. Sep 28 16:03:42 how do you set the resolution if not in u-boot? Sep 28 16:05:17 as I understand it, fb_ddc is not working on omap yet, so the kernel will fallback to some default Sep 28 16:06:38 ynezz: to the best of my knowledge, in omap3 u-boot is the only place. Sep 28 16:06:59 ynezz: on omap4, the driver parses the EDID and set resolution to highest possible. Sep 28 16:07:09 wow Sep 28 16:07:21 thalass: Do a google search. From what I understand, there is documentation available on how to do that. Sep 28 16:08:03 mpoirier: it's the tree with this EDID parsing for omap4 available somewhere? Sep 28 16:08:19 ours does it. Sep 28 16:08:52 ynezz: sorry, ubuntu doesn it. Sep 28 16:09:07 ynezz: sorry again, ubuntu DOES parse EDID. Sep 28 16:09:16 :) Sep 28 16:09:29 in kernel? Sep 28 16:09:35 yes. Sep 28 16:10:11 gotta find it Sep 28 16:10:24 find what, the ubuntu kernel ? Sep 28 16:11:48 yes, the source for omap4 kernel and look how it's done and possibly backport it to omap3/beagle Sep 28 16:12:30 rsalveti: you on ? Sep 28 16:13:05 ynezz: hold on. Sep 28 16:13:11 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 Sep 28 16:13:36 ynezz: that is the same conclusion ubuntu came with. Sep 28 16:14:14 ogra: my buggy brain remembers rsalveti was doing something with EDID in omap3. Do you recall ? Sep 28 16:14:52 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? Sep 28 16:15:14 ynezz: ok, it's just you and me here. Sep 28 16:15:37 ynezz: I was supposed to backport omap4 for EDID feature to omap3. Sep 28 16:16:04 but, to the *best* of my recollection, rsalveti had started the work. Sep 28 16:16:08 mpoirier, yes, but it didnt make it in Sep 28 16:16:27 ogra: what do you mean ? technical problem or time constraints ? Sep 28 16:16:35 time Sep 28 16:16:41 GrueMaster, https://edge.launchpad.net/ubuntu/+source/linux-fsl-imx51 Sep 28 16:16:41 he took over from dyfet Sep 28 16:17:03 GrueMaster, 2.6.31-608.20 went into proposed 3 hours ago Sep 28 16:17:15 ogra: I'm talking about backporting omap4 EDID functionality to omap3 Sep 28 16:17:21 Yea, well system isn't seeing it yet. Sep 28 16:17:49 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 Sep 28 16:17:58 mpoirier: cool, found that [PATCH 0/2]OMAP:DSS:RFC for HDMI in OMAP4 Sep 28 16:18:05 mpoirier, buit there was time for neither Sep 28 16:18:29 ogra: he should have told me... I can probably do something about it. Sep 28 16:18:34 mpoirier: I'm now Sep 28 16:18:55 rsalveti in the flesh - cool ! Sep 28 16:19:26 rsalveti: what's the status on backporting omap4 EDID thing to omap 3 ? Sep 28 16:20:01 mpoirier: backporting is not actually the right thing right now Sep 28 16:20:12 we should improve it first, try to use the common kernel api for edid Sep 28 16:20:17 bjf: Source is visible at http://ports.ubuntu.com/pool/main/l/linux-fsl-imx51/ but no .deb Sep 28 16:20:17 and then propose a common solution Sep 28 16:20:31 what I got is a patch that parse the edid and try to set up the default resolution for omap 3 Sep 28 16:20:50 the draft works, but will need improvements to send it upstream, and the omap 4 driver needs a lot more love Sep 28 16:20:59 mpoirier: this bug is not related with edid I'd say Sep 28 16:21:12 rsalveti: what bug ? Sep 28 16:21:17 it's probably the bug I'm facing with my monitor, that I was planning to start debugging it today Sep 28 16:21:24 the 640x480 on omap 4 Sep 28 16:21:28 rsalveti: can you pls share your patch? Sep 28 16:21:55 rsalveti: ynezz was asking about the backport of Rob Clark's work on the omap4 EDID. Sep 28 16:22:05 ynezz: sure, will publish it at my tree and send you the link Sep 28 16:22:12 this is my beginning with EDID parsing in u-boot http://github.com/ynezz/u-boot-sakoman/commit/36ab7487e1b55ae54b44b02196c4ebfd8ebe1a58 Sep 28 16:22:19 that's when I told him about your work, hence this discussion. Sep 28 16:22:26 bjf: Nevermind. Looks like it just started building. Sep 28 16:22:27 but I'll rework it to use the EDID parsing code in kernel Sep 28 16:22:29 ynezz: yup, saw that, also did something similar when trying the edid parsing Sep 28 16:22:44 ynezz: cool, nice to see more people interested on that Sep 28 16:22:48 GrueMaster, sorry was a little premature there Sep 28 16:23:35 bjf: Heh. No big deal. I was just making sure it wasn't stuck in post-build limbo which has happened in the past. Sep 28 16:23:36 ynezz: just give me some minutes and I'll publish it, cause I'm waiting a kernel built to finish on the same tree Sep 28 16:24:12 rsalveti: no problem, I don't need it today or tommorow :) Sep 28 16:24:17 ynezz: what's your email? will send you explaning what I did and what is the state of the omap 4 implementation Sep 28 16:24:26 ynezz@true.cz Sep 28 16:24:41 but maybe it would be better to follow up on my email in beagleboard mailing list Sep 28 16:24:56 there are others interested in this Sep 28 16:25:12 thanks Sep 28 16:25:15 sure, np Sep 28 16:28:21 GrueMaster: how's your testing going ? Sep 28 16:29:04 System is in the middle of a package update. Should be able to try testing in 10 minutes or so. Sep 28 16:29:49 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 Sep 28 16:30:12 ynezz: yup, that's why it needs more work on it first Sep 28 16:30:17 it's parsing it by hand Sep 28 16:30:43 I tried to use it on my patch the most I could Sep 28 16:30:53 so we'd avoid having duplicates Sep 28 16:32:25 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. Sep 28 16:33:55 The gdk-pixbuf issue appears to just be a flood of warnings. Sep 28 16:34:39 persia: you on ? Sep 28 16:35:16 It is 1:35am his time. Doubtful. Sep 28 16:35:54 GrueMaster: he told me to poke him at any hours of the day... Sep 28 16:36:20 I'm trying my luck... Sep 28 16:36:30 GrueMaster: you panda, Sep 28 16:36:42 do you boot it with DHCP or static IP ? Sep 28 16:36:45 Hey, lets not get personal. Sep 28 16:36:50 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 Sep 28 16:36:52 Oh. DHCP. Sep 28 16:37:10 ynezz: do you have the link or thread name? Sep 28 16:37:26 ok. does it keep the same mac address after every boot ? Sep 28 16:37:39 rsalveti: http://www.spinics.net/lists/linux-omap/msg35867.html Sep 28 16:37:54 I'm not sure. Have to check the logs. Sep 28 16:38:25 ynezz: oh, about the hdmi, thanks Sep 28 16:38:29 doing ifconfig -a will tell you. Sep 28 16:38:50 ynezz: you can ask mythripk directly :-) Sep 28 16:39:00 Not very well. I do image testing. Meaning I have a new image almost daily. Sep 28 16:39:02 also, if the mac changes, you *should* get a different ip address. Sep 28 16:39:17 I can more easily check my dhcp logs. Sep 28 16:39:30 one sec (requires monitor switch). Sep 28 16:39:39 as you please. Sep 28 16:41:10 ynezz: but I believe one thing is the hdmi driver, another is the edid parsing Sep 28 16:41:28 for the only the edid parsing part could be common for both omap 3 and omap 4 Sep 28 16:42:08 brb Sep 28 16:42:27 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) Sep 28 16:43:08 GrueMaster: are you doing anythign special with your panda8 right now ? Sep 28 16:43:27 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! Sep 28 16:44:35 mpoirier: Not really. I was mainly focusing on dove audio today while I await RC images. Sep 28 16:44:53 is your panda8 up ? Sep 28 16:45:49 Not at the moment. Ran out of spare power supplies (have to timeshare with my XM at the moment). Sep 28 16:46:01 I plan on getting another one today. Sep 28 16:46:49 GrueMaster: ok, when you do bring it up, please do an ifconfig from the console and note the mac address. Sep 28 16:47:07 from there reboot, and check the mac again. Sep 28 16:47:34 mine changes from boot to boot. Sep 28 16:47:49 rsalveti: I don't know much about omap4 and its differences between omap3 Sep 28 16:48:20 GrueMaster: either driver issue or not MAC has been programmed in eeprom. Sep 28 16:48:36 rsalveti: as I understand it, on omap3 you can read edid using i2c3 and on omap4 using hdmi, right? Sep 28 16:48:41 ynezz: http://focus.ti.com/pdfs/wtbu/OMAP4430_ES2.0_Public_TRM_vJ.pdf in case you want to know more about it Sep 28 16:48:47 ynezz: right Sep 28 16:54:44 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 Sep 28 16:55:13 code for just reading edid and leave the rest on fb_ddc Sep 28 16:55:17 ynezz: yeah, that's what I think Sep 28 16:55:52 give me just a min and I'll show you what I did Sep 28 16:55:52 cool Sep 28 16:58:12 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. Sep 28 16:59:00 GrueMaster: thanks - it confirms my suspicion. Sep 28 16:59:29 I'll check with TI before opening a bug... Sep 28 17:01:46 You may not get very far. Dove has the same issue and there has been a bug on that for two cycles. Sep 28 17:02:19 Their answer was that they didn't want to cause conflict between two systems with the same mac. Sep 28 17:08:58 ynezz: please check http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/omap3-edid-parsing Sep 28 17:09:25 ynezz: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=commitdiff;h=a0ea712b64988ccd7984069b99864a1b4ac43881;hp=99372b26f533da4d9f6e59a744c67170a7d990d3 Sep 28 17:09:34 here you can find how I'm probing and parsing it Sep 28 17:09:43 ok, thanks! Sep 28 17:09:56 I decided to first generate the modedb, like any other video driver we have, and then try to get the best one Sep 28 17:10:16 it's dvi, but I'm only using CVT with reduced blanking Sep 28 17:10:21 to get better timings Sep 28 17:10:52 ynezz: and then the dpi_check_timings will try to adjust the timings to be ok with the pck Sep 28 17:11:49 so if you have an example that has a higher pck (limit 86500), it'll try to adjust the vsync and hsync Sep 28 17:12:00 so it can work at least from the omap perspective Sep 28 17:12:22 but then you need to check if this is actually supported by the monitor, otherwise you'll easily get out of sync Sep 28 17:13:35 ynezz: if you activate debug at drivers/video/fbmon.c you'll see all the modes and everything, quite cool Sep 28 17:14:04 ynezz: I know the panel-generic is not the right place, was using it just to get a working model Sep 28 17:14:12 and another one from tomba http://groups.google.com/group/beagleboard/msg/bd988bdaa65b7d58 Sep 28 17:14:15 :) Sep 28 17:17:53 yup, a little bit similar, but he register an i2c device Sep 28 17:18:52 with my patch I get Best Mode: 1280x1024@56 from my monitor Sep 28 17:19:32 it's the same one you'll get when using 1280x1024MR@60 Sep 28 17:20:14 cool, will try it on my TV :) Sep 28 17:20:46 ynezz: but I also want to improve it to get the best one respecting the aspect ratio Sep 28 17:21:22 1280x720 looks better at my monitor Sep 28 17:26:23 hi i all i am not able to get uboot prompt over minicom Sep 28 17:28:45 rsalveti: I've stolen a few EDID dumps somewhere http://github.com/ynezz/u-boot-edid/tree/master/test/ Sep 28 17:29:12 rsalveti: parsing them and looking into the output seems quite interesting Sep 28 17:29:22 ynezz: hm, lots of interesting ones, cool :-) Sep 28 17:29:34 ynezz: do you have all these monitors to test? would be awesome Sep 28 17:29:45 nope :) Sep 28 17:29:56 jsut this one http://github.com/ynezz/u-boot-edid/blob/master/test/edid.lcd.tv.samsung32inch Sep 28 17:30:25 got it :-) Sep 28 17:30:59 that's the main reason I postponed this feature for maverick, lack of monitors to test at the moment Sep 28 17:31:20 wanted first to be sure that we're not getting a bizarre result with some monitors Sep 28 17:31:41 ajay: What system are you using? Do you have your serial port set to 115200? Null Modem Cable? Sep 28 17:32:11 rsalveti: we've quite a few different 14-27", different vendors in the company, so I can test it, no problem Sep 28 17:32:54 cool, good to know Sep 28 17:46:24 GrueMaster: did you have time to dig up the few options needed to get beagle sound going ? No big deal if you haven't... Sep 28 17:46:52 No, but I can in a second. System is available & idle. Sep 28 17:46:59 cool Sep 28 18:01:45 sorry, network is running a bit slow. Mirror must be updating. Sep 28 18:08:23 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. Sep 28 18:09:26 GrueMaster: before and after what ? Sep 28 18:09:34 what's happening in between ? Sep 28 18:10:17 I ran "amixer>amixer-before.txt" to dump default settings, then made changes in alsamixer, and redumped. Sep 28 18:10:51 File is at http://members.dsl-only.net/~tdavis/beagle-audio.tgz Sep 28 18:11:42 running amixer by itself will dump the current mixer settings/levels. Then alsamixer can be used to visually change them. Sep 28 18:13:09 GrueMaster: you just typed "amixer" on the cmd line ? Sep 28 18:13:27 yes Sep 28 18:13:42 You do know how to use alsa utils, right? Sep 28 18:14:09 I do but I need to undertand exactly what you did to reproduce properly. Sep 28 18:15:28 The "alsamixer used to visually change them" part, is that through graphic interface ? Sep 28 18:15:43 It is a console tool. Sep 28 18:16:14 Open a terminal and try it. It gives you direct control over the exposed audio controls through the driver. Sep 28 18:16:39 yes, just wanted to make sure we're on the same page. Sep 28 19:45:01 GrueMaster: I've been playing with sound for a while now thanks. Sep 28 19:45:21 ok Sep 28 19:45:35 GrueMaster: how did you know it was "HeadsetL Mixer AudioL2" you had to un-mute ? Sep 28 19:45:40 is there a trick ? Sep 28 19:46:30 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. Sep 28 19:46:50 AH ! Sep 28 19:47:06 Speaker-test will run untill -c. Sep 28 19:47:38 I love brute force solutions - thanks. Sep 28 19:48:24 Well, I am a brute, so it's what I do. Sep 28 19:48:29 :P Sep 28 20:10:45 Hi, can anyone help enable svideo in Maverick Meerkat beta, on Beagle XM, over minicom Sep 28 20:15:10 Heff01: I don't know if that has been tested or even enabled. Not something that is easy to test here. Sep 28 20:15:49 Stuck until I get hdmi to dvi d cable then Sep 28 20:16:16 I left one in my cube when I left TI Sep 28 20:16:30 doh Sep 28 20:16:45 :-) Sep 28 20:16:56 Only got board yesterday, just eager to get going Sep 28 20:17:04 Micro Center carries them for $10US Sep 28 20:17:29 I know, on GMT everythings shut Sep 28 20:17:40 had svideo lying around Sep 28 20:18:35 I guess it could be enabled thru xorg when booted Sep 28 20:21:07 #android-arm Sep 29 01:33:09 cooloney: hey! Sep 29 01:33:20 cooloney: any news about the mem issue bug? Sep 29 01:45:03 robclark: do you know if we're going to get the fb resize feature from the omap 4 x11 video driver? Sep 29 01:46:52 rsalveti: I guess the new pvr driver eventually.. although it would help to get DRM support into the kernel in a sane way for non PCI systems.. Sep 29 01:49:26 rsalveti: nothing new here. Sep 29 01:49:33 rsalveti: i got the same result like you Sep 29 01:49:44 2G:2G split to disable highmem Sep 29 01:49:45 robclark: that's for sure.. Sep 29 01:50:13 robclark: was thinking for maverick, how we're going to deal with people changing monitors, and even when we can't probe the correct edid when booting Sep 29 01:50:17 the case of my monitor Sep 29 01:50:48 cooloney: for me it's quite stable with 2G:2G, no highmem and using just one cpu, or no L2 Sep 29 01:50:56 yeah, that's ture Sep 29 01:50:58 Need at least a sane default. Sep 29 01:51:09 for monitor resolutions. Sep 29 01:51:14 rsalveti: but one cpu might not be acceptable, i think Sep 29 01:51:33 GrueMaster: for default there's a bug currently for monitors that turns off and on during probe (my case) Sep 29 01:51:50 I hit the same thing with my HDMI switchbox. Sep 29 01:51:51 that the screens turns 640x480 initially and then it changes to the correct one Sep 29 01:51:56 probably the same bug Sep 29 01:52:01 I'm looking at it now.. Sep 29 01:52:06 Except mine stays at 640x480. Sep 29 01:52:12 yeah, probably same bug Sep 29 01:52:12 cooloney: probably not, even without L2 Sep 29 01:52:35 GrueMaster: pls send your edid.. /sys/devices/omapdss/display0/edid Sep 29 01:52:37 L2 will have some impact to the performance Sep 29 01:52:45 that's the problem ... Sep 29 01:53:02 rsalveti: so there is not good solution now, Sep 29 01:53:15 yeah, disabling L2$ or 1 cpu is not ideal.. but 768m has been relatively stable for me so far.. Sep 29 01:53:28 GrueMaster: yeah, can you paste your edid when using the switchbox? Sep 29 01:53:32 rsalveti: i also applied the patches in 2.6.35.4, 2.6.35.5 and 2.6.35.6 Sep 29 01:53:37 from stable tree Sep 29 01:53:44 got the same result Sep 29 01:53:46 if we get a correct edid then it's just timing issues when probing the edid Sep 29 01:53:48 hey all... is current build having any issues? Sep 29 01:54:02 just if you're using omap 4 Sep 29 01:54:04 Erm, is there a tool for reading this? It looks like garbage. Sep 29 01:54:16 * III is using omap4 Sep 29 01:54:19 GrueMaster: yep, binary Sep 29 01:54:21 parse-edid Sep 29 01:54:41 III: currently when using 1GB we get build issues when building the kernel Sep 29 01:54:53 with highmem you can easily get it, without highmem you get it some times Sep 29 01:55:09 if we disable L2 or use just one cpu, everything works fine Sep 29 01:55:33 another workaround is to use 768MB (the one we're using now) Sep 29 01:55:44 * III moves to older build :D Sep 29 01:55:54 and if we don't fix it for the release, this will probably be the way to go Sep 29 01:56:38 cooloney: the problem is that it's quite hard to trace it, I'm out of ideas Sep 29 01:57:31 rsalveti: me either, i tried to enable ftrace with dynamic tracing Sep 29 01:57:46 but it took me lots of time to get some useless information Sep 29 01:57:58