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