| 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 |
|---|---|---|
| ubottu | 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 |
| 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:45 |
| bryce | paran, yep | 00:52 |
| paran | bryce: ok, will do that tomorrow then. | 00:57 |
| JanC | bryce: does Ubuntu support multiseat systems? ツ | 03:49 |
| crdlb | several people in +1 have said that their xorg.conf files are blank today | 04:12 |
| crdlb | is this intentional? | 04:12 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| crdlb | huh? | 04:47 |
| JanC | why parse a skeleton xorg.conf? | 04:48 |
| 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:49 |
| crdlb | and they can stay ignorant even if it does exist | 04:50 |
| JanC | and AFAIK configuration tools will create it if needed | 04:50 |
| 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:51 |
| 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:52 |
| JanC | right, so the blacklisting should be refined | 04:53 |
| crdlb | ... | 04:53 |
| crdlb | you have yet to suggest a reason not to include the skeleton | 04:54 |
| JanC | ... or to include it | 04:54 |
| JanC | I don't really care, except maybe parsing it takes time but is useless for most people | 04:55 |
| crdlb | parsing it is negligable | 04:56 |
| 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:57 |
| 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:58 |
| crdlb | this is the real world :) | 04:59 |
| 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:00 |
| 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:01 |
| JanC | the ultimate goal is to get rid of xorg.conf, so everything that still needs it is a bug ;) | 05:02 |
| 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:03 |
| 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:04 |
| 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:07 |
| crdlb | the skeleton is 11 lines :) | 05:09 |
| JanC | well, I don't think anything is gonna change before tomorrow ;) | 05:12 |
| crdlb | of course :) | 05:12 |
| crdlb | stop the release!!! | 05:13 |
| JanC | there are much more serious issues than this :-( | 05:13 |
| crdlb | intel | 05:13 |
| 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:14 |
| JanC | duno, I have only intel (3x) | 05:15 |
| * crdlb has no intel | 05:15 | |
| JanC | anyway, I'm gonna sleep, 6:15 am here ;) | 05:16 |
| crdlb | skip it ;> | 05: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 :( | 12:16 |
| === mdz_ is now known as mdz | ||
| apw | jbarnes, about? | 16:58 |
| jbarnes | apw: yeah | 16:58 |
| 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 | 16:59 |
| 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:00 |
| 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:01 | |
| 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:05 |
| bryce | morning | 17:17 |
| jbarnes | morning | 17:17 |
| 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:18 |
| === mnem0 is now known as mnemo | ||
| 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:37 |
| bryce | tjaalton: sound interesting to you? | 17:38 |
| 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:43 |
| 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:44 |
| 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:45 |
| mnemo | yea I guess intel in jaunty is bad but not nearly bad enough | 17:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| * bryce nods | 17:50 | |
| mnemo | a karmic PPA would be very nice though | 17:50 |
| 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:51 |
| bryce | to keep it simple maybe just stick with major driver updates (e.g. -intel 2.7, etc.) | 17:52 |
| tjaalton | bryce: yeah, sounds fine | 18:12 |
| === mvo__ is now known as mvo | ||
| 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:29 |
| 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:30 |
| bryce | i.e. no this does not have that set | 19:31 |
| 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:32 |
| bryce | is there a way to check post-boot whether the option is in effect? | 19:33 |
| 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:34 |
| bryce | that would do. log output in what file? | 19:35 |
| jbarnes | the gdm log iirc | 19:40 |
| jbarnes | like albert23 had | 19:40 |
| 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:41 |
| bryce | is the batch output included in intel_gpu_dump or /sys/kernel/debug/dri/0/i915* or dmesg as well, already? | 19:42 |
| 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:43 |
| 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:44 |
| 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:46 |
| bryce | I see that an easy way to tell that it's in effect is that it slows the system down noticeably | 19:48 |
| 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:51 |
| jbarnes | any running clients won't pick up the change though afaik | 19:52 |
| bryce | ok, now have a freeze with the dri option, your patch, and INTEL_DEBUG=batch. | 19:53 |
| jbarnes | cool | 19:53 |
| bryce | intel_context.c:527: Batchbuffer flush with 404b used | 19:55 |
| bryce | hrm, the compressed tarball with the gdm.log is 100mb | 20:18 |
| bryce | 74 mb to be specific | 20:19 |
| jbarnes | can you put it somewhere? | 20:21 |
| jbarnes | btw I hope you can meet w/anholt, would probably go much faster | 20:22 |
| bryce | waiting on it to upload to launchpad... might be a while | 20:24 |
| bryce | meanwhile, snag it from: http://www2.bryceharrington.org:8080/files/i915_debugfs_bwh6.tgz | 20:25 |
| bryce | jbarnes: ^ | 20:30 |
| jbarnes | thanks | 20:30 |
| 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:37 |
| bryce | it locked up while the switch-desktop OSD was showing, fwiw | 20:38 |
| 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:41 |
| jbarnes_ | bryce: ok cool | 20:50 |
| bryce | forwarding the invite | 20:50 |
| bryce | heh, compiz is starting to get piles of "compiz suddenly stopped working!!1!" bug reports | 20:55 |
| 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:08 |
| 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:09 |
| mnemo | bryce: cool, I requested to join now | 21:11 |
| bryce | awesome, I've approved you | 21:11 |
| mnemo | thanks | 21:12 |
| mnemo | bryce: you use the "X-Launchpad-Bug: sourcepackage=blah" mailheader to sort the mail right? | 21:22 |
| bryce | mnemo: exactly | 21:23 |
| 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:24 |
| 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:27 |
| * bryce nods | 21:32 | |
| bryce | I use mutt, and colorize based on status changes | 21:32 |
| bryce | mnemo: http://pastebin.ubuntu.com/156128/ | 21:33 |
| bryce | heya tormod | 21:34 |
| 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:35 |
| bryce | tormod: pretty bare bones so far, but it will be living at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates | 21:36 |
| tormod | hi bryce! that's exactly what we have in ~intel-gfx-testing | 21:49 |
| tormod | I have just been waiting for 2.7.1... | 21:50 |
| 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:51 |
| 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:52 | |
| 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:53 |
| 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:54 |
| 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:55 |
| bryce | it's the kernel dependencies that I worry most about... | 21:56 |
| tormod | yes those are a pita - I guess the "mainline kernels" repo will be popular | 21:57 |
| * 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:58 |
| 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.. | 21:59 |
| 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:00 |
| 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:02 |
| tormod | can it not run without acceleration? sounds like it dead slow anyway | 22:04 |
| === jbarnes_ is now known as jbarnes | ||
| bryce | jbarnes: another dri_debug dump with INTEL_DEBUG - https://bugs.edge.launchpad.net/ubuntu/+bug/365299 | 23:43 |
| ubottu | Launchpad bug 365299 in xserver-xorg-video-intel "[i965] X freeze while running repro script" [Undecided,New] | 23:43 |
| jbarnes | bryce: ok thanks | 23:44 |
| jbarnes | god interactive perf sucks when a build is going on | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!