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