[00:29] mfisch: what are your thoughts on this bug?https://bugs.launchpad.net/ubuntu-nexus7/+bug/1076793 [00:29] Launchpad bug 1076793 in ubuntu-nexus7 "Bad multicore performance" [Undecided,New] [00:30] cwayne: unsure really [00:30] cwayne: I'm about eod, lets check it out tomorrow [00:30] cwayne: I guess we should repro it [00:31] I'd like to know how it works on a multicore x86 box too [01:50] with regards to nexus7 and running android side-by-side can I suggest LVM, it is the solution I have gone down for the tf201 cause repartitioning on these tegra devices is a real pain [01:54] lilstevie: Turn all the Android partitions into one big LVM volume? I think I suggested that to Oliver a couple of weeks ago. ;) [01:54] infinity, well that too, I started with just UDA [01:55] but lately yeah, the whole damn lot [01:55] Would be nice if we could just repartition, like I did on my ac100, but that seems to be a non-option on the nexus7. [01:56] you need nvflash for that [01:56] Indeed I did, yes. [01:56] and the nexus 7 is ODM secure [01:57] and our nvflash stuff doesn't work with it [01:58] not to mention I don't think canonical could endorse such hackery [02:00] * persia considers mobiln-image-creator and smirks [02:01] lol [02:02] persia, do you have time at the moment? [02:02] also hi [02:02] :p [02:02] Some, not lots. [02:03] heh ok [02:03] repo.lilstevie.geek.nz is where that kernel is if you get some time to have a look [02:03] Give me a URL, and I'll hit it as soon as I have time, which likely saves scheduling issues (and apologies for not poking you earlier today) [02:04] that's ok, you probably wouldn't have reached me [02:04] I didn't get up until 10am and it is only 1pm now [02:04] What did you have to change in casper? [02:04] TheMuso changed something, I think he pushed that for quantal though [02:04] Yeah, but I had more time when you got up than I do now :) [02:06] it was something to do with not looking at any storage on the usb bus for the tf201 [02:06] Anyway, unless something comes up, I should be able to look at it in ~6 hours. [02:06] ok cool :) [02:13] anyway with some minor work, the new kernel should support the entire tegra3 transformer range === zz_chihchun is now known as chihchun [05:21] sweet, my chromebook is now running ubuntu! [05:36] ok, does anyone know how software for ubuntu/arm (e.g. firefox) is built? [05:37] is it cross-compiled, or just built nativelty? [05:37] mjrosenb: Everything that ships with Ubuntu on Arm is built natively. [05:37] ow [05:38] I tried building firefox on a pandaboard last night [05:38] Took a while eh? [05:38] and the linking phase killed it [05:38] use that shiny new a15 [05:38] ...or lots and lots and lots and lots of swap. [05:38] * achiang would be interested in seeing chrubuntu build performance [05:38] * lilstevie too [05:38] dual a15, 2gb ram... and using usb3 for IO [05:39] yeah, I think my pandaboard has 1G ram + 512m swap [05:39] * achiang nominates mjrosenb to do some tests. :) [05:39] I should give it some more swap [05:39] Yep, try a lot more swap. [05:39] building on my quad a9, 1gb ram with slow mmc is a bit more decent but that a15 should kill it [05:39] achiang: oh, its internal hard disk uses usb3.0? [05:39] No, it usees MMC internally. [05:40] At least afaik. [05:40] mjrosenb: oh, no. cr-book has an external usb3 port [05:40] internal mmc [05:40] yeah, something or other is showing up as an sdcard [05:40] that's the mmc [05:41] sadly, / is *quite* small [05:41] ogra_: ignored flash. hangouts are handled by plugin (not tried extracting) [05:41] the ubuntu buildds use external USB disks [05:41] you know if the mmc is user-replacable? [05:41] TheMuso: that ppa which persia mentioned is with ucm profile. [05:42] * mjrosenb does not have any external usb disks available, but I do have a nice 32g sd card [05:42] (that I need to find) [05:42] hrw: i'd be interested if you were able to figure out the hangout plugin. that's my blocker for getting a chromebook. :) [05:42] TheMuso: what do you think about moving ucm profiles to separate package? would be easier to update and I would love to get them in Debian as well [05:43] hrw: How easier to update? [05:43] achiang: hdmi output works fine [05:43] hrw: sorry, i don't understand? how is hdmi related to google hangouts? [05:43] hrw, moving the ucm profiles to a separate package would also make tweaking for devices with similar codecs easier [05:43] lilstevie: Why? [05:44] persia, smaller, more portable package? [05:44] lilstevie: more boilerplate documentation bloating deployed images [05:44] hm [05:45] ucm files are trivially portable. Uploading them as part of a single thing makes it easy, as long as we effectively collaborate on the uploads. [05:45] It's only if one falls into the trap of believing in maintainers and maintainer lock that it could be an issue. [05:45] 23:55 < achiang> the fact that they shipped without getting hdmi working is... lame [05:46] hrw: oh, you're processing old scrollback. :) [05:46] persia: and ucm profiles are ubuntu delta [05:46] achiang: yes, I do [05:46] hrw: That makes it even simpler: they just drop in local VCS, and get deployed. [05:46] achiang: its 6:45 here [05:46] nod [05:46] 2146 here [05:46] 1646 here :p [05:47] 47 here [05:47] just 47? [05:47] * persia refutes the concept of timezones, and claims it to be 8:17, based on time since becoming awake. [05:47] persia: my plan is to get all chromebook related to debian rather then ubuntu [05:47] well, 0047 if you want to zero pad it [05:47] persia, heh [05:47] hrw: I like that plan. How does Debian deploy ucm today? [05:47] and chromebook can fry speakers when wrong switches are enabled in alsa mixer [05:48] persia: so far not found any [05:48] Frying speakers is good: some hardware actually melts. [05:48] hrw, ouch, that seems like..... a very poor design decision [05:48] hrw: Have you asked #debian-arm@OFTC? [05:48] persia: conferences does not help too much to make real work [05:49] hrw: I totally understand (hence you not seeing me last week) [05:49] Err, this last week. [05:50] but today I start few days of vacations in 'still not so cold' Spain [05:50] Heh. Enjoy the last breath of summer. [05:50] if 11°C counts as summer ;d [05:51] lilstevie: I have a feeling that chromebook was released in a rush when I use it [05:51] hrw, probably, like everything is these days [05:52] alsa mixer without restrictions, power usage during suspend-to-ram [05:53] hrw: Anyway, as far as I can remember, we stuck the ucm stuff in libasound2 because it matched /usr/share/alsa/* for the Intel-HDA quirking: if there's a better architecture, then it probably makes sense to abstract out the /usr/share/alsa/cards/* stuff as well. [05:54] But, as mentioned before, that would require additional licensing and documentation files, and I suspect achiang will support the idea of having less of that to ease deployment. [05:54] yep [05:55] persia: hm, i'm not planning on doing anything with chromebooks. :) [05:56] achiang: Yes, but such extra stuff would be on *all* rootfs constructions, which increases the footprint requirements for every install. [05:56] And I thought I remembered you wanting smaller footprints from UDS: my apologies if I'm mistaken. [05:57] ah, yes. sorry, that is still definitely true [05:58] hrw, persia, I asked the alsa guys fi they wanted to carry the ucm stuff and I was told no. [05:59] And really, it is trivial to carry them. [06:00] TheMuso: Do you think it's better to carry them as a distro-patch, or a separate package? [06:00] Having said that, if upstrea were convinced to make another package for all ucm stuff, then I wouldn't object, upstrea being alsa devs. [06:00] * persia is in favour of the distro-patch model [06:00] Me too, only because they are so easy to carry. [06:00] If they were hell to patch in, I'd be pushing for a separate package, but since they are only text files... [06:01] TheMuso: Have you had any discussions with Debian ALSA folk about them? [06:01] persia: As aboev, I asked if debian wanted to carry, and afaicr they said no. [06:01] above* [06:01] Sorry: I read the above as the ALSA project, rather than Debian. I understand now. [06:02] But this stuff is really alsa upstream stuff. [06:02] I need to check the archives to see if any previous discussion was held about sed topic. [06:02] I thought UCM was originally done by ALSA upstream folk, but maybe there's still discussions ongoing there. [06:02] Well they don't appear to carry any ucm files from what I've seen in git. [06:03] persia: UCM was rather ASoC guys stuff [06:03] Liam G., Mark Brown etc [06:05] hrw: Ah, right. I get asoc confused with ALSA sometimes. [06:06] I still remember discussion from Openmoko times about that stuff [06:07] It maybe ASOC but its still part of ALSA. [06:08] Ok this is weird. In /proc/asound/cards on the nexus7, I see an HDA driver loaded for NVIDIA Tegra HDA... [06:09] Hrm? I would have expected tegra-alc5632 [06:09] that isn't totally odd [06:09] same thing on the tf201 [06:09] Sure, there is an rt5xxx card, and the one I mentioned above. [06:10] rt5640 to be exact. [06:10] Oh its for HDMI. [06:10] Interesting: are there actually two different audio interfaces in hardware, both connected to the same speakers/ [06:10] Which is absolutely crazy, given no HDMI out on the Nexus. [06:10] with the tf201 I get HDA NVIDIA Tegra and tegra-codec [06:11] TheMuso, I think it is actually integrated into the SoC [06:11] Does it not have some sort of dock connector, which maybe carries underdocumented HDMI? [06:11] lilstevie: As above, I suspect the second HDA based one is for HDMI. [06:11] Mini USB only for the nexus7 afaik. [06:11] Or micro USB whatever its called. [06:11] the SoC itself supports HDMI [06:11] Silly hardware manufacturers: save money by not exposing ports, limiting functionality. [06:11] it has 2 outputs [06:11] lilstevie: Yeah afaik you can still have an hda codec as part of the SOC. [06:11] LVDS and HDMI [06:12] I haven't looked at the block diagram but you will probably find the HDA codec is somewhere in that [06:12] I know there is something similar with the Tegra 2 [06:12] lsmod shows snd-hda-codec-hdmi loaded on the n7. [06:13] From what I read aon achiang's blog, a new kernel si coming that will disable athat though. [06:13] yeah, on the trimslice it has tegra-trimslice-analog and tegra-trimslice-digital [06:13] A new kernel isn't the right way to do that: it just pushes us further down the path of device-specific kernels. [06:13] I really need a microhdmi cable to test hdmi out with the tf201 [06:14] Yeah but I am surprised they used HDA for HDMI... but it does make sense. [06:14] Better would be to have a framework that lets us blacklist modules based on device name. [06:14] persia, yeah, the tf201 kernel needs a crapload of work before that will become an option though [06:14] They already have to do the legwork for their desktop hardware, so why not incldue it in the SoC. [06:15] lilstevie: Lots of them do, but I still think we want SoC-specific kernels in Ubuntu if we can. [06:15] I'd like ISA-specific kernels, or even architecture-specific kernels, but those are significantly harder targets. [06:15] persia, I agree, an SoC specific kernel would take a crapload of stress off me with tf201 stuff [06:16] In other news, GNOME shell appears not to work on the Nexus 7, I get GNOME fallback. [06:16] microhdmi... I got one yesterday. in a box with some Atom based device [06:16] Off everyone, as the SoC licensor could just push upstream (or to gregkh for LTSI) and nobody would have to reimplement. THe issue being that we don't have any way *other* than kernel patches to turn on or off features on a per-device basis, nevermind the issues with board-bringup on initial boot. [06:16] but at this stage it just isn't possible, stupid kernel cross contamination crap asus have done [06:17] lilstevie: tf201-not-possible, or tegra-not-possible? [06:17] persia, tegra3 transformer not possible [06:17] persia, the best I can probably do is all the tegra 3 transformers into 1 kernel [06:18] That's a huge step forward though. [06:18] yeah, well thankfully the tf201 tf300t and tf700 are very similar devices [06:18] and asus have left much of the code for the other devices in the latest kernel [06:18] have a nice day guys. I go for vacations [06:18] I still need to do a bit more research into what is missing [06:18] Good for them. [06:18] hrw, have fun [06:19] persia, likely situation is they build for all 3 devices from the same tree [06:19] lilstevie: They just need to be convinced to only maintain one kernel. You don't happen to know folk there, do you? [06:19] persia, asus don't like us very much [06:20] and I suspect since July they would be even less likely to open dialogue with me [06:20] /c/c [06:20] lilstevie: Oh well. [06:21] persia, yeah, we kinda really broke their platform :) [06:21] I don't think nvidia would like talking to us either [06:24] persia, not that that matters anyway, I have in the past tried to open communication with them and got ignored === chihchun is now known as zz_chihchun [06:42] TheMuso: we have bugs for gnome-shell === zz_chihchun is now known as chihchun [07:29] major annoyance #1 about the chromebook [07:30] the power button is evidently right where I expect pageupu to be [07:30] also, it doesn't have a page up [07:43] Mapping to Search-UpArrow probably makes sense. That keyboard should have had a function key. [07:46] good morning [07:49] dholbach: morning. [07:49] hey, is there a TI guy in here? [07:50] I remember I had an issue with a TI provided library, and someone was pinged [07:50] but I no longer remember who it was. [07:52] Do you remember which issue? [08:06] persia: yes, various parts of unity didn't work because libgbm shipped via the omap ppa had the wrong version number. [08:22] Just to confirm, this is likely a mesa issue? === doko_ is now known as doko [09:04] yeah. [09:29] Then the person you seek is likely ndec (at least according to my backscroll) [09:55] persia: ahh, yes. I remember it was a short name [09:55] *remembered [09:56] ndec: ping? [09:56] also, it took me 17 minutes to build the spidermonkey shell [09:56] * mjrosenb tries on the pandaboard === chihchun is now known as zz_chihchun [11:00] janimo, did you ping any archive admin about the kernel upload yet ? [11:00] still in NEW [11:06] heh [11:07] * ogra_ sees an armhf package for fastboot ... so i should be able to flash my nexus from my ac100 or chromebook now [11:12] ogra_, I told infinity yesterday [11:12] k [11:13] ogra_, would the x86 one not run under qemu? [11:13] i dont think we have a qemu i386 on arm [11:13] There used to be one: was it disabled? [11:13] iirc i looked at that for last UDS [11:14] persia, a system one probably [11:14] user-mode also, at least at DebConf11, but that was a while ago now. [11:14] for which you would need to run a full VM ... which in turn would eat all my RAM :) [11:14] Get more RAM then (and if it's all soldered, go complain to your manufacturer) [11:15] i had a discussion with one qemu upstream guy back then and he told me there are too many syscals missing for -user mode [11:15] persia, well, i fixed that ram issue on the ac100 [11:15] How? [11:15] by buying a chromebook :) [11:15] * persia fails to see how that fixed the ac100 [11:16] heh [11:16] lol [11:19] mfisch: android-tools are built and published in the ppa:ubuntu-nexus7/ubuntu-nexus7-installer, you can update your blog post =)))) === victorp_ is now known as victorp [12:00] ogra_, I am doing some video test, the nexus7 is really struggling with 720p ogg movie [12:01] i havent tried ogg yet, but that might well be, i doubt there is an ogg omx plugin [12:01] it works fine with h264 mp4 files, at lest it did at aome point for me [12:02] i.e HD movbie trailers [12:06] ogra_, I will try that [12:06] ogra_, different question [12:06] http://www.dvdloc8.com/list_clip.php [12:07] there you should be able to find some h264 HD movie trailersa [12:11] livecd-rootfs (2.94) raring; urgency=low [12:11] * add a dependency on android-tools-fsutils for armhf builds [12:11] * add nexus7 live-build configuration [12:11] * add nexus7 post processing with make_ext4fs for teh tarball to roll a [12:11] proper android img file [12:11] there we go :) [12:12] oh i hate if i typo changelog entries, damned [12:47] I have a beagleboard-xm that runs ubuntu-server. What is the name of the package that I need to install on my laptop (ubuntu 12.10) to cross compile my C code? [12:54] ogra_, hehe [12:55] ogra_, I am using big buck bunny [12:55] much nicer ;) [12:55] anyway I logged a bug for ogg [12:55] is there a way to pull in latest decoders that might speed it up? [12:59] angs, apt-get install gcc-arm-linux-gnueabihf [12:59] angs, trhats the cross compiler [12:59] angs, http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/ [13:09] victorp, sorry, missed your last sentence (life is a bit crazy today over here, lots of people in my house), the codecs come from nvidia, so we wont be able to update unless they release a new version [13:10] ogra_: iirc at uds there was deiscussion to take all linaro crosscomplation pages and make finally some docs for ubuntu ;) [13:10] hrw, yeah, but its not done yet === Ursinha is now known as Ursinha-afk [13:23] ogra_: thank you very much === Ursinha-afk is now known as Ursinha [13:58] ogra_, I am transform it to mp4 h264 and does not playwell [13:58] do you use totem? [13:58] transform ? [13:58] yes, you have to [13:58] using vlc in my pc [13:58] or any othert gstreamer based player [13:58] the nvidia codecs are only available for gstreamer [13:59] totem plays the mp4 well in my laptop but like an old TV in the nexus 7 [14:00] colour all messed up [14:01] well, use a proper mp4 not something you manually transcoded [14:01] i have the simpsons trailer here from the page above [14:01] and that plays fine [14:01] some audio lag sometimes but i blame pulse for that [14:02] hum, do we advise nexus7 users to upgrade? http://www.mattfischer.com/blog/?p=298 [14:02] to me it looks like at least nux and unity will be replaced by unpatched versions then: https://launchpad.net/~ubuntu-nexus7/+archive/ppa [14:02] I'm just asking because it was picked up by http://www.omgubuntu.co.uk/2012/11/ubuntu-for-nexus-7-gets-small-updated [14:11] ogra_, at risk of being bitten, i'd like the broach the subject of some sort of DMI equivalent on ARM. i've heard DeviceTree mentioned [14:13] dholbach, well, -updates and -security are disabled by default (on purpose) but fixes that go to the PPA should be updated, yes [14:14] ogra_, ah ok [14:14] brendand_, yeah, for kernels using DT that could server as a dim like tool [14:14] *dmi [14:14] brendand_, sadly only very few kernels have DT yet [14:14] ogra_, does the n7? [14:14] no [14:14] ogra_, can it/will it? [14:15] if you find someone to port it :) [14:15] there are no plans to port the current kernel anywhere on our side beyond adding fixes to make the HW work better [14:16] but if someone from the community wants to work on a port to i,.e. 3.5 or newer nobody will block him/her [14:20] ogra_, alright. we have some tests that use DMI, but it may be necessary just to skip them if DMI/DT is not available [14:20] right [14:20] ogra_, an example is a test that checks the amount of installed RAM on the system and makes sure the kernel detects it all [14:20] i was working on a lshw fix for that before releaase [14:21] seems it has the dmi check hardcoded as the very first test [14:21] (but there is an option to override that, i was planning to make that a default on arm builds of lshw) [14:21] ... but didnt manage to finish that bit yet [14:22] memory should really not be pulled from DMI anyway, you want it from /proc/meminfo [14:22] ogra_, /proc/meminfo is what the kernel sees, right? [14:22] yep [14:23] dmi is what the BIOS sees [14:23] but arm systems are usually BIOS less [14:23] ogra_, exactly. they should match up after allowing for UMA, right? [14:24] well, the bios data usually only tells you about the RAM modules used etc [14:24] while the values in proc show you the actual currently usable ram [15:01] cwayne, I saw you raised some bugs on video. Did you get any HD video working? [15:02] victorp: i'm trying it again now. i had gotten 720p working for a bit in copenhagen, but haven't tried since [15:02] will keep you updated [15:02] cwayne, I have 720p ogg working but is very very choppy [15:02] http://www.bigbuckbunny.org/index.php/download/ [15:02] ^^ [15:02] victorp: yeah, i saw that, im downloading that file now to test [15:03] but I tried mp4/h264 and I get lots of image corruption [15:03] in my tests before uploading the codecs package it just worked [15:04] using commercial 720p and 1080p trailers for testing [15:24] ogra_, you wont have a link to the actual files? [15:25] not direct, i use them from the site i gave you above [15:26] http://www.dvdloc8.com/view_clip.php?movieid=12167 [15:26] the 720p one should definitely be fine [15:32] ogra_: i think that's what i used in copenhagen and they seemed to work iirc [15:32] yup, same for me [15:33] victorp: need to mute and unmute your video button in the indicator again ;) [15:33] * cwayne tries again [15:33] achiang, what? [15:34] ogra_, downloading now... [15:34] * achiang wonders if victorp knows what a snipe hunt is ... [15:34] achiang, lol [15:37] * cwayne tries out mfisch's kernel while waiting for sample videos to download [15:38] cwayne: great [15:39] janimo, CONFIG_USB_GADGET=m and CONFIG_USB_CDC_COMPOSITE=m [15:39] ogra_, ack [15:39] will add them in the next kernel upload [15:39] ++ [15:39] ogra_, it is not HD though 1280 x 544 [15:40] victorp, its 720p [15:40] I wonder if these are needed by adb too. I could not get adb to connect to an adbd running on ubuntu, maybe this is why [15:40] victorp, the content is 1280 x 544 instead of 1280x720 because its a cinema (16:10) format though [15:41] the black stripes are in the movie as well :) that makes it 720p [15:41] cwayne: this new video from Blender is much more fun than Big Buck Bunny: http://www.tearsofsteel.org/ [15:42] ogra_, ha [15:42] it is not HD is has only 544 horizontal lines [15:42] 1280 x 544 [15:42] http://en.wikipedia.org/wiki/720p [15:43] mfisch: your kernel seems to work! [15:43] cwayne: great [15:43] victorp, how else would you display a 16:10 movie on a 16:9 display ? [15:43] ogra_, I am just talking about how hard is making the hardware work [15:43] its 544 lines of content and 2x88 lines of black [15:44] mfisch, achiang, is it fair to set the brightness bug as "won't fix" since it's working as upstream designed it? the bug doesn't mention the UI, so changing the label on the tickbox seems like a separate task [15:44] still 720p ;) [15:44] ssweeny: which brightness bug? [15:44] cwayne, https://bugs.launchpad.net/ubuntu-nexus7/+bug/884041 [15:44] Launchpad bug 884041 in ubuntu-nexus7 "Screen brightness not adjusted when switching from AC to battery" [High,Confirmed] [15:45] ssweeny: at the very least we need an upstream bug about the confusing wording [15:45] mfisch, i think the wording is tangential to the bug as filed [15:45] i'm going to file a bug with gnome anyway [15:46] but i'm not sure it needs to be attached to this one [15:46] the filer didn't say "I checked this box and it didn't do what I thought". They said "This thing used to work and now it doesn't" [15:46] anyway, I am sending it to the nexus7 and see if it plays without green shades [15:47] ssweeny: i think it could be attached [15:47] if you installed vnc it might have replaced any codecs with its own btw, i'm not sure what vnc pulls in through deps [15:47] and then won't fix'd for nexus7 [15:47] ogra_: +1 i think we should only use totem for video testing for now [15:48] cwayne, vg [15:48] cwayne, i will trust your expert opinion :) [15:48] afaik, vlc brings in a lot of codecs, which is why we don't ship by default i believe [15:48] cwayne, right, or any other gstreamer based player (are there any ?!?) :) [15:49] I am getting checksum failed when downloading the new image [15:49] it can well be that there are still issues with the actual codecs indeed i only did some smoke testing before uploading [15:49] hmm, why is vanhoof not in this channel ? [15:50] hggdh: what if you clear out that directory (~/Downloads/UbuntuNexus7) and try again? [15:50] ogra_, is playing extremely choppy [15:50] cwayne, ^^ [15:50] cwayne: on it [15:50] victorp: which one? ogra_'s? damn i need faster internet, mines still downloading [15:51] victorp, yeah, i fear your vnc installation might have trashed the setup [15:51] cwayne: a look on the dir shows the sha256 file with a date of Oct 26, not today... I wonder [15:52] hggdh: hmm, perhaps its not overwriting as it should... i believe vanhoof may have just fixed that [15:52] cwayne, yes, ogra's [15:52] ogra_, that is just random [15:52] well, it most likely does SW rendering [15:53] so once the queue is full it chops frames out [15:53] and what does vlc have to do with that? [15:53] if you let htop run in a terminal window you should actually see one CPU maxed out if thats the case [15:54] the whole multimedia stack consists of multiple packages [15:54] vlc might have replaced one or the other through a dependency [15:54] htop not in the image [15:54] :( [15:55] apt-get install it :) [15:55] I am just complaining that is not in the image ;) [15:55] we discussed pulling it into the desktop seed for ubuntu during UDS [15:55] shouldnt this tools be pre-install on a dev image? [15:55] seems everyone is using it anyway and we should have the space [15:55] you have top [15:55] its just harder to read [15:56] fewer pretty colors :) [15:56] or we could have a meta packages that install all the debug tools [15:56] * victorp like colors [15:57] ogra_, cores are not maxed out [15:57] cwayne, well, the important part for me is always the total ram usage, nothing shows that as nicely as htop [15:57] ogra_: agreed [15:57] * cwayne <3 htop [15:58] victorp, well, then it uses the omx libs apparently [15:58] fun fact: htop actually starts up slightly faster than top [15:58] it is with the ogg 720p [15:58] for bbb [15:59] cwayne: OK. deleting the sha256 file and re-downloading all causes an Oct 26 sh256 file to be recreated -- and failure ensues [15:59] hggdh: ruh roh [15:59] vanhoof: ^^ [16:00] cwayne, let me know if you get the simpsons running well [16:00] victorp: ack. just finished downloading [16:01] ssweeny: you get an answer re: brightness? my opinion is that we have an opportunity to do better than upstream [16:01] achiang, i can take a look at implementing something if you like [16:03] mine crashes at 9 seconds in victorp... weird [16:03] ssweeny: iow, i think as part of our power savings kick, shouldn't dimming screen make sense? my android phone autodims even when plugged in [16:03]