| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === zz_chihchun is now known as chihchun | ||
| === chihchun is now known as zz_chihchun | ||
| mjrosenb | so I boot ubuntu-12.04 on my pandaboard | 08:07 |
|---|---|---|
| mjrosenb | and it gets to X, but I don't seem to have any sort of a window manager running | 08:07 |
| mjrosenb | I can right click on the desktop to get a small context menu | 08:07 |
| mjrosenb | but no more menus. | 08:07 |
| mjrosenb | ok, if I run gnome-terminal from ssh, that seems to work | 08:10 |
| mjrosenb | I guess it is just the launcher that is broken/not running. | 08:10 |
| [mbm] | what session are you trying to use? if you're running a *dm you can set the session on the login screen | 08:11 |
| mjrosenb | the default one. | 08:15 |
| mjrosenb | I also set it up to not have a login screen, evidently? | 08:15 |
| mjrosenb | what is the default these days, unity? | 08:16 |
| [mbm] | lightdm | 08:32 |
| mjrosenb | ps says lightdm is in fact running. | 08:37 |
| === doko_ is now known as doko | ||
| hrw | I see (in backlog) that so far we do not got chromebook users here | 09:57 |
| ogra_ | hrw, waiting for mine :) | 09:57 |
| hrw | ogra_: you still use ac100? | 09:58 |
| ogra_ | sure | 09:58 |
| ogra_ | i didnt use it much at UDS but always had it with me | 09:59 |
| ogra_ | i doubt the chromebook will change that, lets see | 09:59 |
| ogra_ | janimo, did you upload the kernel to raring yet ? | 11:19 |
| * ogra_ doesnt see it in any queue | 11:19 | |
| janimo | ogra_, not yet | 11:23 |
| janimo | I wonder if I should keep both quantal and raring branches in git | 11:24 |
| ogra_ | well, essentially the difference should just be in the changelog entry | 11:25 |
| ogra_ | i.e. the distro name | 11:25 |
| ogra_ | http://www.broadcom.com/products/Wireless-LAN/802.11-Wireless-LAN-Solutions/BCM4330 | 11:26 |
| ogra_ | oh, wow | 11:26 |
| ogra_ | i didnt know our wlan chip also has an FM radio builtin | 11:27 |
| ogra_ | i noticed that NM offers WIMAX .... | 11:27 |
| [mbm] | hmm never thought of chromebook; figured they would be locked down and only run chromeos | 11:29 |
| persia | janimo: Better to keep both branches, in case there is a reason to folk based on SRU vs. development release in the future. | 11:29 |
| ogra_ | i think they already offer an ubuntu image | 11:29 |
| ogra_ | persia, there wont be SRUs | 11:30 |
| persia | I heard they took extra effort to make it easy to replace the OS in the Chromebook | 11:30 |
| ogra_ | as soon as we have working raring images we'll mainly care for raring only | 11:30 |
| persia | ogra_: Why not? | 11:30 |
| persia | ogra_: You will. Maybe someone else cares. It's not like an extra git branch is that much overhead. | 11:30 |
| ogra_ | and will ask people to either upgrade or do a fresh install off an "alpha" | 11:30 |
| [mbm] | I remember there was a pc bios for the early chromebooks, just haven't heard anything about the latest | 11:31 |
| persia | (and if apw's new system for universe kernel management happens, it would be nice to be prepared to match it) | 11:31 |
| ogra_ | persia, for only a handfull of chars difference ? | 11:31 |
| ogra_ | i think it is :) | 11:31 |
| ogra_ | its really only the distro name in the changelog entry that should differ | 11:31 |
| persia | It is? I find it more work to *delete* a branch than leave it there, if there are no changes for it. | 11:31 |
| ogra_ | uploads should go simultaneously to both places | 11:31 |
| ogra_ | until we abandon one of them | 11:32 |
| * persia grumbles about policies and compliance and best practices and bows to the inevitable pragmatism that comes when folk believe they have limited developer resources | 11:33 | |
| ogra_ | but currently even an empty package in raring would help me, starting images is blocked on missing a kernel atm | 11:33 |
| ogra_ | haha | 11:33 |
| persia | Why didn't the quantal kernel get copied over when raring opened? | 11:33 |
| ogra_ | because it doesnt exist in quantal | 11:33 |
| persia | Ah. That's a good reason. It's so good that I don't care if there's a quantal branch anymore. | 11:34 |
| ogra_ | we started working on that three weeks before release | 11:34 |
| ogra_ | and the release team had better stuff to do than reviewing new kernels at that time | 11:34 |
| persia | So, in fact, there *shouldn't* be any SRUs: just raring backports. | 11:35 |
| ogra_ | just PPA uploads in fact | 11:35 |
| persia | Why not backports? | 11:35 |
| ogra_ | well, if someone from the backports team wants to care | 11:35 |
| ogra_ | the 12.10 image is largely a throw away thing | 11:36 |
| ogra_ | its heavily hacked in many places and should only serve as a demo | 11:36 |
| ogra_ | the "real thing" will be the raring image | 11:36 |
| persia | ogra_: As I understand it, arranging a backport consists of running `requestbackport packagename` and confirming the test result. But if the image itself is hacked, rather than just the kernel, yeah, nobody should run quantal. | 11:37 |
| ogra_ | the image has -updates,-security and -backports enabled anyway and we dont encourage people to enable them | 11:38 |
| ogra_ | in fact it will break your desktop since yesterday | 11:38 |
| persia | For a demo, that's probably best. | 11:38 |
| persia | I'll stop heckling for now, as the answer to everything will be the same :) | 11:39 |
| ogra_ | (since there is a new unity that overrides our version in the PPA and no intend to update the PPA package) | 11:39 |
| === Sv is now known as sv | ||
| ogra_ | persia, do i read that right that this license allows redistribution as long as nobody sues broadcom because we distributed it ? https://android.googlesource.com/platform/hardware/broadcom/wlan/+/43362466e68ebaed8b7ca5eaf5c9cede8b7a0f57/bcmdhd/firmware/LICENSE.TXT | 11:58 |
| ogra_ | janimo, ^^^ that sounds like we could use it legally | 11:59 |
| ogra_ | to me at least | 11:59 |
| janimo | ogra_, pftt, but I wanted to sue Broadcom! | 11:59 |
| ogra_ | haha | 11:59 |
| janimo | ogra_, I will wait till kernel-team/legal whoever gives a verdict :) | 11:59 |
| ogra_ | yeah, i added a ling to it to the bug | 12:00 |
| ogra_ | *link | 12:00 |
| * janimo installs bash-completion on the nexus7 | 12:00 | |
| ogra_ | brave ! | 12:02 |
| persia | ogra_: I don't read it quite that way. | 12:06 |
| ogra_ | :( | 12:06 |
| persia | 2.3(b) makes me think that it's unsuitable for mirroring | 12:07 |
| persia | Check with the mirrors team, but I suspect it needs to be distributed a different way. | 12:07 |
| ogra_ | sigh | 12:08 |
| persia | Because mirrors distribute Ubuntu under the assumption that they accept no liability in doing so. | 12:08 |
| ogra_ | well, i wonder if thats true for all the closed bits we have | 12:08 |
| persia | The above does not represent legal advice: if actually intending to distribute this software, confer with your own counsel and counsel for any organisations providing hosting services | 12:08 |
| persia | I don't propose to do an audit :) | 12:09 |
| * persia gets in enough trouble for reading licenses already | 12:09 | |
| persia | The provision in 3.2 to promptly report all bugs fails the desert-island test for DFSG too, although the word "reasonable" might be sufficient to make it pass. | 12:10 |
| ogra_ | well, i doubt linux-firmware is anywhere close to DFSG anywaqy | 12:11 |
| persia | I do like the wording of 3.3 though: it doesn't actually discriminate against field of endeavour, but not for lack of trying :) | 12:11 |
| persia | I did review chunks of linux-firmware at some point in the past, and most of it was only modification-restricted. | 12:12 |
| persia | I didn't review all of it, and this was enough years ago that much has probably changed, so you could be right today. | 12:12 |
| ogra_ | i think it had a real audit at some point | 12:13 |
| ogra_ | beyond developers | 12:13 |
| persia | Mind you, modification-restriction makes it non-DFSG-free, but the rest of the tests pass. | 12:13 |
| ogra_ | heh | 12:13 |
| ogra_ | its hard to modify binary blobs anyway | 12:14 |
| persia | The question to ask when being told that is "on whose behalf"? The license you showed me is likely suitable for Canonical to distribute it if Canonical wants, but may not be acceptable to some mirrors. | 12:14 |
| persia | Um, no. That'S why xxd is shipped by default. | 12:14 |
| persia | Anyway, I have a warm bed I wish to use. Ask an archive admin for an official Ubuntu opinion, or ask the mirrors team for a hint if you don't want to bother the archive admins yet. | 12:16 |
| ogra_ | yeah, i asked at the bug, lets see what the kernel team thinks | 12:16 |
| ogra_ | sleep well ! | 12:16 |
| === satellit_ is now known as satellit_e | ||
| ogra_ | janimo, so rtg asks us to not ship it in linux-firmware at all but in our kernel package | 12:41 |
| ogra_ | (there was just a discussion on #ubuntu-kernel) | 12:41 |
| janimo | ogra_, ok. But that has little to do with legality to distribute right? | 12:41 |
| ogra_ | right, just with "pfft its a special device, come back if more people use it" | 12:42 |
| ogra_ | or something along these lines | 12:42 |
| ogra_ | apparently linux-firmware is mostly generated by looking at the mainline kernel and checking for MODULE_FIRMWARE() calls | 12:43 |
| ogra_ | if ours does show up there at some point it will be auto-included | 12:43 |
| ogra_ | (or at least attempted to) | 12:43 |
| janimo | ogra_, I thought this broadcom chip combo was also in quite a few x86 machines | 12:44 |
| ogra_ | i thought so too | 12:44 |
| ogra_ | and theoretically http://linuxwireless.org/en/users/Drivers/brcm80211 should actually work for us | 12:45 |
| ogra_ | (the SDIO driver) | 12:45 |
| janimo | but anyway, we can include it in the kernel | 12:45 |
| janimo | ogra_, is that in 3.1? | 12:45 |
| ogra_ | practically i didnt get it to work, though that might be totally my fault | 12:45 |
| janimo | having a newer kernel would help in many regards I think | 12:45 |
| ogra_ | janimo, in staging iirc | 12:45 |
| === yofel_ is now known as yofel | ||
| ogra_ | janimo, btw, i think our kernel really has a math problem, most numbers i see seems to be doubled up ... i.e. these 600M ram used in hatp, or the charging time in upower -d output | 14:04 |
| ogra_ | *htop | 14:04 |
| janimo | ogra_, where can you see the alternate/real numbers? | 14:06 |
| janimo | does anyone running Android on nexus7 see ambient light having any effect on screen brightness? I keep changing the light or even covering what I think is the sensor aperture but nothing changes | 14:14 |
| mfisch | janimo: I'll ask our team, I think a few have personal devices | 14:25 |
| mfisch | carif: janimo has some questions about the ambient light sensor in Android | 14:30 |
| mfisch | janimo: carif is still running Android | 14:30 |
| carif | mfisch, janimo, pl walk me through the test you want? Shine some light on tne n7 and see if it changes brightness? | 14:32 |
| janimo | carif, well I have no idea what it would take for it to change brightness. That's the issue I see, I don't see a difference in brightness even if it is set to automatic | 14:32 |
| carif | janimo, i have the brightness setting to be automatic and about midway for the slider | 14:34 |
| janimo | carif, I can adjust it manually if automatic is not on though | 14:34 |
| carif | janimo, very good, so you're asking the question what changes the brightness when automatic is actually set? | 14:34 |
| janimo | carif, yes | 14:35 |
| janimo | my experiment in covering the sensor or shining a lamp on the tablet do not seem to have an effect | 14:35 |
| janimo | or if there is one it is unnoticable | 14:35 |
| carif | janimo, i confirm your experiment, i don't know what makes the brightness change however | 14:37 |
| janimo | carif, ok thank for the confirmation | 14:37 |
| janimo | I'll check on another android device too later | 14:37 |
| ogra_ | janimo, no idea, but i simply cant belive we eat over 600M nor are the estimated hours for charging (18h in the beginning, after 4 it dropped to 9h) in upower -d right | 14:40 |
| ogra_ | to me everything seems doubled up | 14:41 |
| janimo | ogra_, so maybe bugs in battery level reporting and memeory measurements are known to not be very accurate :) | 14:41 |
| ogra_ | i also see a constant load of 2.xx | 14:42 |
| ogra_ | but nothing that produces it | 14:42 |
| ogra_ | and iirc marvin24 once added as fix for to high load reporting to the ac100 tree | 14:42 |
| ogra_ | (or nvidia did and he merged it) | 14:42 |
| janimo | ogra_, never heard of this before. If it happened in ac100 then hopefully we can fix it too | 14:44 |
| ogra_ | janimo, bug 985661 | 14:51 |
| ubot2 | Launchpad bug 985661 in linux (Ubuntu) "High load average" [Medium,Triaged] https://launchpad.net/bugs/985661 | 14:51 |
| ogra_ | I can confirm that following commit is responsible: "sched: Fix nohz load accounting" | 14:51 |
| ogra_ | SHA: 3a50863f6706ece7719a68be0ae57957164a0f0c | 14:51 |
| ogra_ | (comment #35) | 14:52 |
| ogra_ | though that claims the breakage was originally added in a 3.2 kernel | 14:52 |
| janimo | ogra_, I think our 3.1 tree has backports of several commits | 14:53 |
| ogra_ | http://thread.gmane.org/gmane.linux.kernel/1310462 | 14:53 |
| * marvin24 can't remember fixing something like this | 15:04 | |
| ogra_ | well, i think it might just have been mentioned in #ac100 | 15:08 |
| ogra_ | or i saw it in a erge in the changelog osr so | 15:08 |
| ogra_ | xnox, the resultimg images from the tools look good, i havent flashed one yet but what the tools produce seems to definitely be fine | 15:11 |
| ogra_ | -rw-rw-r-- 1 ogra ogra 1,7M Nov 7 16:13 test2.img | 15:13 |
| ogra_ | -rw-rw-r-- 1 ogra ogra 6,0G Nov 7 16:12 test.img | 15:13 |
| ogra_ | test2 is the sparse one (both are empty) | 15:13 |
| ogra_ | hmm, producing the saem with ext2simg instead of using img2simg gets it even smaller | 15:14 |
| ogra_ | err, no, bigger | 15:14 |
| ogra_ | misread | 15:14 |
| xnox | ogra_: I'd like to add an autopkgtest for it. Does the test_* utility do anything useful? | 15:29 |
| ogra_ | no idea | 15:29 |
| xnox | ogra_: does it simply need an ext4 image - which can be created on the fly? | 15:29 |
| xnox | ack | 15:29 |
| ogra_ | ogra@anubis:~/Desktop/nexus/builder/tmp$ test_ext4fixup -3 5 rootfs_test.img | 15:29 |
| ogra_ | error: ext4_parse_sb: superblock magic incorrect | 15:29 |
| ogra_ | test_ext4fixup: ext4fixup failed!\n | 15:29 |
| xnox | hmm... | 15:30 |
| ogra_ | well, that one was built with img2simg | 15:31 |
| ogra_ | likely not the right tool for ext4 images if there is edxt2simg ;) | 15:31 |
| ogra_ | xnox, so, hmm ... it even fails with an image properly created using make_ext4fs | 15:32 |
| xnox | interesting so what does test_* thingy suppose to do then? =P | 15:35 |
| ogra_ | heh, i wonder that too | 15:35 |
| ogra_ | i like that it so nicely adds a \n :) | 15:35 |
| ogra_ | in any case the image size isnt acceptable that i get with ext2simg | 15:37 |
| === chihchun is now known as zz_chihchun | ||
| dholbach | hey guys | 15:45 |
| ogra_ | yo ! | 15:45 |
| janimo | dholbach, welcome to ARM :) | 15:46 |
| dholbach | hello ARM hippies :) | 15:46 |
| infinity | This channel sure has gotten busier since UDS. :P | 15:46 |
| ogra_ | heh, yeah | 15:46 |
| ogra_ | infinity, we lost Grue though | 15:47 |
| ogra_ | he went away grumpy yesterday | 15:47 |
| dholbach | bugs 297368 and 1049935 are tagged 'mobile' but are not nexus7 related - do you think it'd make more sense to use a more specific tag than 'mobile'? | 15:48 |
| ubot2 | Launchpad bug 1049935 in modemmanager (Ubuntu) "Crash on connecting Sierra Wireless mobile hotspot" [Low,Incomplete] https://launchpad.net/bugs/1049935 | 15:48 |
| ubot2 | Launchpad bug 297368 in gnome-phone-manager (Ubuntu) "Sony-Ericsson W910i Not Supported in USB Mode" [Undecided,New] https://launchpad.net/bugs/297368 | 15:48 |
| dholbach | I was just reviewing the bug filing instructions on https://wiki.ubuntu.com/Nexus7 | 15:48 |
| ogra_ | achiang, ^^^ | 15:49 |
| janimo | dholbach, I think it should be up to you, you know best practices better and what makes sense globally for ubuntu | 15:49 |
| dholbach | is someone regularly triaging https://bugs.launchpad.net/ubuntu/+bugs?field.tag=mobile and adding the ubuntu-nexus7 task? | 15:49 |
| janimo | mobile was the initial tag but it may have been misused at times | 15:49 |
| ogra_ | dholbach, these tags are most likely 4 years old or older from the original ubuntu-mobile team | 15:49 |
| dholbach | I don't care too much :) | 15:49 |
| dholbach | I was just wondering when I went through the list | 15:49 |
| ogra_ | we used to use that tag before we got renamed to -arm | 15:49 |
| dholbach | luckily enough it's just 2 out of 12 bugs | 15:50 |
| ogra_ | they should all be invalidated actually | 15:50 |
| dholbach | so theoretically we could just leave things as they are and untag the two I mentioned | 15:50 |
| ogra_ | ++ | 15:50 |
| dholbach | ok, WFM | 15:50 |
| achiang | dholbach: as for triaging, we do triage bugs, but mostly in the ubuntu-nexus7 project. | 15:51 |
| achiang | we could start triaging that tag though | 15:51 |
| dholbach | maybe running a script which spits out a list of bugs which are 1) against Ubuntu with tag 'mobile' and 2) not in the ubuntu-nexus7 project might help | 15:52 |
| dholbach | just so we don't overlook bugs filed by testers | 15:52 |
| ogra_ | achiang, well, i thought the idea was to have the tag in raring through apport/ubuntu-bug | 15:59 |
| achiang | right | 15:59 |
| achiang | ubuntu-bug | 16:00 |
| achiang | who is signed up for that WI? :) | 16:00 |
| ogra_ | so future bugs will definitely carry it | 16:00 |
| ogra_ | might be me | 16:00 |
| ogra_ | still wading through WIs this week :) | 16:00 |
| ogra_ | achiang, though we should probably reconsider the choice of "mobile", we might come across some old LPIA cruft :) | 16:01 |
| achiang | ogra_: i don't think i suggested it... ;) | 16:01 |
| * achiang twitches re: lpia | 16:01 | |
| ogra_ | someone suggested it in the discussion | 16:02 |
| ogra_ | cant remember who that was | 16:02 |
| brendand | is anyone interested in a way to see the 'top' entry for a specific binary? | 16:02 |
| NekoXP | surely you'd get that from "ps aux | grep name" | 16:06 |
| NekoXP | or some variant | 16:07 |
| brendand | NexoXP - well yeah, exactly. but it's nowhere near that short | 16:12 |
| brendand | NekoXP, problem is top only accepts PIDs to filter the list | 16:13 |
| brendand | top -p `ps aux | grep $1 | head -n1 | awk '{print $2}'` | 16:13 |
| NekoXP | point taken | 16:14 |
| janimo | infinity, debuild creates a new orig.tar.gz by default if there is no orig. Can it be told to use one of the other compression methods | 16:14 |
| ogra_ | brendand, pgrep ? :) | 16:14 |
| janimo | infinity, I just debuild out of the git tree with no orig at all so far | 16:14 |
| infinity | janimo: Erm, if there's no orig, it builds natively. But yes, I'm pretty sure you can tell it to compress the native package differently in debian/source/options | 16:15 |
| janimo | infinity, thank. I'll check that out | 16:15 |
| infinity | janimo: (Only if using a v3 source format, I suspect) | 16:15 |
| janimo | infinity, yes just switched linux-nexus7 to 3.0 to see how it works | 16:15 |
| janimo | and tought of taking advantage of alternate compressions | 16:15 |
| mfisch | janimo: did you look into the "Dim screen to save power" bug also or just the ambient light bug | 16:15 |
| janimo | mjust the ambient one as I have a WI to enable the get the light sensor in the kernel working | 16:16 |
| mfisch | ok | 16:18 |
| ogra_ | "Your Amazon.co.uk order of "Samsung Chromebook Wifi (L..." has been dispatched" | 16:26 |
| ogra_ | \o/ | 16:26 |
| NekoXP | wow | 16:28 |
| achiang | ogra_: ping re: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1065644 - do we have a theory that it is an nvidia driver problem or a plymouth problem? | 16:49 |
| ubot2 | Launchpad bug 1065644 in ubuntu-nexus7 "plymouth causes a hard reset of the nexus" [Critical,Confirmed] | 16:49 |
| ogra_ | achiang, well all i know is that nvidia recommends to remove plymouth completely because it breaks your system | 16:50 |
| ogra_ | we dont really know which side of the fence is at fault, but i have a WI somewhere to research that | 16:50 |
| achiang | ogra_: hm, so known issue for them | 16:50 |
| ogra_ | right | 16:50 |
| ogra_ | its prominently in their usage docs on developer.nvidia.com | 16:51 |
| ogra_ | (for tegra2/3) | 16:51 |
| ogra_ | achiang, i'll do some debugging and add inof to the bug once i'm through the image build stuff | 16:52 |
| ogra_ | *info | 16:52 |
| achiang | ogra_: np, just going through some of my WIs | 16:53 |
| ogra_ | right, i did the same today :) | 16:53 |
| achiang | ogra_: btw, how do you find your WIs? /me has never really used blueprints before | 16:53 |
| ogra_ | you can check the blueprints you are involved in on your presonal LP page | 16:54 |
| achiang | ok, i've done that | 16:54 |
| ogra_ | what i personally do though is to just take my personal schedule on summit.u.c | 16:54 |
| achiang | but i have to go through the blueprints and then troll for WIs? | 16:54 |
| ogra_ | and go through the sessions i attended | 16:54 |
| achiang | there's no way to automatically see my WIs? | 16:54 |
| ogra_ | ojnce your WIs are proper and the specs are approved you can use status.ubuntu.com though | 16:54 |
| achiang | ah | 16:55 |
| ogra_ | its just inconvenient during the approval phase | 16:55 |
| ogra_ | later it gets easy | 16:55 |
| achiang | hm, i don't appear here - http://status.ubuntu.com/ubuntu-raring/people.html | 16:55 |
| ogra_ | your team isnt on there i guess | 16:56 |
| xnox | achiang: do you have workitems on blueprints that are "accepted for raring" in the series goal? | 16:56 |
| achiang | ah, i was looking at this one -- https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-tablet-desktop-convergence-divergence which does not have it | 16:57 |
| ogra_ | right, it might needs at least one WI in an approved spec for even generating a report | 16:57 |
| achiang | ok | 16:57 |
| ogra_ | http://status.ubuntu.com/ubuntu-raring/u/ogra.html definitely has something for me already | 16:58 |
| achiang | unrelated question: if we're not going to have alphas, when do we expect to start generating dailies? :) | 16:58 |
| ogra_ | ah, no, it doesnt need to be approved, needs to be "accepted for raring" i think | 16:59 |
| ogra_ | achiang, asap | 16:59 |
| janimo | I see x86 already has dailies so we should too. ogra is probably waiting for my kernel upload :) | 16:59 |
| ogra_ | achiang, i would like to get going this week but fiurst need a kernel package ... that takes a bit | 16:59 |
| xnox | achiang: we have dailies. and we are meant to have a fully working set every two weeks. | 16:59 |
| achiang | ogra_: ok, thanks | 16:59 |
| janimo | re firmware I still want to know whether we can ship it | 16:59 |
| ogra_ | janimo, well, for more than that ... | 17:00 |
| janimo | I mean we were told by rtg not to put it in linux-firmware | 17:00 |
| ogra_ | but yeah, kernel is one blocker | 17:00 |
| xnox | achiang: so we don't have alphas just many more littlealphas | 17:00 |
| janimo | but that does not mean we can put it anywhere for that matter | 17:00 |
| xnox | janimo: we are meant to have a bi-weekly testing senergy on a known set. | 17:00 |
| ogra_ | janimo, well, i think the other fw i found in the generic android wlan tree has a looser licence | 17:01 |
| ogra_ | we might be able to ship that, someone has to test if it actually works though :) | 17:01 |
| achiang | xnox: ogra_: which blueprint talks about installer support in ubiquity? | 17:01 |
| ogra_ | it claims to be for 4330 | 17:01 |
| xnox | achiang: huh? ubiquity is the installer.... | 17:02 |
| ogra_ | achiang, https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-ubiquity | 17:02 |
| xnox | achiang: or are you after usb-creator? | 17:02 |
| achiang | xnox: sorry, me english no good, but ogra_ figured out what i was asking ;) | 17:02 |
| ogra_ | xnox, i bet he meant nexus :) | 17:02 |
| xnox | ack. | 17:02 |
| ogra_ | achiang, thats for oem-config though | 17:02 |
| ogra_ | https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-arm-usb-creator-fastboot-support | 17:03 |
| ogra_ | is the installation/flashing | 17:03 |
| achiang | ogra_: ah, ok. i'm just trying to close out as WONTFIX - https://bugs.launchpad.net/ubuntu-nexus7/+bug/1072681 | 17:03 |
| ubot2 | Launchpad bug 1072681 in ubuntu-nexus7 "ubuntu-nexus7-installer should have some logging" [Medium,Confirmed] | 17:03 |
| ogra_ | heh | 17:03 |
| ogra_ | achiang, i commented | 17:04 |
| ogra_ | brendand surely has a point there ... and its easy to add logging to the traball extraction | 17:04 |
| achiang | ogra_: no, he was talking about our zenity installer, not tarball-installer | 17:05 |
| ogra_ | ah | 17:05 |
| ogra_ | well, usb-creator does logging already i think | 17:05 |
| achiang | ogra_: brendand ran into issues with our zenity installer at UDS, but eventually got it working | 17:05 |
| ogra_ | so does oem-config | 17:05 |
| ogra_ | but the tarball installer should surely get some | 17:05 |
| achiang | ogra_: right, and we won't invest anymore time into the zentiy installer | 17:05 |
| achiang | ogra_: sure, file a new bug then. :) | 17:06 |
| ogra_ | k, just close that one then | 17:06 |
| achiang | already done, we spent another 5m talking about it. ;) | 17:06 |
| ogra_ | i wont file a bug, i'll just implement it with the first upload :) | 17:06 |
| ogra_ | oh come on ... you manager you | 17:06 |
| ogra_ | :P | 17:06 |
| achiang | :) | 17:07 |
| ogra_ | does charging the nexus take extremely long for anyone else or is it just me ? | 17:12 |
| xnox | ogra_: yes, but it's quicker if you use "official" cable & plug. | 17:13 |
| ogra_ | probably these 18h it showed me initially were actually correct ... it definitely hangs on the charger since i started my workday | 17:13 |
| ogra_ | xnox, i do | 17:13 |
| ogra_ | its at 41% | 17:13 |
| xnox | hmm =/ | 17:13 |
| ogra_ | after a fukll workday | 17:13 |
| xnox | also I found that the connectors on the nexus are not that good. E.g. the headphones fall-out and the charger disconnects often. | 17:14 |
| ogra_ | ubuntu@nexus7-roccos:~$ upower -d|grep state | 17:14 |
| ogra_ | state: fully-charged | 17:14 |
| ogra_ | ubuntu@nexus7-roccos:~$ upower -d|grep percentage | 17:14 |
| ogra_ | percentage: 41.4464% | 17:14 |
| ogra_ | ubuntu@nexus7-roccos:~ | 17:14 |
| ogra_ | OH ! | 17:15 |
| ogra_ | janimo, there is something wrong here | 17:15 |
| NekoXP | so I have a weird question, has anyone ever seen any sd cards that actually support trim or secure trim or is this just one standard that got stuck on eMMC? | 17:15 |
| * ogra_ guesses thats ckings work | 17:15 | |
| janimo | ogra_, mine is not fully charged but either charging or discharging depending on whether the cable is plugged in or not | 17:18 |
| janimo | ogra_, but probably a bug indeed | 17:18 |
| ogra_ | janimo, well, if you keep the cable plugged it should at some point go to 100% | 17:18 |
| janimo | sure | 17:18 |
| janimo | in a few hours I guess | 17:18 |
| ogra_ | and not think it is fully charged and report 41% :) | 17:18 |
| janimo | 6.0 according to upower | 17:19 |
| ogra_ | and i'm pretty sure after more than 8h charging it should be at 100% it surely was with the former kernel | 17:19 |
| ogra_ | i think chraging it to 100% never took me more than 2h actually | 17:20 |
| ogra_ | so i guess cking has to revisit it :) | 17:20 |
| janimo | any reason I should not use xc compression on the kernel package (besides compressing it being sloow) ? | 17:20 |
| janimo | infinity, ^ ? | 17:20 |
| ogra_ | bootspeed | 17:20 |
| ogra_ | oh, the package | 17:21 |
| janimo | ogra_, the source package | 17:21 |
| ogra_ | not vmlinuz | 17:21 |
| * ogra_ doesnt care | 17:21 | |
| janimo | ogra_, I am not sure whether build servers can handle it, whether it is all stable etc | 17:21 |
| janimo | 60M vs 100M for the sourece tarball | 17:21 |
| ogra_ | well, someone has to try it anyway :) | 17:21 |
| ogra_ | i think we have some xz packages already though | 17:22 |
| ogra_ | and havent seen issues about it on arm | 17:22 |
| ogra_ | iirc xnox had a list in the xz packages session ;) | 17:22 |
| * ogra_ remembers some font package | 17:22 | |
| ogra_ | heh, so my percentage jups back and forth between 41.4464% and 41.4364% | 17:25 |
| ogra_ | doesnt move beyond that | 17:25 |
| achiang | it's trying to converge to 42, of course | 17:27 |
| infinity | janimo: We have lots of xz source packages, infrastructure all deals with it fine. | 17:27 |
| ogra_ | well, if it wouldnt go down to .4364 all the time i would tend to belive that | 17:27 |
| infinity | janimo: It may take longer to decompress at build time, but meh. | 17:28 |
| janimo | ogra_, it does converge on 42 but due to miscalibration you see the values shifted a bit | 17:29 |
| ogra_ | well, i'm pretty sure it sits at 41.xxxx% since more than 1h ... and it thinks its fully charged, if the kernel thinks the same its very unlikely to ever go beyond | 17:30 |
| janimo | ogra_, having android dual boot now to see what it says would sure be handy | 17:30 |
| janimo | are there sys files that can be read, do they say the same thing? | 17:30 |
| ogra_ | you wont find uppower in android : | 17:31 |
| ogra_ | :) | 17:31 |
| ogra_ | /sys/devices/platform/tegra-i2c.4/i2c-4/4-0055/power_supply/battery/ | 17:31 |
| xnox | janimo: with source package - go ahead as much as you want =) | 17:31 |
| janimo | xnox, alright :) | 17:32 |
| xnox | janimo: ubiquity, libreoffice and emacs all do that ;-) | 17:32 |
| janimo | ah, I'm in good company then | 17:32 |
| infinity | libreoffice is hardly "good company". | 17:32 |
| janimo | my sarcasm key ain't working | 17:32 |
| ogra_ | janimo, i'm pretty sure it is caused by d017332e756ba9294679c453431bf39507fd176e in our tree | 17:33 |
| infinity | I thought that's what AltGr was for. | 17:33 |
| infinity | Alternative Grin, or something. | 17:33 |
| janimo | mine is remapped to Facebook Like | 17:33 |
| ogra_ | it wasnt like that in the -6 kernel | 17:34 |
| janimo | ogra_, that is cking's patch to fix reporting | 17:34 |
| infinity | janimo: Damnit, I nearly have a beverage->laptop incident, thanks. | 17:34 |
| janimo | so maybe it had side effects | 17:34 |
| ogra_ | janimo, right | 17:34 |
| infinity | s/have/had/ | 17:34 |
| janimo | infinity, I must try harder next time | 17:34 |
| infinity | janimo: If you want to buy me a new laptop, carry on trying. | 17:34 |
| ogra_ | janimo, wait until you two are in a hangout together so you can record it | 17:34 |
| xnox | ogra_: did you test flashing nexus7 with fs-utils now? | 17:34 |
| * xnox is pondering if it's safe to flash my own nexus using those =) | 17:35 | |
| janimo | infinity, what model doth your heart desire? | 17:35 |
| ogra_ | xnox, no, and i want to back up my rootfs first ... soo many chganges i dont want to lose already | 17:35 |
| infinity | janimo: A T430s to replace my T420s wouldn't hurt my feelings. | 17:35 |
| ogra_ | i'll keep that bit for tomorrow | 17:35 |
| xnox | ogra_: interesting, how do I back it up? | 17:36 |
| xnox | with fast boot? | 17:36 |
| ogra_ | xnox, i think ext2simg is a no go, the image is around 100M bigger than with make_ext4fs | 17:36 |
| xnox | *sigh* | 17:36 |
| ogra_ | xnox, i do boot into the initrd with usb hub attached, on the hub i have kbs and usb key ... then i just dd /dev/mmcblk0p9 into an image file on the usb key | 17:37 |
| janimo | ogra_, maybe the mkfs part does things differently by not emulating what make_ext4fs does? | 17:37 |
| ogra_ | janimo, yeah, i think it compresses bits of the filesystem | 17:38 |
| ogra_ | *filesystem meta data | 17:38 |
| janimo | does things that e2fsutils cannot do? That would be strange, but I know too little about these tools | 17:38 |
| ogra_ | same here | 17:39 |
| xnox | ogra_: was slangasek suggesting some other way of creating sparse images? | 17:39 |
| ogra_ | but slangasek asked me to look into the possibility to only use ext2simg and stick to our existing sparse img creation we already have | 17:39 |
| xnox | at the closing plenery. | 17:39 |
| ogra_ | dd if=/dev/zero of=test.img bs=1M seek=6144 count=0 | 17:39 |
| ogra_ | mkfs.ext4 test.img | 17:40 |
| ogra_ | then i loop mount and cp the tarball into it | 17:40 |
| ogra_ | and then: ext2simg test.img rootfs_test.img | 17:40 |
| ogra_ | thats largely the way we discussed (and the way debian-cd and friends etc use) | 17:41 |
| xnox | ack. | 17:41 |
| ogra_ | ogra@anubis:~/Desktop/nexus/builder/tmp$ ls -lh rootfs_test.img | 17:44 |
| ogra_ | -rw-r--r-- 1 ogra ogra 783M Nov 7 18:43 rootfs_test.img | 17:44 |
| ogra_ | ogra@anubis:~/Desktop/nexus/builder/tmp$ make_ext4fs -l 6G -s rootfs.img mnt/ | 17:44 |
| ogra_ | .... | 17:44 |
| ogra_ | ogra@anubis:~/Desktop/nexus/builder/tmp$ ls -lh rootfs.img | 17:44 |
| ogra_ | -rw-r--r-- 1 ogra ogra 646M Nov 7 18:44 rootfs.img | 17:44 |
| ogra_ | quite a size difference | 17:45 |
| ogra_ | content is identical | 17:45 |
| ogra_ | i suspect make_ext4fs does something like compressing the unused inode tables or so which fastboot uncompresses while flashing | 17:46 |
| janimo | ogra_, uploaded kernel and meta packages to raring NEW. I hope it builds. I just remembered I tested on quantal only. This bit me recently with precise/quantal gcc switch. Oh well | 17:53 |
| ngharo | Does anyone have a minimal nexus7 rootfs image floating around? | 17:54 |
| ogra-nx7 | janimo, thanks so much ! | 17:54 |
| ogra-nx7 | ngharo, not to my knowledge | 17:54 |
| NekoXP | I am having the weirdest experience here | 18:29 |
| NekoXP | mkdir qm && mount /dev/sde2 qm && mount /dev/sde1 qm/boot && umount /dev/sde? | 18:29 |
| NekoXP | the qm directory disappears | 18:29 |
| NekoXP | unity is deleting it because it assumes if I mount it manually that it's the same as being in /media and being removed | 18:30 |
| NekoXP | can anyone reproduce that quickly on something safe? I dunno if I found a bug or if I'm being a moron about something | 18:30 |
| NekoXP | also this is precise and I can't get a quetzal running to test :D | 18:30 |
| === Ursinha-afk is now known as Ursinha | ||
| r0k5t4r | hi, I have a gooseberry running ubuntu 12.04 armhf and the loadaverage is at 2.x just after boot.. The system is idle. I have no clue what is going on but other users have no problems with the system load at all... | 18:43 |
| mfisch | achiang & ssweeny: I'm picking this bug up: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1071259 | 18:49 |
| ubot2 | Launchpad bug 1071259 in ubuntu-nexus7 "Setting brightness all the way down actually switches off the display completely" [Medium,Confirmed] | 18:49 |
| achiang | mfisch: cool, i'm assuming we're using the normal process of assigning to ourselves, etc. | 18:51 |
| janimo | ogra_, see the 2.0 loadaverage happening above too^ | 18:58 |
| janimo | r0k5t4r, that is seen on the nexus7 as well | 18:58 |
| janimo | with 12.10 | 18:58 |
| mfisch | achiang: yes | 18:59 |
| r0k5t4r | janimo: ok, thought I'm the only one as others on the gooseberry forum didn't report this | 18:59 |
| janimo | r0k5t4r, what kernel are you using? | 19:00 |
| r0k5t4r | janimo: 3.0.36 | 19:03 |
| janimo | r0k5t4r, what source? Is there a goosberry kernel and you built it using Ubuntu's gcc? | 19:04 |
| === Ursinha-afk is now known as Ursinha | ||
| r0k5t4r | janimo: I downloaded the ubuntu image from someones dropbox account. there was a link on the gooseberry forum | 19:04 |
| janimo | ok | 19:05 |
| r0k5t4r | janimo: The users account on the gooseberry forum was alanb and i just saw that here is some called AlanBell... It can hardly be a coincidence :) | 19:06 |
| r0k5t4r | janimo: brb | 19:06 |
| AlanBell | r0k5t4r: oh? | 19:07 |
| AlanBell | I suspect it is a coincidence, I am AlanBell in most places | 19:07 |
| === Ursinha_ is now known as Ursinha-afk | ||
| r0k5t4r | AlanBell: :) sorry | 19:19 |
| AlanBell | thats fine :) | 19:19 |
| AlanBell | what is the gooseberry forum? | 19:20 |
| AlanBell | oh, right, that certainly isn't me, I don't have one of those, I have a raspberry pi and a nexus 7 (well, my family has the nexus 7, I am not allowed to play with it) | 19:21 |
| AlanBell | play/break | 19:22 |
| yofel | are there any howto's for making a VM with a nexus 7 environment in it? | 19:23 |
| r0k5t4r | AlanBell: you are lucky not to have one. I have one since day one and there is really nothing that really works except the default android that comes with it | 19:24 |
| mfisch | yofel: why would you want to? | 19:44 |
| mfisch | achiang: ping | 19:45 |
| mfisch | yofel: it's just the standard ubuntu desktop on arm, minus thunderbird and open office | 19:45 |
| achiang | mfisch: pong | 19:46 |
| yofel | mfisch: well, I would prefer to have something where I could build packages in. Other than the actual tablet itself | 19:46 |
| mfisch | achiang: an update on the brightness issue, it seems to be up to the device that at brightness 0 you can still see the screen | 19:46 |
| mfisch | yofel: give me 5 mins and I can help | 19:46 |
| yofel | sure :) | 19:46 |
| mfisch | achiang: what I mean is that on my laptop and the other ARM device I have, you can still see the screen when brightness is set to 0 | 19:47 |
| mfisch | achiang: I can take it to 0, which also implies that the brightness control has no hard stop at say, 1 | 19:47 |
| achiang | mfisch: that's interesting. maybe we need to add logic to our brightness controller that can figure out what "0" actually means and then set in a minimum if necessary | 19:47 |
| achiang | if we can't figure that out dynamically, then perhaps we should add a quirk system | 19:48 |
| mfisch | achiang: yeah, I'll poke around some more, but best I can figure now is that we need to hard stop at 1 for this device | 19:48 |
| mfisch | yep | 19:48 |
| mfisch | yofel: have you used a pbuilder before? | 19:48 |
| yofel | yes, I'm a kubuntu packager so I know that part | 19:49 |
| yofel | I just have very little ARM experience | 19:49 |
| mfisch | yofel: so we're recommending people just setup an armhf pbuilder | 19:49 |
| mfisch | yofel: you can install pbuilder-scripts which came from Canonical and it will make life significantly easier | 19:50 |
| mfisch | pcreate -a armhf -d quantal <pbuilder name> | 19:50 |
| mfisch | and when that's done | 19:50 |
| mfisch | ptest <pbuilder name> gives you a shell inside a qemu chroot | 19:50 |
| mfisch | ptest -p <pbuiler name> ^^ | 19:50 |
| mfisch | writing up notes on pbuilder scripts is on the to do list | 19:51 |
| yofel | pbuilder image is being created, thanks! | 19:51 |
| mfisch | np | 19:51 |
| mfisch | yofel: did I talk to you at UDS? | 19:51 |
| mfisch | in the bar at the closing | 19:52 |
| yofel | impossible, I wasn't there ;) | 19:52 |
| mfisch | okay, I met the rest of your Kgang though | 19:52 |
| yofel | heh | 19:52 |
| achiang | mfisch: where's the pad re: memory debugging? i'll work on writing up the wiki page today | 19:56 |
| mfisch | achiang: looking | 19:57 |
| mfisch | achiang: http://summit.ubuntu.com/uds-r/meeting/21394/how-do-i-know-my-code-is-not-consuming-too-much-memory/ | 19:58 |
| achiang | thanks | 19:58 |
| === Ursinha_ is now known as Ursinha-afk | ||
| mfisch | achiang: does ARM have a sys firmware interface analogous to ACPI? | 20:05 |
| achiang | not really | 20:05 |
| achiang | there is device tree | 20:05 |
| achiang | but i think that is more for topology | 20:06 |
| achiang | acpi covers so many bases | 20:06 |
| mfisch | what about SMBIOS/DMI? | 20:06 |
| achiang | i don't know if device tree allows you to query for capabilities | 20:06 |
| achiang | those are both x86 specs | 20:06 |
| achiang | the best i've been able to find on ARM is lsusb | 20:07 |
| mfisch | just wondered if there was an analog | 20:07 |
| achiang | :-/ | 20:07 |
| mfisch | there's an entry in sys called "bl_power", and even the great wiki page I found doesn't know what it's supposed to do | 20:08 |
| achiang | well the way sysfs works, any vendor can create any entry there | 20:10 |
| achiang | so that may (or may not) be a standard interface | 20:10 |
| achiang | it can be hard to tell | 20:10 |
| achiang | where does bl_power live? | 20:10 |
| achiang | full path | 20:10 |
| mfisch | /sys/class/backlight/<device>/ | 20:11 |
| mfisch | it's set to 0 on every device i've tried, I was hoping it would be useful | 20:12 |
| mfisch | but I'm doubting it | 20:12 |
| achiang | achiang@yew:~$ cat /sys/class/backlight/intel_backlight/bl_power | 20:12 |
| achiang | 849009384 | 20:12 |
| achiang | achiang@yew:~$ cat /sys/class/backlight/acpi_video0/bl_power | 20:12 |
| achiang | 0 | 20:12 |
| mfisch | interesting | 20:13 |
| mfisch | I only have the acpi_video0 on my amd64 box, the 2 ARM devices have "pwm-backlight" | 20:13 |
| mfisch | achiang: does bl_power change as you change the display brightness? | 20:16 |
| achiang | nope | 20:17 |
| mfisch | oddly if I set mine to 1, the display turns off | 20:18 |
| === Ursinha_ is now known as Ursinha-afk | ||
| mfisch | achiang: I found docs: http://www.mjmwired.net/kernel/Documentation/ABI/stable/sysfs-class-backlight | 20:19 |
| achiang | ok, so /sys/class/backlight/acpi_video0/brightness echos the current status of my backlight | 20:20 |
| mfisch | yep | 20:22 |
| mfisch | and you can echo to it | 20:22 |
| mfisch | my laptop goes from 0-20, the N7 is 0-255 | 20:22 |
| mfisch | the other ARM device is 0-7 | 20:22 |
| mfisch | achiang: squirrel this away in your notes: https://wiki.kubuntu.org/Kernel/Debugging/Backlight | 20:23 |
| achiang | interesting but too x86 focused | 20:25 |
| achiang | those are all acpi assumptions | 20:25 |
| mfisch | yep | 20:25 |
| NekoXP | bl_power is the on/off switch for backlight. the value is kind of meaningless | 20:26 |
| === Jack87 is now known as Jack87|Away | ||
| NekoXP | but on and off for backlight are different from brightness. brightness 0 is the *lowest* brightness it can have, and most backlight controllers have a lower safe limit of operation on PWM frequency and period. | 20:28 |
| NekoXP | so what we have is a PWM period control button which is abstracted to a set of reasonable levels (0-7 or 0-20 or 0-255) and a PWM off button which disables anything going out. Actually cutting power would be done via regulators, and the backlight driver may do this or may not (on ACPI it's hidden, so.. ) | 20:29 |
| NekoXP | what are you trying to do? :) | 20:29 |
| mfisch | NekoXP: brightness 0 on the Nexus7 turns the display full off | 20:35 |
| mfisch | NekoXP: which makes it challenging to get lit back up, unless you don't move your finger | 20:35 |
| NekoXP | this is just how LCD panels work. It's a little window with a liquid crystal in front of it. The liquid crystal turns from clear to black when voltage is applied. But, if you don't shine light through the window, you don't see anything | 20:36 |
| NekoXP | brightness 0 could mean anything to different backlight implementations, but what it usually means is the lowest possible PWM frequency | 20:37 |
| mfisch | It seems of the devices I've tried that they have set 0 to be "still on" to avoid this | 20:37 |
| NekoXP | that may be a "safe" low PWM value to not have to actually tear down a PWM controller or disable a clock, but it may be lower than you actually need to turn a lught on | 20:37 |
| NekoXP | lets get technical. I have a panel here that says it has an upper and lower bound pwm period for safe operation, and a minimum and maximum frequency. the frequency generally doesn't change (although depending on he backlight, it may). the important thing is the period. | 20:38 |
| NekoXP | all it does is turn on and off fast enough that the device at the other end feels like it's getting a constant power, but it actually isn't. for an LED it doesn't just go on and off, it turns on and it needs to warm up a bit, so the light is not instant. and turning off, it will actually fade a little before turning completely off. | 20:39 |
| NekoXP | that gives you varying levels of brightness, and the trick is not to have it flicker because of the fading | 20:40 |
| NekoXP | but, you can't just say don't generate a pwm waveform, you have to actually supply enough power for it to not drop out completely, which means just a low period. that's why you have a 0 (which may be no light coming out) *and* a power on/off. | 20:42 |
| mfisch | ok | 20:42 |
| NekoXP | some backlight controllers spec that you can't turn them completely off via pwm, some do. it's implementation dependent in the driver *and* the hardware | 20:42 |
| mfisch | so that all makes sense | 20:43 |
| NekoXP | also the power off switch may turn off the pwm controller, disable it's parent clock so it doesn't soak power itself, and disable the regulator feeding the supply for the backlight anyway | 20:43 |
| mfisch | and I think the fix from a user-experience POV will be to not allow the brightness controller to go to 0 on this device, in whatever form that takes | 20:43 |
| NekoXP | you shouldn't do that with just a request for brightness 0, even if it "feels" like it's doing that. | 20:43 |
| NekoXP | on the N7 what's the driver called again? | 20:43 |
| NekoXP | maybe pwm_bl or something? or tegra_pwm_bl? it's the name of the /sys/class/backlight/<thing> | 20:44 |
| mfisch | pwm-backlight is what's in /sys/class/backlight | 20:45 |
| NekoXP | okay so probably there is a control in the board support file platform data that supplies the frequencies, periods etc. it needs | 20:46 |
| NekoXP | I need a copy of the N7 kernel.. hang on :D | 20:46 |
| NekoXP | ah no, here it is | 20:47 |
| NekoXP | drivers/video/backlight/pwm_bl.c:51 | 20:48 |
| NekoXP | if (brightness == 0) { | 20:48 |
| NekoXP | pwm_config(pb->pwm, 0, pb->period); | 20:48 |
| NekoXP | pwm_disable(pb->pwm); | 20:48 |
| NekoXP | } else { | 20:48 |
| NekoXP | brightness = pb->lth_brightness + | 20:48 |
| NekoXP | (brightness * (pb->period - pb->lth_brightness) / max); | 20:48 |
| NekoXP | pwm_config(pb->pwm, brightness, pb->period); | 20:48 |
| NekoXP | pwm_enable(pb->pwm); | 20:48 |
| NekoXP | } | 20:48 |
| NekoXP | ^^ this is so wrong I can't describe, but it does actually disable the pwm | 20:48 |
| NekoXP | it's still drawing power technically (leaking at least) but there's no waveform going out to the backlight at 0. acpi etc. stuff, 0 doesn't mean off it means first in a list of values passed back by some call to _BLQ or something | 20:49 |
| mfisch | NekoXP: what's in the board support file? | 20:50 |
| NekoXP | period, brightness default, "top" brightness, max brightness value.. that kind of thing | 20:50 |
| NekoXP | I was wrong in that it would be controlled by the board file, whatever you do there, the backlight driver itself will turn off the pwm at brightness 0 which is despicable :) | 20:51 |
| NekoXP | there are two options.. one of which depends on kernel version | 20:52 |
| NekoXP | firstly, modify the userspace that is controlling the backlight, probably gnome-power-manager, to never set 0 if the backlight name is pwm-backlight. Then you have to figure how you turn the backlight off in any case.... but it should be kicking bl_power for that. I'd need to look at gpm | 20:53 |
| NekoXP | second, modify pwm_bl.c so that it says if (brightness == 0 && !machine_is_nexus7()) { or something similar. That really depends on if you can even tell it's the nexus 7 inside the driver... :D | 20:53 |
| NekoXP | if it's a device tree kernel you might have to do a string match on probe, and store a little value to change behavior and check for that value, which is clumsy as hell | 20:54 |
| NekoXP | the behavior of pwm_bl just seems not to be correct, this is kind of a bug I would think. I bet the driver was written before bl_power was implemented. | 20:56 |
| NekoXP | it's been updated to take it into account but it hacks it above those lines; | 20:56 |
| NekoXP | if (bl->props.power != FB_BLANK_UNBLANK) | 20:56 |
| NekoXP | brightness = 0; | 20:56 |
| NekoXP | if (bl->props.fb_blank != FB_BLANK_UNBLANK) | 20:56 |
| NekoXP | brightness = 0; | 20:56 |
| NekoXP | this is wrong. it should deal with power off completely differently. | 20:56 |
| NekoXP | lth_brightness should be involved here; | 20:57 |
| NekoXP | I just saw a patch for DT kernels that adds this; https://lkml.org/lkml/2012/9/26/271 | 20:57 |
| NekoXP | brightness == 0 should be setting the low threshold brightness | 20:58 |
| NekoXP | props.power or props.fb_blank should unconfig the pwm | 20:58 |
| NekoXP | not a mishmash of the two | 20:58 |
| NekoXP | can you tell I spent weeks crying over how awful backlight support is on the linux kernel? we still have problems with our stuff and that godforsaken driver :D | 21:00 |
| NekoXP | mfisch, so, ultimate solution, add lth_brightness to board support or device tree if possible, based on the panel spec. I doubt you have that.. but.. oh well. A good guess might suffice. And fix pwm_backlight_update_status() to deal with the blanking and power controls independently, and NOT just set the brightness to 0. That brightness thing actually meant on our systems that we had to add a copy of the "previous" brightness to come back out from standb | 21:01 |
| NekoXP | y and set the correct brightness value (otherwise it would come back and it would be "off") | 21:01 |
| mfisch | NekoXP: someone just called me, so hold on a sec | 21:01 |
| NekoXP | http://pastebin.com/gYdPs0fV | 21:08 |
| NekoXP | I didn't compile check it or even test it, but that might be a more favorable behavior | 21:08 |
| NekoXP | even if you set the brightness to 0 it will always be the minimum duty cycle. if you tweak bl_power it will unconfig the pwm... and config it again with the stored brightness... | 21:09 |
| NekoXP | I'd need to fully test the userspace that goes with it to be sure what it tries to do | 21:10 |
| NekoXP | but there's your start | 21:10 |
| NekoXP | you would have to be sure lth_brightness is set somewhere though :] | 21:10 |
| mfisch | NekoXP: I'll catch up in about 30 mins, long phone call then I'm stepping out for a bit | 21:16 |
| NekoXP | I might be gone in 30 mins :] | 21:17 |
| === Ursinha_ is now known as Ursinha-afk | ||
| achiang | i think we should put a quirk in the kernel, not in userspace | 21:30 |
| * mfisch catches up | 22:04 | |
| mfisch | achiang: do you know how to do that process? | 22:04 |
| === nijaba_ is now known as nijaba | ||
| NekoXP | mfisch, apply that patch, thats the starting poiint, but I don't have the nexus7 kernel ubuntu guys are using nor a nexus 7 to test (actually one of the staffers here does but I doubt he will install ubuntu on it) | 22:12 |
| NekoXP | the pwm_bl driver is dead to rights wrong in it's behavior so it needs fixing | 22:12 |
| mfisch | ok | 22:13 |
| mfisch | NekoXP: I'll give it a shot today or tomorrow | 22:13 |
| mfisch | NekoXP: thanks | 22:14 |
| NekoXP | no guarantees, but it should at least stop it from being able to set brightness = 0 and turn off the backlight. that will only happen now if the bl_power is tweaked. brightness = 0 still could be black though or barely visible.. this is a tweak you need to figure out based on usage ;) | 22:15 |
| NekoXP | lth_brightness definitely needs to be set (it'll be in mach-tegra/board-nexus7.c or something or a device tree) for it to work otherwise brightness = 0 is still pwm off, but it will actually be running under minimum duty cycle which COULD damage a backlight | 22:16 |
| NekoXP | be warned | 22:16 |
| NekoXP | you could set it to 10 and should be fine. 13 if you want to be safe. I've never seen a panel say it had a higher minimum duty cycle than 12.5% | 22:16 |
| mfisch | ok | 22:16 |
| NekoXP | hopefully asus gave it a good value to start | 22:17 |
| NekoXP | but that's a percentage so 10% brightness is as low as it goes.. that may still be "too bright". you'd need the panel specs. | 22:17 |
| NekoXP | I'm sure they're online somewhere. | 22:17 |
| NekoXP | anyway I'm off home | 22:17 |
| mfisch | ok | 22:18 |
| NekoXP | have fun, I'm sure there are people around here who can help at some point | 22:18 |
| mfisch | have a nice day | 22:18 |
| === SteveRiley_ is now known as SteveRiley | ||
| cwayne | mfisch: ping | 22:46 |
| mfisch | cwayne: yo | 22:50 |
| cwayne | mfisch: isnt this fixed in our image? https://bugs.launchpad.net/ubuntu-nexus7/+bug/1055949 | 23:05 |
| ubot2 | Launchpad bug 1055949 in unity (Ubuntu) "Unity panel shadow appears as solid black bar on GLES/ARM (Pandaboard, Nexus 7)" [Medium,Confirmed] | 23:05 |
| mfisch | cwayne: I was going to ask you about that one | 23:10 |
| cwayne | mfisch: afaik its fixed in ours, but not upstreamed yet. I'm gonna mark it fix committed on our project | 23:10 |
| mfisch | cwayne: is it in image? | 23:12 |
| mfisch | cwayne: or in the public PPA? | 23:12 |
| mfisch | if so mark it released | 23:12 |
| cwayne | mfisch: in the image, may be in the ppa as well, let me check | 23:12 |
| mfisch | and note when it was fixed "fixed in first release" | 23:12 |
| mordicchio_ | hello | 23:18 |
| mfisch | hi | 23:23 |
| mordicchio_ | excume me can i ask you a question= | 23:30 |
| mordicchio_ | ? | 23:30 |
| k1l_ | mordicchio_: go ahead | 23:32 |
| mordicchio_ | i m searching a irc client for my raspberry pi | 23:33 |
| mordicchio_ | can you help me? | 23:33 |
| k1l_ | mordicchio_: see the topic :) better ask in #raspbian | 23:35 |
| persia | With the emergence of our armhf environment, was the downgrading of the armel environment sufficient to run on a Pi? | 23:36 |
| slangasek | persia: yes, but a) pi wasn't the target of that downgrade, b) the fact that armel is v5 instead of v6 makes it largely uninteresting, c) there's no kernel in the archive or image for it, d) armel is going away now | 23:50 |
| persia | What's the rationale for d)? c) is fixable in the meantime. | 23:50 |
| slangasek | persia: the rationale for d) is that we have no rationale for not-d | 23:51 |
| persia | So, lack of users? | 23:51 |
| slangasek | armel was always intended to go away once armhf was on its feet | 23:51 |
| slangasek | the armv5 rebuilt was a speculative repurposing for a contract that never panned out | 23:52 |
| slangasek | s/rebuilt/rebuild/ | 23:52 |
| persia | Ah, Canonical doesn't want to host the buildds, and there's not lots of protest about it. That makes sense as a rationale for d) | 23:52 |
| slangasek | right | 23:52 |
| slangasek | rather, we want to host the buildds but want them to be armhf buildds ;) | 23:53 |
| persia | I say that's effectively the same as saying there's a desire not to host armel buildds :) | 23:53 |
| persia | In that case, I suppose I oughtn't push kirkwood kernels and migrate those devices to Ubuntu. | 23:54 |
| slangasek | unless you want to stick with 12.10, probably not | 23:54 |
| * persia still has devices running 9.10 as a result of participating in discussions with folk who were less forthcoming, and doesn't especially want to repeat | 23:54 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!