[00:00] <bryce> a couple more comments...  http://bryceharrington.org/drupal/node/31#comment-6
[00:00] <bryce> I'm suspecting some sort of drm issue
[00:15] <inuka> bryce, do you now what kerenel image your testing against, I am getting errors pointing to a bad kernel driver
[00:15] <bryce> 2.6.24-4-lpia
[00:15] <bryce> built Mon 14 17:33:18
[00:21] <inuka> bryce, I have the same, but I do not see the behavior you experienced. 
[00:21] <bryce> tell me what you are seeing?
[00:29] <inuka> bryce: I see Failed to load module "psb" (module requirement mismatch, 0 )
[00:40] <GrueMaster> If someone would kindly help me get a Hardy snapshot going, I can start looking at the video driver issues.
[00:40] <amitk> inuka: can you elaborate the kernel-drivers in hardy being bad?
[00:41] <inuka> amitk,I am not sure about it yet, I am trying to recompile the psb kernel modules against the ubuntu kernel
[00:42] <amitk> inuka: the modules are already present in linux-ubuntu-modules. Are you saying they are broken?
[00:43] <inuka> amitk, I am not sure it definitely it does not work against the packages bryce created. His packages work against the moblin kernel and corresponding kernel driver
[00:45] <amitk> inuka: we can do a diff between the source in psb-kmd and the one in lum. You can clone LUM from git://kernel.ubuntu.com/ubuntu/ubuntu-hardy-lum.git
[00:46] <inuka> amitk thanks.
[00:47] <GrueMaster> Am I being filtered?  If someone would help me get MIC to generate an Ubuntu-Hardy snapshot, I can start troubleshooting the PSB Video driver issues.
[00:49] <StevenK> GrueMaster: Yes, I can help you.
[00:49] <amitk> GrueMaster: what help do you need? do you have MIC installed from the hardy repo?
[00:49] <amitk> inuka: diff -ur psb-kmd/ ubuntu-hardy-lum/ubuntu/media/drm-poulsbo/
[00:49] <GrueMaster> I pull a daily MIC snapshot from moblin.org git tree.
[00:50] <StevenK> GrueMaster: Ah, you'll need to make a change to the menlow base.fset
[00:50] <GrueMaster> ok
[00:50] <StevenK> GrueMaster: Moblin has the package called xf86-video-psb, whereas in Ubuntu it's called xserver-xorg-video-psb.
[00:51] <GrueMaster> I wasn't aware that Ubuntu had changed the name.
[00:52] <StevenK> We hadn't changed it, it's always been called that in Ubuntu. I thought, anyway.
[00:52] <GrueMaster> There are multiple packages.  Are you referring to the open source or closed source package?
[00:52] <StevenK> I'm unsure about that, sorry.
[00:53] <bryce> Debian calls X drivers "xserver-xorg-*" rather than "xf86-*".  I do not know why.  But we've always followed their lead in the naming.
[00:53] <GrueMaster> irrelevant to me anyways.  I am working on driver integration testing, so what I have is newer than public.  I just need a working ubuntu snapshot.
[00:54] <GrueMaster> I can get it renamed I think.  I'll ask.
[00:56] <GrueMaster> At any rate...
[00:56] <GrueMaster> What I'm getting is apt-get failures.  First it was the kernel, now it's gnome related.
[00:57] <GrueMaster> And at this point, I must leave.  It's almost 5pm and I have to be somewhere else at 6pm.
[00:57] <GrueMaster> bye.
[01:04] <amitk> inuka: anything?
[01:05] <inuka> amitk, I am getting compiler errors compiling against 2.6.24 headers....
[01:06] <amitk> inuka: can you paste those errors into a pastebin
[01:07] <inuka> 5: error: missing binary operator before token "("
[01:07] <inuka> In file included from /usr/src/psb-kmd/i810_drv.c:35:
[01:07] <inuka> /usr/src/psb-kmd/i810_drm.h:166: error: expected specifier-qualifier-list before 'drm_clip_rect_t'
[01:07] <inuka> In file included from /usr/src/psb-kmd/i810_drv.c:36:
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.h:80: error: expected specifier-qualifier-list before 'drm_map_t'
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.h:118: error: expected ')' before '*' token
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.h:119: error: expected ')' before '*' token
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.h:122: error: expected ')' before '*' token
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.h:123: error: expected ')' before '*' token
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.h:124: error: expected ')' before '*' token
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.h:126: error: expected ')' before '*' token
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.h:128: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'i810_ioctls'
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.c:51: error: 'i810_driver_lastclose' undeclared here (not in a function)
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.c:52: error: 'i810_driver_preclose' undeclared here (not in a function)
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.c:53: error: 'i810_driver_device_is_agp' undeclared here (not in a function)
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.c:54: error: 'i810_driver_reclaim_buffers_locked' undeclared here (not in a function)
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.c:55: error: 'i810_driver_dma_quiescent' undeclared here (not in a function)
[01:07] <inuka> /usr/src/psb-kmd/i810_drv.c:58: error: 'i810_ioctls' undeclared here (not in a function)
[01:08] <mjg59> Sounds like you're trying to build against the wrong DRM
[01:09] <bryce> hi mjg59
[01:10] <inuka> mjg59, your right nothing to do with the kernel headers...... let me try and install bryce's drm dev debs
[01:10] <bryce> inuka: yeah if you don't have that libdrm-dev snapshot installed, that could cause the compilation issues with -psb
[01:11] <bryce> inuka: however it shouldn't matter for compiling the kernel
[01:12] <inuka> bryce, I am recompiling the driver against the hardy kernel.... to make sure the kernel driver is correct or if it is something else
[01:12] <bryce> gotcha
[01:13] <bryce> in that case I don't think my libdrm2 package is involved
[01:15] <inuka> I am trying to compile it against the dev package of the libdrm2 you produced
[01:15] <mjg59> Yes, I don't believe PSB will compile against the in-kernel drm
[01:16] <inuka> yes it wont, doesnot seem to like the updated one either, I am going to try the one in moblin
[01:18] <bryce> amitk: dunno if this is important, but looking at the startup log on Mithrandir's image, I see an error:
[01:18] <bryce> * Setting kernel variables...
[01:18] <bryce> error: "vm.mmap_min_addr" is an unknown key     [fail]
[01:19] <StevenK> I don't think it is.
[01:19] <mjg59> Yeah, don't worry about that
[01:24] <bryce> mjg59: I've posted my troubleshooting log at http://bryceharrington.org/drupal/node/31, woefully unsuccessful though it is...  do you have any thoughts or tips on further steps I could take?
[01:25] <bryce> unfortunately I can't get networking going on it, so running gdb against it is difficult
[01:26] <amitk> bryce: as soon as you modprobe psb, the screen blanks out. Since I tried this an Xterm, Ctrl-Alt-Bksp killed X and gave me a tty console at a weird resolution. Is this what you see too?
[01:27] <mjg59> amitk: Loading drm modules inside X is likely to result in badness
[01:27] <bryce> yeah
[01:27] <bryce> actually I tried it without X running, but saw similar
[01:27] <mjg59> Some potential for them to beat on registers that X has set
[01:27] <mjg59> bryce: Mount / -o sync
[01:27] <mjg59> That way you'll get more xorg.log
[01:28] <amitk> mjg59: true. I think they do a good job of clobbering the regs :)
[01:28] <bryce> mjg59: ahh thanks
[01:28] <mjg59> Does -psb run without drm? Or is drm a dependency?
[01:28] <mjg59> (I know we're moving to a model where drm is needed)
[01:28] <bryce> amitk: however before it restarted, I saw three error messages written.  Unfortunately the screen blanked before I could read them
[01:29] <bryce> mjg59: afaik it's required
[01:29] <amitk> mjg59: drm is a dep
[01:30] <amitk> mjg59: this drm is something very close to git HEAD though. The in-kernel one has been turned off on LPIA.
[01:31] <bryce> amitk: interesting; starting X after doing modprobe psb causes a black screen (not power saving mode)
[01:33] <amitk> yeah
[01:33] <bryce> it let me ctrl-alt-backspace too, which it hadn't allowed before
[01:33] <amitk> bryce: I caught glimpse of that error. It looks very very familiar. I'm gonna try to get a picture here. Something related to MSVDXblah.
[01:35] <bryce> amitk: since this isn't using /etc/fstab to control mounting, where does / get mounted?
[01:37] <inuka> I managed to recompile the kerne driver will see if that changes anything.... 
[01:37] <mjg59> amitk: When building, I suspect there's a chance stuff will still end up trying to link against the kernel headers unless you're careful
[01:38] <alek_desk> bryce, the root got mounted in initrd
[01:40] <bryce> fwiw, I see an error, "mount: "Mounting /dev/sda1 on /container failed: No such file or directory"
[01:40] <bryce> I suppose that's non-fatal though
[01:41] <amitk> mjg59: I will check that out. We did not have this problem in Gutsy though...
[01:42] <amitk> bryce: inuka: modprobe psb throws a error about msvdx_fw.bin not present blah foo. Is this being powered by a PowerVR?
[01:42] <mjg59> PSB is PowerVR MBX
[01:42] <mjg59> With custom 2D modesetting, I think
[01:43] <amitk> no wonder it sounded familiar
[01:43] <inuka> yes, and it shows that error normally
[01:43] <amitk> inuka: is this related to the 3d driver?
[01:43] <amitk> the error I mean
[01:44] <bryce> amitk: not sure
[01:44] <inuka> amitk, no it does not , it is shown in the log even when things work correctly
[01:47] <amitk> bryce: mjg59: in any event, modprobe psb shouldn't do what it is doing, correct? So things are pretty messed up before the X psb driver kicks in.
[01:48] <bryce> yeah it looks bad
[01:48] <mjg59> Yeah
[01:49] <mjg59> It's not immediately obvious to me how that could have anything to do with our kernel or drm
[01:49] <mjg59> It sounds like it's entirely in psb
[02:00] <bryce> mjg59: unfortunately, adding -o sync doesn't seem to have changed the amount of stuff logged in Xorg.0.log...  It still ends right after the drm bits
[02:00] <bryce> unless I've done the sync option incorrectly (trying to verify)
[02:01] <bryce> last line is "(II) [drm] Irq handler installed for IRQ 17."
[02:03] <mjg59> bryce: There may not be any further output before it hangs, then
[02:04]  * bryce nods
[02:04] <bryce> next...  digging in driver source
[02:17] <amitk> inuka: in psb-kmd/Makefile.kernel, drm_ioc32.o is conditionally included if CONFIG_COMPAT is defined. Does the moblin kernel define it? We don't.
[02:18] <mjg59> amitk: Is that just the 64-32 bit compatibility layer? If so, it shouldn't be needed on lpia
[02:19] <amitk> mjg59: that's what it is.
[02:20] <mjg59> (lpia is 32 bit, right?)
[02:20] <amitk> correct
[02:20] <mjg59> Right. Yeah, it should just be needed on 64-bit architectures
[02:26] <bryce> a bit more progress after spelunking through the X driver...  http://bryceharrington.org/drupal/node/31#comment-11
[02:26]  * bryce -> dinner.  bbl
[07:56] <dholbach> good morning
[07:57] <Mithrandir> hiya Daniel
[08:00] <dholbach> heya Tollef
[09:51]  * Mithrandir kicks the psb driver
[12:31]  * Mithrandir wonders what to do in order to make the hardy build work right, graphics-wise.
[12:39] <Mithrandir> alek_desk: there's no reason for you guys to have a kernel-mid binary package; apt-get source will look for source packages if no binary package matches.
[12:43] <amitk> Mithrandir: I might have a fix for networking, could you try building the latest commit to the hardy tree.
[12:44] <amitk> Mithrandir: I am building now, but it takes time
[13:01] <Mithrandir> amitk: sure, will do.  I got distracted for a minute here
[13:22] <Mithrandir> meh, almost 20 minutes to build a kernel. :-/
[13:22] <Mithrandir> I'll try it once I have tested this stuff
[13:34] <Mithrandir> amitk: loading the moblin.org psb driver seems to initialise the framebuffer
[13:34] <Mithrandir> as in, I then get a 1280x1024 framebuffer console.
[13:51] <Mithrandir> amitk: you win!  Thanks.
[13:51] <Mithrandir> amitk: as in, works, and I can ping something.
[14:00] <Mithrandir> bryce: would (EE) PSB: Failed to load module "Xpsb" (module does not exist, 0)
[14:00] <Mithrandir> explain anything?
[14:11] <amitk> Mithrandir: Are you compiling the moblin kernel driver against our headers?
[14:11] <Mithrandir> amitk: that was just pulling in their binaries.
[14:11] <Mithrandir> (if you're referring to the framebuffer thing)
[14:12] <amitk> Mithrandir: yes. How do you check the framebuffer resolution? We too get a high-res framebuffer console.
[14:13] <Mithrandir> amitk: it looked native on my 1280x1024 screen. :-)
[14:13] <Mithrandir> I could be wrong, of course, but it looked right.
[14:14] <amitk> Mithrandir: ohh ok. :) Have you tried modprobe psb with the Ubuntu module? It too gives a high-res console after blacking out at first
[14:15] <Mithrandir> will try
[14:16] <alek_desk> Mithrandir, got it. the kernel-mid is an empty binary package.
[14:16] <Mithrandir> alek_desk: yeah, I noticed.  Just wanted to tell you since you were listed as the maintainer
[14:16] <Mithrandir> it's not actively harmful, just useless.
[14:17] <alek_desk> Mithrandir, thanks. :)
[14:17] <Mithrandir> amitk: indeed, our psb.ko gives the same result.
[14:17] <Mithrandir> now I wonder where I can find a module that answers to the name "Xpsb"
[14:17] <alek_desk> Mithrandir , I know the 1280x1024 issue
[14:18] <alek_desk> you need build the drivers/acpi/video module
[14:18] <Mithrandir> as in, what's the problem you're seeing?
[14:18] <mjg59> ?
[14:18] <amitk> alek_desk: what is the 'issue'?
[14:18] <Mithrandir> I have a just fine 1280x1024 framebuffer console.
[14:19] <alek_desk> Mithrandir, Moblin hildon desktop assume a 1024x768 and 800x600 resolution by default
[14:20] <Mithrandir> alek_desk: oh, but my display actually is 1280x1024, so it shouldn't blow up, should it?
[14:21] <alek_desk> psb-kmd will set the screen to 1280x1024 if could not detect LVDS pannel
[14:21] <mjg59> alek_desk: The ACPI video extension doesn't support resolution setting. How does drivers/acpi/video help?
[14:21] <mjg59> Oh, I see
[14:21] <alek_desk> the psb-kmd module will detect /proc/acpi/video
[14:21] <mjg59> ...
[14:21] <mjg59> That sounds kind of wrong
[14:21] <alek_desk> :(
[14:22] <Mithrandir> it seems to just hang in (II) PSB(0): Locking DRI for screen
[14:22] <mjg59> Let me take a look at the code for this
[14:22] <Mithrandir> and I can't attach with gdb
[14:22] <alek_desk> the video extension has something to do with the LVDS interface
[14:22] <alek_desk> psb-kmd support both LVDS and SDVO RGB output
[14:23] <alek_desk> LVDS resolution is 1024x768 while SDVO resolution is 1280x1024 by max
[14:24] <smagoun> Mithrandir: do you have Intel's libdrm?
[14:24] <Mithrandir> smagoun: I have what I got from bryce.  I could test with libdrm from moblin.
[14:24] <smagoun> Mithrandir: also, at one point you had to add the following to xorg.conf: Section "DRI" Mode 0666 EndSection . Not sure it's still necessary, but might be worth a shot?
[14:25] <alek_desk> amitk, I guess you did not enable CONFIG_ACPI_VIDEO?
[14:25] <amitk> alek_desk: We have it enabled, IIRC.
[14:25]  * amitk checks
[14:25] <mjg59> Hm. Where does the psb-kmod code live? I can't find it in the moblin git, but maybe I'm looking in the wrong place
[14:26] <amitk> amit@amit-laptop - (..sources/ubuntu-hardy) $ grep CONFIG_ACPI_VIDEO debian/binary-custom.d/lpia/config.lpia
[14:26] <amitk> CONFIG_ACPI_VIDEO=m
[14:26] <alek_desk> mjg59 http://moblin.org/repos/projects/psb-kmd.git
[14:26] <smagoun> mjg59: It's in the psb-kmd git tree at moblin
[14:26] <alek_desk> amitk, ok.
[14:27] <mjg59> Ah - it's not linked from the browser
[14:27] <alek_desk> mjg59, yes. it is a secret :)
[14:28] <amitk> alek_desk: I live for secrets on public IRC channels ;)
[14:29] <alek_desk> amitk, LOL
[14:29] <mjg59> alek_desk: http://moblin.org/repos/?p=projects/kernel-mid-2.6.24.git;a=blob;f=debian/patches/thermals-ext-acpi_video.dpatch;h=9539cec3a250baaaf1acab3c06e49dd4b4e54dad;hb=26b8b6eadf0651726500360d3e639128512a1e0c - are you sure this patch is named correctly?
[14:29] <mjg59> The only thermal related bit is the addition of a structure to the backlight class, and there's various other bits in there
[14:30] <alek_desk> mjg59, we have no chance to test thermal at all -- it needs a special CRB board
[14:31] <mjg59> alek_desk: Right, but the patch still seems wrong
[14:31] <alek_desk> mjg59, well. we need to trace it back to 2.6.22 kernel.
[14:32] <alek_desk> to check if it is a porting error or original error
[14:32] <mjg59> alek_desk: The get_brightness_levels() code isn't upstream (and really shouldn't be necessary), but it's nothing to do with thermal code so should be in a separate patch
[14:34] <mjg59> alek_desk: My reading of the psb code is that it'll do the ACPI validation itself - it shouldn't need the video.ko module?
[14:35] <mjg59> It's executing _DOD natively rather than calling out to a separate module
[14:35] <alek_desk> mjg59, do you mean get_brightness_levels will never get called ?
[14:35] <mjg59> alek_desk: No, I mean it's nothing to do with thermal code
[14:35] <mjg59> The only thing it does is present a sysfs node
[14:35] <mjg59> Whereas what we should be doing is flattening the list of backlight values that acpi gives us (I've sent a patch to Len to do that)
[14:37] <alek_desk> CONFIG_ACPI_VIDEO depends on CONFIG_VIDEO_OUTPUT_CONTROL, I guess psb-kmd read /proc/acpi/video to detect LVDS existence is ok.
[14:37]  * alek_desk is not sure
[14:37] <mjg59> alek_desk: No, it calls the methods itself. It doesn't use the drivers/acpi/video code at all.
[14:38] <alek_desk> mjg59, so it only check the /proc/acpi/video node?
[14:38] <mjg59> alek_desk: No, it calls the methods itself. It doesn't use the drivers/acpi/video code at all.
[14:39] <alek_desk> mjg59, I saw the code to check if /proc/acpi/video exists.
[14:39] <mjg59> alek_desk: In psb-kmd? Not that I can see.
[14:40] <alek_desk> if you insert video.ko before loading psb-kmd, the screen get initialized to 1024x768 by default
[14:40] <mjg59> If it is doing that, it's doing it wrong
[14:40] <mjg59> Since the module executes the methods itself
[14:40] <alek_desk> mjg59, yes. I see the code.
[14:40] <Mithrandir> amitk: uploading to the ppa now.
[14:41] <mjg59> alek_desk: See the code in intel_lvds.c 
[14:41] <mjg59> intel_get_acpi_dod() will get the list of devices and walk them
[14:41] <alek_desk> mjg59, yes.
[14:41] <mjg59> That doesn't need the video module
[14:42] <alek_desk> mjg59, wait.
[14:53] <alek_desk> mjg59, I may miss the point. But if you could do the test -- insert video module before loading psb-kmd module, you would find the difference.
[14:53] <mjg59> alek_desk: I don't have PSB hardware at the moment. But if that's the case, there's a bug.
[14:53] <mjg59> Since psb-kmd never calls anything in the acpi video module
[14:55] <alek_desk> mjg59, if you run xrandr on them, you will find one report LVDS and RGB, another only report RGB
[14:55] <mjg59> alek_desk: Then there's a bug in psb-kmd.
[14:56] <mjg59> How do we reliably ensure that the acpi video module has started before loading psb-kmd?
[14:56] <mjg59> psb-kmd needs to either declare an explicit dependency on the acpi video driver and then use its functions rather than its own, or it needs to do whatever setup is missing itself
[14:56] <mjg59> I think the former is the better plan
[14:57] <alek_desk> mjg59 there is a module parameter ignore_acpi seems could cut the relation.
[14:58] <mjg59> alek_desk: No, it clearly wants to use the acpi functions
[14:59] <mjg59> Otherwise we can't tell whether there's an LVDS or not
[15:00] <alek_desk> mjg59, currently most our CRB boards are not connected with LVDS, but psb-kmd will report they are connected
[15:00] <alek_desk> most CRB are using SDVO
[15:00] <mjg59> alek_desk: Right, but it still needs fixing
[15:01] <alek_desk> mjg59, agree.
[15:01] <mjg59> I'll look at this next week
[16:12] <bryce> Mithrandir, I believe the Xpsb error is a red herring - http://bryceharrington.org/drupal/node/31#comment-5
[16:12] <Mithrandir> bryce: yeah, seems to be.
[16:12] <Mithrandir> it's still stuck in acquiring the DRI lock, though
[16:16] <bryce> hrm.  Do you have a new img I could mess with today?  (I'm still having trouble getting image-creator to build imgs)
[16:17] <Mithrandir> grab the one from the same location as yesterday (http://err.no/tmp/menlow_full_install-usb.img)
[16:18] <Mithrandir> it's much bigger since it includes both the kernels from moblin, but no other moblin components.
[16:22] <bryce> ok cool
[17:03] <bryce> hmm, each of the 3 kernels in the image fail squashfs, leaving me at an initramfs prompt
[17:04] <bryce> c3a693eb53d710e7cf23ee0fc6654d33  menlow_full_install-usb-mithrandir3.img
[18:02] <Mithrandir> bryce: md5sum matches
[18:03] <Mithrandir> robr: you going to be on the call?  It seems the call info we have from Peter isn't working.
[18:05] <rustyl> Mithrandir, we are having problems with the room and number we scheduled
[18:05] <rustyl> Mithrandir, seems it was setup for UK time
[18:05] <Mithrandir> ah.
[18:05] <Mithrandir> that would have been pleasant. :-)
[18:06] <rustyl> getting a new number right now
[18:06] <Mithrandir> excellent, just keep us posted.
[18:06] <lool> rustyl: Yes
[18:06] <lool> rustyl: Operator confirmed this
[18:06] <robr> calamity of errors 
[18:07] <rustyl> Bridge: 5, Passcode: 3211606
[18:08] <rustyl> Mithrandir, lool ... if you call the original number but use the above bridge and passcode, then you are good
[18:10] <lool> rustyl: I tried saying hi a couple of times, but nobody seems to hear me; I tried *6 and #6 to unmute, doesn't seem to work for me
[18:10] <lool> rustyl: Could you confirm how to unmute please?
[18:10] <rustyl> ok
[18:11] <rustyl> just  a sec
[18:11] <lool> It happened last time to me as well, couldn't talk for the whole call
[18:11] <Mithrandir> I'm in now.
[18:11] <lool> Thanks *6 didn't work the first time
[18:11] <lool> But now I did hear "Unmuted"
[18:33] <mdz_> https://wiki.ubuntu.com/HardyReleaseSchedule
[18:35] <mawhalen> mdz - can you resend the link
[18:35] <mdz_> https://wiki.ubuntu.com/HardyReleaseSchedule
[18:41] <mdz_> patm: are you back on the call now?
[18:41] <patm> we are on yes
[18:41] <patm> I grabbed Steve to listen as well
[19:26] <agoliveira> bspencer_: Hi Bob. I was discussing with Ted about messing abit with the applets. The idea is to mak an alerm clock running in the home applet. Do you see any problem with that? Should I bother someone else? :)
[19:26] <bspencer_> tell me more
[19:26] <bspencer_> alarm clock simple application... or a "settings" control panel applet?
[19:27] <bspencer_> and who is Ted? :)
[19:28] <agoliveira> bspencer_: Ooops, I meant Todd
[19:29] <bspencer_> I see.   
[19:29] <agoliveira> bspencer_: The idea is to have an alarm clock just being called from the applet like you click on the time and it shows the clock or something like that.
[19:29] <bspencer_> alarm clock is interesting because if you put it in "Settings" it isn't a perfect fit. 
[19:29] <bspencer_> in any case though it is a good idea
[19:29] <bspencer_> (wherever we put it)
[19:30] <agoliveira> bspencer_: The clock would run on the home applet thus being allt he time available if the user wants it.
[19:30] <agoliveira> bspencer_: Is there any docs you know that can help me (running something in the home appler I mean)
[19:30] <bspencer_> the rub is that currently the home screen HTML is a fill-area home applet
[19:31] <bspencer_> so unless home applets can overlap you won't be able to have both
[19:31] <bspencer_> but you could resize the HTML stuff... that woudl work
[19:31] <bspencer_> you'd probably have bugs related to background
[19:31] <agoliveira> bspencer_: Hmmm... what's rendering the html?
[19:32] <bspencer_> a mozembed home applet
[19:33] <bspencer_> where the applet size is 100% width and 100 height of home area
[19:34] <agoliveira> bspencer_: I see. Looks like my idea will be a bit more complex to implement that I thought.
[19:35] <bspencer_> sorry :(
[19:35] <bspencer_> but it may be possible to overlap applets
[19:35] <bspencer_> I haven't tried that, have you?
[19:35] <bspencer_> if that is the case then there is no problem
[19:35] <agoliveira> bspencer_: No, I didn't. I'll check this out tomorrow.
[19:35] <bspencer_> I have an N800 here now
[19:35] <bspencer_> it lets me edit the home screen layout (I just did this)
[19:36] <bspencer_> but when I say "Apply" it says:  "Some of the applets are overlapping.  Try closing or moving them"
[19:36] <agoliveira> bspencer_: Same with the 770
[19:36] <bspencer_> this may be an arbitrary restriction though, not part of the underlying home applet capabilities
[19:40] <agoliveira> bspencer_: Well, thanks a lot. I'll give it some thought tomorrow.
[19:40] <bspencer_> yep.
[19:41] <amitk> bspencer_: the new OS for N800 does not have the Edit and Apply modes. All the applets are freely draggable
[19:41] <bspencer_> amitk: interesting.  Can they overlap?
[19:42]  * amitk drags
[19:42] <amitk> bspencer_: yes. and the underlying applet shows through due to the transparency
[19:43] <bspencer_> ah, good to hear.  agoliveira ^^
[19:43] <lool> Pretty cool heh
[19:43] <bspencer_> we might be in luck then as we're using the latest hildon stuff (hopefully)
[19:44] <agoliveira> bspencer_: Ah, cool. It will give me more food to the thought (and make David nuts as will take longer :) ) but it's certanly something to look at.
[19:45]  * agoliveira -> coffee
[21:26] <amitk> Mithrandir: got a few minutes?
[21:29] <Mithrandir> sure