=== amitk is now known as amitk-afk === XorA|gone is now known as XorA === amitk-afk is now known as amitk [11:51] ogra: where is the system-wide fstab that mounts the initial filesystems? [11:51] you mean /etc/fstab ? [11:52] ogra: no, the other one that upstart uses [11:52] upstart ? [11:52] where things like /var/run are mounted as tmpfs [11:52] oh you mean mountall [11:52] aah, right [11:52] thats /lib/init/fstab [11:52] perfect, thanks ogra === zul_ is now known as zul [13:53] rsalveti, robclark : hi! At last, here's the result of the parse-edid command: [13:53] http://pastebin.com/9QwDri4a [13:54] Produced on Panda ES1.0, 2.6.34-903-omap4 #7resalveti2 kernel [13:54] k.. will look at that in a few min.. in a call atm.. [13:55] Thanks! Here's my kernel log too: http://pastebin.com/MT3QJCDR [13:56] Still observing the interlaced screen effet. [14:00] mopdenacker: btw, can you point me at a git tree and commit-id for the kernel you are using.. just so I know which patches you do and don't have? [14:11] robclark: unfortunately, this info is not available. I just used rsalveti's pre-built kernel. [14:12] rsalveti: do you have a git tree and commit id for your 2.6.34-903-omap4 #7rsalveti2 kernel, please? [14:12] ahh, ok.. so I'm guessing you do not have this patch http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commit/6b36538ae4495bc4e6c44b01192814b4d702882f [14:12] since it was causing rsalveti some issues.. [14:13] but it is required for monitors that can't do 1920x1080.. otherwise, what happens is fb configures itself for 1920x1080 (which is the default at boot-up before hdmi driver has a chance to read the EDID), and doesn't realize when the resolution changes to 1280x1024 [14:14] which causes the weird repeating pattern.. because at start of row 2, the display is reading what the fb client thinks is 2/3rds of the way thru row 1.. [14:14] (hopefully that made sense) [14:15] rsalveti: do you have time for an experiment, to see if adding that console lock stuff around the fb_set_var() calls helps w/ your monitor? [14:15] I can make an updated patch quickly.. but at moment don't have any good way to test it [14:16] * robclark is pandaless at the moment :-( [14:50] mopdenacker: Btw can you try sysfs? ie do a echo 350 > custom_edid_timing ? [14:50] mythripk: I think his problem is the framebuffer resizing.. fwiw [14:50] hdmi driver itself is ok.. it is finding and using a supported resolution correctly [14:51] but unfortunately fb still thinks resolution is 1920x1080 [14:56] yes :) i saw that , it is picking 1280 * 1024 [14:57] but i guess the sysfs trial might trigger FB , so wanted to confirm that. [14:57] I guess I need to figure out a good solution for making the omapfb size-change callback work in all cases.. [14:57] no, don't think it would trigger fb if he doesn't have the patch to add callback.. [14:57] not if resolution changes, at least.. [14:58] i will be adding uevent for all the hot plug trigger in timing change , would that help fb to listen? [14:58] can fb listen to the uevent ? [14:58] not really sure.. that might help userspace.. but I think normally that sort of notifcation would come thru DRM driver somehow.. [14:59] oops sorry my last bus time [14:59] k, don't miss the bus ;-) [14:59] c-ya [14:59] :) good day === bjf[afk] is now known as bjf [15:06] mythripk: thanks for the tip. Writing to custom_edid_timing didn't help [15:37] mopdenacker: robclark: hi [15:38] ahh, hi rsalveti [15:38] http://gitorious.org/ubuntu-experimental/kernel-maverick/commits/rsalveti-ti-omap4 [15:38] my tree [15:38] morning :-) [15:38] rsalveti: morning! Where are you? [15:39] fine thanks :-) [15:39] let me read the backlog [15:39] rsalveti, do you have some time to try an experiment? I can make a patch for the omapfb size-change callback with added acquire/release console lock, to see if that works on your monitor.. but no way to test it at the moment.. [15:39] rsalveti: like your answer ;-) [15:40] robclark: sure [15:40] ok.. I'll send you a patch in 10 or 15 [15:41] nice [15:48] prpplague: Good morning :) [15:48] lag: greetings [15:50] prpplague: Looks like we missed one another yesterday [15:52] yea [15:52] lag: rough day [15:52] lag: L24.9 release yesterday fully supports panda audio [15:54] prpplague: Very nice [15:54] lag: you'll need an update pulse config and alsa.state file, but other than that it works fine [15:54] prpplague: Has L24.9 been released to us yet? [15:54] lag: yesterday [15:55] http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=commit;h=4a49ddc5fdf3e4acf90ea4c219f9742b3be48ab8 [15:55] prpplague: Why doesn't anyone tell me these things - I'm meant to be reviewing it! [15:56] Are ndec and sebjan away? [15:56] lag: i know ndec is [15:57] lag: iirc ndec will back on the 23rd [15:57] prpplague: I think he may be on holiday [15:57] And sebjan has only just came back [15:58] lag, prpplague: hi, I just came back today :) [15:58] Hi sebjan [15:58] I aligned with cooloney earlier today [15:58] Have you spoken to Bryan today? [15:59] Then the fault lies with him :) [15:59] I'll do some cleaning on the L24.9 patch-set (checkpatch is shouting a lot) [15:59] sebjan: On here? [15:59] robclark: I tried to clone your tree, and compile the kernel with your commit: [15:59] git clone git://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4.git [15:59] However, it fails with [15:59] sebjan: Yeah, I know [15:59] Resolving deltas: 100% (1301615/1301615), done. [15:59] warning: remote HEAD refers to nonexistent ref, unable to checkout. [15:59] sebjan: I ran it through last week [15:59] and hand-off a branch to him to add the ubuntu patch set [15:59] sebjan: Are you going to try and fix the errors? [16:00] That's just a warning, but I don't see the master branch [16:00] thats odd [16:00] lag: yes as far as I can in few days [16:00] sebjan: When do you think it will be ready for us? [16:00] mopdenacker: hmm, possibly there is no master branch.. I do that sometimes to confuse people ;-) [16:00] sebjan: If you can send me an email when it's ready, I can cast my eye over it [16:01] you'll anyways want to checkout L24.8_panda-hdmi-patches branch [16:01] lag: I think sometimes next week [16:01] lag: usre, I'll keep you posted as well as bryan [16:01] sebjan: Okay, it will be worth us waiting until then [16:01] robclark: successful attempt. ;-) Thanks [16:01] sebjan: No problem [16:01] heheh, no prob [16:03] robclark: Oops, I don't get *any* branch: [16:03] git branch [16:03] $ [16:03] git branch -r [16:04] git checkout --track -b L24.8_panda-hdmi-patches origin/L24.8_panda-hdmi-patches [16:04] (or something roughly like that) [16:04] Thanks, sorry for my lack of practise with git... [16:04] heheh, I'm same way w/ bzr ;-) [16:05] rsalveti: I'm thinking the following patch on top of the "OMAP4:OMAPFB: register callback to get notified of resolution change" patch: http://www.pastie.org/1102224 [16:06] robclark: sure, will build and test it here [16:06] just a min [16:06] if it isn't working, don't spend time on it.. I'll just see if I can find a panda to borrow from prpplague for the afternoon, or maybe over the weekend [16:07] there are a couple other display issues I want to look into anyways [16:07] me too [16:07] mopdenacker: I can build the uImage with the patch for you, if needed [16:07] cause I'm going to test another patch on top of the patch you need [16:08] rsalveti: perfect, thanks! [16:09] Is there a place where I can get Lucid packages for CodeSourcery cross toolchains? Or shall I install these toolchains manually (errk)? [16:09] For armel of course... [16:16] hm, cs packages I don't know [16:17] currently I'm using maverick with linaro's cross compiler [16:27] mopdenacker: http://people.canonical.com/~rsalveti/kernel/uImage-mopdenacker [16:27] with the patch from robclark [16:27] now I'm going to build mine to test [16:27] with latest changes [16:28] rsalveti: hope I can find a package for lucid. We have a fast buildserver, which should run something stable... [16:28] rsalveti: thanks! Do you have a deb package with the modules, or is it enough to test without the modules? [16:29] mopdenacker: it's enough to test without modules [16:29] I can generate a full deb file if it works [16:30] rsalveti: all right, more soon. [16:40] rsalveti: Ouch, my uInitrd got corrupted (bad luck). I have to restore it first from the image. [16:41] mopdenacker: you have to recreate your fat partition :-) [16:41] copy the files, run mkfs.vfat -F 32 and then copy the new files again [16:41] mopdenacker: a bug in u-boot [16:43] robclark: nops, same odd behavior [16:43] screens turn on, but nothing goes on it [16:43] so it's not a lock issue [16:43] hmm.. ok [16:44] is ubuntu kernel already based on 2.6.35? [16:44] but then you just set the overlay_info [16:44] robclark: nops [16:44] hmm.. I wonder what is the difference.. [16:44] lag is still waiting the final tree from sebjan [16:45] robclark: what change in both cases is that in one the resolution is wrong, than it get fixed [16:45] at my case I believe the resolution is right already [16:45] rsalveti: thanks for the tip. That's easier than I thought :-) [16:45] I mean, I wonder why I wasn't seeing that issue when I was testing on smaller monitors.. [16:46] and in fact, why there is any change on a monitor that can already support 1920x1080 natively.. [16:47] rsalveti: I'm not sure it's a U-boot bug: [16:47] mkimage -l uInitrd [16:47] mkimage: ERROR: "uInitrd" has corrupted data! [16:47] mopdenacker: at least this corrupt issue should be [16:47] The image really looks corrupted. [16:47] but why are you running mkimage on uInitrd? [16:48] you can just grab it from my deb package [16:48] Just to check whether the image is corrupted or not. [16:48] get the new uImage, write it again at the sd card and test [16:48] rsalveti, -l just lists the setup [16:48] It was "mkimage -l" [16:49] yep, sorry, was thinking you were trying this before -l [16:49] but you were just checking it :-) [16:50] mopdenacker: in my case if I get the sd card and write a new uInitrd or uImage, u-boot says it's corrupted during the boot [16:50] and recreating vfat fixes it [16:56] robclark: I'm getting a size_notify for 640x480 first and then to 1920x1080 [16:56] rsalveti: obrigado, I could recover just by replacing the corrupt uInitrd file (didn't have to format the partition again). [16:56] rsalveti: oh.. ok, that is odd.. [16:56] it is like at first it can't read EDID.. [16:57] mopdenacker: np :-) [16:57] robclark: yep, weird [16:57] rsalveti: now I think I need your .deb file for the modules. The screen is just black (but the good news is the monitor doesn't complain... it's actually getting a correct signal). [16:58] mopdenacker: hm, just blank or are you able to at least see some messages on it? [16:58] so an interesting question might be why we can't go from 640x480 -> 1920x1080.. but I have a small monitor here so maybe I can recreate the situation.. [16:58] my current problem with this patch is that my screen stays blank :-) [16:59] yeah.. question is just *why* it stays blank.. [16:59] rsalveti: just blank, but I haven't enabled the console on it. Will it go to tty0 if I remove "console=ttyO2,115200n8", or shall I explicit this? [16:59] maybe that intermediate step of 640x480 triggers some problem.. [17:00] mopdenacker: you should at least see some penguins [17:00] mopdenacker: you can set another console argument at the same line [17:00] btw rsalveti / mopdenacker .. are you using just console-only filesystems.. or one w/ x11? [17:01] remove quite and splash, if you have it [17:01] robclark: currently I'm using a console-only fs [17:02] I'm using with x11 [17:02] ok.. I've done mainly full X11 fs.. sometimes I don't see the console, but I think (or thought) that was just because the monitor didn't come on fast enough before xserver starts. [17:02] rsalveti: good idea to enable both consoles. [17:06] robclark: I added "console=tty0" and removed "splash", but I didn't see any penguin. The fb console stays blank after getting initialized. [17:07] hmm, ok.. sounds like same issue rsalveti sees.. [17:07] robclark: omapdss HDMI: fallback to VGA [17:07] should it fallback? [17:07] it got the right resolution before this message [17:08] well.. possibly if the monitor doesn't support anything else [17:08] but not in your case [17:08] could you paste your bootlog again? [17:09] sure, 1 sec [17:10] is this for L24.9? [17:10] hmm, if you haven't already, please enable dss traces too [17:10] omapdss.debug=1 bootarg [17:11] robclark: http://paste.ubuntu.com/480499/ [17:12] robclark: thats the similar issue that i have with the L24.9 [17:12] monitor cycling through modes? [17:12] robclark: basically it thinks there was a physical disconnect when there was just a soft disconnect [17:13] robclark: see line 444 [17:13] rsalveti: do you have any way to set your monitor to only HDMI input, so it doesn't cycle between VGA/DVI/HDMI ports when it doesn't find a signal? [17:13] prpplague: hmm, yeah [17:14] rsalveti: i'm trying to collect a list of monitors that show these symptoms, can you give me your make and model? [17:14] robclark: nop, my monitor tries to be smarter than me [17:14] prpplague: LG W2253V [17:15] hmm.. damn [17:15] mopdenacker: what monitor are you using? [17:15] prpplague: maybe you could paste the patch for the change you made so rsalveti could try it [17:15] prpplague: hm, you fixed that already? [17:16] oh, #pandaboard talk [17:16] robclark: the one i have is against L24.9 [17:16] rsalveti: does parse-edid answer your question? http://pastebin.com/9QwDri4a [17:16] It's a Dell Monitor [17:16] prpplague: DELL 1707FP ^ [17:16] yeah.. so might need some manual massaging to apply.. but it is a small change so I guess rsalveti can do it [17:16] robclark: i can have a quick look at the L24.8 [17:16] prpplague: paste me the patch [17:16] prpplague: rsalveti is using this tree: http://gitorious.org/ubuntu-experimental/kernel-maverick/commits/rsalveti-ti-omap4 [17:17] one sec, let me get it for you [17:19] http://paste.ubuntu.com/480502/ [17:20] one line :-) [17:20] rsalveti: please note that this is very hackish and i am researching a proper fix [17:20] prpplague: sure, np, we just want to know if it works first :-) === zyga is now known as zyga-lunch [17:23] prpplague: shit, did work :-) [17:23] robclark: ^ [17:23] ah-ha! prpplague you are the man! [17:24] robclark: now it doesn't call size_notify [17:24] Thanks Dave! [17:24] mopdenacker: let me post you the kernel [17:25] rsalveti: sure! With great pleasure! [17:25] rsalveti: good.. in your case, it should not.. since the resolution should stay at 1920x1080 and fb doesn't need to be notified.. [17:25] robclark: yep :-) [17:25] so now I think with the combo of my patch and prpplague's patch, it should work for mopdenacker [17:25] probably, let's see [17:26] dandy [17:27] mopdenacker: http://people.canonical.com/~rsalveti/kernel/uImage-mopdenacker-2 === zyga-lunch is now known as zyga [17:30] rsalveti: ouch, still blank! [17:30] hm [17:30] mopdenacker: please boot with omapdss.debug=1 at your cmdline and show us the dmesg output [17:33] rsalveti: http://pastebin.com/L7c9NE3e [17:34] mopdenacker: please run dmesg at your console, then you'll get more messages [17:34] like the dbg ones [17:34] if you're able to login [17:35] rsalveti: no, I can't login, but I can put loglevel=8 in my bootargs [17:35] mopdenacker: could be, but you can grab the console by creating the following file: http://paste.ubuntu.com/480507/ [17:36] then you'll get a tty at ttyO2 [17:36] robclark: he's getting just one size_notify: size_notify: 1280x1024 [17:37] hmm, ok... I'm back to thinking there is a prob w/ the size_notify.. [17:38] I think I will need to get a panda and spend some time on that.. but I have the link to your kernel, so I should be able to build with that kernel and hopefully reproduce it [17:39] robclark: you have the sources and the binary, if needed [17:39] rsalveti: good idea. I should have thought about it before. [17:39] ok.. now I just need a panda.. but ok, need to finish looking into something else first [17:43] rsalveti: http://paste.ubuntu.com/480512/ [17:43] rsalveti, robclark : sorry, I really gotta go. Mustn't miss my bike ;-) [17:44] np, see you tomorrow! [17:44] np mopdenacker :-) [17:44] c-ya [17:44] c-ya, hope the dump will help! [17:46] robclark: weird, what mopdenacker got is basically your main base case when you tested your patch [17:46] tried 1920x1080, set 1280x1024 and calls size_notify [17:47] yeah.. it does the same thing that your's was doing before prpplague ... hdmi_display_suspend() and then starting over.. [17:48] * prpplague looks [17:50] hmm, looks like it is grabbing an odd config [17:50] * prpplague looks some more [17:51] are we sure that this is an HDMI display and not a DVI-D display? [17:52] DVI-D should be supported too [17:53] robclark: yea DVI-D should be supported, but it does look as though it is going into vesa mode for 1280x1024 [17:53] robclark: which would indicate that it is a DVI-D display [17:55] prpplague: I think he's testing on a dvi monitor [17:57] yep, this monitor is only DVI-D and VGA [18:00] robclark: prpplague: why do we suspend and then resume the hdmi again during the boot? [18:01] rsalveti: that is a good question ;-) [18:01] yea very good question [18:01] i was just looking at that [18:03] that is very odd [18:03] guess i need to do some testing with some DVI-D displays [18:08] hm, 2pm already, need to grab something to eat [18:08] brb [18:09] * prpplague hands rsalveti some coffee and says "get back to work!" [18:09] robclark: setting up to test with my samsung dvi-d display [18:10] :-) [19:43] prpplague: were you able to test with your dvi-d monitor? [19:44] rsalveti: yes and no [19:44] rsalveti: looks there is a problem with calculating the 1280x1024 PLL values [19:44] rsalveti: looking into it now [19:47] hm, ok [19:48] GrueMaster: were you able to test the es2 kernel? [19:49] rsalveti: 1280x1024 doesn't appear to be calculating properly [19:49] rsalveti: the other freqs seem to be ok [19:49] interesting [19:49] that could be the reason why it worked for robclark [20:19] rsalveti: yea it seems to be only an issue with 1280x1024 === scottb_ is now known as scottb === gcl_ is now known as gcl [21:59] rsalveti: found the problem with the dvi [21:59] rsalveti: i'll have to get a fix tomorrow [21:59] prpplague: cool, what is it? [21:59] ops :-) [21:59] robclark: ^ [21:59] mopdenacker will be happy about it [22:00] oh cool [22:13] rsalveti: Unfortunately no, not yet. Will try tomorrow. Do I need a new xloader & uboot? [22:14] GrueMaster: yep, do you want me to cook them for you? [22:14] easy task [22:17] Yes, please. (and don't say cook - I've had English meat pies for dinner every night). [22:17] (burp) [22:17] lol [22:19] GrueMaster, did you find any reasons for the broken oem-config yet ? [22:20] no, not yet. [22:21] Very slow process. [22:21] yeah, i know [22:21] All of my systems are going through a switch connected through my laptop, and my lt is thethering wifi. [22:21] tethering [22:22] you should run an approx instance on your lappie then :) [22:22] ? [22:22] Yopu mean apt-proxy? [22:25] The problem with packages is that there are so many that it's hard to tell typos from real names :) [22:27] Also, I only have a 16G ssd. [22:27] i mean approx [22:27] ogra@osiris:/var/build/images$ du -hcs /var/cache/approx/ [22:27] 2,1G /var/cache/approx/ [22:28] thats for all releases since jaunty (main only for i386 and armel) [22:29] Sure, Now you tell me. On the last day of the sprint. [22:30] i tell everyone since years :P