[06:27] bryce: great! [06:27] heya [06:28] morning [06:48] I presume the nv driver isn't always this corruption-prone? [07:11] RAOF: how so? [07:13] Turning on metacity's compositor appears to make everything not work; I think this is just because it's stupendously slow at drawing fullscreen transparency. [07:13] But gnome-terminal gets corrupted, too. [07:14] In that everytime a new character is written, or a link is underlined, it's white on an all-white background. [07:15] Also, there seemed to be some confusion between usplash and nv, but I'm pretty sure that bug's been filed. [07:58] At least nouveau still loves me [08:15] that's nice [08:15] :) [08:16] I'll hunt down the bugs/file new ones after housework. [08:16] But nouveau is _so much_ better than nv, at least for me. [08:17] We should be using it by default. If only they'd nail down their kernel interface and release something! [08:17] indeed... [08:18] At least they've got a full-time paid dev now. That should speed things up! [08:18] yeah [08:18] I think fedora is pushing to have nouveau KMS ready asap [08:19] Which, IIUC, means nailing down the TTM/GEM/whatever MM stuff. [08:19] At least, that's what I gathered was blocking it from my idling in #nouveau. [08:20] probably so [08:20] * RAOF doesn't have a nv5x, so has never tested the existing KMS support. [08:22] I tried testing the -ng branches for DRI2/tfp/compiz support. That didn't go well :) [08:22] what marketing names match nv5x? [08:22] geforce 8+ [08:23] great, I've got one [08:23] Oh, and whatever quattro boards match it, too. [08:23] But quatros seem to have arbitrary product strings associated with them, so I couldn't even guess which ones are nv5x ;) [08:23] right [08:25] I'm not sure if the nv5x KMS is merged in the drm master we have as nouveau-kernel-source, though. It may still be in -modesetting-101, or something. [08:29] modesetting-gem probably [08:29] -101 is dead AIUI [08:33] Isn't modeseting-gem dead, too? [08:33] But it died later, certainly. [08:35] dave seems to use it for radeon [08:36] but darktama's branch seems to be the one for nouveau [08:36] repository, even [08:37] hum, no [08:37] That's the MM work, right? I think the initial KMS support went elsewhere. [08:37] yep.. [08:38] In some branch of some repository there is some KMS support. Who knows where! [08:39] yeah :) [08:39] I suspect the person who knows is darktama :) [08:43] nice, the intel pageflipping patch has six hunks that fail to apply [08:44] no idea what version it's against [08:45] tjaalton: where can I get this version of libxcb? https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/317746 [08:45] Launchpad bug 317746 in libxcb "Error when building libxcb 1.1.92 on jaunty" [Undecided,Incomplete] [08:45] tseliot: experimental [08:45] .93 builds [08:46] aah, ok so there's no need for me to fix it. [08:46] haha, the automated message is hilarious [08:46] good [08:46] "Hi bryceharrington," [08:46] hehe he's talking to himself [08:46] me, myself and LP [08:47] a title for a new film :-P [08:49] rotfl [10:11] intel builds now, but really needs the new mesa until it can be uploaded, because starting gnome hangs the machine [10:11] er, starting compiz that is [10:30] well, progress at least [11:00] * Ng is entirely happy to throw jaunty live CDs at his 3 or 4 different Intel chipset machines, whenever the versions of driver/mesa/etc are a bit settled :) [11:00] you might even say I was "actually rather keen" to do that, since I want them all to work :D [11:03] (which is a roundabout way of asking if, when the pieces have landed, you guys could post on the planet asking people to test) [11:23] hi guys.. any more info on the Xrandr loop bug? [11:23] I'm just prodding it with a stick now. [11:24] Seems that whilst this perhaps isn't causing the loop, I'm getting a monitor change event from GDK each time I step brightness up and down [11:25] changing using the hot-key, I get an xrandr event, monitor change event, then another xrandr, and another monitor-change event [11:26] Changing using xrandr directly, I'm seeing an xrandr event (notifying the property change), and a monitor change event from GDK [11:27] I suspect GDK is emitting that event when it shouldn't - looking at the code, it doesn't differentiate property change events from ones which actually effect the displays in a way suggested by the monitor change event [11:27] "The ::monitors-changed signal is emitted when the number, size or position of the monitors attached to the screen change." [11:29] *** infact, I'm not sure this is an infinite recursion loop at all... [11:30] I wonder if it is gnome-power-manager incrementing the backlight in tiny little steps [11:30] (which it does) [11:30] the underlying bug is that each step is taking a very long time because its causing the hardware to be re-probed [11:31] (Which may be due to buggy applications watching for Xrandr notify events, then querying the hardware for each it recieves) [11:32] hi, how do I get the current config out of Xorg? my xorg.conf is empty [11:32] empty xorg.conf means everything is auto-detected [11:32] I'm not sure if there is a way to extract an equivalent config [11:33] you could look at /var/log/Xorg.0.log for clues though [11:33] so rewriting the xorg.conf by hand is the next best thing? [11:33] ok, thanks [11:37] sure, but only if you need to specify some non-standard config [11:37] it is supposed to work without a config file unless you have an unusual case [11:41] jcristau? [12:18] hmm, monospace 7 looks even better now [12:21] Did the font change, or has something else? [12:21] I'm not sure :) [12:22] it's looks a bit smaller, but still is crisp and easy to read [12:22] meaning that I can fit more in my 10x7 screen [12:22] can't be bad [12:23] I'm just debugging Xrandr stuff [12:23] something nasty is going on [12:23] thanks for doing that :) [12:23] it doesn't affect my i965 [12:24] I'm not sure if there are any cases where this is a good thing, but GDK is emitting a "monitors-changed" event for every RRNotify_OutputProperty event recieved [12:24] Some apps are listening out for those - as far as I can tell, and retaliate by probing the hardware - which is very expensive [12:25] what Intel driver are you running on the i965? [12:25] currently 2.6.0 [12:25] ok, I've not updated yet.. was running git HEAD [12:25] let me fetch 2.6.0 and see if that changes things [12:29] it doesn't build unless you apply the patch from freedesktop bug 19591 [12:30] Error: Could not parse XML returned by Freedesktop: timed out (http://bugzilla.freedesktop.org/xml.cgi?id=19591) [12:33] Just fetched the package from Xorg-edgers and am rebuilding it [12:33] (Its marked as being for intrepid) [12:35] hmm, the upstream ChangeLog for that package ends at Bump version 2.5.99.2 [12:35] it needs to be manually updated [12:35] something they broken in the released tarball? [12:36] I'm not sure if the tarball ships it at all [12:37] the edgers package is probably built from git [12:37] ok - fair enough [12:59] A simple patch to GTK fixes the Xrandr issues [13:00] Just tell it not to emit a monitors-changed signal for any Xrandr output property notifications [13:00] I don't know if that is the "right thing" or not, but it seems vaguely sensible [13:00] no monitors-changed signal -> gnome-power-manager doesn't perform an expensive probe for every brightness change [13:00] turns out it probably wasn't an infinite loop.. just a lot of small steps to give a fading effect [13:03] great :) [13:03] do you have any idea why it was triggered by updating libxrandr? [13:04] no, but if you know which libxrandr versions the update was between, I'll grab the git repository and look over the appropriate delta [13:09] between 1.2.3 and 1.2.99.2 [13:10] only 14 commits.. shouldn't be too hard to track down [13:10] I'm not convinced that there wasn't a problem before though [13:10] My brightness changing problem existed before that librandr update [13:11] hmm... [13:12] there was an interesting bug fixed between those versions, regarding the event's "screen" property [13:12] I noticed GDK tested if screen != NULL before processing the event [13:13] I wonder if that disposed of some events in the old, buggy events case [13:16] oo... cool [13:16] new for Xrandr1.3, there is a new request which allows programs to retrieve the "current" resources without causing a hardware probe [13:18] gah, it was the "window" property of the event which had a bug.. never mind [13:18] heh [13:20] .... but the screen was determined from the window [13:22] its really not obvious whether that could have caused the problem or not [13:27] I bet :) [13:39] * pcjc2 really wishes GTK was in a GIT repository so I could do some decent history diving [13:47] it'll be.. [13:52] right.. I think I'll just post findings so far to Xorg, and send some info to gtk-devel [13:53] Now Xrandr 1.3 is available, those apps shouldn't be querying the config on notification... assuming the fact a notification occurred means that the Xserver knows the new state, you can just use the new API to retrieve the current config [14:04] xserver 1.6rc1 seems to work.. will release in a minute [14:14] pcjc2: but gnome-desktop and gnome-control-settings are gtk apps which use xlib. Gnome-desktop is maintained in svn and we even have a bazaar branch which keeps track of the changes in the svn repo [14:15] ah, I didn't read the "GIT" word [14:15] never mind [14:20] pcjc2: I think that the idea behind using notifications in the gnome randr applet was to have the cairo widget automatically updated (in theory) when the outputs change [14:20] did you see the last I posted on xorg@... [14:20] no, I didn't [14:20] * tseliot checks the mailing list [14:21] You can make the problems go away if you teach GDK not to emit a "monitors-changed" signal when receiving an Xrandr output property change notification. [14:22] With Xrandr 1.3, there is a new API which should avoid the server re-probing hardware. You could use that in response to a notification, since presumably if the server is notifying _you_ of a change, you then just need to ask it what its current understanding of the hardware is.. not use the old API which instructs it to re-probe [14:28] ok, so it was GDK. I wasn't aware of the change in the RandR API [14:31] aah you're referring to RRGetScreenResourcesCurrent() [14:31] yes, that should be cheaper [14:32] I've not actually tested the various versions of libXrandr people bisected this problem to.. [14:32] would have to un-patch / reinstall old GTK, then build both Xrandr versions to have a poke and see if GDK behaves differently [14:33] I could try patching g-s-d and g-p-m to use RRGetScreenResourcesCurrent instead of RRGetScreenResources [14:33] ordinarily I'd be curious, but part of me thinks we should just approach the necessary people to fix based on what we have now [14:33] that would be cool [14:33] I think g-s-d calls some other costly probe too, but I'm not sure [14:34] with more than one client firing requests in response to the notifications, it became difficult to tell just what was expensive, and what wasn't [14:34] heh [14:36] libxcb 1.1.93 uploaded, a fakesync of libx11 will follow [14:36] great [14:36] if it builds :-P [14:36] .92 didn't build, .93 should [14:37] otherwise bryce will have another conversation with himself [14:37] yeah :) [14:43] bryce: for some reason dch doesn't add spaces to the author when you modify the changelog (you have "[name]", instead of "[ name ]"), maybe that's one source of your git griefs?-) [14:49] afk, floorball -> [14:54] pcjc2: I can't reproduce the problem with my new patches [14:55] seb128 will be happy :-) [14:55] * Alexia_Death grumbles... [14:55] Alexia_Death: what's the matter? [14:56] Theres an annoying bug in X that is not really debuggable. [14:56] my X dies in graphcs driver code if I use my tablet for some time. [14:56] and it happens the same wether i use nv or nvidia [14:56] did you try vesa? [14:57] just for testing [14:57] I cant use vesa sensibly on my laptop... [14:57] It is not an on demand crash [14:57] ah, ok [14:57] It usually happens when I start drawing. [14:58] and have done it for a little bit. [14:58] and usually costs me my work. [14:58] I have two dumps for it but they are not really informative. [14:59] logs with stack traces that is [14:59] did you try with gdb? https://wiki.ubuntu.com/X/Backtracing [15:01] tseliot: What patches? [15:01] Using the new Xrandr 1.3 APIs to avoid the costly probe? [15:01] tseliot: difficult... but I think I know why my trace is useless. [15:02] tseliot: I dont think I have nv debuging symbols [15:02] pcjc2: the one which replace XRRGetScreenResources with XRRGetScreenResourcesCurrent [15:02] s/one/ones/ [15:04] tseliot: isnt jaunty repros supposed to contain debugging symbols for nv? [15:05] Alexia_Death: I don't know as I don't maintain it. Either tjaalton or bryce should know it though [15:05] tseliot: ok - cool. Although if they were to go upstream, I guess they'd need to be conditional on detecting Xrandr 1.3 being available [15:05] tseliot: Ok. I will ask one of them... They dont seem to tho... [15:06] I still think GDK is emitting more events than it should [15:06] not sure who to bug about that [15:06] pcjc2: yes, but g-s-d and g-p-m use xlib directly [15:06] I was hoping someone might pick up the thread. Soren Sandmaan showed an interest already [15:06] g-p-m also handles the GDK event [15:07] where? [15:07] maybe I missed it [15:07] g-p-m is pretty impotent in responding to the notifications in fact, when I checked out the source [15:07] the code was in an if (FALSE) {} [15:07] Alexia_Death: you can use the dbgsym from here: http://ddebs.ubuntu.com/pool/main/x/xserver-xorg-video-nv/ [15:08] ok, let me check [15:08] but.. in when it first sets up the Xrandr stuff, it calls gpm_brightness_xrandr_update_cache [15:08] tjaalton: why there are no debugging symbols for nv in jaunty repros? [15:08] albert23: how do I use them? [15:09] which connects to "monitors_changed" if it hasn't done so already [15:09] Alexia_Death: download the deb and install with dpkg -i [15:09] they are ddeb-s not just debs.. why? [15:10] deb [15:10] Ooh... [15:11] OK:) [15:11] Hopefully now I get some more informative dumps out of my crashes... [15:11] might need to fetch a load of debug packages [15:11] libc etc.. as well [15:12] otherwise the back-traces can be incomplete [15:12] Its really annoying btw that I have to go to console to coppy out the log or my next log-in will overwrite it... [15:12] some of them are in the repos as libfoo-dbg though [15:12] so you don't necessarily need the -dbgsym version [15:12] I have most that are in repros already [15:12] Xorg.0.log.old ? [15:12] pcjc2: yes. its overwritten the moment I log in. [15:13] ok - didn't know it fired up a new X server _after_ GDM [15:13] Crash, grm starts, crash log becomes .old, I log in the trace is lost... [15:14] It would be really neat if gdm stuffed after crash logs somewhere itself... [15:14] pcjc2: aah, you meant that it uses gdk to register the event type and add a filter. Yes, this is correct. [15:14] no [15:15] it uses g_signal_connect (G_OBJECT (gscreen), "monitors_changed", ... [15:15] line 610, gpm-brightness-xrandr.c [15:15] it is that callback which is / was causing the slow probe on [15:15] brightness changes, since GDK is emitting "monitors_changed" for every brightness change [15:16] (Which doesn't fit with its documented function) [15:16] yes, that's a property change [15:16] the documentation for "monitors_changed" doesn't say it will get called for property changes [15:17] The ::monitors-changed signal is emitted when the number, size or position of the monitors attached to the screen change. [15:18] in theory it should be correct if, for example, you change TV format (which is a property) [15:18] not.. this event will fire for every property change.. including one time for each of the hundreds of steps used when fading the backlight brightness [15:18] I had guessed there might be causes where that signal is needed [15:19] but the description of the signal is still wrong [15:19] that's easy to change ;) [15:20] and the changes to use the "Current" version of the Xrandr getters makes the performance hit go away [15:20] It still feels like it should be possible to filter those monitor-changed events to avoid getting swamped in backlight events [15:20] no point waking up so many processes to do essentially nothing [15:22] ok, so are you suggesting something like output-properties-changed? [15:23] which should be separate from monitor-changed [15:23] in GDK, I mean [15:24] I'd leave that sort of design decision to those who know the realm better [15:24] but its not a bad idea. [15:24] Even if you added "output-properties-changed", you might need to add detail about _what_ property you cared about [15:25] that would be nice to have [15:25] I guess it will take some time for developers to decide and implement this thing [15:26] in the meantime I'll write a patch for gnome-desktop and gnome-power-manager which checks the version of RandR and uses Current accordingly [15:26] and of course I'll give credit to you for suggesting the use of the less expensive call [15:28] I think most credit deserves to go to the implementer there... [15:28] hehe that's right [15:53] monitors-changed firing on property changes sounds like a bad idea [15:56] jcristau: the only reason I can think of is that of tv format. But of course as pcjc2 said, it would be nice to be able to separate events [16:32] tseliot: Are you Alberto Milone? [16:33] pcjc2: yes, I am [16:33] ok- no need to reply back to your email then ;) [16:33] no, I guess not ;) [16:34] Do you have an upload for the new g-s-d and g-p-m packages? [16:35] I'm writing things as we speak (so that only if X supports RandR 1.3 we use Current) [16:35] cool! [16:37] maybe we should check the version at runtime instead of doing it at compilation timeù [16:37] time [16:44] since it is a dynnamic thing, yes [16:44] although I doubt many users would be connecting to a remote X server using gnome-power-manager [16:44] IIRC, GDK has some code to check the version - if a cheat-sheet would help [16:49] I would like to call that function (e.g. XRRQueryVersion) only once though. I don't think we need to check the version every time an event is triggered [16:49] no - that would be roundtrips - which would be bad [18:44] hey [18:44] it seems X crashed, but bug reporting with apport doesn't work apparently [18:44] hmm [18:44] anyway the stackstrace is useless [20:50] hello, i compiled 2.6.29-rc2 kernel with kms support and use latest xorg and intel on jaunty a.t.m. But i get a corrupted screen instead of GDM. KMS seems to work tho... anyone want to help? [21:20] marijus: I guess you'd get more help from #intel-gfx [21:21] doubt many have tested kms here [21:21] tjaalton, i just posted there... thanks [21:21] np [21:24] crevette: any ideas on why apport isn't reporting the crash? I've noticed that not as many crash reports have been coming in as I expected [21:25] bryce: I have no idea at all, all my bugs reported end with a warning message [21:25] was anything put into /var/crash? [21:26] bryce: I'll be able to fix the mesa build tomorrow, it turns out to be pretty simple [21:27] tjaalton: ah good to hear [21:27] bryce: also, I fakesynced libx11 to get it out at the same time with libxcb [21:27] we can sync both when there are new releases [21:27] I'm about to head down to see my dad and will be gone through Wednesday. Dunno how internet connectivity will be. Might try to get some more of the xorg.conf backup/recovery stuff coded if I have time. [21:28] tjaalton: good deal, yeah it'd be nice to get all these merges through [21:28] ok, take your time.. I'll deal with the fallout ;) [21:29] I noticed that I've had xkeyboard-config merge sitting idle for a looong time.. will check it out too [21:31] kmail is not installable because of akonadi btw... [21:31] oops [21:31] wrong chan [21:31] sory [21:32] yeah I started looking at the xkeyboard-config merge yesterday. Noticed there's a *bunch* of conflicts [21:32] what I was thinking was we should work on getting all those changes upstream and drop everything else so we can just sync [21:33] upstream is reasonably responsive when we forward bugs and changes, so no reason we can't get into a position where we can give them our changes and just sync [21:34] anyway, put that low on your priority list, and I can take care of it when I get back if you don't get to it [21:49] bryce: I didn't notice your reply [21:51] bryce: http://pastebin.ubuntu.com/106069/ [22:19] ok, taking off, cya [22:23] take care bryce