**** BEGIN LOGGING AT Sat Feb 27 02:59:56 2010
Feb 27 04:04:02 <slaxxer> used the unstable shr kernel  an couldnt usb network
Feb 27 04:16:12 <slaxxer> crapload of linking  going on in opkg upgrade on shr-u
Feb 27 04:17:08 <slaxxer> busybox
Feb 27 04:29:03 <DocScrutinizer> yeah, and if you haven't the top current build, messybox will bork your system
Feb 27 04:29:59 <slaxxer> _
Feb 27 04:30:28 <slaxxer> i did have
Feb 27 04:30:41 <DocScrutinizer> cool
Feb 27 04:30:51 <slaxxer> well the latest .jffs2
Feb 27 04:31:23 <slaxxer> gsm seems to fail
Feb 27 04:32:04 <DocScrutinizer> [2010-02-27 01:15:15] <alexxy> it cannot register to network
Feb 27 04:32:05 <DocScrutinizer> [2010-02-27 01:15:19] <alexxy> 2010.02.27 03:13:58.398 ogsmd.modems.ti_calypso INFO     Requesting new 
Feb 27 04:32:23 <DocScrutinizer> [2010-02-27 01:15:26] <JaMa> alexxy: w8 a bit
Feb 27 04:32:25 <DocScrutinizer> [2010-02-27 01:15:54] <JaMa> alexxy: NOTE: Running task 6607 of 7034, maybe, just maybe it will be fixed after it
Feb 27 04:32:35 <slaxxer> it did connect
Feb 27 04:32:54 <slaxxer> made a call
Feb 27 04:33:37 <DocScrutinizer> well, me away
Feb 27 07:06:21 <PaulFertser> Psi: xrandr gets all of its data from X server
Feb 27 07:07:06 <Psi> ok, so i should have a look at the X video driver?
Feb 27 07:07:08 <PaulFertser> Psi: so the list of supported resolutions comes from the driver, for gta02 that's glamo
Feb 27 07:07:21 <PaulFertser> Psi: for gta01 i think that fbdev, right?
Feb 27 07:07:42 <Psi> yep
Feb 27 07:08:18 <Psi> in gta01 the lcd is on the cpu, correct?
Feb 27 07:09:56 <PaulFertser> Psi: yes
Feb 27 07:10:09 <PaulFertser> Psi: and handled by the kernel driver
Feb 27 07:10:26 <Psi> thanks
Feb 27 07:10:48 <PaulFertser> Psi: let me try to find a bit more valueable info.
Feb 27 07:11:58 <Psi> thanks
Feb 27 07:19:15 <DocScrutinizer> mooo
Feb 27 07:21:02 <PaulFertser> Psi: from skimming the code it looks like you can define video modes you want the usual way in xorg.conf and fbdevhw helper will try to convert them to fb notation and issue appropriate ioctls to ask kernel driver for a switch.
Feb 27 07:21:06 <PaulFertser> ^)
Feb 27 07:21:09 <PaulFertser> DocScrutinizer: boo
Feb 27 07:21:20 * DocScrutinizer ponders what kinds of kinky hacks you could do by enabling video second function on gta02 :-P
Feb 27 07:21:25 <DocScrutinizer> SoC
Feb 27 07:23:09 * DocScrutinizer needs coffee and all the other chemicals it seems
Feb 27 07:24:16 * PaulFertser too
Feb 27 07:32:08 <DocScrutinizer> PaulFertser: check maemo, raster flaming the omap opengl :-)
Feb 27 07:32:25 <PaulFertser> DocScrutinizer: nice, thanks!
Feb 27 07:49:54 <PaulFertser> raster: so are you going to report GL bugs at theirs (maemo.org) bugtracker? ;)
Feb 27 08:14:18 <Psi> PaulFertser: thanks
Feb 27 08:15:08 <PaulFertser> Psi: did it help?
Feb 27 08:15:19 <Psi> it did yes
Feb 27 08:15:40 <Psi> i didnt really understand much of how it worked before
Feb 27 08:15:42 <Psi> now i do :)
Feb 27 08:16:24 <PaulFertser> Psi: i mean have you tried adding modelines and if they appeared in xrandr list? 
Feb 27 08:16:27 <PaulFertser> :)
Feb 27 08:16:48 <Psi> ive never had 240x320 appear in the xrandr list
Feb 27 08:17:10 <PaulFertser> Psi: even after adding a modeline?
Feb 27 08:17:23 <PaulFertser> I might try to research more if that's the case.
Feb 27 08:17:48 <Psi> i played with fbset a bit
Feb 27 08:18:03 <Psi> and got it to change modes, but never found the right settings to get 240x320 working
Feb 27 08:18:46 <PaulFertser> Psi: did you get anything close to working? 
Feb 27 08:20:15 <Psi> think i have a pic somewhere of what i got
Feb 27 08:22:39 <Psi> http://psi.abcom.co.nz/qvga.jpg
Feb 27 08:23:12 <Psi> dont actually think its qvga at all, thats just what i got
Feb 27 08:23:21 <Psi> looks lower res than qvga
Feb 27 08:33:50 <PaulFertser> Psi: there might be a bug in kernel driver. Or you just used wrong fb.modes parameters. Also if X is unaware (because the mode was switched behind its back) it doesn't update framebuffer appropriately.
Feb 27 08:39:55 <Psi> just tried again now, and this is whats its doing http://psi.abcom.co.nz/qvga2.jpg
Feb 27 08:40:50 <PaulFertser> Psi: looks almost reasonable. What's your fb.modes?
Feb 27 08:41:32 <PaulFertser> Psi: and can you try adding a modeline to X to see if it appears in xrandr?
Feb 27 08:42:03 <PaulFertser> Psi: because the testing method you use seems to me unreliable.
Feb 27 08:43:31 <Psi> http://psi.abcom.co.nz/fb.modes
Feb 27 08:44:44 <Psi> 240x320 should fit 4 app icons, since i get 16 icons at 480x640
Feb 27 08:45:12 <Psi> only 2 in the pic, so its definitly smaller than 240x320
Feb 27 08:45:58 <PaulFertser> Psi: framebuffer format might differ, so i'd say it doesn't prove anything.
Feb 27 08:47:20 <PaulFertser> Psi: try exactly the same timings as for 640x480, except for the pixelclock (the first one, make that 100000).
Feb 27 08:47:44 * DocScrutinizer recommends to have a look at LCM datasheet (jbt6k74)
Feb 27 08:48:37 <DocScrutinizer> PaulFertser: yep, exactly
Feb 27 08:48:42 <Psi> thanks i was just wondering where the datasheet for the lcd was
Feb 27 08:50:00 <PaulFertser> DocScrutinizer: i can't do that right atm, i'm at work and i'm sleepy.
Feb 27 08:50:32 <PaulFertser> DocScrutinizer: but those values i suggest are the values that seem to work on gta02.
Feb 27 08:50:55 <DocScrutinizer> yep, seem to remember...
Feb 27 08:54:10 <Psi> ok, put modeline into x.org, what else do i need to do so that xrandr can see it
Feb 27 08:55:21 <PaulFertser> Psi: i hope nothing but read Xorg log if it doesn't appear.
Feb 27 08:55:33 <PaulFertser> Psi: read and pastebin :)
Feb 27 08:55:44 <Psi> ok
Feb 27 08:56:58 <DocScrutinizer> omg, timing lines in x*.conf. Last time I had to mess with those was some 15 years ago
Feb 27 08:58:40 <Psi> hm.. thats odd
Feb 27 08:59:07 <PaulFertser> DocScrutinizer: i even fully calculated those myself reading the manual of my CRT. 
Feb 27 08:59:11 <PaulFertser> :)
Feb 27 08:59:35 <Psi> it seems to be ignoring the pixelclock line
Feb 27 08:59:54 <Psi> if i switch to qvga, then do fbset to see what mode its in, i get.. timings 40000 104 8 2 16 8 2
Feb 27 09:00:12 <Psi> but fb.modes is set to pixelclock 100000 as you suggested
Feb 27 09:03:23 <Psi> yep fbset seems to be totally ignoring fb.modes
Feb 27 09:04:47 <Psi> mode "240x320-204"  no idea where its getting that mode from
Feb 27 09:04:56 <Psi> no mode called that in fb.modes at all
Feb 27 09:06:35 <DocScrutinizer> PaulFertser: I had to do that as well, back 199x with that friggin cyrruslogic(?) gac
Feb 27 09:07:08 <DocScrutinizer> or video7?
Feb 27 09:07:20 <DocScrutinizer> freudian amnesia
Feb 27 09:12:02 <PaulFertser> Psi: there shouldn't be "pixelclock" line. Pixelclock is the first number in "timings" line.
Feb 27 09:12:16 <Psi> yeah, i meant the first value in the line
Feb 27 09:12:41 <Psi> its looking like fbset is ignoring whatever values are in fb.modes or even if you give it the values by hand "fbset -g 240 320 240 320 16 -t 100000 104 8 2 16 8 2"
Feb 27 09:13:26 <PaulFertser> Psi: it's more like kernel fb driver ignoring them i'd say.
Feb 27 09:13:34 <Psi> ok, yeah, something is
Feb 27 09:14:13 <Psi> "timings 40000 104 8 2 16 8 2" is what it keeps doing, no matter what i tell it
Feb 27 09:19:05 <Psi> ok, were do i find the fbdev source
Feb 27 09:24:52 <Psi> nevermind, found it
Feb 27 09:27:22 <DocScrutinizer> I guess if fb driver is choking on just one of the values, it either defaults to a sane preset, or results from the rather wicked calculations done to get actual register settings and checking ranges are resulting in really weird settings once one value is out of bounds
Feb 27 09:28:23 <Psi> whats the 204 mean in "mode "240x320-204""
Feb 27 09:29:10 <DocScrutinizer> noooooo idea
Feb 27 09:29:22 <DocScrutinizer> vesa mode number maybe?
Feb 27 09:29:29 <Psi> could be
Feb 27 09:29:46 <Psi> oh, its Vertical hz
Feb 27 09:29:55 <DocScrutinizer> huh?
Feb 27 09:29:58 <Psi>  D: 25.000 MHz, H: 69.444 kHz, V: 204.248 Hz
Feb 27 09:30:00 <DocScrutinizer> 204Hz??
Feb 27 09:30:00 <larsc> 10000000/40000 rounded to the nearest available clock frequency
Feb 27 09:30:45 <DocScrutinizer> so quit eobviously that's WAY off from what LCM can sync to
Feb 27 09:30:59 <Psi> http://pastebin.com/GuirUbN9
Feb 27 09:31:04 <Psi> thats what it defaults to
Feb 27 09:31:25 <Psi> yeah, id not noticed it before
Feb 27 09:31:35 <Psi> what kind of person sets a default to 204hz :P
Feb 27 09:31:53 <Psi> obviously some kind of calculation that has gone wrong :)
Feb 27 09:32:07 <Psi> alteast this is a good starting point
Feb 27 09:32:23 <Psi> figure out where thats coming from and change it :)
Feb 27 09:32:42 <larsc> hm... i did calculate the right values once, wondering why they didn't make it to the source...
Feb 27 09:33:42 <DocScrutinizer> let's see - the LCM has 480*640, no matter if standing on the heaad or flying to the moon
Feb 27 09:33:56 <Weiss> mmmm.... MoonMoko...
Feb 27 09:34:02 <DocScrutinizer> means for 240*xxx you need to doublescan
Feb 27 09:35:03 <DocScrutinizer> or switch jbt6k74 mode to fill drive two rows with one shiftregister content concurrently
Feb 27 09:35:04 <Psi> maybe thats the error, 40000 should be 80000
Feb 27 09:35:23 <DocScrutinizer> I'd guess 20000
Feb 27 09:35:40 <Psi> Paul said on gta02 100000 works best for qvga
Feb 27 09:35:53 <DocScrutinizer> as you effectively do a 480*320
Feb 27 09:36:28 <DocScrutinizer> gta02 has glamo. No idea how they relate to each other
Feb 27 09:36:34 <Psi> true
Feb 27 09:38:35 <DocScrutinizer> then on a deeper thought the shiftregister in jbt6k is clocked by pixelclock. So - unlike for a crt or composite video - you can't strech one pixel to double length by halving the pixel clock
Feb 27 09:40:19 <DocScrutinizer> actually, by pixclk, hsync and vsync, the LCM is quite solidely hardwired to the framebuffer wrt resolution. Means any changes in timing shouldn't change the resolution at all
Feb 27 09:41:09 <PaulFertser> Psi: that's just what radek found by experimentation. With lower pixelclock colors were way off.
Feb 27 09:41:10 <DocScrutinizer> so the fb driver probably does some rather nasty "magic" to estimate what user wants to set, and what the real fb hw config should be for this
Feb 27 09:42:19 <Psi> hm.. sounds like we need some new magic for it
Feb 27 09:43:10 <Psi> the comment line fbset gives ... # D: 25.000 MHz, H: 69.444 kHz, V: 204.248 Hz
Feb 27 09:43:19 <Psi> do you think its actually calculating that out
Feb 27 09:43:28 <DocScrutinizer> 240*320 basically means the SoC has to provide the same signal timing to LCM, but increment pixel pointer counter on every second pxclk only, and increment linecounter pointer on every second hsync only
Feb 27 09:43:54 <Psi> that makes sense
Feb 27 09:48:38 <DocScrutinizer> o course except if there's a special mode switch inside jbt6k74 to implement that pixel doubling X and/or Y
Feb 27 09:51:04 <Psi> are all these dev_dbg calls() im seeing just the debug messages?
Feb 27 09:59:52 <Psi> intersting, if i dont touch fbset at all, and just switch between qvga-normal and normal in /spi0.0/state i get a much better 240x320 picture
Feb 27 10:00:25 <Psi> ie, if i go fbset, it reports being in normal 480x640 mode, but the lcd is at 240x320
Feb 27 10:00:38 <Psi> its not perfect, color is all washed out, but its definitly 320x240 mode
Feb 27 10:02:40 <Psi> http://psi.abcom.co.nz/qvga3.jpg
Feb 27 10:02:41 <DocScrutinizer> what I say - the timing shouldn't matter for the resolution at all. At least if it's really just timing for the fb driver
Feb 27 10:02:47 <PaulFertser> Psi: oh, i've forgotten about that shit :(
Feb 27 10:03:01 <PaulFertser> Psi: sorry. Of course one needs to also set jbt mode to qvga-normal.
Feb 27 10:03:11 <PaulFertser> Psi: exactly with that trick.
Feb 27 10:03:41 <Psi> that last pic is the best ive ever had it
Feb 27 10:03:53 <PaulFertser> Psi: and washed out colors are exactly what was solved by bigger pixelclock.
Feb 27 10:04:43 <Psi> not sure why there is a horizontally stripped gray background tho
Feb 27 10:04:48 <Psi> background is black
Feb 27 10:05:11 <Psi> *striped
Feb 27 10:09:38 <Psi> its still totally ignoring my attempts to set the pixelclock tho
Feb 27 10:10:00 <Psi> i can see it flicker, so its updating, just not with the value i supply
Feb 27 10:15:55 <Psi> there look to be two s3c fb drivers.
Feb 27 10:16:07 <Psi> linux/drivers/video/s3c-fb.c  Copyright 2008 Openmoko Inc.
Feb 27 10:16:17 <Psi> linux/drivers/video/s3c2410fb.c Copyright (c) 2004,2005 Arnaud Patard
Feb 27 10:16:52 <Psi> fbset -i reports "Name        : s3c2410fb"
Feb 27 10:16:59 <Psi> is that right?
Feb 27 10:17:39 <Psi> i would have expected it to be using the newer openmoko one
Feb 27 10:29:23 <DocScrutinizer> modinfo ?
Feb 27 10:30:30 <Psi> ?
Feb 27 10:30:44 <Psi> think its compiled into kernel
Feb 27 10:31:03 <Psi> dont see it in lsmod
Feb 27 10:31:24 <DocScrutinizer> ahh yep
Feb 27 10:32:29 <Psi> i did find in the source
Feb 27 10:32:29 <Psi> var->xres_virtual = display->xres;
Feb 27 10:32:30 <Psi> var->yres_virtual = display->yres;
Feb 27 10:32:31 <DocScrutinizer> aren't the dbg prints showing up in dmesg or somewhere?
Feb 27 10:33:14 <Psi> which looks to set x and y to 480x640 no matter what you set
Feb 27 10:33:27 <Psi> as we expected
Feb 27 10:34:12 <Psi> dbg is fine
Feb 27 10:35:03 <Psi> i was only asking about dev_dbg before because im not use to reading linux C
Feb 27 10:36:04 <DocScrutinizer> so I guess the both drivers have unique dbg_prints to tell when/if the code is running
Feb 27 10:37:39 <Psi> there are no dev_dbg in s3c2410fb.c
Feb 27 10:37:51 <Psi> plenty in the openmoko one, s3c-fb.c
Feb 27 10:38:08 <Psi> both have dev_err 
Feb 27 10:38:54 <PBeck> hi
Feb 27 10:39:14 <DocScrutinizer> moin
Feb 27 10:39:57 <PBeck> hey DocScrutinizer 
Feb 27 15:27:31 <johngay> Good moorings bouys and gulls.
Feb 27 15:38:39 <johngay> Anyone here use qtmoko or H:1?
Feb 27 15:39:11 <badcloud> johngay: used to, both actually
Feb 27 15:39:15 <badcloud> v14 for qt
Feb 27 15:39:28 <badcloud> rc4 for H1
Feb 27 15:39:35 <badcloud> (the one before Chuck?)
Feb 27 15:39:37 <badcloud> why?
Feb 27 15:39:55 <johngay> But you don't have ant BT devices, right?
Feb 27 15:40:39 <badcloud> I do
Feb 27 15:40:43 <badcloud> pocket kbd
Feb 27 15:40:59 <johngay> I'm running chuck right now. my BT keyboard works great, as you can see, but my headset has no sound?
Feb 27 15:41:26 <badcloud> haven't delved much into the realm of bt sound yet
Feb 27 15:41:26 <badcloud> sorry
Feb 27 15:41:40 <badcloud> ask around s'more, I'm sure someone will be able to help
Feb 27 15:42:11 <johngay> I'm interested in tryin' qt again but I'm very attached to my BT keyboard.
Feb 27 15:42:25 <badcloud> do you have an usd card?
Feb 27 15:42:38 <badcloud> you could just dbl boot
Feb 27 15:43:33 <johngay> Thinking about that. qtmoko need qi to boot from SDCard, but if I flash qtmoko to my phone, I can keep H:1 on my SDCard
Feb 27 15:44:36 <johngay> Lately, though I've heard there are issues with the kernel for qtmoko. The debug kernel works great, but is slow, the non-debug kernel is fast, but flaky?
Feb 27 15:45:14 <badcloud> woudn't know. I stopped using qt after v14
Feb 27 15:45:19 <badcloud> and never used the debug knl
Feb 27 15:45:42 <badcloud> on my way out
Feb 27 15:45:48 <badcloud> good luck with all that
Feb 27 15:45:55 <johngay> Thanx!
Feb 27 15:47:18 <PaulFertser> badcloud: in fact you've always used the debug kernel.
Feb 27 16:08:45 <badcloud> PaulFertser: touche :P
Feb 27 16:09:20 <badcloud> ignorance is bliss
Feb 27 16:09:45 <PaulFertser> hehe
Feb 27 16:09:58 <johngay> that's why I'm in a constant state of orgasmic bliss.
Feb 27 16:21:39 <badcloud> :)
Feb 27 16:22:00 <badcloud> finally leaving
Feb 27 16:22:15 * badcloud *preeeows*
Feb 27 19:56:02 <Graf_Ithaka> hi there.. I've got a fresh install of shr and now I'm stuck changing the height of the dropdown-menus (GtkComboBox?) in the gtk-theme.. I've already succeeded in changing it for the scrollbar - any ideas?
Feb 27 22:05:14 <lfs> hello
Feb 27 22:05:39 <lfs> when is openmoko gonna get cheap enough for me to buy/
Feb 27 22:05:42 <lfs> ?
Feb 27 22:13:51 <slaxxer> ebay man
**** ENDING LOGGING AT Sun Feb 28 02:59:57 2010