=== ripps_ is now known as ripps === jldugger is now known as pwnguin [07:49] ugh, going to have to do something else with mesa, need to install a dri.pc to build xserver master [11:20] tseliot: Are you aware of the -synaptics rename in Debian, and its clobbering of our local changes in Karmic? [11:21] ouch, no [11:21] wgrant: I'll have a look at it [11:21] thanks for reporting [11:21] Bug 378391 [11:22] Launchpad bug 378391 in xserver-xorg-input-synaptics "Source rename clobbered local changes" [High,In progress] https://launchpad.net/bugs/378391 [11:22] I have a merged version in my PPA. [11:23] Should I prepare a proper upload, or do you have other stuff that needs doing to it? [11:24] ooi, what are the synaptics changes besides the tapping default? [11:24] Mostly defaults changes. [11:24] But let's see what else... [11:26] The defaults we change are tapping, corner tapping, multifinger tapping, vertical edge scrolling. [11:26] ok [11:27] We have a newish patch to blacklist from movement some region at the bottom of the touchpad. [11:27] vert edge was changed in 1.1.1 so hopefully that'll be fine now [11:27] Different defaults for ALPS. [11:27] 1.1.1 has been released? [11:27] yeah [11:28] it's brand new [11:28] Ah, 4 hours new. That explains why I hadn't seen it. [11:28] wgrant: I'm at All Hands now in Barcelona and I'm dealing with -psb [11:28] so I don't have a lot of time now [11:29] but the different edge scrolling defaults for alps is already in the snapshot that mattia uploaded to sid a week ago [11:29] tseliot: Ew, that can't be much fun. [11:29] it's not ;) [11:30] * tseliot has to run [11:30] jcristau: It looks like we change a lot more than scrolling defaults for ALPS. [11:30] tseliot: I'll prepare an upload. Thanks. [11:30] great :-) [11:30] jcristau: And the patch doesn't conflict with the latest sid version. [11:31] wgrant: was that sent upstream, or not yet? [11:31] jcristau: I don't know; I had insufficient time to keep track of these things during Jaunty, when it was added. [11:31] It's one of tseliot's patches. [11:32] okay. thanks! [11:36] * hyperair wonders if anyone has met with but #367377 [11:36] i've been dropping 108 and 109 in the 1.1.99 git snapshots i use [11:36] bug #367377 [11:37] Launchpad bug 367377 in xserver-xorg-video-intel "High load average, disk read, no apparent reason - 2.6.28-11" [Undecided,Confirmed] https://launchpad.net/bugs/367377 [11:37] hmm the description should be changed, really. it's basically the stupid memory leak sisue [11:37] issue* [11:38] Sarvatt: 108 should go, but I've kept 109. [11:38] hyperair: Yep. Not so much now as in early Jaunty, but it still happens occasionally. [11:38] It used to happen many times a day. [11:39] wgrant: only occassionally for you? =( [11:39] wgrant: it happens to me every 6 hours or so [11:39] and that's after patching drm-snapshot [11:39] to disable BO caching, that is [11:39] hyperair: I restart X a bit at the moment. [11:39] previously, ever 4 hours [11:40] yeah, i'm forced to restart X every 6 hours now. [11:40] which is very annoying [11:40] But the swap is constantly filling up. [11:40] Although it seems to be OK now. [11:40] Actually, I'm not using KMS today. Maybe that makes a difference. [11:41] i'm not using KMS either [11:41] what's your X's uptime? [11:42] and what are the versions you're using? (kernel, driver, drm, mesa) [11:42] that patch is straight out of my diff on edgers, its part of a 3 part patch series that fixes the UXA firefox crashes and needs a kernel patch as well thats not upstream yet.. [11:42] driver/drm/mesa from xorg-edgers. [11:42] and your gpu? [11:42] is it a 965? [11:42] Karmic's Linux 2.6.30-5.6 [11:42] i915 [11:42] 915 eh.. [11:42] i think it doesn't hit the older cards as hard [11:43] 965 seems the most badly hit [11:43] (and it's still around with xorg-edgers' driver/drm/mesa [11:43] so i've taken to watching /proc/dri/0/gem_objects [11:43] Yep. [11:43] i've currently got about 500MB in there. [11:44] i've got 724MB [11:44] but it keeps rising until approximately 2G [11:44] that's when i have to restart X [11:44] Been up for 9 hours, but unused for most of that time. [11:44] or it'll begin thrashing [11:44] its still around with the kernel patch that thats part of too, it didnt happen until about a week and a half ago for me strangely [11:44] unused doesn't count =O [11:44] 908mb here [11:44] Sarvatt: and your X uptime? [11:45] mine's approx 3h 30m [11:46] 72 minutes since i zapped it last [11:47] then you're definitely experiencing the bug to a certain extent [11:47] try stretching it over 6 hours and see [11:48] wgrant: 109 didnt apply to 1.1.99 I dont think, since they ripped out all the SHMConfig stuff, and I dont have alps so I didnt bother with it is all :D [11:49] right, shmconfig is ripped out in master, but not 1.1-branch [11:50] shmconfig? the synaptics driver? [11:50] won't syndaemon fail then? [11:50] No, it uses XI properties now. [11:50] Same with synclient. [11:50] In master, SHMConfig is only used for monitoring internal stuff, not setting things. [11:50] hmm cool. [11:50] The horrible beast is finally dead. [11:51] indeed [11:51] its nice being able to disable tap and drag on 1.1.99 :D [11:51] ? [11:52] http://cgit.freedesktop.org/xorg/driver/xf86-input-synaptics/commit/?id=ee265e10c9cc724ad0badcab86a3893667717322 [11:54] tap and drag meaning ..? [11:54] aah [11:54] i see [11:55] awesome [11:55] i've had a lot of my clicks accidentally sticking [11:55] heheh [11:57] hmm Xorg gets loaded when an application window changes its title rapidly [12:41] 974680064 object bytes T_T [12:42] surely a driver doesn't need over 1G just to render an empty desktop?! [13:23] hyperair: I'm up to 800MB. I just closed Firefox with its several dozen tabs, and the usage went *up*. [13:39] and it'll keep going up [13:39] * hyperair grumbles [13:40] eventually it'll shove everything into your swap, and free -m will show that you've got around 1G of disk cache [13:40] wgrant: ^ [13:42] i don't see anything like that on debian. does it only show up with compiz, or newer than 2.6.29 kernels, or? [13:42] .28 is enough [13:42] only with compiz [13:43] or rather... [13:43] compositing is required. [13:43] ah so that explains it [13:43] otherwise the bug doesn't appear [13:43] i'm also beginning to believe that most of the #intel-gfx people don't have compositing enabled. [13:43] and so they don't notice this bug [13:43] and don't give a frigging damn about it [13:45] i don't think that's true. but they have so many bugs some just stay under the radar for a while :) [13:45] hyperair: Right, that's what I've been seeing. [13:45] It took me a while to work out that the cache was actually mostly GEM data. [13:46] yeah that took me a while too [13:46] i was blaming ext4 at first [13:46] but then i realized that vm.vfs_cache_pressure and vm.swappiness wasn't working [13:46] I twigged it wasn't really cache when 'swapoff -a' got OOM-killed while there was still 1GB cached... [13:46] heh yeah [13:46] exactly [13:46] same here [13:46] no actually swapoff didn't get OOM-killed for me [13:47] it went into super-thrashing mode [13:47] and never got out [13:47] i left it for an hour or so [13:47] hmm. [13:47] Maybe you left it too late. [13:47] and the hard disk light still didn't stop blinking [13:47] maybe [13:47] i usually ^C swapoff myself [13:47] before it goes into a swapin/out frenzy [13:51] i think if you continually use the ring switcher in compiz, you can dramatically raise the GEM usage [13:51] for testing purposes of course. i wouldn't actually want something like that to happen =( [13:54] does killing compiz reclaim the buffers, or do you need to restart X? [13:55] restart X [13:55] it's X which owns most of the GEM buffers [13:55] you could do something like sudo lsof -n | grep drm | grep Xorg | wc -l [13:55] and compare that figure to without grep Xorg [13:56] with grep Xorg it's 779 on my system currently [13:56] 2 :) [13:56] and 794 in total. [13:56] ..2?! [13:56] 1106 here [13:56] what do you have running, xterm and xclock?! [13:56] 0 now [13:56] and 1106 total :) [13:56] jcristau: what's the second line in /proc/dri/0/gem_objects? [13:57] 1133780992 object bytes [13:57] that's it for me =( [13:57] (note that i'm not running a compositor) [13:57] yes, you've mentioned [13:57] 39084032 object bytes [13:57] a lot more reasonable :) [13:57] yes. a lot more reasonable indeed. [13:57] during the first hour or so, that's the figure for me [13:58] after that it rises [13:58] now is... the fifth hour. [13:59] i dont get the same symptoms as most of these bugs on it though, it was absolutely fine until about a week and a half ago [14:00] how very strange. [14:00] =( [14:00] Sarvatt: what's your hardware again? [14:00] acer aspire one, 945GME [14:00] ah yes [14:00] it doesn't affect 945 i reckon [14:00] i was bugging some people on #intel-gfx [14:00] and they said it doesn't happen for them [14:00] and they were using 945 [14:01] most of the people i know who have issues are using 965. [14:01] including me [14:01] and since wgrant is having the issue, i suppose it affects 915 as well. [14:02] 915 and 945 are basically the same, though.. [14:02] is it? [14:02] =\ [14:02] so that's weird [14:02] weird indeed. [14:03] we need more 915 people. [14:03] and more 945 people [14:03] i'm getting the same problem now though with the hdd thrashing and everything though, but i never had it before about a week and a half ago even with weeks of uptime [14:03] ah [14:03] ^ thats some 9 am grammar [14:03] but do you know what changed? [14:03] nope [14:03] =( [15:34] Hi guys. Forgive the noobish question, but I'm wondering how to download and install this Nvdia driver: https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/+build/958828 [16:04] go to https://launchpad.net/~ubuntu-x-swat/+archive/x-updates [16:04] instructions are there [16:10] 189329408 object bytes (restarted X) [17:14] hyperair: he left already ;) [17:26] he did? [17:26] oh right [17:26] he did [17:26] bah [17:33] there are 915-specific bugs? [17:51] * hyperair doesn't know [17:56] likely so [18:21] nice, opening a specific webpage hangs my i965 [18:24] same backtrace [18:25] bryce_: did you have the intel merge ready? [18:26] tjaalton, they fixed that up 2 days ago, need an updated kernel/libdrm/-intel [18:26] Sarvatt: nice [18:27] but how do you know it's the same bug?-) [18:27] https://bugs.freedesktop.org/show_bug.cgi?id=20152 [18:27] Freedesktop bug 20152 in Driver/intel "[G45/GM965 UXA] cannot view JPG in firefox when running UXA (lots of errors in dmesg)" [Major,Resolved: fixed] [18:29] i have the libdrm/-intel updated on xorg-edgers already and if you want to test the kernel out i've got one here with the update already applied if you want to try it, its not upstream yet and rc7 isnt far off so it'll probably be a few weeks till it hits a ubuntu kernel [18:29] http://sarvatt.com/downloads/2.6.30-rc6/ [18:30] there's nothing in dmesg [18:30] yep i got nothing too [18:32] but the backtrace is the same [18:32] the url was about the unix-timeline, and it probably had the picture on the frontpage [18:33] try going to www.woodtv.com :D [18:38] I'll pass ;) [18:42] now I just need to remove it from the ffox sessionstore.js.. [18:51] can just uncheck that specific page on the crash restore thing cant ya? [18:53] what's that? [23:00] tjaalton: no I do not have any merges pending at the moment [23:01] Sarvatt, tjaalton: that woodtv.com issue was traced down to a particular image on that page, which apparently has a width exceeding some buffer [23:02] tjaalton: the internet here at the hotel is too crappy to maintain an ssh session, so I think I'm not going to be doing any merging before I get home [23:03] however, since internet's been down so much, I'm working on a new tool to help with analyzing bugs, that I've been meaning to work on for quite some time