[00:04] robclark: now my monitor is on but I get nothing at the screen [00:04] will try to get a console at the image, oem-config is turned on by default [00:04] hmm.. can you add omapdss.debug=1 to bootargs.. and send me bootlog and /sys/devices/omapdss/display0/edid? [00:04] omapdss DISPC error: SYNC_LOST_DIGIT [00:05] this is the only error message I'm getting [00:05] sure, 1 min [00:05] hmm.. [00:05] this is with L24.7_panda-hdmi-patches branch? [00:06] L24.7_panda-hdmi-patches yep [00:06] hmm [00:06] tested with ubuntu's config file [00:06] just removed the commit 109fd14008275c9be56562612e3f8d8628e444b0 as it didn't compile with it [00:07] "add support for external tracing" [00:07] ok, that won't matter.. [00:07] yep [00:07] (I need to update that one.. but I guess ubuntu config enables trace..) [00:07] probably [00:07] let me get the kenel log with debug [00:08] k, thx [00:08] GrueMaster: do you know from top of your head how to disable oem-config? [00:08] not off hand. Never really tried before. [00:09] I'm sure there is a way to get it to run oem-config instead of oem-config-gtk. [00:09] * rsalveti will just remove it to see if works === fta_ is now known as fta [00:29] My brain is fried. bugging out for the evening. Ping me if you need me. === fta_ is now known as fta [00:41] robclark: I'm now finally able to get a console! will send you the logs in a minute [00:47] robclark: sent [00:47] ok, got it.. lets see now [00:48] rsalveti: does it seem reasonable for it to be trying to pick 1680x1050? [00:49] hm, it's a full hd monitor [00:49] but it should work, I guess [00:49] it sees a couple 1920x1080 resolutions.. but doesn't like them for some reason.. [00:50] maybe pixel clock isn't matching.. I have to compare to the all_timings table.. [00:51] hm [00:52] ok.. mythripk had one more patch.. that disregards exact timing (backporch/frontporch/syncwidth).. as long as the sum of them still matched.. with that patch, your monitor would pick 1920x1080.. [00:52] I'm not sure if that would help with the sync lost.. but let me see if I can find the patch.. [00:53] robclark: ok, I can test it here [00:54] rsalveti: do you mind doing a bit of surgery to apply patch, or do you want me to quickly rebase it first? [00:54] robclark: just send me the patch, I can try change it here [00:54] it looks like it won't directly apply, but mostly of a result of nearby changes in debug printouts.. [00:54] ok [00:55] ok, sent.. if you have any trouble with making it apply, let me know.. it's not a problem to rebase it on latest branch [00:56] robclark: ok, thanks [00:56] basically instead of doing a straight memcmp() of the contents of the timing struct, it is checking if the sums of the h or v fields matches [00:57] (I'm not entirely sure if that is a valid thing to do or not.. so it would be interesting to know if it works) [00:58] ok, give me a minute [00:59] ok, no prob [01:04] building [01:16] robclark: Timing Info pixel_clk = 148500 [01:16] Xresolution =1920 [01:16] yresolution =1080 [01:16] ok.. is that working any better? [01:16] or same behavior, different resolution? [01:18] it seems to be better, let me just try with the full X11 image [01:19] ok.. I think then it should work w/ x11 as long as the monitor is detected before x11 opens the framebuffer and reads the resolution.. === fta_ is now known as fta === fta_ is now known as fta [01:50] robclark: hi [01:50] hi rsalveti [01:50] robclark: X11 is able to find the correct resolution but I get nothing on the screen [01:50] just a black screen [01:50] hmm.. console is ok, but X11 is not? [01:50] that is a strange one.. [01:50] robclark: nops, console seems not to work fine either [01:51] hmm.. what changed between now and the one that was working? [01:51] do you still have omapdss.debug=1 in your bootargs? [01:52] if so you should be able to unplug and replug the monitor, and it will re-detect and print out all the same info about what resolution it picks and so on.. [01:52] the other one is not working, I thought it worked because my monitor turned on and so on [01:53] but when I changed to get the console messages I got nothing :-( [01:53] oh, but you never actually saw anything on screen with will X11 fs or with console only fs? [01:54] robclark: nops, my monitor shows the resolution and etc and tuns on, that's why I thought it would work better [01:54] oh.. darn.. [01:54] but while testing it better I found that I can't see anything in the screen [01:55] do you have parse-edid? If so you can check whether your monitor is requiring negative hsync or vsync pulse.. (which isn't implemented yet) [01:55] if you don't, I will check in a couple minutes [01:55] robclark: nops [01:56] where can I find it? [01:56] sudo apt-get read-edid :-) [01:56] easy :-) [01:56] yup [01:57] 1 sec, let me install this package [02:04] installed on the target, easier, let me just boot it again [02:05] rsalveti: don't need to reboot [02:05] just run: [02:05] I removed the card to install the package, that's why [02:05] parse-edid /sys/devices/omapdss/display0/edid [02:05] oh, ok [02:06] brb [02:06] robclark: http://paste.ubuntu.com/472889/ [02:07] robclark: nops, it seems fine [02:07] weird [02:09] rsalveti: hmm, weird.. [02:10] well, let me fwd your boot log and edid to mythripk and see if she has any suggestions when she wakes up [02:11] robclark: ok, thanks [02:11] hang on.. I'll drop off momentarily when I login to vpn [02:11] ok [02:14] rsalveti: ok, well I think if you revert mythripk's patch that I fwd'd, and my "better support for DVI monitors" patch, that you should at least get a good picture at 640x480... [02:15] one other thing to try first, if your monitor has both HDMI and DVI ports, you and you have an HDMI->DVI adapter, you could try the DVI port.. [02:15] robclark: I'm trying it now [02:15] sometimes you will get a different EDID on DVI vs HDMI port.. [02:16] (and might be worth to forward to mythripk and myself the edid file and bootlog on DVI port too, just for good measure) [02:16] robclark: do I need to use omapdss.hdmimode=0 omapdss.hdmicode=35? [02:16] no.. those will be ignored now with mythripk's patches to configure the resolution based on EDID.. [02:17] although you could still try to echo different values to the custom_edid_timings file under sysfs.. and see if there are some other working resolutions.. [02:17] oh, true [02:17] see http://omapedia.org/wiki/Bootargs_for_enabling_display [02:17] yep, my monitor doesn't even turns on [02:18] with dvi port -> hdmi->dvi adapter [02:18] for ex, echo 350 > custom_edid_timings... will be equiv to hdmimode=0, hdmicode=35 [02:18] nice [02:18] hmm, ok.. [02:19] well, I guess since you had a scrambled picture when it was falling back to 640x480, at least that resolution should work.. it is just a matter of figuring out why it doesn't like the higher resolutions.. [02:20] (but try this with a console only build.. the console driver will handle the resolution switch when you write different values to custom_edid_timings.. but X11 won't) [02:20] sure [02:20] robclark: so, back to the older kernel [02:20] to many new issues with this tree :-) [02:21] sigh [02:21] I take it 1280x1024 was working ok when you hard-coded it? [02:22] robclark: never actually tried with dvi, was mainly debugging hdmi [02:22] this is the combination GrueMaster is using, that's why [02:22] :-) [02:22] oh, ok [02:22] first day I'm actually trying to make the panda display work [02:23] well, fwiw if GrueMaster has a different monitor, his issues could be different... but sending a boot log with omapdss.debug=1 and edid file to mythripk and myself are a good idea for everyone who is having hdmi issues [02:25] lag is also using a lg monitor (different version) and he's getting the same issues I'm getting with mine [02:25] so ti seems that some lg monitors may have this issue [02:26] *it [02:26] hmm.. I thought lag's monitor was working after one of mythripk's patches.. or was that only the monitor he was using at the sprint? [02:26] * robclark is wondering whether he missed one of mythripk's patches? [02:27] robclark: could be the one he was using at the sprint [02:27] hmm, ok === rbelem is now known as rbelem-afk [02:58] robclark: echo 161 > /sys/devices/omapdss/display0/custom_edid_timing sets to the correct resolution with the older kernel [02:58] and it works fine, I can log in the console successfully [02:58] just need to debug why the first resolution is wrong [02:59] hmm.. [03:00] the kernel I'm using is the maverick one plus http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commit/c6019735b852b625918c9f3788058f7b0fd5f607 [03:00] and http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commit/1e8b137986d8f53a393e5e0e44baa8fc62bcd254 [03:00] hm, shit [03:00] there's one other change that I had to add to this kernel [03:00] + mdelay(500); [03:00] what was it using when you added mythripk's patch? 820? [03:00] maybe this is the cause of not working with the latest tree [03:01] at least mythripk said that without this patch it wouldn't work [03:01] oh.. hmm, I have mdelay(50) instead of mdelay(500).. [03:01] http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=blobdiff;f=drivers/video/omap2/dss/hdmi.c;h=0830bbc6baed30e04afca7b1c1a5b83ec298c890;hp=a8bedb1facd324eb6d2f07767ae6399f7c24ec3a;hb=76dd0768b77f731bbe6ad4df55379734f3a38770;hpb=f6c95ac85cfa087a84cd82564dcaea8ce4a6c867 [03:01] maybe I pulled that from an earlier version of her patch [03:02] could you go back to my branch plus mythripk's patch, but change 50 to 500? [03:02] and if that doesn't work, cat /sys/devices/omapdss/custom_edid_timing [03:02] that will tell if it is picking 820 instead of 161 [03:03] yep, will recompile it here and grab a beer [03:03] sure, sounds like a good plan :-) [03:04] beer is always a good plan :-) [03:05] indeed [03:29] robclark: nops, same result :-( [03:29] can you cat custom_edid_timings? [03:29] I'm curious if it is picking 820 instead of 160.. [03:30] and you should be able to manually overwrite by writing 160 to that file [03:30] (sorry, I mean 161) [03:33] root@beagle-maverick:~# cat /sys/devices/omapdss/display0/custom_edid_timing [03:33] 161 [03:33] default with your kernel + mythripk's patch [03:33] hmm, ok.. odd.. same timings and it is working with the old kernel.. [03:33] yep [03:33] and this is with mdelay(500) instead of 50? [03:35] robclark: yes [03:35] hmm.. ok, so not a matter of picking which timings.. and not an mdelay() issue.. [03:35] yep [03:36] so I guess there must be some other patch missing.. or one of the new patches breaks something.. hmm [03:36] probably [03:38] hmm, I don't see any other patches if I look in the commitlog of ubuntu kernel.. [03:38] ugh [03:38] probably a new patch that breaks something [03:39] yeah [03:39] cause the ubuntu kernel is still using a quite old hash [03:40] well, most of the patches are related either to resolution switch (which shouldn't matter in this case, because you are still picking 1920x1080 which is the default startup resolution).. and EDID parsing.. so it must be something more subtle.. === robclark_ is now known as robclark === hrw|gone is now known as hrw [07:58] morning === fta_ is now known as fta === XorA|gone is now known as XorA [10:13] what a lovely morning === kmargar is now known as markos_ [11:36] rcn-ee: Are you around? === asac_ is now known as asac [11:51] lag, a bit early for the US [12:09] ogra: He as proxy - I'm sure he'll ping me when he's had his breakfast :) [12:10] has* [12:10] indeed [13:23] lag: I don't like binaries, send me the code! :-) [13:26] rsalveti: Just try that first - if it works I'll send you the code [13:58] lag: yep, it works with yours [13:59] lag: now send me the code! :-) [14:00] rsalveti: http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=shortlog;h=refs/heads/mythripk-patch [14:00] lag: this patch? http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=commitdiff;h=f6c95ac85cfa087a84cd82564dcaea8ce4a6c867;hp=7e32c02207fe99010175845996f4dfa6b8173121 [14:03] lag: ok, the only thing that you have on your kernel that I don't is the changes at hdmi_get_code function [14:03] that's the one that gets the correct resolution for this monitor by default [14:03] rsalveti: You'll also need http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=blobdiff;f=drivers/video/omap2/dss/hdmi.c;h=0830bbc6baed30e04afca7b1c1a5b83ec298c890;hp=a8bedb1facd324eb6d2f07767ae6399f7c24ec3a;hb=76dd0768b77f731bbe6ad4df55379734f3a38770;hpb=f6c95ac85cfa087a84cd82564dcaea8ce4a6c867 [14:03] lag: yep, I already got this [14:04] Then you shouldn't see any difference [14:04] Do you have console=tty2 when you use your kernel? [14:04] lag: sure [14:05] rsalveti: There should be no difference then [14:05] lag: I got the patch from a different source, as I said at the email, applied both patches from mythripk and added the mdelay 500 [14:05] Shouldn't be a problem then [14:05] You should get the same results from your kernel and the one you built [14:05] the only thing you have that I don't have is the changes at the hdmi_get_code function [14:05] ... from the one I sent you [14:06] lag: nops because I'm missing one patch, but I already found it [14:06] lag: but the main problem I was fighting yesterday with robclark is that the monitor doesn't work at all with the latest tree [14:07] I tested with L24.7_panda-hdmi-patches and got nothing at the screen [14:07] so you could merge these patches now, get it to work but then later on you'll have to debug to see why it stopped to work [14:07] when you merge their latest patches [14:08] Which tree did you build from? [14:08] robclark's one [14:08] http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commits/L24.7_panda-hdmi-patches [14:08] he added some patches to make it to work better with some monitors [14:09] Then you need to tie up with him and figure out why it's not working [14:09] The current Ubuntu tree along with mythripk's patches work [14:10] rsalveti: if you have time, it could be interesting to apply the hdmi patches one by one on ubuntu kernel to isolate where it works and where it doesn't.. but keep in mind that one of the early hdmi patches from mythripk removes the bootargs to hard code monitor mode, so you'll have to use custom_edid_timings sysfs file.. [14:10] if we knew where it broke, that would help to debug.. but probably best to do on top of ubuntu kernel in case it is some other difference between the two kernels [14:11] (but to build that many variants, I hope you are cross compiling and not building kernel natively) [14:12] ok, be back in a bit [14:12] yep, it seems that the only way is to bisect it [14:12] painful [14:14] lag: do you have plans to merge these patches? [14:14] Nope [14:15] mythripk has sent them for review [14:15] They should be out in TI's kernel soon [14:15] When they are either me or cooloney will initiate a pull request from them [14:15] the problem is that I also think the robclark's patches will be inside [14:15] at current robclark's tree all these patches are already included [14:16] You'll have to find out what the differences are between yours and mine [14:17] I'm sure robclark will be happy to help you : [14:17] :) [14:18] rsalveti: How does the client use bip.pem? [14:19] lag: mine doesn't have any differences from yours, the question is more which patch from robclark's tree broke the display [14:19] currently my tree is the same thing as yours [14:19] I was missing one patch [14:20] Have you added that patch? [14:20] yep [14:20] OMAP4:DSS:HDMI:Get code update to match timing of vsync hsync as whole instead of as hsw hbp and hfp respectively [14:21] I got this patch from robclark directly by email, but the url should be somewhere :-) [14:23] So is that one that you have and I don't - or one that I have applied and you don't? [14:25] lag: the one you had I just applied now [14:25] I had a working one with wrong resolution [14:25] this patch basically helps setting the correct resolution at the first time [14:26] so everything works [14:28] You've tested it? [14:33] lag: not yet, but I tested this patch with the other tree and it helped getting the correct resolution [14:33] lag: and looking at the diff is the only thing that makes sense [14:33] robclark: do you know if your patches were also sent for review and will be published at the next TI release? [14:34] rsalveti: they were sent.. and at least most will be in next release.. some of the last few about EDID parsing, I'm not sure if there is time to get them in.. [14:35] robclark: ok [14:35] robclark: do you know when it will be released? [14:35] but, fwiw, my hdmi-patches branch is based on a slightly older release.. so I'm wondering if all those patches on top of ubuntu kernel works, maybe it is a difference in the kernel those patches are on top of? [14:35] could be, I can try to bisect later [14:35] well, the kernel team will make their handoff soon, I think.. or at least their code-freeze soon.. [14:35] after applying the patches at the ubuntu kernel [14:36] but I guess it takes another month by the time the patches make their way to ubuntu kernel.. [14:36] ouch [14:36] next release will be based on 2.6.35.. fwiw [14:36] hm, probably lots of things will change [14:36] so takes some time for all teams to rebase, test with it, figure out everything that broke, etc :-) [14:36] yeah [14:38] robclark: ok then, will try to apply and bisect the patches later, as it's quite time consuming [14:46] rsalveti: I can send the patch set for HDMI that will go on top of out tree this friday [14:46] mythripk: nice, that would help [14:49] rsalveti: sent [14:55] robclark: will try mythripk patches on top of the current ubuntu tree to see if it works better [14:55] ok.. thx [14:55] then we can try your patches on top, if it works [14:56] ok, that should be a good plan [14:57] robclark : i guess it should not matter for non acii EDID encoded DVI monitors or HDMI monitors rt ? [14:58] k drop a mail with the log whether it works or not :) ,please enable the debug on ... [14:58] yeah, I think if your monitor isn't falling back to 640x480 when it should be able to do better, my patches shouldn't matter.. === bjf[afk] is now known as bjf === lag is now known as Guest96571 === fta_ is now known as fta [16:20] plars: rcn posted a work around for 588243 to the omap-linux list but it was rejected see here for details: https://patchwork.kernel.org/patch/101907/ [16:20] jcrigby: right, saw that. Iirc it just concealed the problem for now [16:21] yes, Toni says that the fix belongs in the panel driver [16:22] the other thing I see on XM but not C4 are three WARNINGS about clocks [16:22] jcrigby: unfortunately that was >2months ago, but I think cooloney is looking at it now too [16:22] jcrigby: if you are up for it, I'm sure he would appreciate the help :) [16:22] I might do that [16:22] jcrigby: yeah, I don't remember seeing that on my c4 either, don't have an xm to test with right now [16:23] I googled and all I found was a pastebin from yesterday [16:23] posted by Voodoo [16:25] plars: I am not able to reproduce bug 588243 on my C4 beagleboard with the 20100802 image and 2.6.35-14-omap kernel. [16:25] Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/588243 [16:27] GrueMaster:one thing is you have to wait 10 minutes for some PM event to kick in [16:27] if you reboot immediately it does not happen [16:28] you have to wait for dpms [16:29] and iirc its a duplicate [16:30] of a bug that mpoirier recently closed as non reproducable === JaMa is now known as JaMa|Sports === fta_ is now known as fta [16:32] would have been nice if that bug would have been triaged properly so we dont work on it without coordiantion between the teams [16:32] Well, my system has been idle overnight, and I just issued sudo reboot from a serial login (screen was off and locked). Screen refreshed and showed proper shutdown sequence and rebooted. Nothing appears in any of my log files. [16:32] Hence the reason the other bug was marked as unreproducable. [16:32] GrueMaster, right, thats what i think mpoirier saw as well [16:33] its just bad to have two bugs about the same issue and two teams working on it without any communication [16:33] thats a waste of manpower [16:33] So mark one of the bugs as duplicate. [16:33] plars, dont you guys subscribe ubuntu-armel to bugs anymore ? [16:34] But until it can be readily reproduced, it will be difficult to debug. [16:34] well, it would be good to know why its reproducable for some [16:34] ogra_cmpc: I do, but I guess I didn't see the dup, do you have a bug#? It's certainly reproducible, and easily [16:35] ogra_cmpc: according to cooloney, he could see it on some boards, but not others (not on c3 for instance) [16:35] ogra_cmpc: all I have at the moment is a c4, jcrigby was able to reproduce it there also, and on the xm too [16:35] Is it possibly a difference in x-loader or u-boot? [16:35] i'm not sure with what mpoirier tested, i think GrueMaster uses a C4 [16:36] plars, with which kernel do zou boot the XM ? [16:36] ogra_cmpc: tested what ? [16:36] mpoirier, the DPMS hang on reboot/shutdown [16:36] GrueMaster: did you have your kernel messages going to serial console? [16:36] mpoirier, iirc we decided to close it because nobody could reproduce anymore [16:36] No, but I had before during the sprint (when we were trying to reproduce it). [16:37] ogra_cmpc: I have news on this problem. [16:37] mpoirier, and we have another bug open about it apparently [16:37] I was able to reproduce with a minimal file system built by rootstock [16:37] bug 588243 [16:37] Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/588243 [16:37] mpoirier, oh, cool [16:37] I was never able to reproduce with UNR image [16:38] therefor don't know how relevant to us it is,. [16:38] well, its clearly a kernel bug even though we dont seem to trigger it in the UNR image [16:38] indeed [16:38] indeed. [16:39] but seems of a lesser issue since it is not in UNR. [16:39] I'm back on SDHC [16:39] right [16:39] I actually found this while working on SDHC [16:40] the MMC/SDHC stuff is way more important [16:40] Indeed. [16:40] it currently blocks the XM nearly completely [16:40] we could check in a temporary fix... [16:40] like we did with the daisy chains. [16:40] I didn't 'cause no one asked. [16:41] well, afaik rcn-ee has patches for all issues that would work as temp fixes [16:41] he worked a lot on mmc issues recently he said [16:41] i think lag is in conversation with him about the patches already [16:42] but afaik they are not "upstreamable quality" [16:42] (yet) [16:42] who is afaik ? [16:43] "as far as i know" :) [16:43] ok. [16:49] ogra_cmpc: know anyone using distcc to do native compiles on arm? === lag is now known as Guest88107 === fta_ is now known as fta [16:52] ogra_cmpc: by temporary fix I meant turning off some of the flags that are known to cause problem [16:53] prpplague: NCommander had a setup on babbage systems last cycle iirc. [16:59] GrueMaster: ahh thanks for the info [17:00] NCommander: ping [17:07] is this a channel for using ubuntu on an arm processor, or using ubuntu to program to arm? [17:07] developing ubuntu for the ARM [17:08] Developing Ubuntu on Armv7 based systems to be more specific. [17:08] Does anybody do the latter? I have a few questions i'm having difficulty resolving [17:09] ask and we'll see... :-) [17:09] I want to start a project and use the ARM processor. Does C or C++ get compiled to run on the ARM? and are there different vendors for compilers? is that where my confusing is steming from [17:10] right now the Linaro/Ubuntu toolchain or the Code Sourcery versions are probably the best to use [17:11] edge: yes there are aw wide range of compilers that can be used, most of the ones that people will recommend are basedd on gcc [17:11] are they for C or C++? [17:12] or both? [17:12] edge: yes you can use a compiler directly on the arm device [17:12] edge: you can get them for both [17:12] edge: many people use what is known as a cross-compiler to do their builds [17:12] edge: all the code I deal with is C++ [17:13] You can run an entire development environment (Like Ubuntu) on arm. [17:13] cross compile referes to using an ARCH like x86 to compile to ARM? [17:13] Just using my normal C++ ide? [17:13] Yes. [17:14] and use a differnt GCC flag or something [17:14] edge: yes, I do it all the time [17:14] when configuring a package for a cross build, configure with --host= [17:14] ah ic [17:15] i assume then that to program for the arm i would need to import a class or something to get in touch with the inputs/outputs? [17:16] edge: if you go to here: http://wiki.gnashdev.org/Gnash#Building you can see my notes on cross compiling and configuring === hrw is now known as hrw|gone [17:21] I think i understand. Thank you guys very much === fta_ is now known as fta [18:16] mythripk: robclark: yep, with the patches I got by email the screen works fine [18:17] shows the console and gets the correct resolution [18:19] rsalveti: nice. [18:21] robclark: it seems that I'm missing just "OMAP4:OMAPFB: register callback to get notified of resolution change" and "OMAP4:DSS:HDMI: better support for DVI monitors" from your tree [18:22] I can apply both and test if you want [18:22] rsalveti: If you get the dvi patches, send me a test kernel as well. Preferably in package form (easier to muck with). [18:23] GrueMaster: sure === fta_ is now known as fta [19:01] robclark: "OMAP4:DSS:HDMI: better support for DVI monitors" needs rework to apply it on top of the other patches [19:02] mythripk changed a lot of stuff in the same file in another patch [19:19] rsalveti: ok.. if I get some time this afternoon I'll rebase on the patches that mythripk sent.. got a mtg in a few, so it will be later today [19:20] robclark: sure, np === JaMa|Sports is now known as JaMa [20:13] Hello people. When is the ubuntu netbook edition 10.07 coming out? Where can I get the beta version? [20:25] Ubuntu 10.07 was scrapped as the hardware it was intended for (Beagle XM) was delayed. If you are looking for an up-to-date image for the beagle, use either 10.04 or the 10.10 (Alpha 3) images. [20:25] Not beagle but a random chinese ARM tablet. Will 10.10 alpha3 work on it? [20:26] It might, depending on the SOC. The preinstalled images are currently designed for omap3 and omap4, but we can't test on every system using these parts. [20:27] Do you know what the tablet is using for a cpu? [20:37] wonder if its an epad :D [20:38] but i'd bet its an armv5 via proc === Andy is now known as Guest4766 === fta_ is now known as fta === fta_ is now known as fta === jimqode is now known as Guest45583 [21:40] NCommander or ogra: ping [21:41] ^^how does /etc/flash-kernel.conf get created? [21:42] jcrigby: It is created by the flash-kernel install scripts, I think. Let me check. [21:43] Yes, it is in the postinst script for the deb package. [21:43] What's up? [21:52] GrueMaster: does your ethernet port works at panda? [21:52] yes. [21:52] hm, mine it doesn't seems to recognize it [21:52] I've been posting bugs, so I think it is ok. [21:52] esb1 or 2? [21:52] esb1 [21:53] Do you have the pig tail plugged into the otg port? [21:53] robclark: as I got this board from you, do you know if it was working before? [21:53] GrueMaster: yep [21:53] GrueMaster: I have the normal usb ports working [21:53] just not the ethernet one === XorA is now known as XorA|gone [21:57] nice, just got more 3 sd cards :-) [21:57] cool [21:58] GrueMaster: did you test any class 6 sd with panda? [21:58] Yes. The one I gave you. [21:59] (I've since replaced it). [21:59]