tjaaltonbryce: great!06:27
RAOFI presume the nv driver isn't always this corruption-prone?06:48
tjaaltonRAOF: how so?07:11
RAOFTurning 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
RAOFBut gnome-terminal gets corrupted, too.07:13
RAOFIn that everytime a new character is written, or a link is underlined, it's white on an all-white background.07:14
RAOFAlso, there seemed to be some confusion between usplash and nv, but I'm pretty sure that bug's been filed.07:15
RAOFAt least nouveau still loves me07:58
tjaaltonthat's nice08:15
RAOFI'll hunt down the bugs/file new ones after housework.08:16
RAOFBut nouveau is _so much_ better than nv, at least for me.08:16
RAOFWe should be using it by default.  If only they'd nail down their kernel interface and release something!08:17
RAOFAt least they've got a full-time paid dev now.  That should speed things up!08:18
tjaaltonI think fedora is pushing to have nouveau KMS ready asap08:18
RAOFWhich, IIUC, means nailing down the TTM/GEM/whatever MM stuff.08:19
RAOFAt least, that's what I gathered was blocking it from my idling in #nouveau.08:19
tjaaltonprobably so08:20
* RAOF doesn't have a nv5x, so has never tested the existing KMS support.08:20
RAOFI tried testing the -ng branches for DRI2/tfp/compiz support.  That didn't go well :)08:22
tjaaltonwhat marketing names match nv5x?08:22
RAOFgeforce 8+08:22
tjaaltongreat, I've got one08:23
RAOFOh, and whatever quattro boards match it, too.08:23
RAOFBut quatros seem to have arbitrary product strings associated with them, so I couldn't even guess which ones are nv5x ;)08:23
RAOFI'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:25
tjaaltonmodesetting-gem probably08:29
tjaalton-101 is dead AIUI08:29
RAOFIsn't modeseting-gem dead, too?08:33
RAOFBut it died later, certainly.08:33
tjaaltondave seems to use it for radeon08:35
tjaaltonbut darktama's branch seems to be the one for nouveau08:36
tjaaltonrepository, even08:36
tjaaltonhum, no08:37
RAOFThat's the MM work, right?  I think the initial KMS support went elsewhere.08:37
RAOFIn some branch of some repository there is some KMS support.  Who knows where!08:38
tjaaltonyeah :)08:39
RAOFI suspect the person who knows is darktama :)08:39
tjaaltonnice, the intel pageflipping patch has six hunks that fail to apply08:43
tjaaltonno idea what version it's against08:44
tseliottjaalton: where can I get this version of libxcb? https://bugs.launchpad.net/ubuntu/+source/libxcb/+bug/31774608:45
ubottuLaunchpad bug 317746 in libxcb "Error when building libxcb 1.1.92 on jaunty" [Undecided,Incomplete]08:45
tjaaltontseliot: experimental08:45
tjaalton.93 builds08:45
tseliotaah, ok so there's no need for me to fix it.08:46
tjaaltonhaha, the automated message is hilarious08:46
tjaalton"Hi bryceharrington,"08:46
tseliothehe he's talking to himself08:46
tjaaltonme, myself and LP08:46
tseliota title for a new film :-P08:47
tjaaltonintel builds now, but really needs the new mesa until it can be uploaded, because starting gnome hangs the machine10:11
tjaaltoner, starting compiz that is10:11
brycewell, progress at least10:30
* 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
Ngyou might even say I was "actually rather keen" to do that, since I want them all to work :D11:00
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:03
pcjc2hi guys.. any more info on the Xrandr loop bug?11:23
pcjc2I'm just prodding it with a stick now.11:23
pcjc2Seems 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 down11:24
pcjc2changing using the hot-key, I get an xrandr event, monitor change event, then another xrandr, and another monitor-change event11:25
pcjc2Changing using xrandr directly, I'm seeing an xrandr event (notifying the property change), and a monitor change event from GDK11:26
pcjc2I 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 event11:27
pcjc2"The ::monitors-changed signal is emitted when the number, size or position of the monitors attached to the screen change."11:27
pcjc2*** infact, I'm not sure this is an infinite recursion loop at all...11:29
pcjc2I wonder if it is gnome-power-manager incrementing the backlight in tiny little steps11:30
pcjc2(which it does)11:30
pcjc2the underlying bug is that each step is taking a very long time because its causing the hardware to be re-probed11:30
pcjc2(Which may be due to buggy applications watching for Xrandr notify events, then querying the hardware for each it recieves)11:31
Makdaamhi, how do I get the current config out of Xorg? my xorg.conf is empty11:32
pcjc2empty xorg.conf means everything is auto-detected11:32
pcjc2I'm not sure if there is a way to extract an equivalent config11:32
pcjc2you could look at /var/log/Xorg.0.log for clues though11:33
Makdaamso rewriting the xorg.conf by hand is the next best thing?11:33
Makdaamok, thanks11:33
pcjc2sure, but only if you need to specify some non-standard config11:37
pcjc2it is supposed to work without a config file unless you have an unusual case11:37
tjaaltonhmm, monospace 7 looks even better now12:18
pcjc2Did the font change, or has something else?12:21
tjaaltonI'm not sure :)12:21
tjaaltonit's looks a bit smaller, but still is crisp and easy to read12:22
tjaaltonmeaning that I can fit more in my 10x7 screen12:22
pcjc2can't be bad12:22
pcjc2I'm just debugging Xrandr stuff12:23
pcjc2something nasty is going on12:23
tjaaltonthanks for doing that :)12:23
tjaaltonit doesn't affect my i96512:23
pcjc2I'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 recieved12:24
pcjc2Some apps are listening out for those - as far as I can tell, and retaliate by probing the hardware - which is very expensive12:24
pcjc2what Intel driver are you running on the i965?12:25
tjaaltoncurrently 2.6.012:25
pcjc2ok, I've not updated yet.. was running git HEAD12:25
pcjc2let me fetch 2.6.0 and see if that changes things12:25
tjaaltonit doesn't build unless you apply the patch from freedesktop bug 1959112:29
ubottuError: Could not parse XML returned by Freedesktop: timed out (http://bugzilla.freedesktop.org/xml.cgi?id=19591)12:30
pcjc2Just fetched the package from Xorg-edgers and am rebuilding it12:33
pcjc2(Its marked as being for intrepid)12:33
pcjc2hmm, the upstream ChangeLog for that package ends at     Bump version
tjaaltonit needs to be manually updated12:35
pcjc2something they broken in the released tarball?12:35
tjaaltonI'm not sure if the tarball ships it at all12:36
tjaaltonthe edgers package is probably built from git12:37
pcjc2ok - fair enough12:37
pcjc2A simple patch to GTK fixes the Xrandr issues12:59
pcjc2Just tell it not to emit a monitors-changed signal for any Xrandr output property notifications13:00
pcjc2I don't know if that is the "right thing" or not, but it seems vaguely sensible13:00
pcjc2no monitors-changed signal -> gnome-power-manager doesn't perform an expensive probe for every brightness change13:00
pcjc2turns out it probably wasn't an infinite loop.. just a lot of small steps to give a fading effect13:00
tjaaltongreat :)13:03
tjaaltondo you have any idea why it was triggered by updating libxrandr?13:03
pcjc2no, but if you know which libxrandr versions the update was between, I'll grab the git repository and look over the appropriate delta13:04
tjaaltonbetween 1.2.3 and
pcjc2only 14 commits.. shouldn't be too hard to track down13:10
pcjc2I'm not convinced that there wasn't a problem before though13:10
pcjc2My brightness changing problem existed before that librandr update13:10
pcjc2there was an interesting bug fixed between those versions, regarding the event's "screen" property13:12
pcjc2I noticed GDK tested if screen != NULL before processing the event13:12
pcjc2I wonder if that disposed of some events in the old, buggy events case13:13
pcjc2oo... cool13:16
pcjc2new for Xrandr1.3, there is a new request which allows programs to retrieve the "current" resources without causing a hardware probe13:16
pcjc2gah, it was the "window" property of the event which had a bug.. never mind13:18
pcjc2.... but the screen was determined from the window13:20
pcjc2its really not obvious whether that could have caused the problem or not13:22
tjaaltonI bet :)13:27
* pcjc2 really wishes GTK was in a GIT repository so I could do some decent history diving13:39
tjaaltonit'll be..13:47
pcjc2right.. I think I'll just post findings so far to Xorg, and send some info to gtk-devel13:52
pcjc2Now 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 config13:53
tjaaltonxserver 1.6rc1 seems to work.. will release in a minute14:04
tseliotpcjc2: 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 repo14:14
tseliotah, I didn't read the "GIT" word14:15
tseliotnever mind14:15
tseliotpcjc2: 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 change14:20
pcjc2did you see the last I posted on xorg@...14:20
tseliotno, I didn't14:20
* tseliot checks the mailing list14:20
pcjc2You 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:21
pcjc2With 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-probe14:22
tseliotok, so it was GDK. I wasn't aware of the change in the RandR API14:28
tseliotaah you're referring to RRGetScreenResourcesCurrent()14:31
tseliotyes, that should be cheaper14:31
pcjc2I've not actually tested the various versions of libXrandr people bisected this problem to..14:32
pcjc2would have to un-patch / reinstall old GTK, then build both Xrandr versions to have a poke and see if GDK behaves differently14:32
tseliotI could try patching g-s-d and g-p-m to use RRGetScreenResourcesCurrent instead of RRGetScreenResources14:33
pcjc2ordinarily I'd be curious, but part of me thinks we should just approach the necessary people to fix based on what we have now14:33
pcjc2that would be cool14:33
pcjc2I think g-s-d calls some other costly probe too, but I'm not sure14:33
pcjc2with more than one client firing requests in response to the notifications, it became difficult to tell just what was expensive, and what wasn't14:34
tjaaltonlibxcb 1.1.93 uploaded, a fakesync of libx11 will follow14:36
tseliotif it builds :-P14:36
tjaalton.92 didn't build, .93 should14:36
tseliototherwise bryce will have another conversation with himself14:37
tjaaltonyeah :)14:37
tjaaltonbryce: 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:43
tjaaltonafk, floorball ->14:49
tseliotpcjc2: I can't reproduce the problem with my new patches14:54
tseliotseb128 will be happy :-)14:55
* Alexia_Death grumbles...14:55
tseliotAlexia_Death: what's the matter?14:55
Alexia_DeathTheres an annoying bug in X that is not really debuggable.14:56
Alexia_Deathmy X dies in graphcs driver code if I use my tablet for some time.14:56
Alexia_Deathand it happens the same wether i use nv or nvidia14:56
tseliotdid you try vesa?14:56
tseliotjust for testing14:57
Alexia_DeathI cant use vesa sensibly on my laptop...14:57
Alexia_DeathIt is not an on demand crash14:57
tseliotah, ok14:57
Alexia_DeathIt usually happens when I start drawing.14:57
Alexia_Deathand have done it for a little bit.14:58
Alexia_Deathand usually costs me my work.14:58
Alexia_DeathI have two dumps for it but they are not really informative.14:58
Alexia_Deathlogs with stack traces that is14:59
tseliotdid you try with gdb? https://wiki.ubuntu.com/X/Backtracing14:59
pcjc2tseliot: What patches?15:01
pcjc2Using the new Xrandr 1.3 APIs to avoid the costly probe?15:01
Alexia_Deathtseliot: difficult... but I think I know why my trace is useless.15:01
Alexia_Deathtseliot: I dont think I have nv debuging symbols15:02
tseliotpcjc2: the one which replace XRRGetScreenResources with XRRGetScreenResourcesCurrent15:02
Alexia_Deathtseliot: isnt jaunty repros supposed to contain debugging symbols for nv?15:04
tseliotAlexia_Death: I don't know as I don't maintain it. Either tjaalton or bryce should know it though15:05
pcjc2tseliot: ok - cool. Although if they were to go upstream, I guess they'd need to be conditional on detecting Xrandr 1.3 being available15:05
Alexia_Deathtseliot: Ok. I will ask one of them... They dont seem to tho...15:05
pcjc2I still think GDK is emitting more events than it should15:06
pcjc2not sure who to bug about that15:06
tseliotpcjc2: yes, but g-s-d and g-p-m use xlib directly15:06
pcjc2I was hoping someone might pick up the thread. Soren Sandmaan showed an interest already15:06
pcjc2g-p-m also handles the GDK event15:06
tseliotmaybe I missed it15:07
pcjc2g-p-m is pretty impotent in responding to the notifications in fact, when I checked out the source15:07
pcjc2the code was in an if (FALSE) {}15:07
albert23Alexia_Death: you can use the dbgsym from here: http://ddebs.ubuntu.com/pool/main/x/xserver-xorg-video-nv/15:07
tseliotok, let me check15:08
pcjc2but.. in when it first sets up the Xrandr stuff, it calls gpm_brightness_xrandr_update_cache15:08
Alexia_Deathtjaalton: why there are no debugging symbols for nv in jaunty repros?15:08
Alexia_Deathalbert23: how do I use them?15:08
pcjc2which connects to "monitors_changed" if it hasn't done so already15:09
albert23Alexia_Death: download the deb and install with dpkg -i15:09
Alexia_Deaththey are ddeb-s not just debs.. why?15:09
Alexia_DeathHopefully now I get some more informative dumps out of my crashes...15:11
pcjc2might need to fetch a load of debug packages15:11
pcjc2libc etc.. as well15:11
pcjc2otherwise the back-traces can be incomplete15:12
Alexia_DeathIts 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
pcjc2some of them are in the repos as libfoo-dbg though15:12
pcjc2so you don't necessarily need the -dbgsym version15:12
Alexia_DeathI have most that are in repros already15:12
pcjc2Xorg.0.log.old ?15:12
Alexia_Deathpcjc2: yes. its overwritten the moment I log in.15:12
pcjc2ok - didn't know it fired up a new X server _after_ GDM15:13
Alexia_DeathCrash, grm starts, crash log becomes .old, I log in the trace is lost...15:13
Alexia_DeathIt would be really neat if gdm stuffed after crash logs somewhere itself...15:14
tseliotpcjc2: aah, you meant that it uses gdk to register the event type and add a filter. Yes, this is correct.15:14
pcjc2it uses g_signal_connect (G_OBJECT (gscreen), "monitors_changed", ...15:15
pcjc2line 610, gpm-brightness-xrandr.c15:15
pcjc2it is that callback which is / was causing the slow probe on 15:15
pcjc2brightness changes, since GDK is emitting "monitors_changed" for every brightness change15:15
pcjc2(Which doesn't fit with its documented function)15:16
tseliotyes, that's a property change15:16
pcjc2the documentation for "monitors_changed" doesn't say it will get called for property changes15:16
pcjc2The ::monitors-changed signal is emitted when the number, size or position of the monitors attached to the screen change.15:17
tseliotin theory it should be correct if, for example, you change TV format (which is a property)15:18
pcjc2not.. this event will fire for every property change.. including one time for each of the hundreds of steps used when fading the backlight brightness15:18
pcjc2I had guessed there might be causes where that signal is needed 15:18
pcjc2but the description of the signal is still wrong15:19
tseliotthat's easy to change ;)15:19
pcjc2and the changes to use the "Current" version of the Xrandr getters makes the performance hit go away15:20
pcjc2It still feels like it should be possible to filter those monitor-changed events to avoid getting swamped in backlight events15:20
pcjc2no point waking up so many processes to do essentially nothing15:20
tseliotok, so are you suggesting something like output-properties-changed?15:22
tseliotwhich should be separate from monitor-changed15:23
tseliotin GDK, I mean15:23
pcjc2I'd leave that sort of design decision to those who know the realm better15:24
pcjc2but its not a bad idea.15:24
pcjc2Even if you added "output-properties-changed", you might need to add detail about _what_ property you cared about15:24
tseliotthat would be nice to have15:25
tseliotI guess it will take some time for developers to decide and implement this thing15:25
tseliotin the meantime I'll write a patch for gnome-desktop and gnome-power-manager which checks the version of RandR and uses Current accordingly15:26
tseliotand of course I'll give credit to you for suggesting the use of the less expensive call15:26
pcjc2I think most credit deserves to go to the implementer there...15:28
tseliothehe that's right15:28
jcristaumonitors-changed firing on property changes sounds like a bad idea15:53
tseliotjcristau: 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 events15:56
pcjc2tseliot: Are you Alberto Milone?16:32
tseliotpcjc2: yes, I am16:33
pcjc2ok- no need to reply back to your email then ;)16:33
tseliotno, I guess not ;)16:33
pcjc2Do you have an upload for the new g-s-d and g-p-m packages?16:34
tseliotI'm writing things as we speak (so that only if X supports RandR 1.3 we use Current)16:35
tseliotmaybe we should check the version at runtime instead of doing it at compilation timeĆ¹16:37
pcjc2since it is a dynnamic thing, yes16:44
pcjc2although I doubt many users would be connecting to a remote X server using gnome-power-manager16:44
pcjc2IIRC, GDK has some code to check the version - if a cheat-sheet would help16:44
tseliotI 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 triggered16:49
pcjc2no - that would be roundtrips - which would be bad16:49
crevetteit seems X crashed, but bug reporting with apport doesn't work apparently18:44
crevetteanyway the stackstrace is useless18:44
marijushello, 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? 20:50
tjaaltonmarijus: I guess you'd get more help from #intel-gfx21:20
tjaaltondoubt many have tested kms here21:21
marijustjaalton, i just posted there... thanks21:21
brycecrevette: 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 expected21:24
crevettebryce: I have no idea at all, all my bugs reported end with a warning message21:25
brycewas anything put into /var/crash?21:25
tjaaltonbryce: I'll be able to fix the mesa build tomorrow, it turns out to be pretty simple21:26
brycetjaalton: ah good to hear21:27
tjaaltonbryce: also, I fakesynced libx11 to get it out at the same time with libxcb21:27
tjaaltonwe can sync both when there are new releases21:27
bryceI'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:27
brycetjaalton: good deal, yeah it'd be nice to get all these merges through21:28
tjaaltonok, take your time.. I'll deal with the fallout ;)21:28
tjaaltonI noticed that I've had xkeyboard-config merge sitting idle for a looong time.. will check it out too21:29
Alexia_Deathkmail is not installable because of akonadi btw...21:31
Alexia_Deathwrong chan21:31
bryceyeah I started looking at the xkeyboard-config merge yesterday.  Noticed there's a *bunch* of conflicts21:32
brycewhat I was thinking was we should work on getting all those changes upstream and drop everything else so we can just sync21:32
bryceupstream 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 sync21:33
bryceanyway, put that low on your priority list, and I can take care of it when I get back if you don't get to it21:34
crevettebryce: I didn't notice your reply21:49
crevettebryce: http://pastebin.ubuntu.com/106069/21:51
bryceok, taking off, cya22:19
tseliottake care bryce22:23

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!