brycejames_w: btw I've finished the gnome-desktop update, I just need to test it and then will upload it, perhaps tonight03:58
brycetests ok; gnome-desktop uploaded05:58
brycehmm, looks like seb128 already did gnome-settings-daemon06:16
james_wbryce: great, I'll test them in a little while.06:46
ubotuNew bug: #214439 in xserver-xorg-video-tdfx (main) "Quake engine games freeze if video settings changed" [Undecided,New] https://launchpad.net/bugs/21443907:11
brycetdfx wtf?07:16
bryce3dfx Banshee... interesting07:18
ubotuNew bug: #214442 in xserver-xorg-video-ati (main) "Time out error with r128 and some games" [Undecided,New] https://launchpad.net/bugs/21444207:20
james_wbryce: what would you like me to work on today?07:21
james_wI can test the uploads, and also seb uploaded g-c-c, so I think the patches need updating there again.07:22
brycejames_w: how far along are you with the gnome-control-center patches?  Getting that uploaded is probably the next priority07:22
james_wthey were pretty good I think, I'll update them and do some more testing, and then talk to seb about them.07:23
brycepresently, I'm working on a new patch to g-d to add a mess of null pointer checks.  Seems like many of our bugs have been due to null pointers from g-d07:23
bryceso yeah, getting all the patches in g-c-c building properly, and getting that package would be the main goal today.07:25
james_wok, sure07:25
bryceLooking over our bugs and that people are reporting problems still even after seb's last set of uploads (which I thought would fix those bugs), the new g-c-c changes unfortunately aren't going to solve that07:26
bryceso priority #2 after that is sorting out why 199960 and 210226 are still happening07:26
brycethe patch I'm doing may help with 210226 but it may just expose the null pointer at a higher level (which would be a good thing, but just one step)07:27
brycein 199960, the reporters are getting pretty ornery and fussy, but I'm hopeful the g-s-d upload sorted it out - but not much word since the 3rd07:29
james_w199960 is nice and easy to reproduce, which helps.07:30
james_wany idea how to reproduce 210226?07:30
bryceare you able to reproduce 199960?  I've not been able to07:31
bryceI haven't reproduced 210226, but the backtraces are pretty clear07:31
brycethere were a bunch of unrelated issues lumped into 199960; I think the only remaining active was when running with Xgl, however I *think* the Apr 6th g-d/g-s-d uploads might have addressed that07:33
james_wI did "aptitude install xserver-xgl" and gnome-settings-daemon didn't start on the next login, so I assumed it was the bug, maybe it wasn't07:33
bryceif not, then maybe we need an explicit check for Xgl in g-s-d (and probably g-c-c) like the code I posted in comment 5707:33
james_wI tested on Monday07:34
james_wI'll test again today.07:35
james_wbryce: have you sent any of the other patches that we are carrying upstream?07:53
brycemy plan has been to send them once we verified they built against the latest code07:56
bryceon my list so far are these three for gnome-desktop:07:56
bryceI'm not sure if I should send in the g-s-d patch; I'm not sure checking for xrandr versions is really that necessary.  ubuntu and fedora are both running xrandr 1.2 servers, so...  might be useful in general, but I don't know07:58
bryceI want to go through the g-c-c patches once your work's uploaded, and send in a few of those.  I think half or so will be relevant for them07:58
james_wyeah, that's what it looks like to me.07:59
james_wthe revert dialog requires 104_gd-randr-revert-support.patch?08:00
james_wok, thanks.08:00
bryceI'd asked ssp previously about that but never got a response, and am guessing he won't be so interested, but who knows.08:01
james_wI'm going back to bed for a short nap, but I'll start with g-c-c after that.08:01
bryceok cool08:01
brycejames_w: I'll be cc'ing the gnomecc list (it's pretty low traffic if you want to subscribe during this project)08:06
seb128bryce: hey08:12
seb128bryce: they changed all that in gnome-desktop since my patch update on monday or did you list changes which we already had in your changelog?08:13
bryceI listed changes we already had08:14
seb128ah ok, that was confusing08:14
seb128I think you didn't see my update and redid the work or something08:14
bryceactually that's the case :-/08:15
seb128but we dicussed it on IRC some days ago?08:15
brycebut I noticed right after uploading and see that we had almost exactly the same patch08:15
bryceI thought you had said you didn't have time to work on it, so I had it on my todo list08:15
seb128then I sent this mail to colin and you08:15
seb128james_w joined the chan08:16
seb128and we discussed the changes08:16
seb128you even asked me when I did take the snapshot08:16
seb128I copied the redhat viewcvs from saturday and you said that was newer than your snapshot08:16
bryceI assumed you took the snapshot and handed it over to james_w08:16
bryceso I asked james_w before I started if he'd had a chance to work on it, and he said no, so I said I had some time and would help by doing that bit08:17
seb128ok, I though I had been clear when I asked you guys to test the new hardy versions08:17
bryceI thought you meant the gnome changes in general08:17
seb128hum, k08:17
seb128so to be clear I updated this one08:17
seb128and the gnome-settings-daemon one too08:17
seb128there was just the gnome-control-center one to update, that's what I explain on the chan to james_w08:18
seb128I though you read that too, sorry about the confusion08:18
bryceno prob, actually the patches for gnome-desktop applied cleanly without issue, so the time was mostly just reviewing all the changes, which I planned to do regardless08:19
seb128btw they broke the ABI, dunno if you noticed08:19
seb128I had to add a breaks in the package on monday due to that08:20
bryceyeah I ran into that; confused me a bit08:20
brycecan you tell me more about it?08:20
seb128ok, so the only change in your update is the unstable define renamed apparently08:20
seb128so no breakage in this one08:21
seb128good ;-)08:21
bryceright; in fact my change just adds another define test we can opt to start using if we wish08:22
brycesince "ONLY_IN_FEDORA" clearly is not 100% true ;-)08:22
seb128right ;-)08:22
brycebut in general it probably doesn't matter to anyone, unless they're browsing code08:22
seb128btw why did you change the configure.in?08:23
bryceI didn't change that, but I wonder if it's a difference between the fedora rpm patch, and what I took from ssp?08:23
seb128they likely have extra debug macros used in git08:24
seb128that they don't use for the packaging08:24
seb128you reenabled those08:24
bryceyeah, I noticed that too but don't know what it does.  I can revert that part if you'd like08:24
seb128if that builds that's alright08:24
bryceit builds and I tested it and seems to work properly08:24
seb128alright, good08:25
seb128let's wait for james_w gnome-control-center patch update now08:25
seb128I'm wondering if somebody tried the current version using xgl08:25
seb128users tend to complain loud when things are broken08:25
bryceyeah I'm wondering that too08:26
seb128but they don't bother adding a comment when things are fixed usually08:26
brycejames_w said he can recreate the xgl issue fairly easy and will test it08:26
bryceyou know I get that with most X bugs too ;-)08:26
ubotuNew bug: #214470 in xorg (main) "gdm screen uses virtual screen size instead of actual" [Undecided,New] https://launchpad.net/bugs/21447008:40
tjaaltonbryce: isn't bug 205979 a dupe of 184651?08:51
ubotuLaunchpad bug 205979 in xorg-server "xserver crash on exit in CloseDownDevices and SrvXkbFreeGeomRows" [Unknown,Confirmed] https://launchpad.net/bugs/20597908:51
brycetjaalton: hmm let me look08:57
brycedarn, I nearly figured that one out myself.  guess I'm duplicating a lot of work lately!  ;-)08:59
tjaaltonheh :)08:59
tjaaltonI've now got six patches for xorg-server, mostly from upstream and one that defaults to intel instead of i81009:00
brycehmm, their patch doesn't match the direction I was going, but I bet it just solves it from a different (likely better) direction09:01
brycehmm, and looking at the backtraces and steps to reproduce, they're *slightly* different09:03
bryceI'm not 100% sure that the patch for 184651 will also solve 205979, but I think it's possible and it wouldn't surprise me at all09:04
tjaaltonmaybe ask again after this has been uploaded and then mark as dupe if it's fixed (and close the upstream report)09:05
ubotuNew bug: #214484 in xorg (main) "Standard NV driver doesn't work with G70 cards at 2560x1600" [Undecided,New] https://launchpad.net/bugs/21448409:26
tjaaltonhmmh, I had some mesa patches to add, but now I can't find any.. "assigned to" ftw09:29
tjaaltonlunch ->09:30
tjaaltonbryce: if you have anything you want me to look at, just ask09:30
bryceI don't have any patches for the xserver at the moment; I've been uploading other things directly as I run across them09:31
brycebugwise, the top priorities right now are the 4 x-related bugs at https://bugs.launchpad.net/ubuntu/+bugs?field.milestone%3Alist=82909:32
seb128did you guys made some video driver changes which could have broken the dpi values detected on some cards?09:32
bryceI uploaded some patches for -intel the past few days, including one that updates a bunch of quirks, a few of which could correct some dpi issues09:34
bryceother than -intel, I've not updated any other drivers09:34
ubotuLaunchpad bug 213745 in evince "PDF pages appear extremely small in evince" [Medium,Incomplete] 09:35
seb128upstream thinks it could be a dpi detection issue, I've asked for xdpyinfo logs and what card those users are using09:35
* bryce nods09:36
brycefor font dpi issues we also need to see their EDID, so it would be good to have their Xorg.0.log's09:37
seb128asked that on the b ug09:38
bryceone thing to look for in EDID is the monitor's physical dimensions, which is the thing that messes up dpi calculations09:38
bryceanyway, off to bed for me.  night09:38
seb128'night bryce09:38
seb128bryce: ok, those guys seem to all have intel cards09:59
seb128bryce: so I would say you broke the intel driver :-)09:59
ubotuNew bug: #213745 in xserver-xorg-video-intel (main) "PDF pages appear extremely small in evince" [High,Confirmed] https://launchpad.net/bugs/21374510:11
ubotuNew bug: #214499 in linux-restricted-modules-2.6.24 (restricted) "Recompiled Ubuntu kernel - nvidia driver does not load (comm: modprobe Not tainted)" [Undecided,New] https://launchpad.net/bugs/21449910:11
ubotuNew bug: #214501 in xkeyboard-config (main) "no dead keys in hardy" [Undecided,New] https://launchpad.net/bugs/21450110:16
Q-FUNKon bug #214119 I heard that before and this was already before the libpciaccess merge.10:19
ubotuLaunchpad bug 214119 in xserver-xorg-video-amd "[HARDY] Koolu W.E. (ION A603) does not detect higher resolution than 800x600" [High,Triaged] https://launchpad.net/bugs/21411910:19
Q-FUNKas far as I can tell, this is yet another case of a buggy BIOS that will require workarounds in x86emu.  The same driver works fine if compiled against an older X and using an xorg.conf10:20
ubotuNew bug: #209759 in firefox (universe) "firefox does not display scaled jpegs (dup-of: 182038)" [Undecided,Confirmed] https://launchpad.net/bugs/20975910:32
ubotuNew bug: #214513 in xserver-xorg-driver-i810 "mouse i810" [Undecided,New] https://launchpad.net/bugs/21451310:56
ubotuNew bug: #214517 in xserver-xorg-video-intel (main) "supend/resume broken with latest intel driver & kernel 2.6.24-15 " [Undecided,New] https://launchpad.net/bugs/21451711:06
ubotuNew bug: #214527 in evince (main) "Evince rendering very small text (dup-of: 213745)" [Low,Invalid] https://launchpad.net/bugs/21452712:10
ubotuNew bug: #208483 in ubiquity (main) "installer crashes in keyboard layout selection (dup-of: 184651)" [Undecided,New] https://launchpad.net/bugs/20848312:16
james_wseb128: hi. I've updated the g-c-c patch: http://jameswestby.net/scratch/g-c-c.diff12:19
seb128james_w: excellent!12:19
james_wit's now not showing any name for my monitor, I'll look in to why.12:20
james_wI also didn't change the #define to be the new one bryce added support for, so it still says FEDORA.12:21
ubotuNew bug: #212373 in firefox-3.0 (main) "PNG error (dup-of: 182038)" [Undecided,Incomplete] https://launchpad.net/bugs/21237312:22
seb128james_w: ok, the applet runs, that broken the "cancel the changes" action though, and I've no monitor description written either12:42
james_wthe cancel button in the timer window?12:43
seb128james_w: should I upload or do you want to give a try at fixing at least the cancellation thing before?12:43
seb128or using esc12:43
james_wit worked here.12:43
james_wdo you get any output on the terminal?12:43
seb128james_w: that's working now, go figure12:46
seb128xrand1.2 is still quite broken though12:46
seb128I thought it would work alright on intel, but it doesn't :-(12:46
seb128when switching to a lower resolution and back the screen has the small resolution area displayed correctly and the borders corrupted12:47
seb128mvo: ^ compiz issue?12:48
seb128compiz seems to thing the corrupted border is the limit of the workspace too12:49
seb128I can move the xorg cursor there and use things under it correctly12:49
seb128but when doing a dialog dnd for example it stops and switch workspaces12:49
mvoseb128: I have a look once I finished debugging this bug #213566 issue12:51
ubotuLaunchpad bug 213566 in xkeyboard-config "dapper->hardy missing files on upgrade" [High,In progress] https://launchpad.net/bugs/21356612:52
mvoits a nasty one12:52
seb128james_w: ok, that seems already to me, thanks a lot for the work on it, I'll upload12:52
seb128james_w: btw do you have an opinion on whether we should use "Refresh Rate" or "Refresh rate"?12:52
james_wif you want to hang on a minute I think I might have fixed the name thing.12:53
seb128the upstream capplet is using "Refresh rate"12:53
seb128james_w: sure12:53
james_wI though upstream was using "Rate", and we patched it to use "rate", which I just reverted12:53
james_wbryce said that the usability guy (is that mpt?) said that we should use capital letters for labels, and all of the rest do.12:54
seb128james_w: if you do patch edition could ou remove the extra g_print? I don't think we make any use of those informations anyway and we should have only errors printing in .xsession-errors12:54
james_wsure, you want me to remove them all?12:54
seb128just the non error ones12:54
seb128we should still display failures12:54
james_wshould I move them to something that would show up in .xsession-errors for debugging?12:54
seb128they do show up there already12:55
seb128that's why I want to clean those ;-)12:55
seb128at the moment it prints thing like12:55
seb128CRTC 49 Timestamp: 379273212:55
seb128Output 4e Timestamp: 379273212:55
seb128applying configuration. Clone: yes12:55
seb128those should not be printed I think12:56
seb128that's just a detail though12:56
james_wyeah, I agree.12:56
seb128I want to clean .xsession-errors for hardy but too much to do12:56
seb128I'll do a mini goal and try to get that for 8.04.112:56
seb128do a mini goal = write a wiki page or something or tag bugs and try to get contributors helping to clean those12:57
james_wI've got it showing "Cloned Output" again, so it's wrong, but less wrong.12:57
seb128did you had this label already using the hardy version?12:57
james_wthere's something wrong with the clone checkbox, so I'll have a quick look to see if I can debug that.12:57
james_wyes, it was wrong in the previous versions as well.12:58
seb128ok, so at least that's not a regression12:58
seb128brb, need to restart xorg to get an usuable workspace again12:58
james_wI think it's a problem with gnome-desktop patch though, so it shouldn't stop us uploading this.12:58
james_wIs there something better to use than g_print for real error messages?13:03
james_waside from a popup of course?13:03
seb128g_warning and g_error13:04
seb128g_error call abort though so it's only to use on real errors13:05
seb128and g_warning is for error worth reporting but which should stop the program13:05
seb128and also g_messages for normal messages13:08
seb128what is nice is that you can change the log handler so make those go in a debug log rather than on std*13:08
seb128oh, that is not a cool bug13:29
seb128using xrand1.2 breaks the dpi informations on intel13:30
seb128which means once you have used the new capplet you will have broken dpis and the evince issue we got several bugs about13:30
seb128that breaks the web browse fonts too13:35
tjaaltonand that was due to the latest change?13:36
seb128I've no idea, I didn't notice the issue before13:39
tjaaltonno, seems to be an upstream issue13:39
seb128I'm going to downgrade the intel driver now13:39
tjaaltonok, the changes seem to have added only some quirks13:40
seb128and people started reporting that some days ago13:40
seb128https://launchpad.net/bugs/178558 suggests the issue is not new13:40
ubotuLaunchpad bug 178558 in xulrunner-1.9 "Firefox 3.0 makes everything annoyingly huge" [High,Fix released] 13:40
seb128see https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/178558/comments/5013:40
seb128I think evince was not sensible to wrong dpi before or something13:41
seb128so we didn't get lot of bugs about the issue13:41
seb128or we got firefox font issues bugs which are not easy to track13:42
jcristaumaybe with X log, output of xrandr and xdpyinfo it would be possible to do something. random screenshots, not so much13:43
seb128jcristau: I can give you any information you need13:43
seb128jcristau: starting xorg xpydinfo shows a correct 120 dpi number13:43
seb128using xrand1.2 to set the same screen resolution I'm already using the xdpyinfo number goes to 1x113:44
seb128that's a dell D630 laptop using a intel 965 video card13:44
seb128using the current intel driver13:44
tjaaltonheh, mine dropped from 106x105 to 87x8513:45
jcristaudo you X log, preferrably with the ModeDebug option turned on?13:45
jcristaus/do you/& have an/13:46
seb128jcristau: easy enough to get, where do I turn this option?13:46
jcristauin the Device section13:46
seb128jcristau: https://bugs.launchpad.net/ubuntu/+source/evince/+bug/213745 has several Xorg.0.log13:46
ubotuLaunchpad bug 213745 in xserver-xorg-video-intel "PDF pages appear extremely small in evince" [High,Confirmed] 13:46
seb128jcristau: but I don't think they are using the debug mode13:46
seb128I'll try in a bit, I've things open that I don't want to close right now ;-)13:47
jcristau(might be a good idea to set ModeDebug by default)13:47
seb128let me know if those logs are useful already13:47
jcristau  dimensions:    1280x800 pixels (40959x50175 millimeters)13:48
jcristau  resolution:    1x0 dots per inch13:48
seb128yeah, that's what you get after using xrandr1.213:49
seb128  dimensions:    1440x900 pixels (37887x31871 millimeters)13:49
seb128  resolution:    1x1 dots per inch13:49
seb128that's the value on my laptop13:49
jcristau(II) intel(0): Printing DDC gathered Modelines:13:49
jcristau(II) intel(0): Modeline "1280x800"x0.0   65.31  1280 1296 1328 1344  800 801 804 810 -hsync -vsync (48.6 kHz)13:49
seb128it was 120x120 before using xrandr13:50
jcristauthat 0.0 is broken13:50
seb128(II) intel(0): Printing DDC gathered Modelines:13:50
seb128(II) intel(0): Modeline "1440x900"x0.0  108.50  1440 1520 1600 1952  900 903 909 926 -hsync -vsync (55.6 kHz)13:50
seb128(II) intel(0): Modeline "1440x900"x0.0  108.50  1440 1520 1600 1952  900 903 909 926 -hsync -vsync (55.6 kHz)13:50
seb128I've those13:50
jcristauseb128: what exact command? xrandr --output 'foo' --mode 1440x900?13:50
seb128jcristau: I'm using this new xrandr1.2 capplet from redhat that bryce backported13:51
seb128is the xrandr command line using 1.2 too?13:51
jcristauhrm, actually it's "1024x768"x0.0 here too13:51
tjaaltonsame here13:51
jcristauso that's not it13:51
jcristaumodedebug would probably help13:51
seb128ok, sec, editing xorg.conf and restarting13:53
tjaaltonwas it a boolean?13:54
jcristaudo you have an url to the capplet source?13:54
jcristautjaalton: yes13:54
seb128jcristau: the patches are on http://people.ubuntu.com/~bryce/Testing/XrandrGui/13:55
seb128jcristau: http://www.gnome.org/~ssp/randr/ is the upstream thing, I think that's using git13:56
seb128http://www.gnome.org/~ssp/randr/.git 13:57
ubotuNew bug: #214561 in evince (main) "Evince shows pdfs file with a very small size (dup-of: 213745)" [Low,Invalid] https://launchpad.net/bugs/21456113:57
ubotuNew bug: #214581 in nvidia-settings (universe) "[hardy] nvidia-settings window is displayed way too small" [Undecided,New] https://launchpad.net/bugs/21458114:00
seb128jcristau: http://people.ubuntu.com/~seb128/Xorg.0.log14:02
jcristauso at startup X sets your screen size to 304 x 19014:06
jcristauas reported by your monitor14:06
jcristauand then something goes crazy14:07
seb128as said if I don't use this capplet the xdpyinfo settings are correct14:07
seb128so it goes wrong when using the xrandr calls14:07
seb128the code which applies the settings seems to be in the gnome-desktop changes14:08
seb128it calls XRRSetScreenSize()14:08
mvotjaalton: if you maintain xkeyboard-config in git for ubuntu you may want to sync with my latest uplaod14:09
seb128mvo: so what was the bug?14:09
tjaaltonmvo: I noticed your latest comment.. maybe this bug went "unnoticed" when people upgraded to edgy..14:09
mvoseb128: multiple ones, but the killer was wrong order of unpack and replacing files in /etc with symlinks that confused dpkg14:10
tjaaltonmvo: and it's not maintained in git, unfortunately14:10
tjaaltonit's not maintained by XSF in Debian :)14:10
mvotjaalton: it pretty servere, if it went unoticed than our QA back then was pretty bad14:10
mvotjaalton: it kills the keyboard for anyone using the gnome-keyboard preferences14:11
mvoit depends on the unpack ordering for it to trigger, maybe we were just luck on dapper->edgy14:11
mvothe issue that xkeyboard-config is in universe (and should be in main) is still open though14:12
tjaaltoncould be yes14:12
* mvo goes to the seeds14:12
mvothat was a bugger of a bug, happy to have nailed it down (works in my upgrade test environement, lts see if it works in the wild as well :)14:13
jcristau    width_mm = (width * 96.0) * 25.4;14:15
jcristau    height_mm = (height * 96.0) * 25.4;14:15
jcristau    14:15
jcristau    rw_screen_set_size (assign->screen, width, height, width_mm, height_mm);14:15
jcristauso it's supposed to set dpi to 9614:15
jcristauexcept, maybe not14:15
tjaaltongotta run, bbl ->14:17
jcristauhmm, shouldn't that be (width / 96.0) * 25.4?14:17
seb128hum, yeah14:18
jcristauseems likely to fuck things up, setting dpi to 1/96 instead of 96 :)14:21
seb128trying that change14:23
seb128jcristau: ok, nice catch, much better now ;-)14:27
seb128note for next time, don't blame xorg too quickly ;-)14:27
jcristaublaming red hat is a much better strategy! ;)14:28
seb128yeah ;-)14:28
ubotuNew bug: #214592 in xserver-xorg-video-intel (main) "[Hardy] OpenGL renders Wrong " [Undecided,New] https://launchpad.net/bugs/21459214:31
james_wseb128: the clone checkbox isn't showing up as 'glade_xml_get_widget (xml, "clone_checkbox");' is returning NULL14:34
james_wthere is '<widget class="GtkCheckButton" id="clone_checkbox">' in the glade file.14:34
james_wdo you know enough about glade to offer any suggestions?14:34
seb128james_w: hum, looking14:39
mvojames_w: was glade_xml_new run with a different root widget?14:40
mvojames_w: so that clone_checkbox is not a child of whatever root was set to? (that might be a possible explaination for this behavior)14:41
james_wglade_xml_new (GLADE_FILE, NULL, NULL);14:42
seb128james_w: where is this clone widget?14:43
seb128james_w: is that the Mirror Screen one?14:44
james_wI'm seeing it at line 100 of "capplets/display/display-capplet.glade"14:44
james_wseb128: yes14:44
seb128it's displayed correctly for me14:44
james_whmm, odd.14:45
james_wDo you have multiple screens?14:45
seb128I'm using a laptop right now14:46
seb128and it's not pluged to any monitor or dock14:46
james_wand this is with the latest changes I made?14:46
seb128using the debdiff you sent me some hours ago14:47
seb128james_w: http://people.ubuntu.com/~seb128/xrandr.png14:47
james_wI'll fix up what I have currently and pass that to you.14:48
seb128ok, thanks14:48
james_wI don't have the checkbox, or the "Detect displays" button.14:48
seb128did you install the glade?14:50
seb128or do you run from your source?14:50
james_wyeah, I'm just wondering whether it's not getting installed.14:50
seb128try to strace -e open gnome-display-properties 2>&1 | grep glade14:50
seb128then glade this one14:50
seb128and see if it's correct14:50
james_wyeah, it's not in the .deb and the one on my system is old.14:52
seb128you are welcome14:52
seb128weird though14:53
seb128the debdiff you sent me works correctly and the glade is installed there14:53
james_wah, it's in capplets-data14:55
seb128I usually sudo dpkg -i *.deb ;-)14:57
james_wyeah, I'm using two machines, and I was too lazy to copy them all across.14:58
james_wIt all seems to work nicely though.14:58
james_wseb128: http://jameswestby.net/scratch/g-c-c.diff updated if you want to grab it again and do your thing15:15
seb128james_w: my thing being debuild? ;-)15:16
james_woh, I thought you used sticky tape to make the .debs15:16
seb128my debian applicant manager made me rewrite my a rules without using debhelper or cdbs15:18
seb128I really appreciate the packaging tools since ;-)15:19
seb128james_w: good work, thanks15:33
seb128james_w: new revision uploaded to hardy15:34
seb128james_w: I get the issue you described I think though, I've only one screen and the clone options is checked by default so the monitor label is wrong15:34
james_wyeah, I think that's a problem in the -desktop patch, I asked bryce about it as I am not sure what the correct logic should be.15:41
seb128that's a minor point15:43
seb128and it's likely that redhat will fix it15:43
seb128next issue should be to look if it still bug under xgl15:43
james_wyep, I'm going to try that now.15:46
james_wxgl kills g-s-d, with a backtrace very similar to https://bugs.edge.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/21022615:55
ubotuLaunchpad bug 210226 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,Confirmed] 15:55
ubotuNew bug: #178274 in xulrunner-1.9 (main) "[hardy] firefox breaks on some pages with an X error (dup-of: 205599)" [Medium,Incomplete] https://launchpad.net/bugs/17827416:31
ubotuNew bug: #184076 in midbrowser "gecko received an X Window System error (dup-of: 205599)" [Undecided,New] https://launchpad.net/bugs/18407616:31
ubotuNew bug: #194782 in firefox-3.0 (main) "[hardy] firefox breaks on some pages with an X error (dup-of: 205599)" [Undecided,New] https://launchpad.net/bugs/19478216:31
ubotuNew bug: #214652 in xorg (main) "Xorg freezes on logout in hardy" [Undecided,New] https://launchpad.net/bugs/21465217:01
james_wseb128: how would you feel about http://jameswestby.net/scratch/g-s-d.diff17:34
james_wis there a preferred way to add the linker options?17:34
james_wI wasn't sure whether autoconf would be appreciated.17:34
james_wIt's taking bryce's code for detecting Xgl and just disabling the xrandr plugin if it is detected.17:35
james_whi bryce, sleep well?17:35
seb128james_w: that seems the wrong approch to me, do you know why it breaks exactly?17:37
james_wnope, afraid not.17:37
brycejames_w: well enough17:38
james_wbryce: testing the new stuff on Xgl I didn't get a backtrace like those in the report, I got one like bug 21022617:40
ubotuLaunchpad bug 210226 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in rw_screen_list_outputs()" [Medium,Confirmed] https://launchpad.net/bugs/21022617:40
seb128james_w: I keep that as an option but I would prefer to find the call which is failing under xgl and fix that because it might cause similar cause under other situations17:40
james_wseb128: yes, that would be better, but I don't know where to look for that. I can look tomorrow if someone has a few pointers.17:40
seb128james_w: we have bugs about similar crash when using nvidia and xinerama for example17:41
seb128james_w: not really, that's just plain C crash debugging, not really hint to help there out of using gdb and valgrind17:41
seb128james_w: let me have a look tomorrow and ping you back, ok?17:45
james_wseb128: sure, I'll take a quick look now as well.17:46
seb128ok, thanks17:50
seb128I'm away for diner, see you later17:50
james_wXRRGetScreenSizeRange fails on Xgl18:06
james_wbryce: this is where I get stuck, I can't follow the X calls in libxrandr, is there a way I can debug this further?18:09
james_wor do we just need to add code for this situation to avoid a segfault?18:09
brycejames_w: what i've been doing is adding in some null pointer checks...18:18
brycewarning - I've not compiled that patch yet, it may have typos18:19
james_wbryce: yeah, you've got the one causing this crash in there, want me to test it?18:21
james_wbryce: I've got to go now, sorry, I'll try and catch you later today to see if there is anything else to do. Feel free to drop me an email with anything instead.18:27
james_wOtherwise I'll test any uploads and work on other things.18:28
* bryce finally catches up on backlog18:33
brycegood work on getting the g-c-c patch uploaded, I'll pull it and test too18:33
james_wI'm pretty embarrased that I was trying to debug why the checkbox was missing when I just hadn't updated capplets-data :-)18:34
bryceyeah I'll get this patch uploaded and you can test tomorrow or as you have time18:35
brycemy suspicion with that bug is that <root cause> is resulting in the xrandr gui code getting an invalid data structure, with some members being NULL18:37
brycewe can pepper the code with the null pointer checks, but it doesn't address the root cause that's causing the problem in the first place18:37
bryceI suspect using Xgl is one root cause.  It's possible seb is right and that there are other similar causes18:38
james_wscreen->info is null in my case18:41
james_was XRRGetScreenSizeRange fails, and so it just sets it too NULL, and then this is never checked for.18:42
james_wnull in rw_screen_list_outputs that is.18:46
bryceso the next question is why XRRGetScreenSizeRange fails18:54
brycejames_w: can you run sudo ddcprobe and see if you get edidfail?18:55
james_wwant the output?18:57
james_w(this is still nvidia by the way)18:57
brycemaybe -nvidia just doesn't work with that call?19:00
bryceperhaps we should simply include code to bail out once that call fails19:00
brycesomething looks odd...  can you pastebin your /var/log/Xorg.0.log?19:01
bryceah, nope nevermind19:01
bryce(thought it was reporting cm when it should say mm, but it's actually doing the right thing)19:02
brycethe ddcprobe output looks ok.  Also, am I remembering correctly that you tested with -nv and it worked ok?  that would rule out an edid issue19:02
james_wum, no I haven't tested with nv yet.19:04
james_wlet me do that.19:04
james_wstill -xgl?19:04
bryceodd, no edid listed in your Xorg.0.log.  19:04
bryceactually wait19:04
bryceI don't think it's an edid issue, don't worry about testing the -nv driver19:05
bryceI'm fairly certain the issue is that -nvidia+-xgl is not supporting the necessary xrandr 1.2 calls, and we just need to check if that call failed19:07
bryceassuming that's right, running -nv without -xgl should work.  I'm not sure what -nv + -xgl would do, actually.  I suspect it'd probably fail19:08
james_wI can log in with nv and g-s-d runs fine, I've no idea whether I'm actually on Xgl though.19:12
brycexpdyinfo | grep -i xgl   I think19:12
james_wthat doesn't report anything even when xgl is working.19:23
brycesorry.   xvinfo | grep -q Xgl19:27
brycexvinfo | grep Xgl   actually19:27
james_wyep nv works, but it's not Xgl19:56
bryceok, that's what I expected19:57
bryce-nv + Xgl probably is a really uncommon config19:58
bryce(if it's even possible to config it that way)19:58
joumetalbug 214168 has good screenshot. What could cause it?20:09
ubotuLaunchpad bug 214168 in xserver-xorg-video-intel "video acceleration broken with .810 driver in Hardy Beta" [Undecided,New] https://launchpad.net/bugs/21416820:09
bryceheya joumetal20:16
joumetalhello bryce20:17
brycejoumetal: I don't know exactly what's causing it but I can give some general comments20:18
joumetalgo ahead20:18
brycefirst, issues that appear with 3D only, are sometimes/often due to issues in mesa.  Not sure that's necessarily true in this case, but a possibility20:18
brycealso, I see the card in question is i815, which is a pretty old model of intel card20:19
bryceand in fact, many i8xx cards didn't work properly in -intel when we started Hardy, but we've forwarded bug reports upstream and the Xorg team has been fixing them20:19
bryceespecially i855 got a lot of fixes.  But each of the i8xx models has its own little quirks and bios-specific issues20:20
bryceI suspect i855 is more commonly found than i815, so it doesn't surprise me that there may be more bugs for i815 to do20:21
bryceso what's needed here is to collect the /var/log/Xorg.0.log (this should always be included when people report X bugs), but otherwise I think it is ready for forwarding upstream20:22
brycejoumetal: do you want to collect that file and/or forward upstream, or shall I take it from here?20:23
joumetalI am happy if you take it.20:24
bryceok will do20:25
brycealso, when you spot a bug that is driver specific and have added a task for that, you can also close the xorg task; not necessary to have them double filed20:26
joumetalok maked xorg task invalid.20:30
james_whey seb128.20:35
james_wbryce has a patch that should fix the -xgl issue I am seeing.20:35
seb128re james_w20:36
seb128ah, cool20:36
seb128where is it?20:36
james_wI haven't tested it, but it adds a NULL check where the segfault was, so it should at least prevent that.20:36
brycejames_w: did you test it?  I'm finding one of the asserts is causing a crash on my dev box (which is good... but needs fixed first)20:37
james_wbryce: no, sorry, I didn't20:37
brycealso the null check may not *fix* the problem (it might), but at worst will shift the problem higher up in the stack where it can be better handled20:37
seb128the patch looks alright, adding extra checks is a good thing20:38
bryceI noticed ssp had added similar checks in a few places, so followed his style and just made sure they were ubiquitous, but I may have been too liberal since now it's asserting20:40
seb128let's get it uploaded soon and see what the user feedback is20:42
seb128bryce: btw dunno if you noticed we fixed the evince issue20:42
seb128bryce: thanks to jcristau who noticed that the dpi calculation was wrong20:43
bryceoh awesome, what was the cause?20:43
bryceyeah I saw the discussion20:43
bryceoh, *96 vs /9620:43
seb128the gnome-desktop call was using width_mm = (width * 96.0) * 25.420:43
seb128and same for height20:43
seb128where is should be / 96.020:43
brycegood catch20:45
bryceI also wonder about using 96 there20:45
seb128that's what GNOME used to code as a value20:45
seb128I was thing about changing that to use the gconf dpig key rather20:45
seb128that would allow users to change the value20:46
bryceI hope in intrepid we can finally get all the dpi fussiness sorted out20:46
seb128which is not possible now20:46
seb128would be nice if xorg would get that right ;-)20:47
bryceyeah...  well looks like a lot of the remaining issues are quirkable20:47
seb128quirk are nice20:47
brycehowever I'm concerned about situations where edid is not available, since all the dpi calcs seem to depend on the monitor providing at least some info20:48
seb128it make possible to fix things broken which it would not be possible to workaround easily in the code20:48
* bryce nods20:48
seb128well, maybe xorg should just fallback to 96 dpis when there is no edid information?20:48
bryceI believe it does.  That may be why we don't see more bug reports than we already do20:49
seb128ah, ok20:49
bryceI wonder if there are apps that are using mechanisms other than Xorg for getting that value though20:49
seb128let's try to drop the coded value again next cycle20:49
seb128not in the standard desktop I think20:50
bryceI need to diagram out all the paths, like I did for the resolution stuff20:50
seb128GNOME seems to not care about the xorg value20:50
bryceseems there are multiple techniques people have used for calculating dpi; maybe unifying them could eliminate many bugs and make quirking more universally effective20:51
seb128bryce: btw xrandr is still quite broken, I though that resolution changes would work on intel20:51
brycetoo many cases of "dpi is right in apps ABC, but bad in DEF"20:51
seb128could be a compiz bug, when when switching between resolution the usuable screen portion stays to the small resolution and the other border are corrupted20:52
brycecould be20:52
brycetwo of my -intel systems work great with the resolution switching.  one system only works when switching resolution to *higher* rez's, and locks up if reducing20:53
brycehowever that system I've hacked so much X stuff on I think it needs a complete reinstall (Xrandr used to work fine on it before I started work on xrandr gui stuff)20:53
seb128is there any driver where xrandr is really working correctly?20:54
brycethere is no driver I've found that works 100% with xrandr with any arbitrary chipsets20:55
brycebut since these issues cause incorrect behavior rather than out and out crashes, I'm not certain how exactly to debug them20:56
bryceonce the major xrandr gui bugs are closed, I want to build a table of xrandr test results for various drivers/chipsets, and approach the upstream devs.20:57
bryceseb128: a useful thing would be to try to reproduce the issue using just the cmdline xrandr tool; if this can be done, we can report the issue directly upstream.  Otherwise we need to first identify if it is due to a bug in xrandr gui (like that dpi issue was)20:59
brycefwiw, this is the crash I'm working on...21:16
bryceProgram received signal SIGSEGV, Segmentation fault.21:16
bryce[Switching to Thread 0xb6d2d720 (LWP 6683)]21:16
bryce0x0804d911 in on_screen_changed (scr=0x8193880, data=0x8070e80) at xrandr-capplet.c:12221:16
bryce122in xrandr-capplet.c21:16
seb128that's the common one I think21:17
seb128one of those I listed in the mail I sent some days ago21:17
seb128would be nice to get it fixed indeed ;-)21:17
bryceah, so then if it's unrelated to my patch (which is as I suspect), should I upload this, so we can test it against the Xgl bug?  Then I'll continue troubleshooting this one21:18
brycethis one is starting to feel like an uninitialized pointer error21:18
seb128uninitialized pointer is easy to figure if you have the issue21:19
seb128build using -O0 rather than -O221:19
seb128when using -O0 usually the variable are initialized21:20
ubotuNew bug: #214787 in xserver-xorg-video-intel (main) "Intermittent monitor flicker after screen blanking in Hardy" [Undecided,New] https://launchpad.net/bugs/21478721:45
bryceok, whatever that bug is, it is unrelated to my changes; the dialog seems to work fine on other hardware, so I'll proceed with uploading.21:53
brycehrm, got rejected22:42
bryceoh whoops, collided with your fix.22:45
ubotuNew bug: #214813 in xorg (main) "Bad detection of card - Dell Optiplex 740 AMD64" [Undecided,New] https://launchpad.net/bugs/21481322:45
brycetry again && lunch (bbiab)22:50
bryceok went through that time23:12
ubotuNew bug: #214836 in linux-restricted-modules-2.6.24 (restricted) "lrm incorrectly installs nvidia-glx-new" [Undecided,New] https://launchpad.net/bugs/21483623:30

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