If I use vesa driver, the GDM font is ok. But if I use i810 the fonts are so big and instead in the password appear **** it appears up arrows (in i810). This is probably a bug in gentoo-sources kernel (or not), because in other distros it is ok in i810 driver. Reproducible: Always Steps to Reproduce:
which version of the xf86-video-i810 package do you have ? hint: this is probably DPI detection related.
adding x11 herd since I doubt it's only a problem with gdm.
I'm using version 2.0.0. In Fluxbox if I try run Firefox or Pidgin the font is too big too. If I change to GNOME it is OK. Any idea?
Gnome has the ability to override the DPI setting, via the font capplet. At a guess, the driver is getting your native DPI correct, but gnome has a lower DPI setting making fonts smaller. This is how I do it. However, short of setting your DPI in xorg.conf, there's no way to change it for gdm.
Weird. In other distros it is ok (Ubuntu, Arch).
I have a problem with i810-2.*.0 driver too - I don't know if in gdm are * or arrows because fonts are so large that I don't see anything, to make applications use correct font size (didn't work for acroread) you can add this to /etc/X11/gdm/PostLogin/Default echo 'Xft.dpi:90' | xrdb -merge It doesn't change gdm's fonts though
With 1.7.4 it is ok with me and the driver uses the correct dpi value calculated from the resolution and the panel dimension. With 2.1.0 the driver states to use the correct value but 96 dpi is used instead. See here: http://forums.gentoo.org/viewtopic-t-571093.html I use a Samsung X20 with i915 graphics.
(In reply to comment #6) > I have a problem with i810-2.*.0 driver too - I don't know if in gdm are * or > arrows because fonts are so large that I don't see anything, to make > applications use correct font size (didn't work for acroread) you can add this > to /etc/X11/gdm/PostLogin/Default > > echo 'Xft.dpi:90' | xrdb -merge > > It doesn't change gdm's fonts though > Replying to my own post, this is how to change gdm's font dpi: 1) Select 'Administration' from the 'System' menu 2) Select 'Login Window' 3) Select the 'Security' tab 4) Click on the 'Configure X-Server' button at the bottom of the screen 5) Append this argument to the text in the 'Command' text-field: '-dpi 96' (Without the ' marks) 6) Restart your X session to see the changes. Now fonts look ok everywhere for me.
Same problem over here with fluxbox-1.0_rc3_p4983 and x11-drivers/xf86-video-i8102.1.0 or -2.1.1. With 1.7.4 everything is fine! - It's NOT a GDM problem (I removed it from the runlevel and startet with startx) - the font in an xterm window is ok, but the window title is too large - yakuake / konsole is also too large (fonts, title, everything) BTW: When using the ACPI-LID hack from http://ge.mine.nu/d400/d400.html, vesafb takes 100% CPU Load after waking up from "acpitool -s", this did not happen with 1.7.4. Those bugs really should be fixed :/
I fail to see what vesafb has to do with either the intel X driver or gdm. At any rate, this is not a gdm bug, re-assigning to X11.
Same problem here... (In reply to comment #1) > which version of the xf86-video-i810 package do you have ? lejour peters # emerge -pv xf86-video-i810 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-drivers/xf86-video-i810-2.1.0 USE="dri -debug" 0 kB > hint: this is probably DPI detection related. lejour peters # xdpyinfo | grep -b2 dim 1323-screen #0: 1334- print screen: no 1356: dimensions: 1280x800 pixels (289x21 millimeters) 1410- resolution: 112x968 dots per inch 1449- depths (7): 24, 1, 4, 8, 15, 16, 32 the correct screen size is 289x210 milimeters xwine and totem are calculatien the vewport and aspect ratio from that dpi settings, no chance to watch movies...
Additionally: I went back to 1.7.4 and now the display size is set coroctly: peters@lejour ~ $ xdpyinfo | grep -B1 dots dimensions: 1280x800 pixels (332x212 millimeters) resolution: 98x96 dots per inch ervin
On intel i945GM, I've the same problem : it works fine with 1.7.4 but not with >=2.0.0* ...
*** Bug 203376 has been marked as a duplicate of this bug. ***
Tell me, why hasn't this been fixed in Gentoo while in other distros it's fixed? This does look like that Gentoo is a not very good maintained Distro to me... :(
1) It's not broken on my system 2) I don't use any other distros 3) I'm not paid to work on this and I don't have much incentive to fix it becayse of reason #1 4) Complaining that others distros do it won't help at _all_ If you want it fixed, then please take a minute to find how Ubuntu/Arch fixed it. That would go a long way. In fact, if you find a working patch, I'll gladly commit it. Be a nice community player and help us help you. One last suggestion, please try the masked xf86-video-i810-2.2.0. I masked it because it's not production ready, but maybe this bug is fixed in there. Thanks for understanding my 4 points above.
I am new to this bug, Please allow me to add my observations (In reply to comment #16) > 1) It's not broken on my system > 2) I don't use any other distros > 3) I'm not paid to work on this and I don't have much incentive to fix it > becayse of reason #1 > 4) Complaining that others distros do it won't help at _all_ First off, Thank You. I do appreciate the effort put forth by volunteers. >please try the masked xf86-video-i810-2.2.0. I found that the problem does exist with this version. Specifying: Option "DDC" "No" in Xorg.conf suppresses the problem. With DDC turned off, I see this in my X11 log: (II) intel(0): Setting screen physical size to 338 x 211 (Note, I have a modeline that specifies 1280x800, and I force dpi with Option "DPI" "92 x 92" ) Whereas, with DDC On, I see: (II) intel(0): Setting screen physical size to 289 x 21 This leads to fonts being drawn about an order of magnitude larger than they should be. Looking at the EDID data, the size bytes are 0x21 , 0x15 which is consistent with ddcprobe which reports: Screen size max 33 cm horizontal, 21 cm vertical. I am willing to try to track this down, but where can I get a better description of the DDC / DPI / Intel driver architecture? Eric Waller.
Thanks Eric for this very useful information. I'll try to ping upstream about it, but it'd be better if you could directly send an email to the xorg mailing list with all the information you've just posted along with full Xorg logs (with and without the DDC option). Should they send you any patches, I'll push them to portage to help you report back to the list. Thanks
I've just added a snapshot of the upcoming 2.2.1 release, as upstream wants more testing before making official releases. Please try this snapshot. If it isn't fixed, please open a bug in freedesktop's bugzilla [1] and paste the url here. Thanks [1] https://bugs.freedesktop.org/
(In reply to comment #19) > I've just added a snapshot of the upcoming 2.2.1 release, as upstream wants > more testing before making official releases. Remi, Sorry for taking so long to get back to this. We have had a loss in the family. I am using this prerelease now, and it looks good. The scaling issue is no longer a problem, it looks like the driver just doesn't use DDC for is confifuration and -- no problem! Indeed, turning DDC on or off has no discernible affect. The Xorg.0.log file shows a great deal of detail about the driver configuration and it reports lots of things that look comforting and very few that cause concern (page flipping is disabled -- for example) The driver performs a little better on glxgears (>640 fps on a 1.6 GHz Pentium w/1GB total DDR RAM. DVD playback is smooth with no frame drop (except immediately after chapter changes) using Xine in OpenGL mode. Google Earth runs well (with the usual complaint about missing interrupts) I will provide more feedback after a couple more days of working with it. Eric Waller
Thanks for reporting back Eric. I'll close this bug as fixed. If you have anymore issues with DPI, please reopen this bug. If it's some other bug, I'd rather you opened a new one, it's easier to track issues that way. Cheers :)
It's not solved. I opened https://bugs.freedesktop.org/show_bug.cgi?id=16466
(In reply to comment #22) > It's not solved. Then you're probably hitting another bug. It happens :) > I opened https://bugs.freedesktop.org/show_bug.cgi?id=16466 Thanks a lot, I'll add myself as CC there.
Anyway, for those who has the problem here is a fix (thanks to: Comment by Alois Nespor (anespor) - Sunday, 01 July 2007, 09:38 GMT-4 I find the problem - driver intel read not correctly info from DDC and set up wrong dimensions/resolution : xdpyinfo |grep -A1 dimensions dimensions: 1280x800 pixels (289x21 millimeters) resolution: 112x968 dots per inch FIX: to Section "Device" add line Option "DDC" "no" xdpyinfo |grep -A1 dimensions dimensions: 1280x800 pixels (338x211 millimeters) resolution: 96x96 dots per inch i know, is small hack, but works good ==> fix driver intel about developers on http://www.intellinuxgraphics.org/ again, sorry for my english, is bad @ http://bugs.archlinux.org/task/7129
@Alexandre, I've asked you a few things on the upstream bug, please comment there :) And FYI, disabling DDC is by *no* means a proper fix. If there's a bug (and it looks like there's one), we all need to cooperate to isolate it and *fix* it. Thanks for your help in this.
