[00:23] <bryce> man, this AGPMode bug is pervasive
[01:52] <bryce> tjaalton: looks like we have a choice between stable 2.4.2 or gem-enabled 2.4.97.0
[01:53] <jcristau> for a flickering value of stable ;)
[04:50] <pwnguin> heh
[04:50] <pwnguin> a bit of bugmail
[04:51] <pwnguin> apparently none of the bugs against wacom have invalid xorg.conf
[07:29] <tjaalton> every time you find the phrase "exact same problem" in a bugmail, stop reading..
[07:29] <tjaalton> you'll just get annoyed at people
[07:30] <tjaalton> bryce: you mean they won't support 2.4.2 anymore?
[07:31] <tjaalton> btw, what is the intel vblank-support supposed to do?
[07:31] <tjaalton> (in drm)
[07:36] <bryce> not sure about the vblank
[07:36] <bryce> but yeah sounds like 2.4.2 is the last in the 2.4.x series
[07:36] <bryce> "exact same problem, except..."
[07:38] <bryce> or my favorite, "making it completely unusable"
[07:39] <tjaalton> hehe, yeah
[07:56] <wgrant> Fix it now or I'm going back to Windows.
[07:58] <bryce> ooh, nice wgrant
[07:58] <crevette> :)
[07:59] <bryce> futile attempts to extort a bugfix really wins points
[08:00] <bryce> another good one is "I did foo, and then X didn't work"
[08:37] <tjaalton> mvo: so you've been running the evdev snapshot for some time?
[08:37] <tjaalton> mvo: any issues with it?
[08:39] <mvo> hey tjaalton
[08:39] <mvo> no, works fine for me
[08:39] <mvo> i run in on my two main machines
[08:41] <tjaalton> mvo: ok cool. I'm just wondering if we should go for the snapshot or pull stuff on top of 2.0.4
[08:44] <mvo> is there a release planned soon?
[08:44] <tjaalton> but looking at the commit diff, it's pretty clear that master doesn't have anything suspicious, mostly more properties supported etc
[08:44] <tjaalton> I'm not sure
[08:44] <tjaalton> I'll ask..
[08:46] <tjaalton> maybe I'll just cheat in the meantime and pull master on top of 2.0.3 so there's no paperwork needed :P
[08:50] <tjaalton> or bump the version to 2.0.99
[08:57] <mvo__> tjaalton: sorry, network trouble - what was the last bit you said?
[08:58] <tjaalton> 10:44 < mvo> is there a release planned soon?
[08:58] <tjaalton> 10:44 < tjaalton> I'm not sure
[08:58] <tjaalton> 10:44 < tjaalton> I'll ask..
[08:58] <tjaalton> 10:46 < tjaalton> maybe I'll just cheat in the meantime and pull master on top of 2.0.3 so there's no paperwork needed :P
[08:58] <tjaalton> 10:50 < tjaalton> or bump the version to 2.0.99
[09:26] <Ng> tjaalton: yes please, do want newer evdev so I can do mvo's emulatescrollwheel trick :)
[09:32] <tjaalton> right, I need to sync the upload of hal/evdev/gnome-settings-daemon/xkb-data to make sure the keyboard rules/model mess is sorted out once and for all
[09:33] <tjaalton> since currently the model is forced as evdev, but that has problems with some exotic layouts.. so the solution is to force rules=evdev instead
[09:33] <tjaalton> then the patch from g-s-d can be dropped, and people can change the kb model again
[09:34] <tjaalton> and the evdev rule should be modified to support the exotic layouts etc
[09:54] <tjaalton> uh, somehow git utterly failed merging xkeyboard-config master
[09:55] <tjaalton> every changed file in conflict
[09:55] <bryce> <3 git
[09:55] <jcristau> you need to merge 1.3 first
[09:56] <tjaalton> jcristau: isn't that merged already?
[09:56]  * jcristau doesn't remember
[09:56] <jcristau> i think not
[09:56] <jcristau> it was still using cvs at the time
[09:56] <tjaalton> ah, ok
[09:57] <tjaalton> wonder if Mohammed would mind me merging this in experimental too
[09:58] <jcristau> cvs keywords ftl though, they conflict the merge
[09:58] <jcristau> but iirc other than that it's trivial
[09:59] <tjaalton> yeah it looked trivial, simple substitutions and nothing else
[10:29] <tjaalton> k, merge done
[10:31] <tjaalton> guess all the .cvsignore files can be replaced with .gitignore
[10:32] <tjaalton> lunch ->
[12:13] <tjaalton> sigh, what a mess in xkeyboard-config.. I have no idea how these patches could apply before
[12:22] <tseliot> tjaalton: I have fixed nvidia-kernel-common a bit (lintian doesn't complain any more) and added didrocks' patch. Would you like to have a look at the new source?
[12:23] <tjaalton> tseliot: sure
[12:23] <tseliot> tjaalton: ok, here's a text file with the links: http://albertomilone.com/ubuntu/newlrm/nvk.txt
[12:28] <tjaalton> tseliot: anything specific I should be looking at?
[12:29] <tseliot> I have changed the debian/rules, control and removed some files
[12:30] <tjaalton> debdiff would probably be easier :)
[12:30] <tseliot> tjaalton: if you do a diff with the current version in ubuntu you will see all the changes
[12:30] <tseliot> yes
[12:30] <tjaalton> oh wait, I can do tha t myself
[12:33] <tjaalton> why didn't you merge with debian, they did most of the stuff already
[12:34] <tseliot> tjaalton: merge or sync?
[12:34] <tjaalton> merge
[12:36] <tseliot> I had a look at the debian package but I wasn't sure as to whether I wanted all the changes
[12:36] <tjaalton> well there is the debian version mentioned in preinst
[12:36] <tjaalton>  if dpkg --compare-versions "$2" lt-nl '20051028+1+nmu2'; then
[12:37] <tseliot> yes, right
[12:37] <tseliot> it's not finished
[12:37] <tseliot> I have to go for lunch now. See you later
[12:38] <tjaalton> ok, ask again when it's finished :)
[12:40] <tjaalton> I don't see why it couldn't be merged first
[13:15] <tjaalton> there xkb-data pushed to git..
[13:15] <tjaalton> +,
[13:15] <tjaalton> didn't feel like autoreconf'ing it
[13:52] <jcristau> tjaalton: haha. you got to discover the xkb-data disaster :)
[13:54] <jcristau> tjaalton: deleting the generated files from the source package and generating them cleanly on build would probably help
[15:22] <tseliot> tjaalton: I did the merge: http://albertomilone.com/ubuntu/newlrm/nvidia-kernel-common_20051028+1+nmu2ubuntu1.debdiff
[15:24] <tseliot> but I haven't attached the debdiff to the bugreport yet
[17:41] <tseliot> federico1: how do you suggest that I apply the settings with the capplet with a .desktop file on login?
[17:41] <tseliot> BTW I have implemented this new feature even though my patches still need some polish
[17:42] <federico1> tseliot: do you actually need a .desktop file?  if you set a flag somewhere, gnome-settings-daemon could notice that flag at startup and reconfigure the screens
[17:44] <tseliot> federico1: ok, I could modify the gnome-settings-daemon but I don't know if I can check that the outputs haven't changed in the settings daemon
[17:45] <tseliot> and we don't want it to apply the settings if the outputs have changed (e.g. if in the meantime you have swapped the external monitor with another,etc.)
[17:49] <federico1> tseliot: you may need to change the API in gnome-desktop a bit so that it can save without applying.  Then you can compare the loaded configuration with the current one, with gnome_rr_config_match()
[17:50] <tseliot> federico1: yes, that's what I did in xrandr-capplet.c and libgnome-desktop/gnome-rr-config.c
[17:50] <tseliot> federico1: but currently I make it save the settings to another xml file if the capplet can't apply the settings
[17:51] <federico1> tseliot: ah, ok
[17:52] <federico1> tseliot: then you can make gnome-settings-daemon see if that file exists.  If it does, match() it to the current screens and see if it's possible to use it
[17:54] <tseliot> federico1: do you know which file I should modify in the gnome-settings-daemon?
[17:58] <federico1> tseliot: gsd-xrandr-manager.c
[17:59] <federico1> gnome-settings-daemon/plugins/xrandr/gsd-xrandr-manager.c
[18:00] <tseliot> federico1: aah, it's in plugins. Thanks
[18:04] <tseliot> federico1: ok, I guess I'll have to play a bit with gnome_rr_config_apply_stored() in gsd_xrandr_manager_start(). I should get something working soon
[18:06] <federico1> tseliot: yeah, it shouldn't be hard... g-s-d is a bit of a PITA to debug, but that's like any startup program
[18:06] <tseliot> heh, right
[18:09]  * tseliot > dinner. bbl
[18:58] <tjaalton> jcristau: yeah, I wonder why anything with xkb in the name is shite
[18:58] <tjaalton> tseliot: that's more like it. ready to go :)
[18:59] <tseliot> tjaalton: great
[19:44] <jcristau> tjaalton: btw, feel free to revert my videoabiver bump, it's not like the abi has actually changed, and i guess it would be a pita for you
[20:02] <Awsoonn_> I am having issues with an ATI Radeon 7000, it has duel heads; the screen resolution tool can detect both of my monitors, but when I apply nothing useful happens
[20:03] <Awsoonn_> It is using the opensource driver, and there are no appernt options to use the blob
[20:41] <tjaalton> jcristau: ok, although soon we should be able to just sync them from experimental ;)
[20:42] <tjaalton> Awsoonn: there are some issues in the tool on intrepid
[20:42] <tjaalton> with
[20:48] <bryce> Awsoonn: probably you need to adjust your Virtual setting in xorg.conf
[20:48] <bryce> Awsoonn: are you on Intrepid?
[20:48] <tjaalton> ah, that incarnation left already
[20:49] <tjaalton> 22:29 -!- Awsoonn_ [n=dereck@oscar.lssu.edu] has quit ["Lost terminal"]
[20:52] <bryce> I've put the AGPMode quirking patch into our -ati for testing - http://bryceharrington.org/ubuntu/Ati/
[20:53] <bryce> I need to refresh my ati test box to test it.  If anyone else has a system they could check it on too it'd be appreciated
[20:57] <tjaalton> I'll probably upgrade my VDR box later this year, and it could end up being an AMD box.. so can't test just yet ;)
[23:14] <bdmurray> bryce: I've finished tagging xorg.conf files
[23:16] <bdmurray> I checked every package at https://bugs.launchpad.net/~ubuntu-x-swat/+packagebugs
[23:19] <bryce> bdmurray: excellent, thanks
[23:19] <bdmurray> only 8 invalid though :(
[23:21] <bryce> still good to know.  I'll go through those 8 when I get some time
[23:22] <bdmurray> hunh
[23:22] <bdmurray> might have missed a few
[23:22] <bdmurray> There are 67 files that end with 'org.conf' for example 'fglx_xorg.conf'
[23:22] <bryce> ahh
[23:22] <bdmurray> and 'working-xorg.conf'
[23:23] <bdmurray> I guess I'll get back to you ;)
[23:45] <bdmurray> heh - diff.xorg.conf seems to be a false positive
[23:49] <bdmurray> bryce: Maybe I should check compiz bugs too?