[07:30] <ppisati> moin
[12:39] <rtg_> ogra_, is dropping luxd all that it took for the ambient light sensor to start working ?
[12:40] <ogra_> rtg_, well, there is definitely also a kernel issue .. but without luxd it wont be exposed as easily (i bet though that you end up with a black screen when moving the brightness slider to zero
[12:40] <ogra_> )
[12:41] <rtg_> ogra_, you probably also lose the automatic adjustment ?
[12:42] <rtg_> I find that it annoys the hell out of on Android 'cause it never gets it right and is always hopping around.
[12:42] <ogra_> well, yeah, but that was supposed to be moved into gnome-settings-daemon anyway, luxd was a hackish interim 
[12:43] <rtg_> ogra_, so ppisati N7 wasn't really broken ?
[12:43] <ogra_> well, there is an issue for sure ... in that our kernel behaves differently once phablet was installed 
[12:44] <ogra_> something redefines the 0 value
[12:44] <ogra_> but you will atm only hit it if you use the brightness slider and pull it to 0 i guess
[12:44] <ogra_> would be good if ppisati could check that 
[12:45] <rtg_> ogra_, sounds pretty low priority unless he's got no other N7 bugs to work on.
[12:45] <ogra_> yeah
[12:46] <ogra_> it might even be that g-s-d catches that and sets it to 1 instead of 0 ... so a test would be welcome 
[12:46] <ogra_> with luck userspace shields us from the bug 
[12:46] <ogra_> (which would make it a non issue for now)
[13:38] <ppisati> ogra_: got a new high priority task assigned, put n7 work on the back burner
[13:38] <ppisati> rtg_: ^
[13:39] <ogra_> well, could you at least do that one test (open the brigfhtness GUI and slide all the way down) ?
[13:39] <ppisati> ogra_: android? phablet? desktop?
[13:39] <ogra_> desktop
[13:40] <ogra_> if the screen doesnt turn fully black with that, we're fine and there is no further work required anyway
[13:40] <ppisati> ogra_: ok, i'll do
[13:40] <ogra_> thx
[13:49] <ppisati> ogra_: ok so
[13:49] <ppisati> ogra_: i pulled the slide down to 0
[13:49] <ppisati> ogra_: and i've a black monolith
[13:49] <ppisati> ogra_: now
[13:49] <ogra_> lol
[13:50] <ppisati> obviously the chance i'll hit the slide again
[13:50] <ogra_> right, so its still serious
[13:50] <ppisati> and bring the brightness to a normal level are 0 now
[13:50] <ogra_> you can indeed do it from cmdline 
[13:50] <ogra_> echoing something into the brightness setting in sysfs
[13:52] <ppisati> ogra_: neee
[13:52] <ppisati> ogra_: i was able to find it again
[13:52] <ogra_> haha, lucky guy
[13:53] <ogra_> well, move on to your important thing ... we can take care later ... 
[13:53] <ppisati> i could still see some shadow on the screen
[13:53] <ogra_> sad, i was hoping we can put it to death
[13:53] <ppisati> ogra_: did you drop luxd in today's img?
[13:54] <ogra_> yes
[13:54] <ppisati> ogra_: nice
[13:54] <ogra_> it was an interim solution anyway ... 
[13:54] <ogra_> gnome-settings-daemon will get that functionality 
[14:18] <bjf> ppisati, did you turn the crank on quantal ti-omap4 after our respin?
[14:18] <ppisati> bjf: not yet
[14:18] <ppisati> bjf: i'll do it now
[14:19] <ppisati> git log -p
[14:19] <ppisati> ops
[14:20] <ogra_> "not a branch"
[14:55]  * ogasawara back in 20
[15:01] <rtg_> jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1154917/comments/5
[15:01] <ubot2> Launchpad bug 1154813 in initramfs-tools "duplicate for #1154917 Boot broken with initramfs-tools 0.103ubuntu0.5b1 - wait-for-root doesn't wait" [Critical,Fix released]
[15:07] <ppisati> bjf: done
[15:08] <bjf> ppisati, thanks
[15:18] <jsalisbury> rtg_, ack, thanks for the info
[15:26] <sconklin> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1097315
[15:26] <ubot2> Launchpad bug 1097315 in xserver-xorg-video-intel "Xorg hangs in drm_helper_connector_dpms" [High,Triaged]
[15:26] <sconklin> https://bugs.launchpad.net/utah/+bug/1092924
[15:26] <ubot2> Launchpad bug 1092924 in utah "Cobbler install of recent raring-desktop images failing" [High,Triaged]
[16:12]  * ppisati goes out for a bit
[17:28]  * rtg_ -> lunch
[17:35] <tjaalton> ogasawara: hey, how about rebasing i915_hsw to 3.8.x, yea/nay? the current version is showing it's age already :/
[18:22]  * cking -> food
[18:23] <rtg_> tjaalton, confused. what are you referring to ?
[18:26] <tjaalton> rtg_: the drm driver for haswell on the quantal kernel, currently based on 3.7-rc6
[18:27] <rtg_> tjaalton, oh, you mean rev the haswell driver in Quantal up to current Linux 3.9-rc2 upstream ?
[18:28] <tjaalton> rtg_: well, to 3.8.x for starters, going further would probably mean (more) issues with drm_*
[18:29] <rtg_> tjaalton, would the fix some specific issues ?
[18:29] <rtg_> would tah*
[18:29] <rtg_> frick
[18:30] <tjaalton> :)
[18:30] <rtg_> thats 325 patches
[18:30] <tjaalton> yes, and enable backporting newer fixes
[18:31] <tjaalton> 3.9rc would be some 250 more :)
[18:31] <rtg_> tjaalton, how about if you just wait for the 3.8 LTS kernel ? or is it Quantal user space you need ?
[18:32] <tjaalton> that's one option yes
[18:32] <tjaalton> so raring kernel + quantal xorg stack
[18:33] <gQuigs> does mtrr_cleanup serve a purpose on a server machine?  is it even still relevant on deskops?
[18:33] <rtg_> tjaalton, I don't think there is _any_ chance that we could SRU 325 patches back into Quantal
[18:33] <gQuigs> related askubuntu question: http://askubuntu.com/questions/244473/how-and-why-should-i-specify-mtrr-gran-size-mtrr-chunk-size
[18:33] <tjaalton> rtg_: well, it is unreleased hw, i915_hsw is only used on hsw
[18:34] <rtg_> tjaalton, except that the haswell fixes are all intertwined with the rest of the i915 driver code
[18:34] <ohsix> if you have a processor that can do PAT, mtrr's aren't very relevant
[18:35] <tjaalton> rtg_: umm, no? it's a separate module in ubuntu/i915
[18:35] <rtg_> tjaalton, lemme refresh my memory. haven't looked at it in awhile
[18:36] <mainerror> ohsix, are there still CPUs there PAT isn't available? I mean it should be available since P3.
[18:36] <mainerror> s/there/where/
[18:37] <rtg_> tjaalton, ok, now I remember. ogasawara copied the whole haswell mess into ubuntu/i915 and restricted the PCI IDs
[18:37] <tjaalton> yep
[18:37] <rtg_> tjaalton, so there are no haswell based systems out there in the real world yet ?
[18:38] <tjaalton> rtg_: nope
[18:38] <rtg_> tjaalton, ok, that makes it easier.
[18:39] <ohsix> mainerror: i have one somewhere, but that was the intent of mentioning it :]
[18:39] <ogasawara> rtg_, tjaalton: so one concern I do have is I pulled the updated driver from an intel specific branch which only contained the patches we supposedly needed for haswell
[18:40] <rtg_> ogasawara, one would assume that all landed in 3.8 ?
[18:40] <ogasawara> rtg_, tjaalton: so I'd be concerned what else we'd get if we pulled the driver directly from v3.8.2.  I'm not opposed to it though since it is pretty well quarantined to just those pci id's
[18:40] <tjaalton> i've created a dkms package and tested that it at least builds against the quantal headers, so rebasing it should be doable
[18:40] <ogasawara> rtg_: yes, I would assume all those patches are in the current 3.8
[18:41] <ogasawara> rtg_, tjaalton: and we do at least haswell platforms to test on
[18:41] <rtg_> tjaalton, does your DKMS driver actually fix some problems ?
[18:41] <gQuigs> ohsix: mainerror:  docs say it's still used as a workaround for X, but I'm not sure that's still true
[18:43] <gQuigs> ohsix: mainerror: if you check both of your dmesgs the current patern is that one of you would have an mtrr error
[18:43] <ohsix> gQuigs: on machines without PAT, and MTRRs that are set up poorly by the bios that might be true; kms may have implications for mtrrs too, id unno
[18:43] <ohsix> \m/ [    0.000000] PAT not supported by CPU.
[18:44] <Sarvatt> rtg_: yeah, the SDP's are decentish but real hardware is coming back with lots of problems fixed in it, especially eDP ones (no surprise)
[18:44] <rtg_> Sarvatt, ok, I'll have a look to see what can be done.
[18:44] <gQuigs> ohsix: :(.. what's your CPU?
[18:45] <tjaalton> ogasawara: yeah, aiui the branch was based on 3.7-rc6, and since you only pulled i915 the rest of the branch churn was likely irrelevant
[18:45] <tjaalton> yeah I was about to mention the eDP issues..
[18:45] <tjaalton> also, powerxpress with fglrx
[18:47] <ohsix> gQuigs: it's an old P3; but it doesn't matter :>
[18:49] <tjaalton> rtg_: there are some issues with the nightly mainline kernel where it just boots up with a blank screen, so testing with them is worthless atm until the issues are fixed. the dkms package allows updating just the module we want to test
[18:50] <tjaalton> 3.8 definitely fixes some issues
[18:50] <tjaalton> with ivb + eDP for instance
[18:51] <tjaalton> i915_hsw won't help there
[18:51] <rtg_> tjaalton, I think ogasawara must have gone a bit further. the last commit in ubuntu/i915 'UBUNTU: SAUCE: i915_hsw: move i915_hsw_enabled symbol to intel_ips' appears to be 68d18ad7fbc16288aa230ec0ffb4416fd4363c87 upstream, which is v3.8-rc2~13^2~7^2~17
[18:52]  * gQuigs didn't realize P3s were still supported
[18:52] <tjaalton> yeah it has some additional fixes
[18:52] <rtg_> or rather 'UBUNTU: SAUCE: drm/i915: set the LPT FDI RX polarity reversal bit when needed'
[18:56] <ogasawara> rtg_: lemme know if you'd prefer I take a first stab at this i915 rebase
[18:57] <rtg_> ogasawara, can you really rebase it? I was just extracting all 52 patches and was gonna apply them mostly by hand.
[18:57] <tjaalton> 52?
[18:57] <rtg_> tjaalton, in the 3.8.2 tree, 'git format-patch 68d18ad7fbc16288aa230ec0ffb4416fd4363c87..HEAD -- drivers/gpu/drm/i915/'
[18:57] <tjaalton> ah
[18:58] <ogasawara> rtg_: I'd go the route of applying by hand
[18:58] <tjaalton> well what I tried was: copy i915/*, re-apply the SAUCE patches by hand, and fix the conflicts
[18:59] <tjaalton> then commit that as the rebase, and any additional ones as new SAUCE patches
[18:59] <tjaalton> for instance, drm_mm_hsw.{c,h} needs a refresh :/
[18:59] <rtg_> tjaalton, but you lose the history
[18:59] <tjaalton> rtg_: true
[18:59] <tjaalton> but only of the rebase
[19:00] <tjaalton> i mean, the first commit didn't carry the history either
[19:00] <ogasawara> rtg_: the other way is you'd have to revert all the patches, copy i915/* like tjaalton said, and then reapply all the sauce patches and fix any conflicts
[19:00] <tjaalton> you don't need to revert them either :)
[19:00] <ogasawara> rtg_: I'd assume it's just as much work as just applying the new ones by hand
[19:00] <tjaalton> although it's probably cleaner/safer to re-do those steps
[19:01] <rtg_> tjaalton, you might be right
[19:02]  * ogasawara lunch
[19:02] <rtg_> tjaalton, though I am loathe to rebase bjf stable tree. we generally don't do that after its released, so there are gonna be lots of messy reverts.
[19:04] <tjaalton> well, you can avoid the reverts if you just copy/re-appy sauce/fix conflicts, then commit the result as le grande rebase
[19:05] <rtg_> yeah, I'll mess with it a bit.
[19:07] <tjaalton> if you want to do it that's fine, but I know what api changes happened in 3.8 so when you give up I can give it a go ;)
[19:14] <rtg_> tjaalton, if you're jonsing to do it. just remember that it can't be a rebase, it has to be a linear application of patches (which may include reverts)
[19:32] <tjaalton> rtg_: ok, I'll keep that in mind
[19:34] <tjaalton> rtg_: but with this approach it's easy to spot the issues, so I'm not stopping you (the kernel team) to do it the right way :)
[19:39] <rtg_> kamal, git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
[19:39] <kamal> rtg_: thanks
[20:06] <tjaalton> rtg_: so, I'm good either way, just let me know
[20:06] <rtg_> tjaalton, go ahead and try it your way. I'm still grovelling around in it.
[20:07] <rtg_> though I gotta take off soon
[20:07] <tjaalton> rtg_: heh, ok something for tomorrow
[20:12] <rtg_> tjaalton, seems that there are some new functions; drm_mm_insert_node_in_range_generic() and drm_mm_insert_node_generic().
[20:12]  * rtg_ -> EOD