[11:51] <RoyalDogBiscuits> Heya. Mark has talked many times about "ultrasmooth" graphics. This is achieved with a low-jitter kernel. 
[11:51] <RoyalDogBiscuits> Please see:  http://ovekarlsen.com/Blog/turning-ubuntu-12-04-into-a-professional-low-jitter-os/
[11:51] <RoyalDogBiscuits> I can answer any questions.
[12:19] <RoyalDogBiscuits> Low-jitter reduces interrputs in the datastreams, giving continuous graphics and audio, that is optimal for a multimedia computer OS.
[12:20] <RoyalDogBiscuits> For instance Doom 3 which is a very jitter sensitive game, that Carmack not long ago stated was taxing even on modern computers, runs with accurate 72fps. 
[12:20] <RoyalDogBiscuits> This also on a core 2 duo, and GTX 280.
[12:20] <RoyalDogBiscuits> Doom 3 does three passes pr Open GL frame.
[12:21] <RoyalDogBiscuits> interrupts :)
[12:32] <ohsix> why did you change your name?
[12:34] <ohsix> and only considering the kernel as a source of jitter is going to majorly miss all the real issues
[13:04] <RoyalDogBiscuits> ohsix: It is tried and tested, there is no other real issues.
[13:14] <rtg> apw, suppose we oughtta do a signed package for Saucy LTS ?
[13:15]  * henrix -> lunch
[13:18] <apw> rtg, hmm, i suppose we might indeed
[13:18] <rtg> apw, are you still the expert there ?
[13:19] <apw> rtg, yeah i'll take the action indeed
[13:23] <arges> smb: hi
[13:24] <smb> arges, maybe... :)
[13:24] <arges> : ) 
[13:24] <arges> smb: bug 1007082
[13:24] <ubot2> Launchpad bug 1007082 in linux (Ubuntu) "BUG: Bad page state in process node pfn:8e9d9" [Medium,Incomplete] https://launchpad.net/bugs/1007082
[14:22] <jpds> Anyone know how I can start to figure out why my laptop is a lot hotter on saucy?
[14:39] <apw> jpds, it is sitting on your lap ?
[14:40] <jpds> apw: Partially, but the fan is spinning a lot more than what I'm use to.
[14:40] <cking> maybe install a raring kernel and see if that changes things
[14:40] <apw> jpds, shame you didn't upgrade 3m ago :(
[15:51] <brendand> how does dmesg get the timestamps used to mark entries?
[15:51] <brendand> is it possible to get that number at any point?
[15:52] <brendand> this number '[ 9231.618344]'
[15:52] <brendand> which i guess is seconds after boot
[16:12] <kamal> tjaalton, hey, so regarding those in-raring-but-not-in-3.8-stable haswell commits . . .   I'd be happy to take the two from upstream in 3.8-stable, if you were to request that
[16:12] <kamal> tjaalton, that would be raring's e8c14411e539718 and 0009bd009e9ec8b
[16:14] <tjaalton> kamal: yeah, do you need a formal request?
[16:15] <kamal> tjaalton, yes please... an email to me with cc: stable@vger.kernel.org .   The upstream commits to request are:
[16:15] <kamal> commit 21ad833075801a7cd81b5ef1604ffc6c600e5ff9 upstream.
[16:15] <kamal> commit 7b9f35a6dd72f89452c58bbdbaf063027bf857ec upstream.
[16:16] <tjaalton> ok, I'll cc the authors too so they can yell 'no!' if they want :)
[16:16] <kamal> tjaalton, sure sounds good (I'll also do that when I actually queue up the patches)
[16:16] <tjaalton> not that I think they should
[16:19] <tjaalton> i'm working on backporting power well changes for haswell, it doesn't support hdmi/dp audio on 3.8 currently
[16:20] <tjaalton> but getting that in stable might be asking a bit too much, currently at five patches and it's not fully there yet
[16:20] <kamal> tjaalton, um . . .  does that relate to 2124b72e6283c4e84a55e71077fee91793f4c801 (which I'm about to queue for 3.8-stable, as requested by Shuduo Sang)
[16:20] <tjaalton> kamal: yes, it needs the other four patches
[16:20] <kamal> tjaalton:  212b72e drm/i915: don't disable the power well yet
[16:21] <tjaalton> or at least it applies cleanly after them
[16:21] <tjaalton> but it's not enough; after unplugging the cable, the hdmi/dp audio device is still listed on audio properties
[16:22] <tjaalton> works fine on 3.11
[16:22] <tjaalton> and apparently on 3.9-rc5
[16:22] <kamal> tjaalton, hmm.   I backported 212b72e to 3.8 with no fuss at all (didn't apply cleanly, but was an easy/obvious port).    I wasn't aware that it needed any other patches, but ...
[16:22] <tjaalton> huh, ok
[16:22] <kamal> see my email (in kteam@) to Shuduo, asking whether it's really even relevant for 3.8
[16:23] <kamal> Subject: Re: stable: 2124b72e6283c4e84a55e71077fee91793f4c801 need backport
[16:23] <kamal> tjaalton, . . . . so now I'm confused.
[16:23] <tjaalton> well, I thought 7f35610cc33cf7ee0797dc684ccc0057742dc12a is just as wanted
[16:23] <tjaalton> but, we'll see after some testing
[16:23] <tjaalton> if the one patch is enough then that's good
[16:24] <kamal> I can't find 7f35610cc33cf7ee0797dc684ccc0057742dc12a  (which repo?)
[16:25] <tjaalton> oops, mine :)
[16:25] <tjaalton> hang on
[16:25] <tjaalton> fa42e23c1055a4 is better
[16:26] <tjaalton> so, the bisection showed the proposed patch fixing things, but of course i915 got 265 other commits to the driver since 3.8..
[16:26] <kamal> tjaalton, well, fwiw fa42e23c1055a4 applies cleanly to my 3.8 tree
[16:27] <tjaalton> yeah it does
[16:28] <kamal> tjaalton, and I'd take it if requested (and assuming it actually compiles :-)
[16:28] <tjaalton> the other commits I'm testing with are cb10799c194369633b18, 6b25a88752e8e and d5f21e4072645d0
[16:29] <tjaalton> but wth.. now I see that this branch doesn't have 2124b72e6283c, grr
[16:30] <tjaalton> so I'll just rerun the tests, maybe things work after pulling it
[16:31] <kamal> tjaalton, ok, lmk what you want to do after you sort it all out.  fwiw, all three of those ^^ look fine to me also.
[16:31] <tjaalton> ok cool
[16:31] <brendand> cking, thanks for the answer on dmesg
[16:31] <tjaalton> since the primary target is the quantal i915_hsw driver they're probably fine there but would be silly not to have them on 3.8/raring too
[16:32] <tjaalton> especially since it's all haswell anyway
[16:32] <kamal> tjaalton, agreed, plus it makes my life easier for future i915 stable merges
[16:33] <tjaalton> sure