Created attachment 24435 [details] xorg.conf with UXA and depth 24 explicitly enabled I'm running a Kubuntu 9.04 system (X.org 7.4), with drm and the intel driver pulled from git. I run a 2.6.29 kernel which has KMS enabled, and the intel driver is told to use UXA in xorg.conf. Problem: X sessions have a visibly less color depth than the default 24. Very apparent on color gradients. * Laptop make and model: Advent 4211 (rebranded MSI Wind) * "uname -a": Linux lethe 2.6.29-ultimate-kms #1 SMP PREEMPT Tue Mar 31 18:12:55 CEST 2009 i686 GNU/Linux * "lspci -v | grep VGA": 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03) * xf86-video-intel: git up to commit fad714c40078d22fff82dc0692a344f66ddf9680 * libdrm: git up to commit 51d6346f9f3c425f49e57d185530c6bcaeb94f5e Investigation: Explicitly telling it to use depth 24 in the Screen section of xorg.conf yields *the same result*, and telling it to use 16 yields worse. Subject to human perception, it gives the impression of being somewhere inbetween the two, which doesn't really make sense. It's obviously less than the 24 I've been enjoying with older drivers. Working state: My earlier setup was with a non-KMS kernel (Ubuntu packaged 2.6.28.11.14) and an intel driver from the xorg-edgers ppa (2:2.6.99.1+git20090327.69c84f2c-0ubuntu0tormod). Excerpt from its changelog: * Checkout from git 20090327 (master branch) up to commit 69c84f2c8204771b68f40ed64e64657237b54546 * Only added debian/ tree from origin/debian-experimental * Disable kernel mode setting * Dropped debian/patches/* * Add lpia architecture * Add depends on libdrm-intel1 (lp 303177) * + hand-patched the one Debian patch Reasoning: I wanted to try out KMS, so I compiled a 2.6.29 kernel, enabling it. Since X apparently goes bananas with a non-KMS aware driver on a KMS kernel (other bug), a new intel driver was needed. I pulled it from git along with libdrm, compiled it and installed. Enabled AccelMethod UXA in xorg.conf, and experienced the problem. How to reproduce: Obtain a KMS-enabled 2.6.29 kernel. Pull xf86-video-intel up to commit fad714c40078d22fff82dc0692a344f66ddf9680 and libdrm up to commit 51d6346f9f3c425f49e57d185530c6bcaeb94f5e, then compile and install. Enable option AccelMethod UXA in xorg.conf (and possibly driver intel), then start X. Observe color gradients. What happened: Low color depth, color gradients visibly "edgy", staircase effect What was expected: Smooth gradients How to revert/recover: Boot from an older kernel (2.6.28) and install the ppa driver. Start X. Observe color gradients. (Same in EXA, same in UXA) Additional information: * Does not occur with above-mentioned setup; driver from ppa *on other kernel* (two variables). Said driver is only days old. * "grep -i depth /var/log/Xorg.0.log" yields: "Default Screen" for depth/fbbpp 24/32 (**) intel(0): Depth 24, (--) framebuffer bpp 32 (==) Depth 24 pixmap format is 32 bpp Conjecture: Is the kernel setting a lower depth mode? Regression between ppa's build (Mar 26 according to git log, Mar 27 according to ppa package changelog) and said git commit (Apr 1)? Let me know if there's anything else I should mention or attach.
Could also be due to a dither bit failure. Can you give this patch a try? diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds index 6619f26..11b4913 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -265,7 +265,7 @@ static void intel_lvds_mode_set(struct drm_encoder *encoder, pfit_control = 0; if (!IS_I965G(dev)) { - if (dev_priv->panel_wants_dither || dev_priv->lvds_dither) + if (1 || dev_priv->panel_wants_dither || dev_priv->lvds_dither) pfit_control |= PANEL_8TO6_DITHER_ENABLE; } else
That did it, looks good now. It's hard to say if it's *completely* as it should be, but I'm likely just being overly diagnostic, noticing for the first time grainy bits that were always there. Worth mentioning is that the original line in the 2.6.29 kernel source didn't check for dev_priv->lvds_dither, so perhaps that check alone would've properly enabled it. $ grep dev_priv-\>panel_wants_dither intel_lvds.c if (dev_priv->panel_wants_dither) I'll try compiling it again, this time not forcing it with 1.
Recompiled with only "if (dev_priv->panel_wants_dither || dev_priv->lvds_dither)" and now it looks horrid again. So it seems to need to be forced with "if (1 || dev_priv->panel_wants_dither || dev_priv->lvds_dither)" to work. So, workaround works, bug remains.
Ok can you attach your vbios to this bug? We must be parsing it wrong on your system (or it's inaccurate). Do the following as root: # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom
Created attachment 24686 [details] vbios extracted via method at #4 Certainly; attached.
Created attachment 24765 [details] [review] LVDS dither KMS fix How about this patch? It was recently pushed into the kernel and hopefully fixes things for you.
Confirmed, patch works, kernel version (still) 2.6.29.1. Many thanks! Mark bug as FIXED?
Yep, thanks for confirming.
(In reply to comment #8) > Yep, thanks for confirming. > Hi! I just upgraded to kms on gentoo and this bug still exist on acer travelmate 2490 on 940gml chipset. If i add 1 || colors look ok. The problem is, that I can't dump bios. Rom file doesn't exist. This is what I have under /sys/devices/pci0000:00/0000:00:02.0: boot_vga class device drm firmware_node i2c-adapter local_cpulist modalias power rescan resource0 resource2 resource3 subsystem_device uevent broken_parity_status config driver enable graphics irq local_cpus msi_bus remove resource resource1 resource2_wc subsystem subsystem_vendor vendor
Can you open a new bug for your issue, Ivan? It may or may not be related.
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.