[00:30] <MIDIE> Amit,  I am trying to enable for the LCD Touch screen, the Touchscreen uses a penmount 6000 driver which requires USB Filesystem support in the kernel.  Do you know if this is planned to be implemented anytime soon?
[00:30] <ChickenCutlass> amitk: ping
[00:31] <amitk> ChickenCutlass: yo mike!
[00:31] <ChickenCutlass> amitk: Can you tell me what version of ACPI is supported in the kernel
[00:31] <amitk> 2.x
[00:32] <MIDIE> ah.. so thats how one gets someones attention
[00:32] <ChickenCutlass> amitk: that is what I though -- our customer is having trouble with their BIOS -- we are not getting events like battery, ac interrupts
[00:32] <ChickenCutlass> They said they are using ACPI 2.0
[00:33] <amitk> MIDIE: yes... you need to use the nickname to get the irc client to beep ;)
[00:33] <MIDIE> thanks..
[00:34] <amitk> ChickenCutlass: does this happen on Crownbeach boards too?
[00:34] <ChickenCutlass> amitk: I do not know -- there is no battery so how can I tell
[00:34] <ChickenCutlass> amitk: Is there a way to debug this
[00:35] <amitk> so its only battery and ac events?
[00:35] <amitk> ChickenCutlass: have you checked for thermal events?
[00:36] <MIDIE> There should be a Battery virtual drive supported by the BIOS
[00:36] <ChickenCutlass> amitk: also power button
[00:36] <amitk> MIDIE: identify yourself... you are from behind the Intel firewall :)
[00:37] <ChickenCutlass> amitk: how do I check thermal events
[00:37] <MIDIE> I am the MID IE and PDE for Menlow
[00:37] <MIDIE> Robert Frisbee
[00:37] <amitk> IE & PDE?
[00:37] <amitk> MIDIE: Hi Robert
[00:37] <MIDIE> Yea..  I am taking over Bond, PDE duties for menlow
[00:38] <amitk> MIDIE: What is IE and PDE? :)
[00:38] <MIDIE> IE = Integration Engineer and PDE = Product Development Engineer
[00:38] <ChickenCutlass> MIDIE: Can you tell me if there are any ACPI issues with Menlow or Poulsbo?  My customer says that the ACPI in the BIOS works just fine under XP but not Linux
[00:38] <amitk> ChickenCutlass: It exports a /sys file somewhere... And I assume is should have something in /proc/acpi as well
[00:39] <MIDIE> Which board version and BIOS version are you using. 
[00:39] <MIDIE> There are issues with the older boards and BIOS's with ACPI compliancy
[00:40] <ChickenCutlass> MIDIE: They are using a B1 stepping of the Poulsbo
[00:41] <ChickenCutlass> MIDIE: Can you be more specific about the issues - - can you think of why XP would work fine and not Linux
[00:41] <MIDIE> so that has the Silverthorne A1 running BIOS version.20 something..
[00:42] <MIDIE> Let me check my errata sheet
[00:42] <ChickenCutlass> MIDIE: thanks
[00:43] <patm> MIDIE, It is a Phoenix BIOS that they are customizing themselves
[00:44] <MIDIE> Oh.
[00:46] <MIDIE> Hmm..  If they are customizing their own BIOS, I am afraid I cannot be much help.   I would recommend them try version .54 which is available up on ARMS.  There were some issues related to ACPI that were fixed around BIOS version 46
[00:47] <MIDIE> If BIOS 54 solves there problem, then I would look at what they are trying to implement
[00:48] <MIDIE> A wild swing in the dark, I would think there might be a problem with how ACPI is identified by the OS which is causing problem
[00:48] <amitk> MIDIE: I have a Crownbeach with AMIBIOS 08.00.14. Do I need to update?
[00:48] <amitk> ChickenCutlass: could you check for the thermal events
[00:49] <ChickenCutlass> MIDIE: I tried passing the acpi_osi to Linux but that does not seem to help
[00:49] <ChickenCutlass> amitk: I can check tomorrow -- I do not have the board with me
[00:50] <MIDIE> Look at the ID string..
[00:50] <MIDIE> something like PSC0G0XX  the XX is your BIOS version
[00:51] <amitk> 44
[00:51] <MIDIE> ChickenCutlass did the Xp installation have the chipset drivers installed?
[00:51] <MIDIE> ok..  The latest BIOS is .54 some ACPI issues were fixed on version 46
[00:54] <MIDIE> amitk do you have access to ARMS?
[00:55] <amitk> MIDIE: none of us do
[00:55] <MIDIE> Hmm..
[00:55] <MIDIE> How do you usually get BIOS updates?
[00:56] <MIDIE> through Premier?
[00:57] <amitk> MIDIE: not gotten one yet
[00:57] <ChickenCutlass> MIDIE: I will have to check that
[00:57] <ChickenCutlass> MIDIE: Which drivers exactly?
[00:57] <MIDIE> Ok..  I just made sure the legal stuff was out of the way so we can post .54 to premier.  I will check with my support person to see if he has loaded them up yet.
[00:58] <MIDIE> the chipset drivers Intel® ALL OS 8.2.0.1012 PV
[00:59] <MIDIE> I know that the chipset drivers include ACPI functionality for Windows.   I am curious if the chipset team is enabling for linux and if functionality has been left out.  I am going to have to dig into this a little.
[01:01] <amitk> MIDIE: ChickenCutlass: But ACPI events should come from the BIOS, right? Chipset drivers shouldn't be required for that...
[01:01] <ChickenCutlass> amitk: that is what I thought
[01:02] <MIDIE> Yes.. For the most part.  However
[01:03] <MIDIE> I have noticed that sometimes the ACPI spec was deviated from.   For example,  I have difficulty checking processor temp and voltage without the Intel Specific tools.
[01:03] <MIDIE> to be honest,  I have not tried with Menlow and XP.
[01:04] <MIDIE> I will have to give it a looksie and see if Menlow also has a ACPI which is "customized"
[01:05] <ChickenCutlass> MIDIE: If this helps sci events are not working
[01:06] <MIDIE> gimmeasec.  I am loading Ubuntu onto my system and loading the ACPI tools.
[01:08] <MIDIE> JUST out of curiosity.  Is your BIOS set to conform to the 2.0 or 3.0 spec?
[01:08] <ChickenCutlass> 2.0
[01:09] <MIDIE> SCI events has to be enabled, It comes disabled by default
[01:10] <ChickenCutlass> oh -- how does one do that
[01:12] <MIDIE> I believe its in Advanced > acpi configuration > chipset ACPI > 
[01:13] <MIDIE> then you can enable the SCI IRQ
[01:14] <MIDIE> amitk I am trying to enable the LCD Touch screen for Crown Beach, the touchscreen that we have uses a penmount 6000 driver which requires the USB Filesystem to be supported in the Kernel.  Do you know if this is going to be implemented anytime soon,  or are you waiting to receive the LCD Kits before its enabled.
[01:14] <ChickenCutlass> MIDIE: ok -- I will look and see tomorrow if the BIOS I have actually has this option.
[01:14] <MIDIE> if it does not.  check premier for the latest BIOS.  I know .54 has the option
[01:14] <MIDIE> if your running an older BIOS, just upgrading might solve your problem
[01:15] <MIDIE> I need to play with ACPI more.  
[01:15] <ChickenCutlass> MIDIE: ok -- need to go thanks for the ideas
[01:16] <MIDIE> on the Moblin Ubuntu,  I am able to get battery states from the ACPI
[01:16] <amitk> MIDIE: You mean USB_DEVICEFS?
[01:16] <MIDIE> amitk yes
[01:17] <amitk> MIDIE: Looks like it is enabled for the lpia flavour in the Ubuntu kernel
[01:18] <MIDIE> Hmm...  wierd,  I checked under proc and it did not seem to be supported.
[01:18] <MIDIE> I will poke at it more
[01:19] <StevenK> MIDIE: The config used to build the kernel is under /boot, for digging purposes
[01:19] <MIDIE> Cool.  Thanks!  Perhaps I just need to update my version.  I am still on build 11
[01:22] <amitk> MIDIE: I just booted up my Crownbeach. cat /proc/filesystems shows usbfs
[01:23] <MIDIE> amitk ok.   I will rebuild.  I just checked, and I don't have a /proc/filesystems  /proc/fs only has nfsd
[01:24] <amitk> MIDIE: even my /proc/fs has only nfsd
[01:24] <amitk> but you need to mount the usb filesystem, right?
[01:24] <MIDIE> I don't have filesystems.  Yes. the driver for penmounts needs it
[01:27] <MIDIE> amitk yea.. Its looking for USB device filesystem but it want one to mount it from mount -t usbdevfs none /proc/bus/usb
[01:28] <amitk> MIDIE: yeah... that can be added to fstab
[06:03] <corevette> how is the project coming along?
[06:40] <dholbach> good morning
[16:57] <davidm> Just about time to start the meeting
[16:57] <Sciri> Greetings davidm.
[16:58] <davidm> hi Sciri 
[16:59] <lool> hey
[17:00] <davidm> Does anyone know if Don Johnson is joining us today?  I don't see him here
[17:00] <mawhalen> I'll check
[17:00] <davidm> thanks
[17:01] <lool> davidm: A lot of Intel folk seem to have been disconnected last hour
[17:01] <davidm> Ouch, that has happend before when their proxy died 
[17:01] <rustyl> the proxy seems to be working now
[17:02] <davidm> I'll wait a few more minutes before starting. rustyl good to hear :-)
[17:02] <rustyl> i'm behind the firewall right now
[17:02] <lool> Indeed, I see people rejoining again now
[17:02] <davidm> Ah, Don_Johnson just joined. :-)
[17:02] <Don_Johnson> Yes, I'm here.
[17:03] <davidm> OK I'll start the meeting then unless we need to wait for anyone else?
[17:03] <davidm> #startmeeting
[17:03] <MootBot> Meeting started at 17:03. The chair is davidm.
[17:03] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[17:04] <davidm> OK action items from the last meeing in order.
[17:04] <davidm> topic upload new version of hildon-desktop out of bzr 
[17:04] <davidm> closed: tfheen/lool to upload new version of hildon-desktop out of bzr (lool: Complete)
[17:05] <davidm> grumble forgot the []
[17:05] <davidm> net topic
[17:05] <lool> (unless anyone has any question on this; it's built for lpia too)
[17:05] <davidm> [topic] bspencer & horaceli to verify the ubuntu branch works and suggest changes.
[17:05] <MootBot> New Topic:  bspencer & horaceli to verify the ubuntu branch works and suggest changes. 
[17:06] <lool> They aren't around
[17:06] <lool> Postpone until end of meeting?
[17:06] <davidm> I was just noticing that.  Don_Johnson should we postpone this to the end or next meeting?
[17:06] <ToddBrandt> here
[17:06] <bfiller> any Intel guys know if bspencer will be joining?
[17:06] <cwong1_> he just joined moblin
[17:06] <Don_Johnson> I don't know if Bob will be joining.
[17:07] <cwong1_> I sent him a message to join
[17:07] <lool> I also pinged horaceli on #moblin
[17:07] <davidm> hi bspencer_ 
[17:07] <lool> 18:05 < davidm> [topic] bspencer & horaceli to verify the ubuntu branch works  and suggest changes.
[17:07] <lool> bspencer_: ^
[17:08] <bspencer_> hello. sorry for being tardy.  I'll stay after school and clean the erasers.
[17:08] <davidm> :-P
[17:08] <bspencer_> lool, thx.  We tried it and all seems ok.
[17:08] <lool> Cool
[17:08] <bfiller> is this in regards to PPA?
[17:08] <davidm> bspencer_, no changes to suggest then?
[17:08] <bspencer_> lool,  I don't have changes per say, but we have new things we might need to add soon
[17:08] <bspencer_> hildon-desktop ubuntu branch is good
[17:09] <bspencer_> we want to be able to disable the hildon-desktop banner from showning.
[17:09] <lool> bspencer_: Okay; feel free to push these and/or ask me to pull stuff from somewhere (patch or bzr branch; please not git!)
[17:09] <bspencer_> bfiller -- how are you doing that now?  Or do you just have 2 banners showing?
[17:09] <bfiller> bspencer_: two banner currently showing..
[17:09] <bspencer_> lool, right.  We'll push these into ubuntu branch and notifiy you
[17:09] <lool> bspencer_: bfiller added a gconf key allowing this to be hidden or shown
[17:09] <bspencer_> bfiller, lame
[17:09] <bspencer_> lool,  I think that was for the marquee, not the startup banner
[17:09] <Mithrandir> bspencer_: hildon-desktop banner?
[17:09] <lool> bspencer_: Ah right
[17:10] <bfiller> bspencer_: easy enough to add for banner too
[17:10] <bspencer_> Mithrandir, there is a "app starting" banner in hildon-desktop
[17:10] <bspencer_> bfiller, true.  That is a good option
[17:10] <Mithrandir> ah, that one.  Yes
[17:10] <bspencer_> Mithrandir, bfiller has a better solution for a banner.  
[17:10] <bfiller> bspencer_: I'll take the action for looking at it
[17:10] <bspencer_> bfiller, great.
 is this in regards to PPA?
[17:11] <bspencer_> this would go into both Hardy and PPA
[17:11] <bspencer_> (right ? )
[17:11] <lool> If it's useful in the PPA, which I guess is the case for bfiller, then yes
[17:12] <davidm> bfiller, is this the action item you are taking: "bfiller to for looking into  a better solution for a banner to be hidden or shown in hildon-desktop"
[17:12] <bfiller> bspencer_: have you tested latest hildon_desktop with the flash plugin home screen (as opposed to html)
[17:12] <bfiller> bspencer_: yes, correct
[17:12] <bfiller> bspencer_: seems like you can't click in flash movie in latest hildon-desktop
[17:12] <bfiller> davidm: yes
[17:13] <bspencer_> bfiller,  latest hildon-desktop means which one? 
[17:13] <bspencer_> the one in gutsy now?
[17:13] <davidm> [action] bfiller to for looking into  a better solution for a banner to be hidden or shown in hildon-desktop
[17:13] <MootBot> ACTION received:  bfiller to for looking into  a better solution for a banner to be hidden or shown in hildon-desktop 
[17:13] <bspencer_> and which mobile-basic-flash ?
[17:13]  * amitk is back
[17:13] <bfiller> bspencer_: sorry, the one in PPA and ubuntu branch on launchpad
[17:13] <lool> bspencer_: 0.43; the one in PPA or hardy
[17:13] <lool> or bzr branch
[17:14] <lool> (in *gutsy* PPA or in hardy)
[17:14] <bspencer_> bfiller,  I  didn't try with  flash.   If you are seeing problems then perhaps my job isn't done.
[17:15] <bspencer_> but I'm wondering if hildon-desktop is the reason...  Seems odd
[17:15] <bfiller> bspencer_: I'll take action to investigate this issue (if in fact it is one..)
[17:15] <bspencer_> davidm,  better leave my ACTION open.  I'll try to close with bfiller on the flash problem.
[17:15] <davidm> bspencer_, will do.
[17:15] <bspencer_> bfiller, ok.  We'll check on it too
[17:16] <davidm> bspencer_, that was ubuntu branch works?
[17:16] <bspencer_> davidm, yes
[17:16] <davidm> [action] continue to hold open: bspencer & horaceli to verify the ubuntu branch works and suggest changes. for next week.
[17:16] <MootBot> ACTION received:  continue to hold open: bspencer & horaceli to verify the ubuntu branch works and suggest changes. for next week. 
[17:17] <davidm> OK are we ready to move to the next item?
[17:17] <bspencer_> yep
[17:17] <davidm> [topic] Don_Johnson to explain USB client use case when user is using ext3 on device and windows on desktop
[17:17] <MootBot> New Topic:  Don_Johnson to explain USB client use case when user is using ext3 on device and windows on desktop 
[17:19] <lool> Don_Johnson: ^
[17:19] <Don_Johnson> Sorry, give me a minute to catch up.
[17:20] <Don_Johnson> We looked into this use case.  The USB client utilities being provided by Intel will not address this case.
[17:20] <Don_Johnson> How we address this user case is an open issue.
[17:21] <smagoun> Don_Johnson: we think this is the primary use case for USB client. When do you expect to have a plan?
[17:21] <davidm> What will the USB client actually do?  Just provide access to any installed flash cards that are VFAT in type? (Like the Nokia N800 does.)
[17:21] <Don_Johnson> I'll have to escalate it to see if we can get some resoruces to work on it.
[17:22] <Mithrandir> Don_Johnson: it doesn't seem clear to me how the USB client support is supposed to work at all then?
[17:23] <Don_Johnson> Yes, this appears to be a big hole.  Which I'll have to follow up on.
[17:23] <Mithrandir> thanks
[17:24] <Mithrandir> davidm: can you give Don_Johnson an action item so we make sure this gets followed up on?
[17:24] <kyleN_> Given the many connection options on the MID, I wonder whether USB client support is needed. how about network shares instead 
[17:24] <davidm> [action] Don_Johnson to investigate USB client use case and how to export ext3 filesystems to windows use case  
[17:24] <MootBot> ACTION received:  Don_Johnson to investigate USB client use case and how to export ext3 filesystems to windows use case   
[17:25] <Don_Johnson> At least we need to have an understanding of how it might be used.  So I'll look into that.
[17:26] <davidm> I do know that the Nokia N800 does not export the file system, only the installed flash cards, but then it only writes files to the flash cards that I've seen when I use mine.
[17:26] <davidm> But I could have missed something.
[17:26] <amitk> davidm: That is correct
[17:26] <davidm> Are we ready for the next action from last week?
[17:27] <lool> I am (complete too; nothing to report here in particular)
[17:27] <Mithrandir> sure, move on
[17:27] <davidm> [topic] lool to upload h-d to ppa (Complete)
[17:27] <MootBot> New Topic:  lool to upload h-d to ppa (Complete) 
[17:27] <davidm> This appears to be complet
[17:28] <lool> (so that's done; it was the same as the first upload, but to a different target)
[17:28] <davidm> Next topic
[17:28] <davidm> [topic] lool to upload an updated MIC which uses the PPA /by default/
[17:28] <MootBot> New Topic:  lool to upload an updated MIC which uses the PPA /by default/ 
[17:28] <lool> That's in progress now; I've started piling some small fixes on MIC and will work on changing URLs next
[17:28] <smagoun> lool: which version of MIC are you working on? 
[17:28] <lool> The git one
[17:29] <smagoun> right, which revision? it changes almost daily?
[17:29] <lool> Which I'll ultimately test and upload to hardy, then backport to gutsy-ppa with the URLs updated to pull from gutsy+gutsy-ppa
[17:29] <smagoun> or are you pulling a new rev each day?
[17:29] <amitk> lool: What does it mean by default? Will MIC not pick up LUM in the gutsy repo?
[17:29] <lool> smagoun: I pulled this morning again
[17:29] <lool> smagoun: I'm pulling regularly
[17:30] <lool> amitk: I'm going to change MIC in hardy to pull from hardy + hardy-ppa (currently empty, but for symetry)
[17:30] <lool> Then backport the same MIC source code to gutsy-ppa but change it to pull from gutsy+gutsy-ppa
[17:30] <davidm> lool, do you have an ETC for it?
[17:30] <lool> So the MIC in hardy will pull from hardy and the MIC in gutsy-ppa will pull from "gutsy+ppa"
[17:30] <amitk> lool: ok.. thats fine then.
[17:30] <smagoun> just be careful with what you pull, MIC in git has been unstable
[17:31] <lool> davidm: Unless it's overly complicated, I should be done on monday, but tests might take me some time
[17:31] <tonyespy> lool: let us know if you need help testing...
[17:31] <davidm> So I'll carry it as an action item for next week then?
[17:32] <lool> tonyespy: Thanks
[17:32] <lool> davidm: Yup
[17:32] <davidm> [action] carry over lool to upload an updated MIC which uses the PPA /by default/ to next week.
[17:32] <MootBot> ACTION received:  carry over lool to upload an updated MIC which uses the PPA /by default/ to next week. 
[17:32] <davidm> [topic] rob_ubuntu take an action item to report back to the team what i find out and what our requirements will be for graphics drivers
[17:32] <MootBot> New Topic:  rob_ubuntu take an action item to report back to the team what i find out and what our requirements will be for graphics drivers 
[17:33] <robr> i sent out email last week to the list to cover this topic
[17:33] <lool> robr: What are the chances to get something cleaner for gutsy's xorg?
[17:33] <smagoun> I did some digging, there are only a couple small differences between EXA 2.1 and Intel's EXA
[17:34] <robr> basically the current psb gfx driver requires xorg 1.3 with a patch for libexa to bring it up from 2.1 to 2.2 + changes
[17:34] <lool> (Either small patches for libexa 1.1 or a libexa 1.1 backport of the driver)
[17:34] <lool> robr: Bringing exa to 2.2 is not acceptable to our xorg folks, so we wouldn't be able to support this
[17:34] <robr> i'm working with the gfx driver team to get them to move to xorg 1.4 which has version libexa 2.2 and is in Hardy
[17:35] <smagoun> FWIW the delta between 2.1 and 2.2 is really small, and the primary change is labelled "this is backwards compatible"
[17:35] <robr> in addition i'm working with them to get drm.ko from the version they have not to the drm.ko that is in the 2.6.24 kernel
[17:36] <lool> smagoun: Bryce told me moving from exa 2.1 to 2.2 would be huge work to backport
[17:36] <Mithrandir> I'd like us to focus forward and not get stuck in trying to backport the world to the PPA.  The current version works, albeit with performance problems.
[17:36] <lool> Like between 6 and 12 core xorg modules to backport
[17:36] <robr> this is getting kicked around the management chain here at intel -- so i don't yet have a commit to make these changes
[17:36] <smagoun> robr: so to be clear, we (canonical mobile business unit) are on our own for accelerated 2D support, right?
[17:36] <lool> Mithrandir: The MID team needs to use gutsy though
[17:36] <robr> smagoun: i'm not following what you mean
[17:37] <lool> Mithrandir: The main target (hardy) seems to be in progress as upstream driver folks rebase on 2.2 and the hardy kernel version
[17:37] <Mithrandir> lool: for now, yes.  We're not going to try to get exa 2.2 with xserver 1.3, that's not recommended by upstream at all.
[17:37] <smagoun> robr: Intel's not going to deliver functional 2D acceleration on gutsy
[17:37] <robr> Mithrandir: i agree with you and i'm trying to work the issue on this end
[17:37] <Mithrandir> lool: investing significant resources into the PPA stopgap is not something we want to do.  It's a stopgap measure, nothing more.
[17:37] <Mithrandir> robr: yup, thanks.
[17:37] <lool> Mithrandir: Yes, which is why I'm questionning the availability of exa 2.1 patches (for xorg 1.3)
[17:38] <lool> Mithrandir: You mean for UME or UME + MID?
[17:38] <smagoun> lool: Intel's EXA is 2.1 + the following patches:
[17:38] <smagoun> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=f8482967ae8080f49dd1bbb0b79cc65020df679f
[17:38] <MootBot> LINK received:  http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=f8482967ae8080f49dd1bbb0b79cc65020df679f 
[17:38] <smagoun> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=56cc24ffb21f7fd41f9ea9e8f969aa85021b9f53
[17:38] <MootBot> LINK received:  http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=56cc24ffb21f7fd41f9ea9e8f969aa85021b9f53 
[17:38] <smagoun> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=6ed08949af4f7ac09170d3d9581e4092b24a84ee
[17:38] <MootBot> LINK received:  http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commitdiff;h=6ed08949af4f7ac09170d3d9581e4092b24a84ee 
[17:39] <smagoun> yuck...thanks mootbot.
[17:39] <davidm> So it will listen to others for some things......
[17:39] <Mithrandir> lool: first, please don't confuse xorg version numbers with xserver version numbers.  They're not the same. :-)
[17:40] <Mithrandir> lool: secondly, xserver 1.3 already has exa 2.1, iirc?
[17:40] <smagoun> Mithrandir: yes
[17:40] <lool> Mithrandir: Yes, not 2.2
[17:40] <lool> Mithrandir: Where did I confuse these two??
[17:40] <Mithrandir> 18:37 < lool> Mithrandir: Yes, which is why I'm questionning the availability of exa 2.1 patches (for xorg 1.3)
[17:40] <robr> that's my understanding and the current gfx drivers require a patch to libexa to bump it to 2.2 for 2D excelleration
[17:41] <lool> Ok, so I should have said xorg server here, not xorg, thanks
[17:41] <robr> i think 2.2 plus additional changes though
[17:41] <Mithrandir> robr: correct.  You can force it to work with 2.1, but it then glitches somehow.
[17:41] <Mithrandir> (unsure exactly how)
[17:41] <robr> Mithrandir: yes, exactly
[17:42] <Mithrandir> lool: the MID team is also going to move to hardy, they might lag a bit more, but investing lots of resources to do something which is not a blocker isn't a good use of resources.
[17:42] <lool> smagoun: (I don't know about the diffs you pasted; I don't even know whether this is enough to move from libexa 2.1 to 2.2 or whether more changes are included between these)
[17:42] <smagoun> Alright. Since my group needs this, I'll take an action item to test Intel's flavor of exa on top of gutsy.
[17:42] <lool> Mithrandir: I certainly did not understand that they would move to hardy which is why I'm bringing this up
[17:43] <smagoun> lool: I do know about the diffs, I looked them up. :) They don't need 2.2 per se, they need those diffs.
[17:43] <lool> But if they are fine with using hardy, then I'll shut up :)
[17:43] <davidm> [action] smagoun Since my group needs this, I'll take an action item to test Intel's flavor of exa on top of gutsy.
[17:43] <MootBot> ACTION received:  smagoun Since my group needs this, I'll take an action item to test Intel's flavor of exa on top of gutsy. 
[17:43] <smagoun> No, we're not switching to Hardy right now.
[17:43] <robr> lool: that's the issue we're trying to resolve internally
[17:43] <Mithrandir> smagoun: I'm not talking about right now, I'm talking about in the short-to-possibly-medium-term.
[17:44] <lool> robr: Well you're also trying to target the same kernel as hardy does and the same libexa + xorg server as hardy does; but there was consensus no that, so I didn't discuss it
[17:44] <smagoun> Mithrandir: we're quite nearsighted
[17:44] <robr> so what i need to know is do you need 2D & 3D acceleration on Gutsy and when will your customers switch to Hardy
[17:44] <bspencer_> is smagoun's team called "MID team" ?  or is that my team?  I thought smagoun's team might be giving a real customer gutsy for awhile (e.g for the next 4 months)
[17:45] <bspencer_> so supporting gutsy is important
[17:45] <smagoun> bspencer_: we're on Gutsy for a couple of months, yes.
[17:45] <Mithrandir> bspencer_: smagoun's team is the "Canonical MID team", or something like that.  We're still struggling with a good name for them. :-)
[17:45] <bspencer_> but you guys can wrestle over that
[17:45] <bfiller> the plan is to stay on Gutsy for our customers until Hardy is stable, then switch
[17:45] <smagoun> bspencer_: My group is the "mobile business unit"
[17:45] <kyleN_> we need 2d and 3d acceleration on gutsy
[17:46] <bfiller> robr: ideally, a solution for gutsy and hardy would be great
[17:46] <bspencer_> smagoun, MBU -- formerly known as Pepper guys
[17:46]  * amitk struggles with MID, UMPC, UME, UMC and now MBU every day
[17:46] <robr> then you will have to take what we have now, i can't see anything changing on Gutsy -- Hardy is when I can see a change
[17:46] <lool> Too many TLAs
[17:46] <bspencer_> amitk, don't forget MIC
[17:46] <Mithrandir> amitk: I thought we killed UMC?
[17:47] <bfiller> robr: sounds reasonable
[17:47] <amitk> Mithrandir: good riddance
[17:47] <smagoun> robr: what is Intel doing to avoid the version mismatch problem in the future? It's happend several times now.
[17:47] <davidm> OK, we are running out of time... Do we know what we are doing at this point?
[17:47] <lool> Ok; so point closed; everybody is free to try fixing gutsy 2D/3D support; development tries to target hardy's kernel + xorg server + libexa versions for now; correct?
[17:48] <davidm> 12 minutes left.
[17:48] <robr> smagoun: physical torture for those groups that fall out of line
[17:48] <bfiller> lool: I think that is an appropriate summary
[17:48] <robr> bfiller / lool : i think that summary is correct
[17:48] <davidm> OK next topic then?
[17:49] <lool> Yup; yours
[17:49] <davidm> [topic] davidm to verify a new time for this meeting. (Complete: Every Thursday at 17:00 UTC is the new standard meeting time.)
[17:49] <MootBot> New Topic:  davidm to verify a new time for this meeting. (Complete: Every Thursday at 17:00 UTC is the new standard meeting time.) 
[17:49] <davidm> This is the new time until the next time change I think.
[17:49] <Mithrandir> sounds splendid to me.
[17:50] <davidm> [topic] carry on "Discuss process for Gutsy / Hardy transition (bspencer)" for next week
[17:50] <lool> I guess everybody here knows about the new time or wouldn't be here :-P
[17:50] <MootBot> New Topic:  carry on "Discuss process for Gutsy / Hardy transition (bspencer)" for next week 
[17:50] <bspencer_> great for us.  no change is good
[17:50] <bspencer_> davidm, seems like we have already been doing this
[17:50] <bspencer_> what was remaining to hash out?
[17:50] <davidm> Sort of, but we carred it over so I just want to make sure there is nothing else or I'll close it.
[17:51] <davidm> Anything else on this topic?
[17:52] <davidm> OK then, next topic
[17:52] <davidm> [topic] Specs need to be finalized next week (for the 22nd)
[17:52] <MootBot> New Topic:  Specs need to be finalized next week (for the 22nd) 
[17:52] <lool> So that's just a reminder that the dead line for the contents of specs before review is the 22nd, that's next week
[17:52] <tonyespy> what does finalized mean?
[17:53] <davidm> Anyone that is drafting a spec needs to have it finished next week. 
[17:53] <lool> I don't know whether the mobile project is affected by the same deadlines though
[17:53] <davidm> Finished/ Complete
[17:53] <davidm> We are
[17:54] <davidm> Mithrandir, from the drafter completing the spec to finialzing it approximately how long does that take?
[17:54] <davidm> Mithrandir, A day/hours?
[17:54] <davidm> I've never finalized a spec as yet.
[17:54] <tonyespy> for the record, i'm on the hook for a blueprint describing usability/functional changes to network-manager for mobile.
[17:55] <lool> There's no drafter for mobile-hardy-image-creator on my specs, other specs seem to have some drafting already
[17:55] <tonyespy> since, i'm just starting it....it's doubtful it can be "finalized" by next week
[17:55] <Mithrandir> davidm: depends on how many specs pile up at once.
[17:55] <bspencer_> Mithrandir, there was a guy who was going to own System Update stuff.  I don't remember.  Is he going to write a MID-specific spec for that?
[17:56] <Mithrandir> bspencer_: we had a miscommunication wrt that, so we need to do something clever for that.  We'll be providing the UI for that, but it might be somewhat delayed over the original schedule.
[17:56] <Mithrandir> davidm: but in general, review + approval takes an hour or two per spec.
[17:56] <davidm> If I understand the Canonical process if it's not finalized it's not in hardy (I think) Mithrandir is that basically correct?
[17:56] <bspencer_> ok.  there's some details we discussed wrt updating, app install, website, etc that should be written somewhere
[17:56] <bspencer_> ( Mithrandir )
[17:57] <lool> HappyCamp_ubuntu: Does anything needs drafting for mobile-hardy-image-creator?  There's currently no associated wiki page on that
[17:57] <Mithrandir> davidm: s/Canonical/Ubuntu/, otherwise yes.
[17:57] <davidm> way running out of time here are we OK to run over?
[17:58] <Mithrandir> I'm fine running over.
[17:58] <bspencer_> my topics can wait if needed.  I'm also fine running over
[17:58] <lool> I'm fine too
[17:58] <davidm> Does anyone have to leave  in 2 minutes or can we run over?
[17:58] <tonyespy> nope...
[17:58] <Don_Johnson> I'll be leaving
[17:58] <Mithrandir> bspencer_: is it in the notes from the BOF?  If so, they should be fine being picked up.
[17:58] <davidm> Don_Johnson, I'll post you the URL for Mootbot so you can read the rest of the info
[17:59] <bspencer_> Mithrandir, probably....   I went through the BoF's for the apps but not that one in particular
[17:59] <bspencer_> someone took to BoF for the apps and put them in the specs.  whoever did that:  thanks!   I tried to clean them up a little too
[18:00] <davidm> OK, are we ready to move on?
[18:00] <bfiller> bspencer_: I did that for the apps. Who owns the system updates spec?
[18:00] <bfiller> bspencer_: hopefully the info is still in gobby?
[18:00] <lool> system updates is registered by StevenK, assigned to mvo
[18:00] <bspencer_> bfiller, thanks a lot. 
[18:00] <lool> (approver is mobile team, no drafter)
[18:01] <lool> https://blueprints.launchpad.net/ubuntu/+spec/mobile-software-updates
[18:02]  * bspencer_ looks around for a volunteer, then pretends he is busy checking email
[18:02] <bfiller> looks like the spec has some BoF notes from UDS at a very high level
[18:02] <bspencer_> on volunteer this week.   davidm let's move on
[18:02] <davidm> K
[18:03] <davidm> finally a new topic not an old action
[18:03] <davidm> [topic] input methods: scim or hildon input method? - Kyle
[18:03] <MootBot> New Topic:  input methods: scim or hildon input method? - Kyle 
[18:03] <kyleN_> I got some Chinese input method stuff working on a UME target via SCIM with Arne and Lool. Posted to list&wiki. There's also the Hildon Input Method approach, about which I can't find much info. 
[18:03] <kyleN_> so the question is: has mobile decided which approach to use?
[18:04] <bspencer_> >  stuff working   
[18:04] <bspencer_> what does that mean?
[18:04] <bspencer_> it is elegant and works well?
[18:04] <smagoun> bspencer_: we wouldn't want it to stand out :)
[18:04] <kyleN_> it means you can enter Simplified Chinese characters from a USA layout keybaord in mobile
[18:04] <kyleN_> both hardware keybaord and virtual
[18:04] <Mithrandir> does there exist an on-screen keyboard plugin for SCIM?
[18:04] <kyleN_> I think it will work for the other CJK languages but haven' tested
[18:04] <bspencer_> smagoun, so synical ! :)
[18:05] <bspencer_> Hildon Input method -- we need to investigate more
[18:05] <bspencer_> I'm always uncertain whether this has been opened or not
[18:06] <bspencer_> there's not a lot of web documentation on it
[18:06] <davidm> has anyone to date looked at the Hildon Input method?
[18:06] <kyleN_> a canonical fellow who works in Taiwan/Asia indicates scim may be a better option in the short run, at least for the mobile business unit
[18:06] <kyleN_> because red flag uses it and it works
[18:06] <smagoun> executive decision: we're using scim
[18:07] <bspencer_> Taiwan/Asia guys' job is asian input though
[18:07] <kyleN_> he also indicated hildon IM didn't work too well but I didn't get the details
[18:07] <bspencer_> he has a tainted perspective :)
[18:07] <kyleN_> No, his job is bizdev
[18:07] <bspencer_> ok.
[18:07] <bfiller> is hildon input method currently included in ume?
[18:07] <Mithrandir> bfiller: no
[18:07] <bspencer_> no one has tackled trying to get it to work that I know of
[18:08] <Mithrandir> I've poked at it a little bit while at UDS + allhands.
[18:08] <Mithrandir> I know StevenK has poked more at it
[18:08] <bfiller> sounds like we need an action of compare/contrast scim and h-i-m and include the appropriate one in ume
[18:08] <davidm> I agree but we need a person that is going to do the action
[18:09] <kyleN_> with support from lex, I would be willing to own the action
[18:09] <Mithrandir> I volunteer StevenK, in absentia
[18:09] <kyleN_> +1 on Mith ;)
[18:10] <davidm> How about kyleN_ and StevenK own the action
[18:10] <bfiller> davidm: sounds good
[18:10] <kyleN_> hmm. that seems diluted
[18:11] <kyleN_> who really owns it then?
[18:11] <davidm> Well I think you do since you
[18:11] <bfiller> maybe StevenK can get h-i-m included in the build so you can test
[18:11] <davidm> ve done at least one side of it
[18:11] <davidm> That makes sense to me.
[18:11] <kyleN_> sounds reasonable
[18:12] <bfiller> kyleN_: you've already got scim - just need to try h-i-m to see which is better
[18:12] <davidm> [action] StevenK to get h-i-m included in the build so KyleN_ can test
[18:12] <MootBot> ACTION received:  StevenK to get h-i-m included in the build so KyleN_ can test 
[18:12] <kyleN_> i'll note that as a non-chinese speaker it is difficult to evaluate, but c'est la vie
[18:12] <davidm> understood
[18:13] <davidm> OK, move on?
[18:13] <bfiller> kyleN_: perhaps we can get Kevin to help us
[18:13] <kyleN_> He alrady said scim was preferable
[18:13] <kyleN_> I'll ping him and ask for details
[18:13] <bfiller> kyleN_: we will force him to test h-i-m as well :)
[18:13] <kyleN_> OK
[18:14] <tonyespy> is it possible to get both installed in an image and make them dynamically switchable?
[18:14] <davidm> kyleN_, perhaps you can speak with him further to determine why he feels that way?
[18:14] <davidm> tonyespy, I have no idea.
[18:14] <kyleN_> davidm: I will email him and broach the subject seriously
[18:14] <bspencer_> tonyespy, certainly possible
[18:14] <davidm> kyleN_, thanks
[18:14] <kyleN_> tony: probably not dynamically, but maybe witha  reboot/new env vars
[18:14] <bspencer_> tonyespy, or at least have two options for different images.
[18:15] <davidm> [action] kyleN_ to email Kevin to understand his issues with  h-i-m 
[18:15] <MootBot> ACTION received:  kyleN_ to email Kevin to understand his issues with  h-i-m  
[18:15] <davidm> Are we ready to move on?
[18:15] <kyleN_> yes
[18:16] <davidm> [topic] i18n: need plan to ensure everything's set up for translation - Kyle
[18:16] <MootBot> New Topic:  i18n: need plan to ensure everything's set up for translation - Kyle 
[18:16] <bspencer_> we put a todo item for l10n
[18:16] <bspencer_> and i18n is not in our plans
[18:16] <kyleN_> when I change the lang to chinese and generate the appropriate locale and look at the UI
[18:16] <kyleN_> I see lots of text that is in english, and some that is in chinese
[18:17] <kyleN_> many settings applets have a mix of chinese and english
[18:17] <bspencer_> kyleN_, that's because chinese pepole use a lot of english words
[18:17] <lool> kyleN_: I think some moblin apps are not gettexized
[18:17] <kyleN_> the marquee has a mix: some of it seems hard coded
[18:17] <tonyespy> bspencer: seems like a pretty big hole if it's not in your plans...
[18:17] <kyleN_> many hildon menus are english
[18:17] <bspencer_> we will gettextize our apps, but not translate them to other languages
[18:17] <kyleN_> bspencer_: great
[18:18] <bspencer_> by Feb
[18:18] <kyleN_> does that include control panel applets et al?
[18:18] <bspencer_> et al
[18:18] <kyleN_> bootiful
[18:18] <kyleN_> so all other apps need to be analyzed
[18:19] <bspencer_> yes, for the 4:  home (marquee), control panel, browser (already done), media player
[18:19] <davidm> OK are we ready for the next topic now?
[18:19] <kyleN_> i propose analyzing an app for i18n is an "offical" requirement, just like hildonizing
[18:19] <tonyespy> kyleN: where will the results of this "analysis go"?
[18:20] <tonyespy> a blueprint?
[18:20] <tonyespy> a doc on the wiki?
[18:20] <kyleN_> tonyespy: I don't know, but it has to be managed and tracked
[18:20] <tonyespy> so there needs to be an action item...
[18:20] <kyleN_> how about adilson?
[18:20] <tonyespy> to create a document somewhere that tracks status...
[18:20] <bfiller> davidm: think we need an action (I volunteer Adilison) to go through the apps on launhpad and determined if and how they support i18n
[18:20] <davidm> Mithrandir, your input here?
[18:21] <lool> kyleN_: erf :)
[18:21] <Mithrandir> mobile-hildon-input-methods sounds like the right spec this analysis should go to.
[18:21] <bfiller> davidm: then based on the findings someone will actually need to do the work of implementeing gettext if not done
[18:21] <tonyespy> Mithrandir: why, aren't we talking about output?
[18:21] <tonyespy> ;)
[18:22] <kyleN_> maybe the apps could be assigned to various folks: divide and conquer
[18:22] <kyleN_> at least for the analysis phase
[18:22] <davidm> When does this need to be done by? 
[18:22] <Mithrandir> tonyespy: inteed, so it should go to the i18n spec.
[18:23] <tonyespy> the sooner the better....
[18:23] <kyleN_> bfiller: do you know our schedule requirements?
[18:23] <Mithrandir> my brain is just trying to explode here.
[18:23] <tonyespy> Mithrandir: take deep breath...we need ya!
[18:23] <bfiller> kyleN_: don't know.. but we should analyze asap so we know what work needs to be done
[18:24] <kyleN_> do we need a real master list of current and proposed apps?
[18:24] <kyleN_> we want to add some: like drivel (blog)
[18:24] <bfiller> should start with the set that has been commited for Hardy
[18:25] <tonyespy> i 2nd that plan...
[18:25] <lool> Yeah, like bfiller said; the list of apps is supposedly in the specs
[18:25] <kyleN_> I'm not sure how to find that set exactly, but OK. 
[18:25] <kyleN_> everytime I press adilson on his list, he says it's not final and is bound to change
[18:26] <tonyespy> it will...
[18:26] <bfiller> kyleN_: good point. Anyone have a link to spec for commited apps?
[18:26] <garyl> kyleN_: Isn't it here?  https://wiki.ubuntu.com/MobileAndEmbedded/UserApplications
[18:26] <kyleN_> that's adilsons list, but it's currently more of an analysis o whether to include certain apps or other apps
[18:26] <kyleN_> I think we need the Current list and the Proposed list
[18:27] <bfiller> do we need an action to write an official spec on what will be included in Hardy?
[18:27] <tonyespy> why don't we start with the list of apps we have now, and modify/change the list as apps are added/removed???
[18:27] <kyleN_> sure
[18:28] <davidm> OK
[18:28] <tonyespy> [stomach grumbles...]
[18:28] <bfiller> davidm: can Adilson own the spec since he's done the most work here?
[18:28] <kyleN_> it would be helpful if it shows whether the app is in the build, whether it's been analyzed for gettext
[18:29] <lool> tonyespy: We try to commit to implementing specs for a release, so a list of apps would be informal IIUC
[18:29] <tonyespy> does it need to be a blueprint or can it just be a wiki page?
[18:29] <davidm> Adilson owns the spec "mobile-applications" already as the drafter and the assignee 
[18:29] <tonyespy> also, if there are proprietary apps involved, where does that analysis go?
[18:29] <lool> tonyespy: And at that point, my understanding is that we're not supposed to add any new blueprint; but then it might be ok for the mobile project this time around
[18:29] <davidm> MID group
[18:29] <kyleN_> in general, we created a page of "app criteria" and it would be nice if the apps were analyzed by those
[18:30] <bfiller> davidm: ok, here is a link to the spec https://wiki.ubuntu.com/MobileAndEmbedded/MobileApplications
[18:30] <davidm> or is it "MBU"
[18:30] <davidm> so do we have an addition action item here?
[18:31] <bfiller> davidm: spec should be updated to include two things: List of commited apps for Hardy, Analysis of "app critieria"
[18:31] <davidm> we are way over time at the moment
[18:31] <bspencer_> action bspencer:  I'll organize the prioritze that list and send out for comment
[18:31] <bspencer_> s/that list/the list of criteria
[18:31] <kyleN_> bspencer: thx
[18:31] <bspencer_> some are must-have.  others are nice-to-have
[18:31] <davidm> [action] mobile-applications spec should be updated to include two things: List of commited apps for Hardy, Analysis of "app critieria
[18:31] <MootBot> ACTION received:  mobile-applications spec should be updated to include two things: List of commited apps for Hardy, Analysis of "app critieria 
[18:32] <davidm> OK next topic?
[18:32] <tonyespy> kernel status/updates + sdio schedule??
[18:32] <kyleN_> yes
[18:32] <bfiller> sounds good
[18:32] <davidm> [topic] Xephyr with GL support and I don't know who posted it.
[18:32] <MootBot> New Topic:  Xephyr with GL support and I don't know who posted it. 
[18:32] <bspencer_> We need a Xephyr that supports GL.  I spoke with Bryce about it.  He said the task for including such changes into Hardy were big but that he could create some .debs for us to use assuming he got permission from Collin for the work. 
[18:32] <bspencer_> in the meanwhile, we will create this too and post on moblin.org
[18:32] <bspencer_> not sure how long it will take Bryce, but we need it sooner
[18:33] <bspencer_> (that's all, just FYI)
[18:33] <davidm> OK thanks
[18:33] <davidm> [topic] Tagging moblin component versions
[18:33] <MootBot> New Topic:  Tagging moblin component versions 
[18:33] <davidm> bspencer_, did you post this one too?
[18:33] <bspencer_> and FYI:  due to a suggestion from smagoun  we will try to tag our components when a release is cut
[18:33] <bspencer_> davidm, yes
[18:33] <lool> bspencer_: "Not sure how long it will take but we need it sooner" I have to quote that!
[18:33] <davidm> K
[18:33] <smagoun> bspencer_: thanks
[18:34] <bspencer_> that's all on that topic too.
[18:34] <bspencer_> easy!
[18:34] <davidm> K, I'm out of topics
[18:34] <lool> "It's due yesterday!"
[18:34] <kyleN_> phew!
[18:34] <davidm> Any last items
[18:34] <davidm> ??
[18:34] <smagoun> #getmeabeer
[18:34] <tonyespy> yea, what happened to my topics?
[18:34] <lool> tonyespy: Where are they on https://wiki.ubuntu.com/MobileAndEmbedded/Meeting/20071115 ?
[18:35] <bspencer_> topic:  kernel status/updates + sdio schedule     (I'm guessing).  robr  you still around?
[18:35] <davidm> I don't see any on the page
[18:35] <tonyespy> nope i screwed up and forgot to press save [sheepish grin]...
[18:35] <davidm> OK press save now :-)
[18:36]  * bfiller getting dizzy from hunger :)
[18:36] <robr> bspencer_: what's that?
[18:36] <tonyespy> quickly, robR and I discussed having intel discuss kernel/driver status at the weekly mtg
[18:36] <bspencer_> tonyespy, what is your topic?
[18:36] <davidm> Still not there
[18:36] <tonyespy> also, want an idea of where the SDIO work stands...
[18:37] <davidm> [topic] <tonyespy> quickly, robR and I discussed having intel discuss kernel/driver status at the weekly mtg
[18:37] <MootBot> New Topic:  <tonyespy> quickly, robR and I discussed having intel discuss kernel/driver status at the weekly mtg 
[18:37] <tonyespy> davidm: that's cause there was a conflict
[18:37] <robr> tonyespy: i've posted our status to the mailing list that past two weeks
[18:37] <ChickenCutlass> tonyespy: ctrl-S
[18:37] <tonyespy> ok
[18:37] <robr> tonyespy: if you need more details i'll be happy to discuss
[18:38] <davidm> Does that bring us to a close?
[18:38] <tonyespy> i'll offline it for now, but i would like a short briefing during this weekly mtg is possible
[18:38] <tonyespy> i'm good...
[18:38] <davidm> Then I will apologize now for allowing this meeting to run so far over.
[18:39] <tonyespy> one last thing...
[18:39] <davidm> #endmeeting
[18:39] <MootBot> Meeting finished at 18:39.
[18:39] <kyleN_> it was all good material
[18:39] <tonyespy> the lexington team will not be around for the next mtg due to the holiday.
[18:39] <bfiller> davidm: lots of stuff to figure out
[18:39] <davidm> True but I really really don't like allowing meetings to go this far over.
[18:39] <tonyespy> should we re-schedule for wed?
[18:40] <bfiller> davidm: agreed
[18:40] <davidm> tonyespy, yes I think so if we can fit it in, since the entire US will be out.
[18:40] <tonyespy> ok, can you send an email to folks
[18:40] <tonyespy> ?
[18:41] <davidm> I will and poll everyone.
[18:41] <tonyespy> cool.  ttyl
[18:41] <amitk> robr: those status reports are great.. keep them coming
[18:41] <davidm> Should have done it at the beginning of this meeting
[18:41] <robr> amitk: thanks, no problem -- i will try my best. ;-)
[18:41] <kyleN_> cheers - lunch
[18:42] <lool> I'm off for dinner too; bon appétit everybody
[18:42] <bfiller> see ya
[18:44] <amitk> bye all
[18:47] <davidm> later