Bug 522155 - RFE choose sensible resolution during boot
Summary: RFE choose sensible resolution during boot
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-09 15:43 UTC by Tony Nelson
Modified: 2016-08-12 03:27 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-12 03:27:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tony Nelson 2009-09-09 15:43:09 UTC
Description of problem:
Since F11 at least, and during Rawhide, during boot with KMS the CRT display is set to the highest resolution mode (1600x1200 here).  I'd prefer a mode near 96dpi, using the highest refresh.  I hear that some monitors have a native resolution, and that should be used if available, but for a CRT, at least until the user's preference is known (after mounting / and I suppose /home and also obtaining the username), I'd like a sane resolution.

In the past, I think a "safe" mode was chosen.  I think "sensible" should be used now, not "tinyest".

Version-Release number of selected component (if applicable):


How reproducible:
always unless nomodeset is used

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Joachim Frieben 2009-09-15 20:39:01 UTC
I have a similar issue using a 21" CRT HP A4576A. Until recently, KMS used to set the default resolution to 1280x1024 which was not that bad but which still differed from the optimum mode of 1400x1050 for a monitor of 21".
Current "rawhide" now defaults to 1600x1200 which is a bit high. Anyway, there no simple logic which would allow to choose the "correct" mode. That said and referring to

  https://bugzilla.redhat.com/show_bug.cgi?id=494098#c10 ,

I strongly support the possibility to make KMS aware of qualifiers like vga=0x345 which I am using successfully in the non-KMS case for ensuring the same physical resolution all the way up from graphical boot until X takes over.
Right now, a mode switch occurs when X starts up.

Comment 2 Ray Strode [halfline] 2009-10-19 18:54:28 UTC
plymouth doesn't set the mode during boot, it just uses what's already set.  moving to kernel.

Comment 3 Adam Jackson 2011-12-06 17:46:21 UTC
I'm afraid you misrepresent what KMS does.  It chooses the mode that the monitor claims to prefer in virtually all cases.  The EDID block from your monitor would tell us for sure (printed in the X log, or in xrandr --props, or in /sys/class/drm/*/edid) but your monitor almost certainly claims to want 1600x1200 if that's what we're picking.

Unfortunately there's no way of knowing from the host side whether a given monitor is a CRT or not.  (Really!)  So there's no good way to use a different heuristic for CRTs versus LCDs.

KMS does allow you to set video modes at boot though:

video=1024x768@60

will force 10x7 on all outputs;

video=VGA-1:1024x768@60

will force that size on just the first VGA connector, etc.

Comment 4 Adam Jackson 2012-01-26 20:25:40 UTC
Without seeing the EDID block from this monitor, I can't know if there's anything else we can do here.  Please attach the output of 'xrandr --props' from a running X session, or else the appropriate EDID file from /sys/class/drm/*/edid.  It's possible that your monitor truly doesn't have a preferred mode, and we could potentially do better in that case.

Comment 5 Tony Nelson 2012-01-28 17:49:08 UTC
I know you don't want to do this, but the monitor's dimensions give better guidance about the desirable size of the frame buffer during character mode boot.  The sensible frame buffer would display characters that are about 10 to 12 point size.  (Admittedly, the monitor dimensions may also be wrong in the EDID data, as this monitor claims to be 320mmx240mm but I measure it at 356mmx267mm.)

[tonyn@localhost ~]$ xrandr --props
Screen 0: minimum 320 x 200, current 1152 x 864, maximum 4096 x 4096
VGA-0 connected 1152x864+0+0 (normal left inverted right x axis y axis) 320mm x 240mm
	EDID:
		00ffffffffffff0040f3e200f3c60000
		070901016c2018b4e89022a255499b20
		11484fa56b8031594559615981808199
		a940a94f31ca00000001000101010001
		010101023e001463000000fd0030a01e
		60ff000a202020202020000000ff0041
		544159303735303933310a20000000fc
		00454f3933300a20202020202020007e
	load detection: 1 (0x00000001)	range:  (0,1)
   1152x864_85.00   85.0*+
   1600x1200      75.0     60.0  
   1280x1024      85.0     75.0     60.0  
   1152x864       75.0  
   1024x768       85.0     75.1     60.0  
   832x624        74.6  
   800x600        85.1     75.0     60.3  
   640x480        85.0     75.0     60.0  
   720x400        70.1  
DVI-0 disconnected (normal left inverted right x axis y axis)
	load detection: 1 (0x00000001)	range:  (0,1)
S-video disconnected (normal left inverted right x axis y axis)
	tv standard:	ntsc
		supported: ntsc         pal          pal-m        pal-60      
		           ntsc-j       scart-pal    pal-cn       secam       
	load detection: 1 (0x00000001)	range:  (0,1)

Comment 6 Adam Jackson 2012-02-09 20:17:02 UTC
Hey cool, no detailed timings at all, let alone preferred.

How do you feel about something like this patch:

http://lists.freedesktop.org/archives/dri-devel/2012-February/018945.html

This should pick either 1152x864 or 1280x1024 on your monitor, I think.

Comment 7 Tony Nelson 2012-02-09 23:29:00 UTC
That patch looks good for my case, at least.

I think the tolerance should be bigger than 10, say 25 to include 72 DPI (and therefore 120 DPI), which should be better than just the largest mode.

Comment 8 Joachim Frieben 2016-08-12 03:27:09 UTC
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.