[03:02] <lfitz> if i put the new kernel uImage-2.6.34 in the boot directory and extract the kernel modules to the root fs, will that successfully update the kernel?
[03:03] <lfitz> ..and try to reboot?
[03:04] <lfitz> or is there docs on how to upgrade the kernel on a sheevaplug?
[08:30] <sebjan> lag: Hi! I just look at the syslink patch applied by Tim, and I don't see the modalias, nor the module_init(). Did you test this patch? I do not expect it to be functional...
[08:31] <lag> What do you mean you don't see them?
[08:34] <lag> Sebjan?
[08:34] <sebjan> lag: in the patch applied on the top of the tree, there is not the MODULE_ALIAS code for example
[08:35]  * lag looks
[08:35] <cooloney> sebjan: that's true, please follow the email thread started from lag
[08:36] <cooloney> lag: in you v1 patch, there is MODULE_ALIAS code
[08:37] <cooloney> lag: but in the v2 patch which is in Maverick now, there is no such code
[08:37] <cooloney> lag: i guess sebjan is asking this
[08:37] <sebjan> correct :)
[08:37] <cooloney> lag: btw, thanks a lot for email me the blob file
[08:37] <lag> cooloney, sebjan: You're correct, I'll add it as a separate patch right now
[08:38] <cooloney> lag: great, man
[08:38] <sebjan> lag: we also need the module_init(), right?
[08:38] <lag> Why do you need that?
[08:39] <sebjan> lag: for the omap4_syslink_init function to be called on startup? Or the __init does it?
[08:40] <hrw> morning
[08:41] <lag> sebjan: The device_initcall(omap4_syslink_init); does it
[08:47] <lag> sebjan: http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4-syslink
[08:48] <lag> Sorry about that. I did a git reset --mixed <sha1>
[08:48] <lag> Added omap4-common.c and must have missed off ipc_drv.c
[08:49] <lag> It was still in my tree though, hence when I tested it, it worked
[09:02] <sebjan> lag: no problems. By the way, we shall stick with syslink drivers static right now, as we are seeing issues when using them as modules. We are investigating that, and will send an update when this will be fixed (then we can activate syslink drivers as modules)
[09:03] <lag> No problem - keep me posted
[09:05] <sebjan> lag: yes, sure!
[09:27] <lag> sebjan: Can you have a look at the patch on the mailing list please
[09:27] <lag> sebjan: If it's okay can you ack it as well?
[09:30] <sebjan> lag: done
[09:32] <lag> sebjan: Thanking you!
[10:34] <ogra> sebjan, i still see hangs with the recent panda kernel
[10:41] <ogra> a lot less frequent, but they happen
[10:45] <lag> ogra: Must be userspace ;)
[10:45] <lag> My kernel works flawlessly
[10:45] <lag> :)
[10:46] <ogra> the archive kernel ?
[10:46] <ogra> installed from the package
[10:49] <lag> Nope
[10:50] <lag> But it will be the latest Maverick kernel won't it?
[10:51] <lag> I'm in the process of flahsing my SD card with the latest archive
[10:51] <ogra> ok
[10:52] <lag> ogra: If one thing (within the kernel) is crashing continuously, raise a bug report and I'll take a look
[10:53] <ogra> lag, here is another one to play with bug 603062
[10:53] <ubot2> Launchpad bug 603062 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "oops in parport_pc_probe_port function of parport_pc module (affects: 1) (heat: 8)" [Medium,New] https://launchpad.net/bugs/603062
[10:55] <lag> The new image still doesn't work with my monitor :(
[10:55] <lag> And there's no console output either
[10:56] <ogra> the image should start in console mode by default
[10:56] <ogra> we dont use splash during resizing yet
[10:57] <lag> I have nothing
[10:57] <lag> Uncompressing Linux... done, booting the kernel.
[10:57] <lag> It's been like this for 5mins
[10:57] <ogra> thats serial
[10:57] <lag> Do you think it's resizing?
[10:57] <lag> Yeah
[10:57] <ogra> we dont use serial on ubuntu images
[10:57] <lag> And nothing on the monitor
[10:57] <lag> Zero
[10:57] <lag> Ziltch
[10:57] <lag> Nada
[10:58] <ogra> do you know a cmdline that works for you ?
[10:58] <ukleinek> lag: try enabling DEBUG_LL and DEBUG_LL_CONSOLE
[10:58] <lag> ukleinek: From within the kernel?
[10:58] <ukleinek> lag: make menuconfig
[10:58] <ogra> ukleinek, note that ubuntu images dont have console= settings by default
[10:58] <lag> fdr editconfigs ;)
[10:59] <ogra> breaks the splash
[10:59] <lag> Still nothing ...
[10:59]  * lag whistles 
[10:59] <ogra> lag, lets try to find a cmdline that works for everyone
[11:00] <ogra> there wont happen anything, if your monitor doesnt init it wont do that later either :)
[11:00] <lag> I have a cmdline that works for me
[11:00] <ukleinek> lag: add a printch(c) to emit_log_char
[11:00] <lag> What will happen if I restart the board during the resizing process?
[11:00] <ogra> you will have to re-dd
[11:00] <ogra> the filesystem will be corrupted
[11:00] <lag> Grrrrrrrrrrrrr
[11:00] <lag> What if I wait
[11:01] <lag> It will take the same amount of time
[11:01] <ogra> it will move on and start X to configure the system eventually
[11:01] <ogra> which you likely wont see if the framebuffer doesnt work
[11:02] <ogra> dd the image newly, mount the first partition and add your cmdline changes to boot.scr
[11:02] <ogra> (before booting it for the first time)
[11:02] <ogra> dont forget mkimage
[11:03] <ogra> it would be good if we can find the smallest common denominator that makes all monitors work
[11:04] <ogra> or if TI can fix the EDID code (preferred indeed)
[11:06] <hrw> 1024x768 should work
[11:06] <ogra> well, depends on your monitor
[11:06] <ogra> mine cant do non widescreen modes on the HDMI port afaik
[11:07] <ogra> but i'll try
[11:07] <hrw> XGA was default beagleboard resolution
[11:11] <ogra> lag, what are the options you use
[11:11] <lag> setenv bootargs omapdss.hdmimode=0 omapdss.hdmicode=4 vram=15M, omapfb.vram=0:5M noinitrd mem=512M root=/dev/mmcblk0p2 rootwait ro ip=none; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000
[11:12] <ogra> omapfb.vram=0:5M ?!?
[11:12] <ogra> thats definately to less
[11:12] <lag> TI told me to use it
[11:12] <lag> Well that works
[11:12] <lag> But 32 and 8 work for me also
[11:13] <ogra>  vram=15M is also to less for our kernel
[11:13] <lag> setenv bootargs omapdss.hdmimode=0 omapdss.hdmicode=4 vram=32M, omapfb.vram=0:8M noinitrd mem=512M root=/dev/mmcblk0p2 rootwait ro ip=none; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000
[11:13] <ogra> we enable all possible output devices
[11:13] <ogra> can you try without omapfb.vram=0:8M ?
[11:13] <lag> Well your cmdline doesn't work for me so ...
[11:13] <lag> I can
[11:13]  * ogra will try omapdss.hdmimode=0 omapdss.hdmicode=4 on his monitor
[11:14]  * ogra just tried  omapdss.hdmimode=0 omapdss.hdmicode=35, that makes the board crash once X is up
[11:15] <ogra> and cuts of 60% of the bottom of the screen on my monitor
[11:17] <ogra> lag, also i dont get why mem=512M would work for you
[11:17] <ogra> i was clearly told that will cause issues and hard locks
[11:18] <lag> Probably because I'm not running a GUI
[11:18] <lag> What was it again 468?
[11:18] <ogra> well, robclark said thats reserved ram for the coprocessor
[11:18] <ogra> i dont think that should harm X
[11:18] <ogra> or have any influence
[11:18]  * lag shurgs
[11:18] <lag> It just does
[11:18] <lag> What is the correct value?
[11:19] <lag> 463>
[11:19] <lag> ?
[11:19] <hrw> 463
[11:19] <ogra> right
[11:19] <lag> I'm using a kernel with TI's hack in it at the moment
[11:20] <ogra> sigh, the last crash trashed my SD
[11:20] <lag> Let me build my own and I'll try it out
[11:20] <ogra> lag, that doesnt help at all
[11:20] <ogra> please use the same kernel we all use
[11:20] <lag> ogra: I'm working with both
[11:21] <lag> I have other things going on too :)
[11:21] <ogra> me too
[11:22] <lag> So, I need to be running both kernels
[11:22] <ogra> but it doesnt help the images if you dotn use and improve the image kernels
[11:22] <lag> Doesn't the daily builds use the latest Maverick kernel anyway?
[11:22] <ogra> the one in the archive
[11:22] <ogra> which is behind the git tree
[11:23] <lag> Where is it built from?
[11:23] <ogra> the git tree
[11:23] <ogra> but its not built every day
[11:24] <ogra> tim builds it from kernel.ubuntu.com from cooloneys tree afaik
[11:24] <ogra> every few weeks
[11:25] <ogra> with mode=4 i get a small square in the top left corner of my monitor
[11:25] <ogra> i dont think any of these options will help, TI needs to fix the EDID detection code properly
[11:26] <ogra> its bad enough that we have to use *any* cmdline options
[11:27] <lag> ogra: http://paste.ubuntu.com/460578/
[11:27] <lag> Try some more
[11:27] <lag> See what works for you
[11:27] <ogra> well, what else works for you ?
[11:27] <lag> I don't know yet
[11:27] <ogra> doesnt help if i try all of them
[11:27] <lag> What do I have to mkimage on?
[11:28] <lag> do*
[11:28] <ogra> the edited boot.scr
[11:28] <lag> How do you do that?
[11:28] <lag> I've only done uInitrd and uImage
[11:28] <ogra> sudo mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.scr <mountpoint of first partition>/boot.scr
[11:28] <ogra> the first boot.scr needs to be plain text (no uboot header)
[11:29] <ogra> thats the one you edited
[11:29] <lag> I only have the one with the header on
[11:29] <lag> Should I just take that off?
[11:29] <ogra> yeah
[11:29] <ogra> just delete it in vi
[11:30] <ogra> mkimage adds it again
[11:30] <lag> vi? pfft
[11:30] <ogra> well, or use: strings  <mountpoint of first partition>/boot.scr >./boot.scr
[11:30] <ogra> but that might leave cruft at the top line
[11:31] <ogra> lag, can you try omapdss.hdmicode=6 ? thats one i could imagine all HDMI monitors should be able to do
[11:32] <ogra> err. line 6
[11:32] <ogra> thats code 28 indeed
[11:33] <lag> 4 sort of works
[11:33] <lag> I can see it
[11:33] <ogra> 4 doesnt work here
[11:33] <lag> But it's out of range of my monitor
[11:33] <lag> And is shakey
[11:33] <ogra> well, it draws on the screen but is unusable
[11:34] <lag> Running /scripts/local-bottom ...
[11:34] <ogra> 640x480n is nothing we can run the desktop in
[11:34] <ogra> you wont be able to reach any of the buttons in the apps
[11:35] <lag> I'll try 28 when it's finished doing 'its thing'
[11:35] <lag> It doesn't matter anyway - my keyboard doesn't work!
[11:35] <lag> Grr
[11:36] <lag> no space left on device?
[11:37] <lag> It's a 16GB card?
[11:37] <ogra> it didnt resize
[11:37] <lag> Why not?
[11:37] <ogra> MMC issues i guess
[11:37] <lag> But it resizes yours?
[11:37] <ogra> GrueMaster reported similar issues with some SD cards
[11:37] <lag> I did get the parport segfault though
[11:37] <ogra> it resizes the five i have here for testing
[11:38] <lag> Do you have a 16GB SDHC card there?
[11:38] <ogra> GrueMaster seems to have a similar card to yours, please check with him (once he is up) if you got the same
[11:38] <ogra> no
[11:38] <ogra> my biggest one is 8G
[11:38] <lag> SDHC?
[11:38] <ogra> yes
[11:38] <lag> Odd
[11:39] <lag> Can I resize it manually?
[11:39] <hrw> error -110?
[11:39] <ogra> no
[11:39] <lag> Nope
[11:39] <lag> Different bug
[11:39] <ogra> can you plug the card into your pc and check for /var/log/jasper.log please
[11:40] <ogra> it should have error messages
[11:40] <ogra> where exactly do you get the "no space left on device" errors btw
[11:40] <ogra> any particular process thats causes them ?
[11:41] <ogra> code 28 doesnt work here either btw
[11:41] <ogra> chops off the bottom half of the screen
[11:44] <ogra> lag, where do you get the no spaxce messages ?
[11:44] <lag> On the monitor
[11:44] <ogra> if its udevd thats a tmpfs issue (udev writes to a tmpfs)
[11:44] <ogra> haha
[11:45] <lag> ;)
[11:45] <lag> I can't remember what it was doing now
[11:45] <ogra> hmm
[11:45] <lag> It could have been udev
[11:45] <ogra> well, then only jasper.log can tell
[11:45] <lag> The screen has gone now
[11:45] <ogra> does X start ?
[11:45] <lag> Nope
[11:45] <ogra> the timeframe was also way to short
[11:45] <ogra> resizing 16G will likely take about 15min
[11:46] <hrw> you guys are insane with that resizing
[11:46] <ogra> so please get me the log so i can see what went wrong
[11:46] <ogra> hrw, why ?
[11:46] <ogra> hrw, compared to a 2-3h install its quite reasonable
[11:47] <hrw> ogra: cant I fetch tarball which will be unpacked to card?
[11:47] <ogra> plus you need an additional target device
[11:47] <ogra> hrw, that will be as messy as a rootstock image
[11:47] <ogra> you will never get a proper ubuntu install that way
[11:48] <ogra> it will be something "ubuntu alike"
[11:48] <hrw> so now I get 512MB image to dd on card which will start with initrd which will resize that 512MB to whole card?
[11:49] <ogra> you get a 1.4G image and yes, initrd is essential for a proper ubuntu image
[11:49] <lag> ogra: 28 from the cmdline is still out of range
[11:49] <lag> However
[11:49] <lag> When I do: echo 28 | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing
[11:49] <lag> It looks great
[11:49] <ogra> oh
[11:49] <ogra> hmm
[11:49] <hrw> why I can install x86(-64) with 1CD but arm needs >2CD?
[11:50] <ogra> hrw, because x86 uses a squashfs and a full installer
[11:50] <ogra> our image is bz2 and needs to be uncompressed before dd
[11:50] <ogra> and is fully preinstalled
[11:50] <lag> hrw: Our boards don't have CD drives :)
[11:50] <ogra> well, they have SD slots
[11:51] <lag> Yes, hence why we use entire images
[11:51] <ogra> which we used before in a similar way to CD drives
[11:51] <ogra> so you had to install a live image to USB from SD card
[11:51] <lag> Our full install takes 5 mins. How long does X86 take?
[11:51] <ogra> a) the installation can take 2-3h depending on the card
[11:52] <ogra> b) you need to use the SD as a "boot floppy" on boards like panda
[11:52] <ogra> so you need to trash the installation media at the end of the install
[11:52] <ogra> very very ugly
[11:52] <lag> Yup
[11:52] <ogra> x86 takes between 20 and 40min
[11:52] <ogra> with a speedy CD drive
[11:53] <ogra> it copies the 2G from the squashfs to the HDD
[11:53] <ogra> and then removes bits
[11:54] <ogra> in our images the resizing takes the longest time, after that its relatively speedy since only oem-config runs
[11:54] <ogra> sadly resizing takes at least 10min
[11:55] <ogra> lag, anything intresting in the jasper.log file ?
[11:55] <lag> It was trashed
[11:55] <ogra> gah
[11:55] <lag> I trashed it
[11:55] <lag> I am re-running
[11:56] <ogra> what you can do is to add break=bottom on the cmdline, that will give you a busybox shell
[11:56] <ogra> jasper.log lives in /dev/.initramfs/jasper.log there
[11:57] <ogra> you can ctrl-d out of that shell and booting moves on
[11:57] <ogra> (works also with break=top or premount, depending where you want to inspect the initramfs)
[11:57] <lag> Just tested 28 with the archive kernel
[11:57] <lag> Nada
[11:57] <lag> Got to reflash now :(
[11:57] <ogra> sad
[11:58] <ogra> we really need TI to fix that properly then
[11:58] <ogra> fiddling with cmdline options in the default install is ugly anyway
[11:58]  * ogra prefers to not have more than "quiet splash root=UUID=..."
[11:59] <ogra> and ro
[12:02] <lag> Well I have direct contact with the video people at TI ...
[12:02] <ogra> robclark is resident here too :)
[12:03] <lag> Is robclark video people?
[12:03] <ogra> yep
[12:04] <lag> Cool - let's bother him :)
[12:04] <lag> Where is he based?
[12:04] <ogra> tx
[12:10]  * ogra played with /sys/devices/platform/omapdss/display0/custom_edid_timing
[12:10] <ogra> sadly i have the same issue as with setting modes on cmdline
[12:10] <ogra> screen isnt fullscreen
[12:11] <ogra> i either have a small square at the top left of the monitor or the screen extends beyond monitor size
[12:12]  * ogra wishes DVI would just work
[12:13] <lag> :(
[12:13] <ogra> hmm
[12:13] <ogra> DVI does work
[12:14] <ogra> well, the HDMI->DVI cable from my beagle does at least
[12:14] <ogra> weird
[12:14] <lag> ogra: .initramfs doesn't exist
[12:14] <ogra> but same effect
[12:15] <ogra> /dev/.initramfs/
[12:15] <ogra> init mounts it under /dev
[12:15] <ogra> its a tmpfs
[12:16] <lag> Oh okay
[12:16] <lag> I'll try dropping into a Busybox shell then
[12:16]  * lag is reflashing
[12:16] <lag> This sucks
[12:17] <ogra> aha, DVI doesnt work on boot at all
[12:18] <ogra> well, it does, but puts the screen to weird ranges
[12:20]  * ogra takes a break
[12:43]  * lag pounces on robclark!
[12:43] <robclark> hi lag
[12:43] <lag> Hey robclark
[12:43] <hrw> hi robclark
[12:43] <lag> How are you this afternoon/morning?
[12:43] <robclark> hi hrw
[12:44]  * robclark is just finishing my coffee
[12:44] <lag> Can you type and drink? :)
[12:44] <lag> Or would you like me to wait for you to finish?
[12:44] <robclark> no, I can type
[12:46] <lag> We're having video issues
[12:46] <robclark> uh-oh
[12:46] <lag> I have an LG FLATRON W2261VP
[12:47] <lag> I have tried omapdss.hdmicode=*
[12:47] <robclark> what resolution?  If it could do 1920x1080 then, in theory, it shouldn't even need any bootargs..
[12:48] <hrw> robclark: thats 22" so rather not fullhd
[12:48] <lag> And depending on what '*' is, I either receive shakey text and the monitor say "out of range"
[12:48] <lag> Or I get nothing
[12:48] <lag> Yes, it does 1920x1080
[12:48] <lag> Or should do
[12:49] <robclark> hmm..  in the printk's from the HDMI driver you should see what resolution the driver *thinks* the monitor can do
[12:49] <lag> But it doesn't
[12:49] <lag> With no args, the monitor just goes to sleep
[12:49] <robclark> but I think the driver still has troubles with some monitors..
[12:49] <lag> We don't have access to the boot-up messages with this kernel
[12:50]  * lag flicks to another kernel
[12:50] <robclark> hmm... ok.. that is a bit inconvenient
[12:50] <lag> It does the same thing on my kernel
[12:50] <robclark> although to be honest, I'm not a display driver guy..
[12:51] <robclark> if you could get a log of the boot msgs, we send that to me (rob@ti.com) and I'll loop in display driver team
[12:51]  * robclark thinks what is really needed is to get the display driver team access to more monitors to test with
[12:51] <lag> I am in direct contact with Mythri
[12:51] <robclark> ok, perfect
[12:52] <lag> But things are slooooooooow over email
[12:52] <robclark> she knows the HDMI driver more than I..
[12:52] <robclark> ok.. I'll try to pester them to get on IRC..
[12:53] <lag> That could be a good thing
[12:53] <lag> I think she's in the far east though isn't she?
[12:53] <robclark> yes
[12:53] <lag> And would have gone home by now?
[12:53] <cwillu_at_work> lag, afaik, the trouble with higher resolutions is that the driver can't keep up the refresh rate
[12:53] <robclark> well, most of them work rather late.. so probably still in the office now
[12:54] <cwillu_at_work> it's pretty much up to the monitor whether it will still work at that point
[12:54] <lag> cwillu_at_work: So where do we go with this?
[12:55] <cwillu_at_work> lag, working from memory here, having spoken to folks before on this.
[12:55] <cwillu_at_work> hang on a sec, let me check my logs
[12:55] <lag> The odd thing is, a mode that doesn't work on the cmdline using omapdss.hdmicode will work using: echo * | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing
[12:56] <lag> And it will work perfectly then?
[12:56] <cwillu_at_work> oh, really?
[12:56] <lag> Yeah! What gives?
[12:56] <lag> But that's no good for be, as I'm working on boot-up code
[12:57] <cwillu_at_work> what does .hdmicode= do that a normal omapdss command line doesn't?
[12:57] <lag> me*
[12:57] <lag> That's what I'm looking for now
[12:57] <lag> ;)
[12:57]  * lag is on it
[12:57] <cwillu_at_work> omapfb.mode=dvi:1024x768MR-16
[12:57] <cwillu_at_work> is what I'm usually doing
[12:57] <cwillu_at_work> although usually 1280x1024 or 1600x900
[12:57] <lag> I'm using hdmi
[12:58] <hrw> cwillu_at_work: on beagleboard?
[12:58] <cwillu_at_work> same thing
[12:58] <cwillu_at_work> yes
[12:58] <cwillu_at_work> oh, are we not talking beagles?
[12:58] <lag> Nope
[12:58] <hrw> cwillu_at_work: they talk about pandaboard
[12:58] <lag> I have Beagle working
[12:58] <cwillu_at_work> I'd still imagine it's the same thing though
[12:58] <hrw> cwillu_at_work: panda can do fullhd-60
[12:58] <cwillu_at_work> just <somethingelse>:1280x1024MR-16 instead of DVI:
[12:59] <cwillu_at_work> especially if it works echoing to the sysfs
[13:00] <cwillu_at_work> I might be out on the road with my boss today, I'll find out in an hour.  If not, I'm interested in spelunking into the relevant dss code today :)\
[13:04] <lag> cwillu_at_work: I just tried your args - the monitor just stuck its fingers up at me and went to sleep
[13:04] <cwillu_at_work> does it report the refresh rate it's getting before it goes to sleep?
[13:05] <cwillu_at_work> and did you try any other options re: the dvi: bit?
[13:05] <lag> Yes
[13:06] <lag> dvi and hdmi
[13:06] <lag> Just did this: echo 40 | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing
[13:06] <lag> And it appeared
[13:06] <lag> Looking perfect
[13:06] <lag> Grrrrrrrrrrr
[13:06] <robclark> lag, hmm, so setting it via bootargs seems broken?
[13:07] <lag> Correct
[13:08] <hrw> 'TI: please fix your drivers'
[13:08] <lag> :)
[13:14] <robclark> btw, for those who haven't already noticed:  #pandaboard
[13:14] <hrw> lag: http://marcin.juszkiewicz.com.pl/2009/06/12/ti-please-fix-your-usb/
[13:14] <lag> Does anyone have a keyboard and mouse attached to their Panda?
[13:15] <robclark> lag: yup
[13:15] <cwillu_at_work> lag, come to think of it, there should be another file in that folder with the names for each display
[13:15] <cwillu_at_work> try doing a "cat *", and see if anything shows up
[13:15] <lag> hrw: How funny!
[13:15]  * robclark has to run.. be back later
[13:16] <lag> EDID-Informationcat: driver: Is a directory
[13:16] <lag> 1
[13:16] <lag> cat: hpd_enabled: Input/output error
[13:16] <lag> cat: mirror: No such file or directory
[13:17] <lag> hdmi
[13:17] <lag> cat: rotate: No such file or directory
[13:17] <lag> cat: subsystem: Is a directory
[13:17] <lag> 0
[13:17] <lag> 148500,1920/88/148/44,1080/4/36/5
[13:17] <lag> DRIVER=hdmi_panel
[13:17] <lag> 1
[13:17] <lag> cat: wss: No such file or directory
[13:17] <lag> Whoops
[13:18] <cwillu_at_work> so, my suspicion is that hdmi or hdmi_panel is the right invocation then
[13:18] <cwillu_at_work> also, I really really hate it when it takes a million years to page an app back into memory when I have 2gb of ram being wasted on cache
[13:19] <cwillu_at_work> (and don't tell me to set swappiness, that's useless as a long term proposition)
[13:19] <lag> cwillu_at_work: Tried both of them ... nothing
[13:20] <cwillu_at_work> boo.
[13:20] <cwillu_at_work> k, I'll poke you in a couple hours if I'm not driving out to the middle of nowhere
[13:21] <lag> I'm going to have a poke around in the driver in the meantime
[13:46] <mythripk> lag, I heard from Rob that you had some more issues in HDMI..
[13:49] <lag> lag == lee
[13:49] <lag> :)
[13:49] <lag> We've been chatting
[13:50] <mythripk> did you try out the timing values i suggested over mail ?
[13:50] <lag> Yes
[13:50] <lag> They worked when I use sysfs
[13:50] <mythripk> ie the custom_edid_timing right?
[13:50] <lag> They don't when I use them on the kernel cmdline
[13:50] <lag> Correct
[13:51] <lag> I don't see why my monitor should be different to any other
[13:51] <mythripk> ok ie when you use omapdss.hdmicode= and omapdss.hdmimode=
[13:51] <lag> Beagleboard works out of the box
[13:51] <lag> Yes, they don't work
[13:51] <mythripk> it would not be , can you please share the log ?
[13:52] <lag> The most I can get from them is a fuzzy screen and my monitor saying "out of range"
[13:52] <lag> When I use which settings?
[13:52] <mythripk> any , where you are getting fuzzy screen and monitor giving "out of range "
[13:53] <mythripk> also what is the timing value that you set with beagle ?
[13:53] <lag> I have no idea
[13:53] <lag> I'll try to find out for you
[13:54] <lag> Also, my monitor doesn't turn itself on
[13:54] <mythripk> no that's fine , log would help , but the same command line i sent for 640 and 480 ie vga setting worked ?
[13:54] <lag> I have to turn it off, then on again to get my fuzzy screen
[13:54] <mythripk> with the vga setting too ?
[13:55] <lag> Here is fuzzy screen settings: http://paste.ubuntu.com/460620/
[13:55] <ogra> mythripk, the problem is that we need something that works generally on the ubuntu images
[13:55] <lag> Nothing has 'worked' - some have been better than others
[13:56] <ogra> there is no way to adjust boot options for every monitor
[13:57] <ogra> preferably by autodetection and without any boot parameters, though if thats not possible, a bootarg with the smallest common denominator that makes it work on all monitors would also work
[13:58] <mythripk> currently the default setting is for 1080p setting but you could pass the boot args , the setting that will definitely work on All Tv's would be VGA resolution according to HDMI spec , I could make it as default
[13:59] <mythripk> Lag didnt VGA resolution work for you ? From your mail i was under the impression that it did.
[13:59] <ogra> VGA is to small for our desktop
[14:00] <lag> Which number was that?
[14:00] <mythripk> omapdss.hdmicode=4 and omapdss.hdmimode=0
[14:00] <ogra> and causes weird effects on some monitors ... i.e. mine doesnt expand to the full monitor size, i get a square in the top left corner of the screen
[14:00] <lag> That's the fuzzy screen setting that I use
[14:01] <mythripk> ogra , ya VGA is too small but that is the only setting that by default is supported by all TV's and then
[14:01] <lag> mythripk:
[14:01] <lag> ubuntu@beagleboard:/sys/devices/platform/omapdss$ cat display0/timings
[14:01] <lag> 61714,1280/80/48/32,720/3/13/5
[14:01] <lag> ubuntu@beagleboard:/sys/devices/platform/omapdss$ cat display1/timings
[14:01] <lag> 13500,720/12/68/64,574/5/41/5  .
[14:02] <lag> From the Beagle
[14:02] <ogra> mythripk, 1024x768 would work for us ...
[14:03] <mythripk> ok then can you set omapdss.hdmicode=16 and omapdss.hdmimode=0 ?
[14:03] <ogra> that gets me the above described effect
[14:03] <ogra> doesnt expand to the full screen size
[14:04] <ogra> not sure what it does for lag's monitor
[14:04] <ogra> or for GrueMaster's who also has display issues
[14:05] <lag> Checking
[14:05] <mythripk> http://omappedia.org/wiki/Bootargs_for_enabling_display this has explanation as to what you code you could use for all the DVI settings ,  How to read and set EDID timings for HDMI  section , you could modify the omapdss.hdmimode and code correspondingly for bootargs
[14:05]  * lag 's monitor stuck its fingers up at him and went to sleep
[14:06] <mythripk> with 16 and 0 ?
[14:07] <ogra> mythripk, is there any chance that works automatically at some point ?
[14:07] <ogra> the EDID data should have all possible modes the monitor can handle or not ?
[14:07] <ogra> so if you can read it you shoudl be able to switch to a valid mode
[14:07] <mythripk> Lag From the pastebin theEDID is read and being set correctly : EDID Content 256                                                                                                                                                   EDID TIMING DATA FOUND                                                                                                                                                   Hdmi_code = 4 mode = 1
[14:08] <mythripk> ogra, yes the EDID has all the values supported by the monitor , but from the log tha lag sent me earlier its NULL , i was actually surprised
[14:08] <lag> I think "Hdmi_code = 4 mode = 1" is coming from my boot args
[14:08] <lag> Although mode should be 0?
[14:09] <ogra> mythripk, aha :)
[14:09] <mythripk> yes are you setting omapdss.hdmimode=0? in the bootargs?
[14:09] <lag> I am
[14:10]  * ogra sees "How to enable HDMI in hot-plug detect mode" ... 
[14:10] <ogra> i wonder if we could enable that by default in our kernel
[14:11] <ogra> are there any drawbacks when defaulting that value to 1
[14:11] <ogra> ?
[14:11] <lag> I just tried setting omapdss.hdmimode=0 and leaving the code - nothing
[14:12] <mythripk> ogra , I sent a patch to lag to default put it in hot plug detect mode as he was sync lost digit earlier , through sysfs you could use  echo 1 > /sys/devices/platform/omapdss/display2/hpd_enabled again from http://omappedia.org/wiki/Bootargs_for_enabling_display
[14:13] <mythripk> lag , could you please try with another monitor ? or is it the same behavior with all ?
[14:13] <ogra> mythripk, right, i saw that
[14:13] <lag> The only other HDMI device I have is my TV downstairs 42"
[14:13] <ogra> mythripk, but it seems like something really userfriendly to enable by default if it doesnt disturb other functionallity
[14:21] <mythripk> ogra, yes we could actually read the first block of EDID and set the timings which we currently are not doing today , for some samsung TV's not working
[14:22] <ogra> hmm
[14:22] <ogra> i have no issues with my samsung monitor
[14:22] <ogra> and apparently i'm the only panda user in the ubuntu team who doesnt have display issues ... which is funny :)
[14:22] <mythripk> we have identified that we were setting AVI checksum wrong that resulted in some samsung TV's not working There is a patch available for that
[14:22] <mythripk> good to hear :)
[14:23] <ogra> so we should include your patch :)
[14:24] <mythripk> that would solve the issues seen in some samsung TV's that enforce strict AVI checksum
[14:24] <ogra> great, lag can we add that ?
[14:25] <mythripk> Lag already has the patch
[14:25] <ogra> right, i just want to make sure it ends up in our tree :)
[14:54] <lag>                                                                                                                                                                                                                                                                                                                                                                                                                                           
[14:54] <lag>                                                                                                                                                                                                                                                                                                                                                                                                                                           
[14:54] <lag>                                           
[14:54] <lag> Oh my word!
[14:54] <lag> Sorry about that - computer went crazy!
[14:54] <lag> I blame the OS
[14:54] <lag> Right, I've tried it on a different monitor
 Lag already has the patch: I do?
[15:05] <lag> ogra: Where's mythripk gone?
[15:25] <robclark> lag, I guess mythripk has gone home now
[15:25] <lag> np
[15:25] <lag> I'm going to try and debug it myself anyway
[15:26] <lag> Who needs expert knowledge? Pfft ...
[15:26] <lag> :)
[15:26] <robclark> heheh
[15:49] <jussi> hrm, why do these packages have {a} and {u} after them?
[15:50] <jussi> The following NEW packages will be installed:
[15:50] <jussi>   libdbus-1-dev{a} libeet-dev libeet-doc{a} libeet1{a} libhal-dev   libhal-storage-dev libjpeg62-dev{a}
[15:50] <jussi> The following packages will be REMOVED:
[15:50] <jussi>   freepats{u} gstreamer0.10-ffmpeg{u} gstreamer0.10-plugins-ugly{u}
[15:51] <hrw> {a} == automatically installed
[15:52] <hrw> as dependency for other packages
[15:53] <jussi> and {u}?
[15:56] <hrw> do not remember
[15:57] <GrueMaster> ogra: I heard my name, but am too fuzzy (ENOCOFFEE) to see what you wanted.  What can I do to help this morning?
[16:01] <lool> jussi: {a} automatically installed {u} will purge
[16:01] <lool> IIRC
[16:02] <lool> Or rather automatically uninstalled
[16:02] <lool> {up} is when they also get purged I think
[16:48] <jussi> lool: thanks. also, weird question of the day,will maemo packages work on an ubuntu install?
[16:50] <hrw> jussi: no
[16:50] <hrw> jussi: you need to recompile them
[16:50] <hrw> some of maemo5 libraries are not available in ubuntu
[16:50] <jussi> ahh
[16:51] <hrw> some are closed even
[16:51] <jussi> Im just trying to find a working "media centre" for arm jaunty - xbmc, enna, moovida etc and it seems impossible to find...
[16:51] <hrw> what hardware?
[16:52] <jussi> enna has maemo pkgs, hence the question
[16:52] <jussi> imx51 based
[16:52] <hrw> imx51... run maverick or lucid then
[16:52] <jussi> no, cant unfortunately.
[16:53] <lool> jussi: You can create a maemo chroot and run it from an Ubuntu install
[16:53] <lool> jussi: Which maemo packages do you mean specifically?
[16:54] <jussi> lool: stuff in here: http://packages.geexbox.org/pool/main/
[16:54] <lool> jussi: It might be that some binaries require opengles though
[16:55] <lool> jussi: Dunno
[16:58] <sebjan> lag: I just tested the last syslink auto-load patches, and they fail in loading the modules. I don't see the syslink_ipc event in the logs, so I suspect the omap_syslink_init function to not be called... Could you make a check please?
[16:59] <lag> Of course
[16:59] <lag> Which logs are you looking in?
[16:59] <lag> grep syslink /var/log/udev
[17:04] <lag> sebjan?
[17:04] <sebjan> lag: yes, into this log
[17:05] <lag> Okay, re-compiling now
[17:27] <ogra_cmpc> GrueMaster, we had a TI display person around and were talking about display probs, i only mentioned your name there
[17:28] <lag> sebjan:
[17:28] <lag> KERNEL[946685538.408904] add      /devices/platform/syslink_ipc (platform)
[17:28] <lag> UDEV_LOG=3
[17:28] <lag> ACTION=add
[17:28] <lag> DEVPATH=/devices/platform/syslink_ipc
[17:28] <lag> SUBSYSTEM=platform
[17:28] <lag> MODALIAS=platform:syslink_ipc
[17:29] <lag> SEQNUM=726
[17:29] <GrueMaster> ok
[17:29] <sebjan> lag: shall I understand that you get the uevent? and the modules loaded?
[17:30] <lag> No, because I have a read-only file system at the moment
[17:30] <lag> Hang on
[17:31] <sebjan> lag: at least 'dmesg | grep syslink' ouputs something (from the omap4_syslink_init function)?
[17:33] <lag> Hmmm... no?
[17:34] <lag> Perhaps I am working on stagnant logs
[17:34] <lag> I'll look into it
[17:37] <GrueMaster> lag: do we have any mainline kernels for arm?  Or do I need to pull source and build my own?
[17:38] <lag> GrueMaster: We have images in the archive
[17:38] <lag> GrueMaster: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/
[17:39] <GrueMaster> I'm aware of those.  I test those.  I'm looking for a mainstream kernel package to verify bug 601226 as affecting upstream.
[17:39] <ubot2> Launchpad bug 601226 in linux-ti-omap4 (Ubuntu Maverick) (and 3 other projects) "Unable to handle kernel NULL pointer dereference in ppdev module (affects: 2) (dups: 1) (heat: 16)" [Medium,Triaged] https://launchpad.net/bugs/601226
[17:40] <ogra_cmpc> GrueMaster, there is only the TI branch for panda
[17:40] <ogra_cmpc> no mainline
[17:41] <GrueMaster> ogra_cmpc: This bug also affects Beagleboard.  I made your bug a duplicate of mine, as it is the same issue.
[17:41] <ogra_cmpc> GrueMaster, you could indeed build from the ti git tree on gitorious.org
[17:41]  * ogra_cmpc isnt sure its the same issue
[17:41] <ogra_cmpc> GrueMaster, oh, thats parport_pc ?
[17:42] <ogra_cmpc> why doesnt your report say that
[17:42] <lag> sebjan: Something strange is going on
[17:42] <GrueMaster> It did.  plars just changed it.
[17:43] <GrueMaster> And I filed my bug last week before I had an omap4 image or system.
[17:43] <sebjan> lag: sorry I need to go now, can we talk tomorrow?
[17:44] <ogra_cmpc> GrueMaster, mumble ... mine even points to the function having the issue, i dont get why he changed it
[17:44] <lag> sebjan: Of course
[17:45] <sebjan> lag: ok, talk to you tomorrow then