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