[04:05] <ubotu> New bug: #183416 in xorg (main) "screen is enlarged very much when I enable my graphics card(NVDIA card)" [Undecided,Incomplete] https://launchpad.net/bugs/183416
[05:46] <ubotu> New bug: #40659 in dmidecode (main) "[ia64] Can't get past "Configuring xserver-xorg"" [Medium,Confirmed] https://launchpad.net/bugs/40659
[06:45] <Q-FUNK> re
[06:55] <bryce> hey
[07:00] <Q-FUNK> no wonder batman's patch would not apply:  it needs to apply after everyone else's patch is there :)
[07:08] <bryce> heh
[07:16] <Q-FUNK> I'm building myself a test package
[07:17] <Q-FUNK> I'll try it with both -amd and the -siliconmotion on my laptop
[07:18] <bryce> amazing how much time this friggin equipment takes to make it work
[07:18] <bryce> can't believe I've put an entire week into ume, and I feel barely further along than a week ago
[07:20] <Q-FUNK> indeed
[07:20] <Q-FUNK> it almost feels like rocket science
[07:38] <tjaalton> bryce: apparently there is a libdrm release coming up in the next few weeks
[07:39] <tjaalton> bryce: which means that the TTM API is finished..
[07:40] <tjaalton> RAOF has snapshot packages for libdrm, so I'll try to build the intel stuff against it
[07:41] <bryce> tjaalton: amazing!
[07:41] <bryce> kewl
[07:42] <tjaalton> the diff against 2.3.0 is over 6MB :)
[07:42] <tjaalton> but that includes the kernel drivers too, same for bsd
[07:42] <bryce> tjaalton: I made some good progress on ume today.  Preliminary results show that the lockup is solved.  I'm hoping by the time i get up tomorrow we'll be close to done with it
[07:43] <tjaalton> bryce: that was with poulsbo?
[07:43] <bryce> yeah I bet.  The libdrm2 patch I was manhandling for ume was like 16,000 lines
[07:43] <bryce> yup
[07:43] <tjaalton> hehe
[07:44] <tjaalton> so I tried RAOF's nouveau packages yesterday, and it worked quite well
[07:44] <bryce> nice
[07:44] <bryce> 3d stuff?
[07:44] <tjaalton> obviously no 3D, and no VT
[07:44] <tjaalton> :)
[07:44] <bryce> oh
[07:44] <tjaalton> it's flaky
[07:44] <tjaalton> but the software rendering wasn't too bad
[07:44] <bryce> ok, so worked quite well for certain definitions of quite well ;-) ;-)
[07:45] <tjaalton> yeah
[07:45] <tjaalton> the VT's not working is a known issue
[07:45] <tjaalton> no DRI since there was no driver for it
[07:46] <tjaalton> but according to the wiki it's known to be broken for most
[07:46] <tjaalton> jcristau: RAOF also promised to co-maintain nouveau on git.d.o :)
[07:47] <tjaalton> the package is derived from -nv, so it's close to the XSF standards
[07:47] <bryce> I hate it when VT switching is broken.  makes debugging a pain
[07:47] <tjaalton> yep
[07:47] <bryce> ah really...  is it a superset of -nv yet?
[07:48] <tjaalton> no, obfuscated parts are mostly rewritten, so it's a fork but has more functionality now
[07:49] <tjaalton> so I'm not proposing to replace -nv with it, not for hardy anyway :)
[07:49] <bryce> well, still good to heaer about the progress
[07:49] <tjaalton> although it seems that there are serious issues with -nv where on some models you need the binary driver to "prime" the card"
[07:50] <tjaalton> and nvidia is not going to fix that
[07:50] <bryce> wow
[07:50] <bryce> I didn't know about that
[07:51] <bryce> wow that sucks
[07:51] <tjaalton> I'm not sure how common that is
[07:51] <bryce> maybe it's updating bios or something?
[07:51] <tjaalton> possibly
[07:52] <tjaalton> i'll dig up the bug on b.fd.o
[08:04] <tjaalton> hmh, can't find it
[08:04] <bryce> ah well
[08:05] <bryce> might be good to note on our wiki somewhere
[08:05] <tjaalton> but there was one where aaronp said that "there's nothing we can do about it right now" or similar
[08:05] <bryce> oh btw, the bug I mentioned in that tagging greasemonkey script is fixed now
[08:06] <tjaalton> oh, cool
[08:06] <bryce> brian also added some tooltips to it (haven't checked that out yet)
[08:09] <tjaalton> so are the ume guys switching to hardy now?
[08:09] <tjaalton> and would that be an excuse for putting the new drm stuff in the kernel?-)
[08:10] <bryce> they're shooting for hardy yes, but gutsy is a backup in case we can't get things like X to work on it
[08:10] <bryce> unfortunately time is very short to prove it on hardy, which is why everyone's scrambling
[08:11] <tjaalton> yep
[08:11] <tjaalton> we'd get TTM with the drm, although that was declined at UDS
[08:11] <bryce> it looks like they've accepted that they're going to be running non-stock ubuntu, with loads of PPA bobbins stuck ontop, so they're working to the assumption that they'll be carrying drm bits and pieces
[08:12] <bryce> I'm sure they would love hearing new drm included in main ubuntu, but don't think they're expecting it
[08:12] <bryce> it would be >awesome< to have TTM
[08:13] <tjaalton> I'm not exactly sure what would break with it, since it's not like a requirement to use it
[08:13] <bryce> yeah
[08:13] <tjaalton> but intel surely is going for it
[08:13] <bryce> mvo would be happy
[08:13] <tjaalton> hehe
[08:14] <tjaalton> so, I'll break my laptop now
[08:14] <bryce> well, if nothing else, it'd be nice to stick it in a ppa for people 
[08:15] <tjaalton> yeah
[08:15] <bryce> I'm sure dell would snag it for their systems
[08:16] <bryce> (assuming it doesn't eat kittens and make babies cry or something)
[08:17] <mvo> bryce: looks like I missed the earlier bits of the conversation :) ? new intel drivers?
[08:18] <tjaalton> mvo: libdrm release due "in a few weeks"
[08:18] <bryce> mvo, with TTM
[08:18] <tjaalton> which would include the new memory manager (TTM)
[08:18] <mvo> oh, with ttm ?
[08:18] <mvo> nice
[08:18] <tjaalton> so I'll try to package the intel branch that uses it
[08:19] <tjaalton> currently the performance with 965 is actually worse than with the old driver, but that's hopefully fixed soon
[08:19]  * mvo nods
[08:19] <mvo> will this branch do redirected direct rendering? 
[08:20] <tjaalton> I mean with TTM, worse than the current driver with EXA (amazed that it's actually possible..)
[08:20] <tjaalton> mvo: I think that's a separate issue
[08:20] <tjaalton> although it would require TTM yes
[08:22] <mvo> ok
[08:23] <mvo> thanks
[08:38] <bryce> tjaalton: I got another meeting with Intel about -intel bugs tomorrow, but I've been so busy with ume stuff I haven't put much thought into what to talk about.  Are there any issues you think would be worth bringing up with them?
[08:39] <bryce> oh speaking of which, Rolla says "We expect it to be better on 965 in about 2 weeks.  If Jesse releases 2.2.1 before that, then 2.3 should include the major improvements."
[08:39] <bryce> "2.3 will release around march. 2.2.1 should be released near this month's end."
[08:39] <tjaalton> hmm
[08:39] <tjaalton> is March too late?
[08:40] <tjaalton> hmm
[08:40] <bryce> hmm, we were putting in new -ati's up until the last moment before release
[08:40] <tjaalton> yeah.. but it was gutsy :)
[08:40] <bryce> true
[08:40] <bryce> ok I'll bring that up.
[08:41] <bryce> what else?
[08:43] <tjaalton> so 2.3 will use TTM, and we should be able to keep the hardy version more uptodate even when it's released
[08:43] <tjaalton> I just hope they'll be around when the bugs keep rolling in :)
[08:43] <bryce> no kidding
[08:44] <tjaalton> so _if_ we are able to use TTM for intel, we _could_ ship with 2.3
[08:44] <bryce> are you certain 2.3 will require TTM?  I can ask to get clarification on that
[08:44] <tjaalton> but otherwise it's 2.2.1 and back to XAA
[08:45] <tjaalton> oh, no I'm not sure, but if it's not available then we still have the annoying bugs
[08:45]  * bryce nods
[08:45] <bryce> I'll ask for clarification on it
[08:48] <bryce> TTM is wholey within libdrm?  No xserver components needed?
[08:48] <tjaalton> I'll probably take a C course this semester, which should improve my debugging skills :)
[08:48] <bryce> wholly
[08:48] <bryce> cool
[08:48] <tjaalton> AIUI yes
[08:49] <tjaalton> the redirected direct rendering touches xserver
[08:49] <tjaalton> but that's separate
[08:50] <bryce> upstream would be very sad if we went back to XAA
[08:50] <bryce> "the gfx team says:
[08:50] <bryce> EXA should only be slower than XAA on 965 mostly.  Also, we're working
[08:50] <bryce> fully on EXA and we're we are doing nothing else with XAA so it doesn't
[08:50] <bryce> support other features we've added - thus reverting to XAA would leave
[08:50] <bryce> you unsupported.
[08:50] <bryce> "
[08:51] <tjaalton> yeah :/
[08:51] <tjaalton> carrot-and-stick
[08:52] <bryce> I sort of don't like how they flip switch over to new features and (relatively) immediately drop support for the old version
[08:52] <bryce> reminds me of the -i810/-intel switch
[08:58] <tjaalton> true
[08:58] <tjaalton> drm built with a couple of nouveau related warnings, nothing else
[09:09] <bryce> tjaalton: are you experiencing bug 175774?  I also started noticing it recently.
[09:09] <ubotu> Launchpad bug 175774 in xserver-xorg-video-intel "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Critical,Confirmed] https://launchpad.net/bugs/175774
[09:09] <bryce> I assumed it was compiz' fault but see the bug has ended up with us
[09:09] <bryce> ah nevermind, I see you've already commented on it
[09:11] <tjaalton> yes, it's visible with EXA
[09:39] <ubotu> New bug: #182489 in linux-restricted-modules-2.6.24 (restricted) "Atheros wireless (AR5006EG) not working on ASUS Eee PC" [Undecided,New] https://launchpad.net/bugs/182489
[09:42] <Ng> the gfx team are wrong, EXA is slower on 855 too ;)
[09:43] <tjaalton> heh
[09:43]  * Ng been playing with pm-utils quirks and I can kind of get X back after a resume, but scrolling is still very broken when I do, so it's clearly not working properly somewhere. I'm trying to find out what the correct suspend quirks are for this hardware and I was wondering if I could reasonably try the intel driver from gutsy-proposed with the hardy Xorg
[09:43] <tjaalton> sure, the current version is, but the TTM version is 40% slower on 965 than a non-TTM version of the driver
[09:43] <Ng> ouch
[09:44] <tjaalton> rest should apparently be fine
[09:44] <tjaalton> ..with TTM
[09:44] <mvo> Ng: contracts for terminator being in the repository!
[09:44] <Ng> I'm also considering pestering Peter Clifton about it, since he was so awesome in tracking down the bug that stopped me suspending with the release gutsy -intel driver
[09:44] <Ng> mvo: ta :D
[09:44] <mvo> Ng: meh, make that congrats :)
[09:44]  * mvo can't type
[09:46] <Ng> I also need to find more brave x40 users :)
[09:48] <mvo> Ng: dholbach comes to my mind
[09:49] <Ng> mvo: ooh, interesting point :)
[10:12] <bryce> night
[10:14] <Ng> cya bryce :)
[10:16] <tjaalton> night bryce, hopefully I'll have a working TTM setup by the time you wake up :)
[10:31] <mvo> night bryce
[10:32] <mvo> tjaalton: do you happen to know aobut the latest development with the redirected direct rendering? is it merged into some branch already?
[10:34] <tjaalton> mvo: I know that cworth is working on it, but at least his personal trees haven't been updated in a while, so could be that they are now in a separate branch (of xserver etc)
[10:35] <tjaalton> once I get this TTM crap working I'll have a closer look
[10:35] <mvo> ok, thanks
[11:34] <tjaalton> hmm strange.. emacs runs on a local display but not over ssh, fails with xcb_xlib_lock assertion
[11:35] <tjaalton> and now it works
[11:35] <tjaalton> puzzling
[12:12] <ubotu> New bug: #4596 in xorg (main) "Xorg 6.8.2-77 has multiple issues/bugs" [Undecided,Fix committed] https://launchpad.net/bugs/4596
[12:18] <sirex`> How can I submit new keyboard layout to Ubuntu?
[12:38] <tjaalton> sirex`: please submit them upstream
[12:39] <tjaalton> file a bug against xkeyboard-config on bugzilla.freedesktop.org
[12:39] <sirex`> Ok, thans tjaalton.
[12:43] <tjaalton> sirex`: then if it is approved and included in upstream we can add it to our package
[12:43] <sirex`> tjaalton: can I sumbit a bug to bugs.launchpad.net?
[12:44] <sirex`> I mean bug about new keyboard layout..
[12:44] <tjaalton> yes, and then link to the upstream bug
[12:44] <tjaalton> so we know when it's applied upstream
[13:11] <sirex`> I filed bug: http://bugs.freedesktop.org/show_bug.cgi?id=14096
[13:11] <ubotu> Freedesktop bug 14096 in General "New Lithuanian keyboard layout LEKP" [Normal,New] 
[13:16] <tjaalton> ok, now file the same on lp.net, and link to the b.fd.o bug
[13:21] <ubotu> New bug: #183511 in xkeyboard-config (main) "New keyboard layout – LEKP" [Undecided,New] https://launchpad.net/bugs/183511
[13:24] <tjaalton> sirex`: ok, I can link the upstream bug to that
[13:25] <tjaalton> done
[14:21] <Ng> ooooh
[14:21] <Ng> I just got a successful suspend/resume cycle
[14:21]  * Ng tries again
[14:22] <tjaalton> don't spoil it :)
[14:22] <Ng> win!
[14:22] <Ng> that's so weird, but somehow the new kernel seems to have fixed that
[14:22] <Ng> I noticed pitti said his suspend worked with it
[14:22] <Ng> now I need to hack the hal fdi's to set the quirks for this laptop
[14:22] <Ng> and maybe try and whittle the list of required quirks down a bit
[14:26] <Ng> but at least I can close out my bug
[18:16] <seb128> see you later
[18:49] <Q-FUNK> apparently, bartman's combined patch (port blacklist, pci listing, ubuntu changelog) on xserver-corg-core 1.3 (gutsy) has been verified to not introduce regressions when upgrading X under -intel.
[18:49] <Q-FUNK> I'm testing now with nv and siliconmotion
[18:52] <Q-FUNK> (and needless to say, with -amd too)
[22:52] <Q-FUNK> bryce: maybe it's just me, but these tow patches make this nv driver feel snappier.
[22:52] <bryce> :-)
[23:09] <tjaalton> mesa head building.. I guess it'll take a while
[23:11] <Q-FUNK> mesa /bin/jarjarbinks ?
[23:13] <tjaalton> not quite as annoying to watch ;)
[23:13] <Q-FUNK> ;)
[23:15] <tjaalton> duh, failed
[23:16] <tjaalton> at i915tex, the next one would've been i965
[23:16] <tjaalton> the one _I_ need
[23:18] <tjaalton> something for tomorrow then..
[23:18] <tjaalton> ->
[23:22] <bryce> heya tormod
[23:22] <tormod> hi bryce!
[23:23] <tormod> testing out the new Render support on radeon. Any idea I what I can test for? compiz?
[23:23] <bryce> tjaalton: I finally managed to get a good backtrace of the poulsbo ume crash - it's a ioctl call to the kernel.  So, something appears to be broken in the kernel.
[23:26]  * tormod is starting to hate {trackerd,updatedb,scrollkeeper-update}
[23:26] <bryce> I may need to learn how to shut that off
[23:28] <tormod> the killer is when I do a package update that calls scrollkeeper-in-hell-update and at the same time the cron job kicks in, and they starve each other :(
[23:28] <Q-FUNK> how was it that I enable my PPA again?
[23:29] <tormod> funny enough, it happens often on a slow machine, if you have the habit of updating just after booting.
[23:29] <Q-FUNK> I have test packages of the patched server for gutsy and of the latest amd, also backported for gutsy.
[23:29] <tormod> Q-FUNK: isn't that just a click on launchpad?
[23:32] <Q-FUNK> seems enabled, but no idea how to upload to it
[23:32] <tormod> Q-FUNK: dput
[23:32] <tormod> where is the blacklist for compiz located?
[23:32] <Q-FUNK> yes, but where to?
[23:34] <Q-FUNK> ah. found
[23:40]  * tormod thought he knew better than the blacklist...