Created attachment 21805 [details]
I have a laptop with i965 graphics and a 1280x800 display. Up until a certain commit, the KMS framebuffer filled the whole screen at native resolution.
Since this commit, the console fills only a 1024x768 area, anchored to the top left corner, leaving blank the right and bottom edges of the screen. usplash also runs at 1024x768. X still uses 1280x800, however.
The console appears to be picking a resolution to accommodate the TV out, according to the following in dmesg:
[ 1.217492] allocated 1280x800 fb: 0x007df000, bo ffff88013e6d2540
[ 1.279983] [drm] TV-13: set mode 1024x768 18
[ 1.360854] [drm] LVDS-8: set mode 1280x800 15
[ 1.645634] Console: switching to colour frame buffer device 128x48
[ 1.648155] fb0: inteldrmfb frame buffer device
No TV is connected, and xrandr correctly reports 'TV1 disconnected'. I assume that the TV out should be irrelevant in picking the console resolution, then.
The problem appears with this commit:
Author: Keith Packard <firstname.lastname@example.org>
Date: Sat May 30 20:42:28 2009 -0700
drm: Hook up DPMS property handling in drm_crtc.c. Add drm_helper_connector_dpms.
Making the drm_crtc.c code recognize the DPMS property and invoke the
connector->dpms function doesn't remove any capability from the driver while
reducing code duplication.
That just highlighted the problem with the existing DPMS functions which
could turn off the connector, but failed to turn off any relevant crtcs. The
new drm_helper_connector_dpms function manages all of that, using the
drm_helper-specific crtc and encoder dpms functions, automatically computing
the appropriate DPMS level for each object in the system.
This fixes the current troubles in the i915 driver which left PLLs, pipes
and planes running while in DPMS_OFF mode or even while they were unused.
Signed-off-by: Keith Packard <email@example.com>
Signed-off-by: Dave Airlie <firstname.lastname@example.org>
First-Bad-Commit : c9fb15f60eb517c958dec64dca9357bf62bf2201
Apparently fixed by these commits: