[07:30] moin === jibel_ is now known as jibel === yofel_ is now known as yofel === amitk is now known as amitk-afk [12:39] ogra_, is dropping luxd all that it took for the ambient light sensor to start working ? [12:40] 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] ) [12:41] ogra_, you probably also lose the automatic adjustment ? [12:42] I find that it annoys the hell out of on Android 'cause it never gets it right and is always hopping around. [12:42] well, yeah, but that was supposed to be moved into gnome-settings-daemon anyway, luxd was a hackish interim [12:43] ogra_, so ppisati N7 wasn't really broken ? [12:43] well, there is an issue for sure ... in that our kernel behaves differently once phablet was installed [12:44] something redefines the 0 value [12:44] but you will atm only hit it if you use the brightness slider and pull it to 0 i guess [12:44] would be good if ppisati could check that [12:45] ogra_, sounds pretty low priority unless he's got no other N7 bugs to work on. [12:45] yeah [12:46] 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] with luck userspace shields us from the bug [12:46] (which would make it a non issue for now) [13:38] ogra_: got a new high priority task assigned, put n7 work on the back burner [13:38] rtg_: ^ [13:39] well, could you at least do that one test (open the brigfhtness GUI and slide all the way down) ? [13:39] ogra_: android? phablet? desktop? [13:39] desktop [13:40] if the screen doesnt turn fully black with that, we're fine and there is no further work required anyway [13:40] ogra_: ok, i'll do [13:40] thx [13:49] ogra_: ok so [13:49] ogra_: i pulled the slide down to 0 [13:49] ogra_: and i've a black monolith [13:49] ogra_: now [13:49] lol [13:50] obviously the chance i'll hit the slide again [13:50] right, so its still serious [13:50] and bring the brightness to a normal level are 0 now [13:50] you can indeed do it from cmdline [13:50] echoing something into the brightness setting in sysfs [13:52] ogra_: neee [13:52] ogra_: i was able to find it again [13:52] haha, lucky guy [13:53] well, move on to your important thing ... we can take care later ... [13:53] i could still see some shadow on the screen [13:53] sad, i was hoping we can put it to death [13:53] ogra_: did you drop luxd in today's img? [13:54] yes [13:54] ogra_: nice [13:54] it was an interim solution anyway ... [13:54] gnome-settings-daemon will get that functionality === amitk-afk is now known as amitk [14:18] ppisati, did you turn the crank on quantal ti-omap4 after our respin? [14:18] bjf: not yet [14:18] bjf: i'll do it now [14:19] git log -p [14:19] ops [14:20] "not a branch" [14:55] * ogasawara back in 20 [15:01] jsalisbury, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1154917/comments/5 [15:01] 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] bjf: done [15:08] ppisati, thanks [15:18] rtg_, ack, thanks for the info === lfaraone_ is now known as lfaraone [15:26] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1097315 [15:26] Launchpad bug 1097315 in xserver-xorg-video-intel "Xorg hangs in drm_helper_connector_dpms" [High,Triaged] [15:26] https://bugs.launchpad.net/utah/+bug/1092924 [15:26] 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] 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] tjaalton, confused. what are you referring to ? [18:26] rtg_: the drm driver for haswell on the quantal kernel, currently based on 3.7-rc6 [18:27] tjaalton, oh, you mean rev the haswell driver in Quantal up to current Linux 3.9-rc2 upstream ? [18:28] rtg_: well, to 3.8.x for starters, going further would probably mean (more) issues with drm_* [18:29] tjaalton, would the fix some specific issues ? [18:29] would tah* [18:29] frick [18:30] :) [18:30] thats 325 patches [18:30] yes, and enable backporting newer fixes [18:31] 3.9rc would be some 250 more :) [18:31] tjaalton, how about if you just wait for the 3.8 LTS kernel ? or is it Quantal user space you need ? [18:32] that's one option yes [18:32] so raring kernel + quantal xorg stack [18:33] does mtrr_cleanup serve a purpose on a server machine? is it even still relevant on deskops? [18:33] tjaalton, I don't think there is _any_ chance that we could SRU 325 patches back into Quantal [18:33] related askubuntu question: http://askubuntu.com/questions/244473/how-and-why-should-i-specify-mtrr-gran-size-mtrr-chunk-size [18:33] rtg_: well, it is unreleased hw, i915_hsw is only used on hsw [18:34] tjaalton, except that the haswell fixes are all intertwined with the rest of the i915 driver code [18:34] if you have a processor that can do PAT, mtrr's aren't very relevant [18:35] rtg_: umm, no? it's a separate module in ubuntu/i915 [18:35] tjaalton, lemme refresh my memory. haven't looked at it in awhile [18:36] ohsix, are there still CPUs there PAT isn't available? I mean it should be available since P3. [18:36] s/there/where/ [18:37] tjaalton, ok, now I remember. ogasawara copied the whole haswell mess into ubuntu/i915 and restricted the PCI IDs [18:37] yep [18:37] tjaalton, so there are no haswell based systems out there in the real world yet ? [18:38] rtg_: nope [18:38] tjaalton, ok, that makes it easier. [18:39] mainerror: i have one somewhere, but that was the intent of mentioning it :] [18:39] 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] ogasawara, one would assume that all landed in 3.8 ? [18:40] 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] 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] rtg_: yes, I would assume all those patches are in the current 3.8 [18:41] rtg_, tjaalton: and we do at least haswell platforms to test on [18:41] tjaalton, does your DKMS driver actually fix some problems ? [18:41] ohsix: mainerror: docs say it's still used as a workaround for X, but I'm not sure that's still true [18:43] ohsix: mainerror: if you check both of your dmesgs the current patern is that one of you would have an mtrr error [18:43] 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] \m/ [ 0.000000] PAT not supported by CPU. [18:44] 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] Sarvatt, ok, I'll have a look to see what can be done. [18:44] ohsix: :(.. what's your CPU? [18:45] 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] yeah I was about to mention the eDP issues.. [18:45] also, powerxpress with fglrx [18:47] gQuigs: it's an old P3; but it doesn't matter :> [18:49] 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] 3.8 definitely fixes some issues [18:50] with ivb + eDP for instance [18:51] i915_hsw won't help there [18:51] 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] yeah it has some additional fixes [18:52] or rather 'UBUNTU: SAUCE: drm/i915: set the LPT FDI RX polarity reversal bit when needed' [18:56] rtg_: lemme know if you'd prefer I take a first stab at this i915 rebase [18:57] ogasawara, can you really rebase it? I was just extracting all 52 patches and was gonna apply them mostly by hand. [18:57] 52? [18:57] tjaalton, in the 3.8.2 tree, 'git format-patch 68d18ad7fbc16288aa230ec0ffb4416fd4363c87..HEAD -- drivers/gpu/drm/i915/' [18:57] ah [18:58] rtg_: I'd go the route of applying by hand [18:58] well what I tried was: copy i915/*, re-apply the SAUCE patches by hand, and fix the conflicts [18:59] then commit that as the rebase, and any additional ones as new SAUCE patches [18:59] for instance, drm_mm_hsw.{c,h} needs a refresh :/ [18:59] tjaalton, but you lose the history [18:59] rtg_: true [18:59] but only of the rebase [19:00] i mean, the first commit didn't carry the history either [19:00] 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] you don't need to revert them either :) [19:00] rtg_: I'd assume it's just as much work as just applying the new ones by hand [19:00] although it's probably cleaner/safer to re-do those steps [19:01] tjaalton, you might be right [19:02] * ogasawara lunch [19:02] 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] 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] yeah, I'll mess with it a bit. [19:07] 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] 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] rtg_: ok, I'll keep that in mind [19:34] 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] kamal, git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git [19:39] rtg_: thanks [20:06] rtg_: so, I'm good either way, just let me know [20:06] tjaalton, go ahead and try it your way. I'm still grovelling around in it. [20:07] though I gotta take off soon [20:07] rtg_: heh, ok something for tomorrow [20:12] 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 === kentb is now known as kentb-out