On Thu, 8 Oct 2009, Dave Airlie wrote:
>
> Please pull the 'drm-linus' branch from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
>
> Its had a recent merge because it was definitely getting non-trivial to
> fixup,
>
> non-radeon-kms: adds proper fb layer colormap support + 8/16 bpp support,
> since I added mode selection it seems like a bug that depth select didn't
> work. Tested on Intel and radeon gpus.
I don't think you tested this very extensively.
I'm bisecting a bug where my new Dell Inspiron 11z has corrupted LUT or
gamma tables or something. And while I have a lot of commits left to go,
only two of them still touch the i915 driver. And the two commits are:
- 068143d38804825d59d951a192cfadd2e22f457d: drm/fb: add setcmap and fix
8-bit support.
- b8c00ac5b50b54491657f8b6740db1df50149944: drm/fb: add more correct
8/16/24/32 bpp fb support.
the symptoms of this bug are that X starts up with some really funky and
odd colors. Not alway sall of them, but it basically looks like most of
the color translation entries are corrupted, resulting in a really "60s
tie-dye" feel to the desktop, when the background picture ends up being
recognizable, but with swirly odd purples and greens etc rather than the
expected colors.
It's fixed by locking the screen - the "fade-out" that happens when
the locking starts fixes all colors (presumably because the fade is done
by changing the alpha channel of all the colors and thus resets them to
the expected values).
But switching to text-mode and back brings the corruption back.
My X desktop is 24bpp - but I have no idea pixel depth the frame buffer
driver uses. The kernel says
[drm] LVDS-8: set mode 1366x768 c
Console: switching to colour frame buffer device 170x48
fb0: inteldrmfb frame buffer device
and maybe that 'c' means something.
Anyway, it's funky, and even pretty, but it's definitely wrong. And it
makes it hard to read text (especially anti-aliased text, which either
turns into a technicolor mess or just loses the halftone pixels into the
background, turning the text from nice smooth outlines to pixelated crap).
Am I really the only one that sees this? The laptop uses all-intel
chipsets, and a 1366x768 LVDS panel, with KMS and the current Fedora-12
beta. Nothing really odd:
- Xorg.0.log:
(II) LoadModule: "intel"
(II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
compiled for 1.6.99.903, module version = 2.9.0
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
- lspci:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller])
Subsystem: Dell Device 0409
Flags: bus master, fast devsel, latency 0, IRQ 26
Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
Memory at d0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 1800 [size=8]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
Kernel driver in use: i915
00: 86 80 42 2a 07 04 90 00 07 00 00 03 00 00 80 00
00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller (rev 07)
Subsystem: Dell Device 0409
Flags: bus master, fast devsel, latency 0
Memory at f0400000 (64-bit, non-prefetchable) [size=1M]
Capabilities: <access denied>
00: 86 80 43 2a 07 00 90 00 07 00 80 03 00 00 80 00
and while the corruption is not entirely consistent (the colors aren't the
_same_ ones), it seems to always happen to some degree (ie sometimes
_most_ colors are correct, but there are always some that aren't). I can
imagine not noticing it if the background is a single solid color (or a
fairly boring one with not a lot of colors).
Ideas?
Linus
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
--
_______________________________________________
Dri-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dri-devel
