**** BEGIN LOGGING AT Sun Mar 25 02:59:58 2012
Mar 25 23:18:40 <lilstevie> I'm having an issue with the battery applet in precise, I have a dual battery system, and it is taking the secondary battery (the battery that drains first) as the primary one
Mar 25 23:18:49 <lilstevie> so when it depletes I am getting a suspend warning
Mar 25 23:30:25 <infinity> lilstevie: gnome-power-manager bug?  Ish?
Mar 25 23:30:35 <infinity> lilstevie: File away and pester seb128 until it's fixed? :P
Mar 25 23:31:24 <infinity> lilstevie: IMO, there shouldn't be a "primary" battery, it should just total up remaining/available for all batteries.
Mar 26 01:25:21 <lilstevie> infinity, ok
Mar 26 01:25:41 <lilstevie> I did notice it only happens on HF
Mar 26 01:26:32 <lilstevie> precise updated from oneiric doesn't give me the suspend warning
Mar 26 01:26:41 <lilstevie> but the hf precise image I have on my sdcard does
Mar 26 02:01:16 <michaelh1> Hey, does anyone know who in Ubuntu creates the ARM UEC images http://uec-images.ubuntu.com/precise/current/ and the tool used?
Mar 26 02:10:54 <infinity> lilstevie: That's probably less to do with el versus hf and more to do with upgrade versus fresh, I'd guess.
Mar 26 02:11:36 <infinity> lilstevie: As in, maybe the old gnome-power-manager got it right, and its settings were carried over on upgrade (thanks to them being in your ~)
Mar 26 02:11:56 <infinity> lilstevie: Could test that theory with your old ~ on a fresh precise/hf image, probably.
Mar 26 02:12:48 <infinity> michaelh1: Not sure exactly where those come from, you might try asking smoser.
Mar 26 02:13:46 <lilstevie> infinity, fair enough, oneiric never displayed the battery stats correctly anyway (stupid android driver) but the new power-manager or upower compensates
Mar 26 02:14:28 <lilstevie> infinity, I guess the other bug I have experienced is pulse audio crashing
Mar 26 02:14:46 <michaelh1> infinity: ta, I'll send him an email
Mar 26 02:15:08 <lilstevie> had to remove pulse just for lightdm to not die
Mar 26 02:16:19 <twb> meh, that just reinforces my low opinion of pcmanfm's work
Mar 26 02:20:13 <lilstevie> twb, ?
Mar 26 02:30:38 <twb> never mind
Mar 26 02:31:04 <twb> (pcmanfm makes most of the LXDE bits)
Mar 26 02:37:27 <lilstevie> the issue isn't lightdm it is pulseaudio
Mar 26 02:37:42 <twb> Yeah well I like lennart even less :-)
Mar 26 02:37:50 <lilstevie> any process that outputs sound with it will either crash, or go haywire
Mar 26 02:42:25 <infinity> lilstevie: Reproduce, file bugs, etc.
Mar 26 02:42:52 <infinity> lilstevie: Better still if you can reproduce on x86 too, but if it really is arm-specific, we should still deal with it. :P
Mar 26 02:43:07 <lilstevie> infinity, ok, I just don't know exactly how to get the bug, or reproduce bug, it is probably my kernel
Mar 26 02:43:22 <infinity> lilstevie: Well, if it's your kernel, I might care less about a bug filing. :P
Mar 26 02:43:24 <lilstevie> I can reliably reproduce on both tf101 and tf201
Mar 26 02:43:52 <lilstevie> but it would have been observed on the panda
Mar 26 02:44:04 <lilstevie> or well, any device :p
Mar 26 02:44:10 <infinity> Speaking of the TF... Are we still in "no way in hell" land on trying to do a unified -tegra kernel?
Mar 26 02:44:28 <lilstevie> well, with mtype hacks we could
Mar 26 02:44:55 <lilstevie> someone did something creative with boot.img creation that dynamically patched the mtype
Mar 26 02:45:11 <infinity> That sounds vile.
Mar 26 02:45:17 <lilstevie> heh
Mar 26 02:45:18 <lilstevie> yeah
Mar 26 02:45:35 <infinity> Wait, binary patched the kernel, or just mangled something else in the abootimg?
Mar 26 02:45:42 <lilstevie> I have no idea
Mar 26 02:45:53 <lilstevie> I wasn't too interested cause it sounded vile
Mar 26 02:45:54 <lilstevie> :p
Mar 26 02:45:58 <infinity> Cause if we could get one KERNEL to work, but just needed different boot images, that's easily done.
Mar 26 02:46:00 <lilstevie> let me check
Mar 26 02:46:32 <lilstevie> yeah, if it just mangles abootimg I'm sure kernel-img.conf could have the device mtype
Mar 26 02:46:34 <infinity> I'd happily ship two boot images (and let flash-kernel sort it for upgrades), if we could have a unified kernel.
Mar 26 02:46:46 <lilstevie> yeah
Mar 26 02:46:53 <infinity> flash-kernel, not kernel-img.conf, but yeah.
Mar 26 02:47:11 <lilstevie> well I am almost certain with a little work that tf101 and tf201 should be able to share a kernel
Mar 26 02:47:37 <lilstevie> that is tegra2/tegra3
Mar 26 02:47:46 <infinity> And AC100, and that Toshiba tablet that was similar, and...? ;)
Mar 26 02:48:01 <infinity> Well, anything that's fastboot+tegra should, in theory, be doable.  One would hope.
Mar 26 02:48:04 <lilstevie> I mean without hacks
Mar 26 02:48:15 <lilstevie> tf101 does not fastboot
Mar 26 02:48:19 <infinity> uBoot tegra platforms (like the Trimslice) might be a bit more of a pipe dream for a unified kernel.
Mar 26 02:48:28 <infinity> Oh, tf101 doesn't?
Mar 26 02:48:48 <lilstevie> no, well it uses the "fast boot" bootloader
Mar 26 02:48:50 <infinity> abootimg kinda implies fastboot, doesn't it?
Mar 26 02:48:52 <lilstevie> but there is no fast boot access
Mar 26 02:49:13 <lilstevie> nvflash access is your only way of manipulating images
Mar 26 02:49:23 <infinity> Well, sure.  That's true of the ac100 as well.
Mar 26 02:49:36 <lilstevie> also Trimslice isn't that pipedream
Mar 26 02:50:01 <lilstevie> I recently saw on the u-boot mailing list a bootz patch
Mar 26 02:50:04 <lilstevie> to boot zImage
Mar 26 02:50:11 <lilstevie> and really
Mar 26 02:50:12 <infinity> Yeahp.
Mar 26 02:50:18 <infinity> Don't know if we'll land that for precise.
Mar 26 02:50:22 <lilstevie> that would solve the problem
Mar 26 02:50:28 <infinity> And even if we do, probably won't go an ditch all th uImages.
Mar 26 02:50:30 <lilstevie> certainly not for precise
Mar 26 02:50:34 <infinity> But it's a sane way forward.
Mar 26 02:50:45 <lilstevie> precise is only like what a week away
Mar 26 02:50:45 <lilstevie> :p
Mar 26 02:50:50 <lilstevie> well a few weeks
Mar 26 02:50:51 <infinity> A month.
Mar 26 02:50:57 <infinity> But yeah, "soon".
Mar 26 02:51:00 <infinity> Too soon.
Mar 26 02:51:38 <infinity> These cycles always seem so long for non-LTS releases, and so damn short when I'm trying to make everything "just right" for an LTS. :/
Mar 26 02:52:09 <lilstevie> https://github.com/astarasikov/mkbootimg-mtype-hacked
Mar 26 02:52:27 <lilstevie> takes mtype as an arg
Mar 26 02:53:51 <lilstevie> looks like it patches the zImage
Mar 26 02:54:00 <infinity> Yeah, I just got there.
Mar 26 02:54:06 <infinity> So much for that idea.
Mar 26 02:55:00 <lilstevie> I guess the only other way is generic board that heuristically determines the platform
Mar 26 02:55:04 <infinity> I wonder if one could parse mtype from the cmdline, or if we need it too early to be able to.
Mar 26 02:55:25 <lilstevie> hm
Mar 26 02:55:25 <infinity> Well, obviously, the real solution is being able to detect, yes.
Mar 26 02:55:35 <infinity> But I'm trying to think of quick hacks. ;)
Mar 26 02:55:41 <lilstevie> heh
Mar 26 02:56:23 <infinity> cmdline parsing happens pretty damned early, though.
Mar 26 02:56:26 <infinity> So, that should be doable.
Mar 26 02:56:41 <lilstevie> yeah the question is if it happens quite early enough
Mar 26 02:57:00 <lilstevie> there are certain fuse structures that could be used for the tf101
Mar 26 02:57:14 <infinity> Well, given that you need it early enough for nosmp to rewrite spinlocks, and for mem= to blacklist regions, it's got to be... Early.
Mar 26 02:57:33 <lilstevie> heh actually that is a good point
**** ENDING LOGGING AT Mon Mar 26 02:59:58 2012