[01:45] <ubotu> New bug: #133060 in xserver-xorg-input-synaptics (main) "Synaptic touchpad fails to register some of the taps for tap-to-click" [Undecided,New]  https://launchpad.net/bugs/133060
[07:05] <ubotu> New bug: #133049 in xorg (main) "Caps Lock & Num Lock don't work" [Undecided,New]  https://launchpad.net/bugs/133049
[07:27] <ubotu> New bug: #132847 in xorg (main) "downloaded updates, now X11 does not load" [Undecided,New]  https://launchpad.net/bugs/132847
[08:08] <ubotu> New bug: #132593 in xorg (main) "Gutsy Thinkpad R31 Xwindows Failure" [Undecided,New]  https://launchpad.net/bugs/132593
[10:41] <ubotu> New bug: #133109 in linux-restricted-modules-2.6.20 (restricted) "wrong nvidia-glx driver loads (1.0-9755 vs. 1.0-9631) when nvidia-glx is installed and enabled" [Undecided,New]  https://launchpad.net/bugs/133109
[11:45] <ubotu> New bug: #133116 in xorg (main) "Implement a way to minimize full screen windows like games" [Undecided,New]  https://launchpad.net/bugs/133116
[12:16] <ubotu> New bug: #133119 in xserver-xorg-driver-ati (main) "no dri or xgl on imac g3" [Undecided,New]  https://launchpad.net/bugs/133119
[06:22] <bryce> seb128: did you want to talk more about  118745?
[06:22] <seb128> bug #118745
[06:22] <ubotu> Launchpad bug 118745 in libgnome "Font sizes in Gutsy are vulnerable to bad X.org DPI detection" [Medium,In progress]  https://launchpad.net/bugs/118745
[06:22] <seb128> not really
[06:23] <seb128> I don't have a real opinion on this guidance thing
[06:23] <seb128> do you know about it? what is it doing? if that's working, shouldn't that be done by xorg rather?
[06:24] <bryce> well, what I gather is that it's not exactly xorg's fault, but rather I believe it's our postinstall scripts
[06:25] <bryce> I don't understand how the gnome code is determining dpi from xorg settings, but it sounds like it's taking it from the refresh rates
[06:25] <bryce> however the way our xorg postinst scripts are designed, much of the time those are just educated guesses
[06:26] <bryce> so relying on those guesses for determining dpi is bound to be problematic and result in lots of incorrectness
[06:27] <bryce> it would be nice to have someone experiencing the issue test it with and without an xorg.conf.  If my hypothesis is correct, in the latter case the font dpis should work out correctly
[06:28] <bryce> I noticed one person in the bug commentary mentioned doing essentially this, but I'd like to see a confirmation on it
[06:28] <bryce> I wasn't able to find any bug reports upstream regarding DPI issues, which also makes me think it's our(+debian) issue, not xorg's
[06:29] <bryce> so the true fix for this would be to massively fix up / rearchitect the postinst for xorg, and replace a lot of the monitor resolution guesswork logic with something more reliable - or make it better at letting xorg take over when it doesn't know
[06:30] <seb128> bryce: I don't think GNOME is calculating the number of dpi
[06:30] <bryce> but I think that's like a 1+ month job, not something we could safely do for gutsy
[06:30] <seb128> xpdyinfo shows the same numbers
[06:30] <seb128> like
[06:30] <seb128>   resolution:    85x86 dots per inch
[06:31] <seb128> hum, k
[06:32] <seb128> so do you have an opinion on whether we should use the guidance script or go back to use a fixed 96dpi version?
[06:32] <bryce> which guidance script?
 seb128: are you planning to do anything about bug 118745?  we have a script in guidance that runs on login for kubuntu that sets the DPI which you could use
[06:32] <ubotu> Launchpad bug 118745 in libgnome "Font sizes in Gutsy are vulnerable to bad X.org DPI detection" [Medium,In progress]  https://launchpad.net/bugs/118745
[06:32] <jcristau> fwiw, there's some discussion of that issue in bugs.debian.org/237877
[06:33] <bryce> jcristau: cool, thanks
[06:39] <jcristau> the "DPI, font size, and Debian" thread at http://lists.debian.org/debian-x/2004/12/threads.html might be relevant too
[06:39] <jcristau> don't know if things changed much since then
[06:42] <bryce> ok
[06:43] <bryce> seb128: interesting, the guidance script basically also hardcodes to 96 when xorg think's its dpi is less than 140
[06:46] <jcristau> bryce: pixman is in incoming right now, on the mirrors in a few hours
[06:46] <bryce> great
[06:46] <seb128> bryce: weird
[06:47] <bryce> but yeah reading the comments on this function it seems to be compensating for inaccurately detected monitor sizes
[06:48] <bryce> so yeah my opinion is that we should hardcode the dpi's, either directly, or using this displayconfig-restore.py script
[06:48] <seb128> I'll use the 96dpi as it used to be
[06:48] <seb128> I don't see the need to add an extra package and script to do basically what we were doing
[06:51] <bryce> I think that should solve the issue suitably for now.  The higher dpi's would provide for higher resolution fonts for users with large monitors, but it won't be a regression to not have that
[06:52] <seb128> right
[06:53] <bryce> I'm planning on doing some plumbing work on the postinst scripts for the next release, that will hopefully make workarounds like these needed less often.
[06:54] <seb128> ok
[06:54] <seb128> I've to go
[06:54] <bryce> cya
[06:54] <seb128> we can talk about that later again
[06:54] <seb128> thanks
[06:54] <seb128> see you
[06:54] <jcristau> anything that kills stuff from xserver-xorg.postinst can only be good :)
[06:54] <bryce> agreed :-)
[09:26] <ubotu> New bug: #133192 in xserver-xorg-video-ati (main) "Screen displays garbage" [Undecided,New]  https://launchpad.net/bugs/133192
[09:46] <ubotu> New bug: #133200 in mesa (main) "[gutsy]  libGL.a missing - linking fails" [Undecided,New]  https://launchpad.net/bugs/133200