After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 738748 - error on detecting screen size and all is showed very huge
error on detecting screen size and all is showed very huge
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: xsettings
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
: 727131 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-10-18 06:51 UTC by piviul
Modified: 2014-12-15 16:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
kernel logs (1.34 MB, text/x-log)
2014-10-18 06:51 UTC, piviul
  Details
gnome screen identification (15.32 KB, image/png)
2014-10-18 06:54 UTC, piviul
  Details
xrandr -q --verbose output (6.11 KB, text/plain)
2014-10-30 07:36 UTC, piviul
  Details
xrandr: Don't check for hi-dpi on monitors with broken EDID (1.55 KB, patch)
2014-10-30 10:29 UTC, Bastien Nocera
committed Details | Review

Description piviul 2014-10-18 06:51:41 UTC
Created attachment 288796 [details]
kernel logs

As Adam suggest me in bug https://bugzilla.gnome.org/show_bug.cgi?id=709859 I open a new bug for this problem. 

After upgrading to 3.14 the screen size of my monitor, a Samsung SyncMaster T260, is detected as 7'' even if is 26''. Consequently all is showed very huge. Running the command gsettings set org.gnome.desktop.interface scaling-factor 1 seems to workaround the problem but gdm3 continue to show the log interface very huge and the gnome control panel I continue to read that my monitor is 7''.

This is a description of my hardware:the monitor is a Samsung SyncMaster T260 attacched using a DVI cable to the integrated Intel 82Q35 graphics card.

I attach the kernel logs even if doesn't seems to contain nothing of interest.

This is the output of xrandr:
$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 4096 x 4096
VGA1 disconnected (normal left inverted right x axis y axis)
DVI1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 160mm x 90mm
   1920x1200     59.95*+
   1920x1080     60.00    50.00    59.94  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.88  
   1280x1024     60.02  
   1440x900      59.90  
   1280x960      60.00  
   1280x800      59.91  
   1280x720      60.00    50.00    59.94  
   1024x768      60.00  
   800x600       60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       60.00    59.94  

If you need other infos please don't hesitate to contact me.

Piviul
Comment 1 piviul 2014-10-18 06:54:04 UTC
Created attachment 288797 [details]
gnome screen identification
Comment 2 Bastien Nocera 2014-10-29 09:47:58 UTC
It's detected as 7" because that's what your monitor is saying in the EDID. You can try doing the math on the size mentioned in the log you attached:
"160mm x 90mm"
(that's 7 inches)

Can you attach the output of "xrandr -q --verbose" when reproducing the problem?
Comment 3 piviul 2014-10-30 07:36:07 UTC
Created attachment 289627 [details]
xrandr -q --verbose output

I attach the output you asked me... I have tried to set the correct size using xrandr or xorg.conf without success... have you any idea how can I tell to X the correct display size?

Thanks a lot

Piviul
Comment 4 Bastien Nocera 2014-10-30 10:29:06 UTC
Created attachment 289639 [details] [review]
xrandr: Don't check for hi-dpi on monitors with broken EDID

If the monitor reports a width/height that looks suspiciously like an
aspect ratio (16/9 or 16/10) don't check for hi-dpi. We can assume that
makers of devices that do support hi-dpi aren't so careless.

See http://cgit.freedesktop.org/~daniels/xserver/commit/?h=lodpi
Comment 5 Bastien Nocera 2014-10-30 10:42:33 UTC
CC:ing Owen as he hacked up this portion of code before.
Comment 6 Owen Taylor 2014-10-30 15:28:13 UTC
Review of attachment 289639 [details] [review]:

Though we don't how common this sort of EDID is (probably not very) - this seems OK to me - a bit of googling didn't reveal any 7.2in 16:9 or 7.4in 16:10 screens/tablets. Could you do the equivalent patch for mutter/src/wayland/meta-wayland-outputs.c - these bits of code should not be out of sync.
Comment 7 Bastien Nocera 2014-10-30 15:35:21 UTC
(In reply to comment #6)
> Review of attachment 289639 [details] [review]:
> 
> Though we don't how common this sort of EDID is (probably not very) - this
> seems OK to me - a bit of googling didn't reveal any 7.2in 16:9 or 7.4in 16:10
> screens/tablets. Could you do the equivalent patch for
> mutter/src/wayland/meta-wayland-outputs.c - these bits of code should not be
> out of sync.

I've already filed https://bugzilla.gnome.org/show_bug.cgi?id=734839 about it, but I don't know how to fix it in mutter the same way it's fixed in Xorg.
Comment 8 Jasper St. Pierre (not reading bugmail) 2014-10-30 16:14:50 UTC
The code is right here: https://git.gnome.org/browse/mutter/tree/src/wayland/meta-wayland-outputs.c#n63
Comment 9 Bastien Nocera 2014-10-30 16:28:00 UTC
(In reply to comment #8)
> The code is right here:
> https://git.gnome.org/browse/mutter/tree/src/wayland/meta-wayland-outputs.c#n63

That wasn't the question though...
Comment 10 Bastien Nocera 2014-10-30 16:40:19 UTC
Attachment 289639 [details] pushed as 1356fe5 - xrandr: Don't check for hi-dpi on monitors with broken EDID
Comment 11 Rui Matos 2014-12-15 16:46:14 UTC
*** Bug 727131 has been marked as a duplicate of this bug. ***