[00:45] <paran> The patch for bug 345397 in evdev 1:2.1.1-1ubuntu4 causes a bad regression for me, key repeat is disabled for certain arrow keys.
[00:45] <paran> A commend warned that this regression had been observed with this patch on Intrepid. I made a comment there, should I also report the regression as a new bug?
[00:52] <bryce> paran, yep
[00:57] <paran> bryce: ok, will do that tomorrow then.
[03:49] <JanC> bryce: does Ubuntu support multiseat systems?  ツ
[04:12] <crdlb> several people in +1 have said that their xorg.conf files are blank today
[04:12] <crdlb> is this intentional?
[04:43] <JanC> crdlb: Xorg files are supposed to be (almost) blank since intrepid
[04:43] <crdlb> sure, the skeleton is great
[04:43] <crdlb> but I got the impression it was _completely_ blank
[04:44] <JanC> well, that shouldn't really matter AFAIK
[04:44] <crdlb> it matters a lot :)
[04:44] <JanC> how?
[04:44] <crdlb> because it makes trivial additions non-trivial
[04:45] <JanC> most people shouldn't make "trivial additions"
[04:45] <crdlb> eg changing the AccelMethod or enabling AccelDFS
[04:45] <crdlb> there's no reason not to include the skeleton
[04:46] <JanC> and it's easy enough to recreate a skeleton xorg.conf if you really need it
[04:46] <crdlb> it's a pointless extra step
[04:46] <crdlb> the skeleton doesn't break any of the autoconfig
[04:46] <JanC> not really, as for most people it's a pointless step to parse xorg.conf  ;)
[04:47] <crdlb> huh?
[04:48] <JanC> why parse a skeleton xorg.conf?
[04:49] <crdlb> who is the implied subject in that sentence? X?
[04:49] <JanC> X
[04:49] <JanC> most people don't even know xorg.conf exists
[04:50] <crdlb> and they can stay ignorant even if it does exist
[04:50] <JanC> and AFAIK configuration tools will create it if needed
[04:51] <crdlb> there are no configuration tools to add Option "AccelDFS" (and there shouldn't be)
[04:51] <crdlb> but that doesn't mean you should be wasting my time by not including the skeleton
[04:52] <JanC> if there is no reason for configuration tools to set that option, there is no need for that option
[04:52] <JanC> except for debugging maybe
[04:52] <JanC> and it's not me that decides  ;)
[04:52] <crdlb> the option makes EXA usable on my GPU, but it cannot be enabled by default due to buggy hardware that I don't have
[04:53] <JanC> right, so the blacklisting should be refined
[04:53] <crdlb> ...
[04:54] <crdlb> you have yet to suggest a reason not to include the skeleton
[04:54] <JanC> ... or to include it
[04:55] <JanC> I don't really care, except maybe parsing it takes time but is useless for most people
[04:56] <crdlb> parsing it is negligable
[04:57] <JanC> well, I still have it, so duno  :P
[04:57] <JanC> worst case you have to recreate it once
[04:57] <crdlb> yes, which multiplies by every single user I have to tell it to
[04:57] <JanC> dpkg-reconfigure will take care of that I suppose
[04:57] <crdlb> it does, indeed
[04:58] <JanC> crdlb: the users you should tell that to should be a tiny minority, otherwise this should be configured automaticly (and if not, it's a bug)
[04:59] <crdlb> this is the real world :)
[05:00] <JanC> well, help work on getting it fixed in the next version then (although I haven't heard anybody who really needed that option to get a working system, maybe that depends on what you want to do)
[05:01] <crdlb> I just fundamentally don't see the logic in not including an xorg.conf
[05:01] <crdlb> I foolishly assumed it was a bug ...
[05:01] <JanC> and by help I mean: report bugs & help testing & help nagging when it's still possible to change things ;)
[05:02] <JanC> the ultimate goal is to get rid of xorg.conf, so everything that still needs it is a bug  ;)
[05:03] <crdlb> no, the ultimate goal is to not need the xorg.conf for anything
[05:03] <crdlb> which is perfectly served by installing a static xorg.conf with the distro
[05:04] <JanC> if you don't need it, then it's useless to install it
[05:04] <crdlb> it does not follow that you should delete it, though
[05:07] <JanC> maybe an empty file with only a comment about running dpkg-reconfigure would be useful for now
[05:07] <JanC> for those people who don't read upgrade notes etc.  ;)
[05:09] <crdlb> the skeleton is 11 lines :)
[05:12] <JanC> well, I don't think anything is gonna change before tomorrow  ;)
[05:12] <crdlb> of course :)
[05:13] <crdlb> stop the release!!!
[05:13] <JanC> there are much more serious issues than this  :-(
[05:13] <crdlb> intel
[05:14] <JanC> right, as well as AMD/ATI AFAIK   :p
[05:14] <JanC> well, maybe less than intel
[05:14] <crdlb> the radeon driver is quite nice this cycle :)
[05:15] <JanC> duno, I have only intel (3x)
[05:15]  * crdlb has no intel
[05:16] <JanC> anyway, I'm gonna sleep, 6:15 am here  ;)
[05:16] <crdlb> skip it ;>
[12:16] <mnemo> "Intel Linux Driver Kills The Netbook Experience"
[12:16] <mnemo> http://www.phoronix.com/scan.php?page=news_item&px=NzIyMA
[12:16] <mnemo> sadly I have to agree :(
[16:58] <apw> jbarnes, about?
[16:58] <jbarnes> apw: yeah
[16:59] <apw> jbarnes, just had some feedback on the new mchbar patches, which i refactored onto our kernel, positive
[16:59] <apw> so i'll be cleaning those up and getting back with you 'Tested-by ...' like
[16:59] <jbarnes> great I was just typing that but you beat me :)
[16:59] <jbarnes> I guess you can just reply to bjorn with the cleaned up version that worked for you and hopefully he'll just send it upstream
[17:00] <apw> also just been talking about the other 965 hangs ... and there are rumours of swapping being involced
[17:00] <apw> i was wondering if the bit 17 swizzle fixups could be involved?
[17:00] <jbarnes> supposedly 965 doesn't generally have bit 17 issues
[17:00] <jbarnes> but it's a possibility
[17:00] <jbarnes> (the swapping I mean)
[17:01] <jbarnes> should be easy enough to test... just need a memory hog to run at the same time
[17:01] <apw> can we tell if we have swizzling there from the dumps we get?
[17:01] <jbarnes> I don't think we provide that info right now...
[17:01]  * jbarnes looks
[17:05] <jbarnes> yeah I think we'd have to add some printks to the mchbar checking code, but 965 doesn't have bit 17 swizzling
[17:05] <jbarnes> doesn't mean the new swap code isn't causing problems though...
[17:17] <bryce> morning
[17:17] <jbarnes> morning
[17:18] <bryce> jbarnes: I realized I didn't run with the dri option in the last couple dumps I gave you... will try again today if it still seems relevant
[17:18] <jbarnes> ok thanks
[17:37] <bryce> tjaalton: I've been mulling over setting up an xorg-updates ppa or some such, with newer drivers for jaunty.  
[17:37] <bryce> tjaalton: maybe as a ppa in xorg-edgers; it seems to fit well with what tormod does
[17:38] <bryce> tjaalton: sound interesting to you?
[17:43] <mnemo> bryce: would you then be willing to push those packages to main if they prove to be reeeally solid ?
[17:43] <bryce> mnemo: well...  they couldn't go to jaunty since that's released
[17:44] <bryce> mnemo: but yes, they'd be pushed to karmic main as well
[17:44] <mnemo> ok, there is no way xorg/intel driver gets updated through SRU/propsed and so no?
[17:44] <bryce> right, only cherrypicked bug fixes
[17:44] <mnemo> right
[17:45] <mnemo> im gonna be on karmic anyway
[17:45] <mnemo> i want UXA to be rock solid for 9.10
[17:45] <bryce> in certain, very very rare circumstances, an entire driver can go in as SRU, but only like if the driver was entirely busted and non-functional for everyone
[17:46] <mnemo> yea I guess intel in jaunty is bad but not nearly bad enough
[17:47] <bryce> but my idea with xorg-updates is to provide a way for jaunty users to get around this by getting new drivers to play with
[17:48] <bryce> another idea along with that, is that we could "test run" driver updates there for karmic, before putting them into main
[17:48] <bryce> so if there are like major issues, we can identify them there and then hold off on doing the update
[17:48] <bryce> but that's just a side idea; dunno if it's worth the extra effort
[17:49] <mnemo> I think part of the problem is that intel ddx and mesa is not well tested with .28 kernel... upstream is testing more carefully with .29 right now and .30 soon
[17:50]  * bryce nods
[17:50] <mnemo> a karmic PPA would be very nice though
[17:51] <jbarnes> 2.6.28 should actually be ok... but dri1 & exa don't get much love these days
[17:51] <mnemo> bryce: we're moving to UXA right away in karmic right?
[17:51] <bryce> yeah I'm unsure if we did an xorg-unstable, if it should be driver/mesa updates only, or also include new xserver, kernel, etc.
[17:52] <bryce> to keep it simple maybe just stick with major driver updates (e.g. -intel 2.7, etc.)
[18:12] <tjaalton> bryce: yeah, sounds fine
[19:29] <bryce> jbarnes: system still freezes with that buffer reuse option turned off
[19:29] <jbarnes> bryce: arg
[19:29] <bryce> jbarnes: want the gpu data?
[19:30] <jbarnes> if you have the INTEL_DEBUG=batch output, yes
[19:30] <bryce> is there a way to set that by default?  having to remember to restart gdm with that set each time is a PITA
[19:31] <bryce> i.e. no this does not have that set
[19:32] <jbarnes> you'd have to put it in one of the X session files i guess
[19:32] <bryce> sometimes I wonder if you guys make up these options just to keep testers busy ;-)
[19:33] <bryce> is there a way to check post-boot whether the option is in effect?
[19:34] <jbarnes> bryce: yeah if we delay fixing the bug long enough the chip stops shipping :)
[19:34] <jbarnes> dunno about a post-boot check no
[19:34] <jbarnes> aside from seeing if you're getting tons of log output
[19:35] <bryce> that would do.  log output in what file?
[19:40] <jbarnes> the gdm log iirc
[19:40] <jbarnes> like albert23 had
[19:41] <bryce> ok
[19:41] <bryce> is that gdm log file useful to you to include in the data dumps?  If so I'll add it to the guide.
[19:41] <jbarnes> if it has the batch output, otherwise it's not interesting
[19:42] <bryce> is the batch output included in intel_gpu_dump or /sys/kernel/debug/dri/0/i915* or dmesg as well, already?
[19:43] <jbarnes> no the INTEL_DEBUG=batch option makes dri clients dump a bunch of stuff while they execute
[19:43] <jbarnes> which just ends up on stderr I think for that client
[19:44] <jbarnes> so if you start gdm that way its log will have all the batch output
[19:44] <jbarnes> for anything X does anyway
[19:44] <bryce> whoa, no kidding, that's a lot of data
[19:46] <bryce> (fwiw, I just stuck it in /etc/init.d/gdm directly)
[19:46] <jbarnes> cool
[19:46] <jbarnes> yeah albert23's last attachment was several megs
[19:48] <bryce> I see that an easy way to tell that it's in effect is that it slows the system down noticeably
[19:51] <bryce> jbarnes: when setting dri options with driconf, do those take effect instantly or only on reboot?
[19:51] <jbarnes> they'll take effect on newly started dri clients
[19:52] <jbarnes> any running clients won't pick up the change though afaik
[19:53] <bryce> ok, now have a freeze with the dri option, your patch, and INTEL_DEBUG=batch.
[19:53] <jbarnes> cool
[19:55] <bryce> intel_context.c:527: Batchbuffer flush with 404b used
[20:18] <bryce> hrm, the compressed tarball with the gdm.log is 100mb
[20:19] <bryce> 74 mb to be specific
[20:21] <jbarnes> can you put it somewhere?
[20:22] <jbarnes> btw I hope you can meet w/anholt, would probably go much faster
[20:24] <bryce> waiting on it to upload to launchpad... might be a while
[20:25] <bryce> meanwhile, snag it from:  http://www2.bryceharrington.org:8080/files/i915_debugfs_bwh6.tgz
[20:30] <bryce> jbarnes: ^
[20:30] <jbarnes> thanks
[20:37] <jbarnes> bryce: wow almost a gig uncompressed :)
[20:37] <bryce> good compression ratio... lotsa 0x00000 ;-)
[20:37] <bryce> yeah it had to run for a bit before locking up
[20:38] <bryce> it locked up while the switch-desktop OSD was showing, fwiw
[20:41] <bryce> jbarnes: there is a Canonical meet up downtown Portland this friday that I'll be at, that anholt could come to if it would help for him to sit in front of the affected hw
[20:41] <bryce> jbarnes: at least 3 people with affected systems will be there
[20:50] <jbarnes_> bryce: ok cool
[20:50] <bryce> forwarding the invite
[20:55] <bryce> heh, compiz is starting to get piles of "compiz suddenly stopped working!!1!" bug reports
[21:08] <mnemo> bryce: is there any way I could subscribe to all incoming intel ddx and mesa bugs? i'm thinking it would be useful to help out with triage etc
[21:08] <bryce> mnemo: yes, you can get this by joining the ubuntu-x-swat team
[21:09] <bryce> mnemo: that will actually subscribe for all of the X bug reports, so you may have to use a filter to only include the source package(s) you actually care about
[21:11] <mnemo> bryce: cool, I requested to join now
[21:11] <bryce> awesome, I've approved you
[21:12] <mnemo> thanks
[21:22] <mnemo> bryce: you use the "X-Launchpad-Bug: sourcepackage=blah" mailheader to sort the mail right?
[21:23] <bryce> mnemo: exactly
[21:24] <bryce> X-Launchpad-Message-Rationale also can be useful in narrowing down what gets put in your mailbox, but sourcepackage= should take care of th ebulk of it
[21:27] <mnemo> right.. I use thunderbird so im thinking maybe I can sort into folders based on package and then color the mails based on bug status or something like that
[21:32]  * bryce nods
[21:32] <bryce> I use mutt, and colorize based on status changes
[21:33] <bryce> mnemo: http://pastebin.ubuntu.com/156128/
[21:34] <bryce> heya tormod
[21:35] <bryce> tormod: I was thinking of an idea sort of inspired from xorg-edgers, to set up a ppa for jaunty updates, but only for stable releases, so people who want newer drivers but not risky git updates have a place to snag them
[21:36] <bryce> tormod: pretty bare bones so far, but it will be living at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates
[21:49] <tormod> hi bryce! that's exactly what we have in ~intel-gfx-testing
[21:50] <tormod> I have just been waiting for 2.7.1...
[21:51] <bryce> tormod: oh, didn't realize that was still being maintained
[21:51] <tormod> (looking) I see you go beyond intel
[21:51] <bryce> yeah
[21:51] <bryce> should we merge these two things?
[21:51] <tormod> well maintained... I am waiting for a "stable" version :)
[21:52] <bryce> have you found 2.7.0 not stable enough?
[21:52] <tormod> no, just the intel x.y.0 experience
[21:52]  * bryce nods
[21:53] <bryce> well, a secondary reason I have for setting this up is to pre-test packages we're considering for karmic, to help us find major issues before uploading
[21:53] <tormod> the only reason for having a separate intel repo is that intel needs newer libdrm, the other drivers usually don't
[21:53] <bryce> er, before uploading to karmic
[21:54] <jcristau> tormod: also intel breaks more than others :)
[21:54] <tormod> otherwise we can just use your xup and forget about intel-gfx-testing
[21:55] <tormod> jcristau: true, it should be kept isolated, and be touched with gloves :)
[21:55] <bryce> tormod: I think it'd be fine to carry newer libdrm's in xup... in fact you can see I already pulled in debian's libdrm 2.4.9 :-)
[21:56] <bryce> it's the kernel dependencies that I worry most about...
[21:57] <tormod> yes those are a pita - I guess the "mainline kernels" repo will be popular
[21:58]  * tormod runs 2.6.30rc3 btw
[21:58] <bryce> I talked to apw about getting a .dsc for 2.6.30-rc2, although not sure if he's had time to set it up
[21:59] <bryce> for xup I'm thinking of restricting it to only updates that can run on the given series' kernel and xserver
[21:59] <tormod> yeah that's a good rule
[21:59] <bryce> but updates to mesa, lib's, etc. are okay
[21:59] <jcristau> i'd be pissed if the driver stopped working with "old" kernels. but maybe that's already happened..
[22:00] <tormod> for the time being this == xorg-edgers
[22:00] <bryce> if we find we need something more than that, then maybe that calls for a specialized ppa, something in xorg-edgers perhaps
[22:02] <mnemo> jcristau: since eric is ripping out EXA/DRI1 I guess it will soonish run only on GEM kernels (which I think is .28 and later) .. not sure when they will merge the cleanup branch to master though
[22:02] <jcristau> yeah
[22:02] <jcristau> but i need partial upgrades from lenny to work. that means .26...
[22:04] <tormod> can it not run without acceleration? sounds like it dead slow anyway
[23:43] <bryce> jbarnes: another dri_debug dump with INTEL_DEBUG - https://bugs.edge.launchpad.net/ubuntu/+bug/365299
[23:44] <jbarnes> bryce: ok thanks
[23:44] <jbarnes> god interactive perf sucks when a build is going on