Bug 19859 - [G45 KMS] X starts with wrong resolution (1920x1920)
Summary: [G45 KMS] X starts with wrong resolution (1920x1920)
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Jesse Barnes
QA Contact:
Keywords: NEEDINFO
Depends on:
Reported: 2009-01-31 06:07 UTC by Peter Ganzhorn
Modified: 2017-07-24 23:11 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Xorg.0.log (18.70 KB, text/plain)
2009-01-31 06:07 UTC, Peter Ganzhorn
no flags Details
dmesg (41.21 KB, text/plain)
2009-01-31 06:07 UTC, Peter Ganzhorn
no flags Details

Description Peter Ganzhorn 2009-01-31 06:07:04 UTC
Created attachment 22414 [details]

I'm using Ubuntu 8.10 with the following self-compiled software:
Linux kernel 2.6.29-rc3
Mesa 7.3

I enabled KMS in the Kconfig and the system loads inteldrmfb on startup (which looks quite nice) and obviously uses the correct resolution.
Then gdm starts up, the resolution still looks correct. But as soon as I log on and fluxbox is started, the resolution obviously is wrong (can't see the lower part of my desktop). Looking at the Xorg.0.log I found that my resolution was set to 1920x1920, but my monitor only does 1920x1200.
Here's the interesting parts of it, full logs are attached:

(II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
(II) intel(0): [drm] framebuffer mapped by ddx driver
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): X context handle = 0x1
(II) intel(0): [drm] installed DRM signal handler
(**) intel(0): Framebuffer compression disabled
(**) intel(0): Tiling enabled
(==) intel(0): VideoRam: -1 KB
(II) intel(0): Attempting memory allocation with tiled buffers.
setting kernel fb to new front buffer
front_buffer->bo->size: 16777216
Add fb id 28 1920 1920
(II) intel(0): Tiled allocation successful.
(II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
(II) intel(0): [dri] visual configs initialized
(II) intel(0): Page Flipping disabled
(II) UXA(0): Driver registered support for the following operations:
(II)         solid
(II)         copy
(II)         composite (RENDER acceleration)
(==) intel(0): Backing store disabled
(==) intel(0): Silken mouse enabled
(II) intel(0): Initializing HW Cursor
(II) intel(0): [DRI] installation complete
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0xfffffffffdffffff: DRI memory manager (18014398509449216 kB)
(II) intel(0): 0x00000000:            end of aperture
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x00000000:            start of memory manager
(II) intel(0): 0x0b920000-0x0d91ffff: classic textures (32768 kB)
(II) intel(0): 0x0a920000-0x0b72ffff: depth buffer (14400 kB) Y tiled
(II) intel(0): 0x09920000-0x0a72ffff: back buffer (14400 kB) X tiled
(II) intel(0): 0x08920000-0x0972ffff: front buffer (14400 kB)
(II) intel(0): 0x08902000-0x08910fff: exa G965 state buffer (60 kB)
(II) intel(0): 0x088fa000-0x08901fff: logical 3D context (32 kB)
(II) intel(0): 0x088ea000-0x088f3fff: HW cursors (40 kB)
(II) intel(0): 0xfffffffffe000000:            end of memory manager
fb id is 28

Video ram is -1 which can't be good, and the resolution is detected as 1920x1920 which isn't good, too.
My xorg.conf contains the following lines (for 24 and 16 bit depth, 24 is the default setting):

        SubSection "Display"
                Depth           24
                Modes           "1920x1200" "1680x1050" "1600x1200" "1280x800" "1280x1024" "1024x768"

Please let me know if you need any more information.
Comment 1 Peter Ganzhorn 2009-01-31 06:07:34 UTC
Created attachment 22415 [details]
Comment 2 Jesse Barnes 2009-02-05 09:38:29 UTC
This should be fixed in the 2D driver now:

commit 0cb87ccfe97b0e016e47dcf236fd5ce78dddfc4b
Author: Kristian Høgsberg <krh@redhat.com>
Date:   Fri Jan 30 17:53:03 2009 -0500

    Implement front buffer resize for KMS.

can you confirm by testing the git version?
Comment 3 Peter Ganzhorn 2009-02-06 11:56:01 UTC
I'm unable to build the current git:

i830_memory.c: In function ‘i830_allocator_init’:
i830_memory.c:539: error: ‘I915_SETPARAM_NUM_USED_FENCES’ undeclared (first use in this function)
i830_memory.c:539: error: (Each undeclared identifier is reported only once
i830_memory.c:539: error: for each function it appears in.)
make[4]: *** [i830_memory.lo] Error 1

Is there a working snapshot available?
Comment 4 Jesse Barnes 2009-02-06 12:30:34 UTC
Oh you need drm headers with that parameter defined.  Or you could just add the following two defines to the top of that file somewhere.

#define I915_PARAM_NUM_FENCES_AVAIL      6
#define I915_SETPARAM_NUM_USED_FENCES                     4

Comment 5 Peter Ganzhorn 2009-02-06 16:25:30 UTC
With the changes you suggested, I managed to get the 2D driver compiled.

Sadly X freezes within seconds after fluxbox starts, but on the bright side it definitely looks like the right resolution gets set. (GDM won't hang and everything looks good there)
The wallpaper in fluxbox looks correct as well, before it was drawn distorted and misplaced.

There were no logged errors with 2.6.29-rc3 and the 2D-git driver, so I can't tell you what's wrong.

I think this particular bug is resolved, and the X freeze is another, unrelated issue.
Another thing I am seeing is poor 2D scrolling performance e.g. in text editors, terminals or any kind of lists. It was there with 2.6.29-rc3 with the wrong resolution and now I am noticing it with 2.6.27 and the 2D git driver.
Even more annoying: Every driver later than xf86-video-intel-2.5.* will cause X to restart when I try to watch a video with xine or any other video player on 2.6.27, but it worked with 2.6.29-rc3 even with the wrong resolution.

Long story short: The new 2D driver is working very poor with 2.6.27 and 2.6.29-rc3 causes X to freeze right now.
I'm installing 2.5.1 again now, I'll check out git in a few days again.
Comment 6 Jesse Barnes 2009-02-06 17:49:18 UTC
Thanks.  Please file new bugs for the other issues.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.