| ppisati | moin | 07:30 |
|---|---|---|
| === jibel_ is now known as jibel | ||
| === yofel_ is now known as yofel | ||
| === amitk is now known as amitk-afk | ||
| rtg_ | ogra_, is dropping luxd all that it took for the ambient light sensor to start working ? | 12:39 |
| 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:40 |
| rtg_ | ogra_, you probably also lose the automatic adjustment ? | 12:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| rtg_ | ogra_, sounds pretty low priority unless he's got no other N7 bugs to work on. | 12:45 |
| ogra_ | yeah | 12:45 |
| 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) | 12:46 |
| ppisati | ogra_: got a new high priority task assigned, put n7 work on the back burner | 13:38 |
| ppisati | rtg_: ^ | 13:38 |
| 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:39 |
| 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:40 |
| 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:49 |
| 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:50 |
| ppisati | ogra_: neee | 13:52 |
| ppisati | ogra_: i was able to find it again | 13:52 |
| ogra_ | haha, lucky guy | 13:52 |
| 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:53 |
| 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 | 13:54 |
| === amitk-afk is now known as amitk | ||
| 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:18 |
| ppisati | git log -p | 14:19 |
| ppisati | ops | 14:19 |
| ogra_ | "not a branch" | 14:20 |
| * ogasawara back in 20 | 14:55 | |
| 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:01 |
| ppisati | bjf: done | 15:07 |
| bjf | ppisati, thanks | 15:08 |
| jsalisbury | rtg_, ack, thanks for the info | 15:18 |
| === lfaraone_ is now known as lfaraone | ||
| 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] | 15:26 |
| * ppisati goes out for a bit | 16:12 | |
| * rtg_ -> lunch | 17:28 | |
| tjaalton | ogasawara: hey, how about rebasing i915_hsw to 3.8.x, yea/nay? the current version is showing it's age already :/ | 17:35 |
| * cking -> food | 18:22 | |
| rtg_ | tjaalton, confused. what are you referring to ? | 18:23 |
| tjaalton | rtg_: the drm driver for haswell on the quantal kernel, currently based on 3.7-rc6 | 18:26 |
| rtg_ | tjaalton, oh, you mean rev the haswell driver in Quantal up to current Linux 3.9-rc2 upstream ? | 18:27 |
| tjaalton | rtg_: well, to 3.8.x for starters, going further would probably mean (more) issues with drm_* | 18:28 |
| rtg_ | tjaalton, would the fix some specific issues ? | 18:29 |
| rtg_ | would tah* | 18:29 |
| rtg_ | frick | 18:29 |
| tjaalton | :) | 18:30 |
| rtg_ | thats 325 patches | 18:30 |
| tjaalton | yes, and enable backporting newer fixes | 18:30 |
| 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:31 |
| tjaalton | that's one option yes | 18:32 |
| tjaalton | so raring kernel + quantal xorg stack | 18:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| tjaalton | rtg_: nope | 18:38 |
| rtg_ | tjaalton, ok, that makes it easier. | 18:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:43 |
| 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:44 |
| 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:45 |
| ohsix | gQuigs: it's an old P3; but it doesn't matter :> | 18:47 |
| 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:49 |
| tjaalton | 3.8 definitely fixes some issues | 18:50 |
| tjaalton | with ivb + eDP for instance | 18:50 |
| 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:51 |
| * 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:52 |
| ogasawara | rtg_: lemme know if you'd prefer I take a first stab at this i915 rebase | 18:56 |
| 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:57 |
| 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:58 |
| 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 | 18:59 |
| 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:00 |
| rtg_ | tjaalton, you might be right | 19:01 |
| * 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:02 |
| 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:04 |
| rtg_ | yeah, I'll mess with it a bit. | 19:05 |
| 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:07 |
| 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:14 |
| tjaalton | rtg_: ok, I'll keep that in mind | 19:32 |
| 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:34 |
| rtg_ | kamal, git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git | 19:39 |
| kamal | rtg_: thanks | 19:39 |
| 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:06 |
| rtg_ | though I gotta take off soon | 20:07 |
| tjaalton | rtg_: heh, ok something for tomorrow | 20:07 |
| 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 | 20:12 | |
| === kentb is now known as kentb-out | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!