Bug 31375

Created attachment 40033 [details]
Xorg.0.log

Created attachment 40034 [details]
dmesg w/ drm.debug=0x06

Created attachment 40035 [details]
Output from: `xrandr -d :0 -q`

Created attachment 40036 [details]
Output from: intel_gpu_dump

Created attachment 40037 [details]
Output from: /sys/devices/pci0000:00/0000:00:02.0/rom

Correction:

tty6 -> tty7

*** Bug 31378 has been marked as a duplicate of this bug. ***

Yes, you are absolutely right Chris. The Bug 31378 is a duplicate of this. I assumed the difference (greyscale vs. total blackness) on screen was due to the AccelMethod XAA vs. UXA, but the deprecation of the XAA+intel possibility is obvious from the Xorg.0.log.

I've researched further to try to nail down what caused the differing screen appearance, and found this:

Starting the X server like this (all with this BUGs setup, no xorg.conf):
`xinit -fg black -bg lightgrey -- /usr/bin/Xorg -depth 8 :0`

Do give a greyscale screen comparable to the one I reported in Bug 31378, see attached image greyscale-xterm.jpg

By the way, the cursor is visible and do change appearance over the xterm window either way (total darkness or greyscale xterm).

There are a couple of potential causes at play here and I haven't dug into either yet. The first is that we are simply misrendering when asked to generate an 8-bit framebuffer. The second is that we not doing the correct modesetting for an 8-bit framebuffer. Both are extremely likely; the latter almost definitely.

Created attachment 40115 [details]
Running `xinit -fg black -bg lightgrey -- /usr/bin/Xorg -depth 8 :0`

Built and tested latest stable 2D driver

intel-drv: 2.13.0 (2010Q3 from intellinuxgraphics.org)

Result: The same dark greyscale display problem persist.

Bug Redux - latest and greatest - still greyish to me

System environment:
Chipset: Arrandale - Intel Core i5 M450 CPU
Arch: i686
libdrm: 2.4.23-2.fc15
mesa-dri: 7.10-0.15.fc15
xorg: 1.9.99.1-2.20101201.fc15
intel-drv: 2.13.902 (git commit 71af40a75fbdd1054b1111e8cbe67ad1f97e6613)
kernel: 2.6.37-0.rc5.git2.1.fc15
xrandr: 1.3.4
distro: Fedora Rawhide (14-15)
machine: Acer Aspire 3820T, model MS2292, TimelineX laptop
display connector: LVDS2

Reproducible: 100%

Steps to reproduce:
1. Install Fedora Rawhide (hmm.. somewhat reproducible)
2. Log in on first tty
3. Run `xinit -- /usr/bin/Xorg -depth 8 :0`

Result: The same dark greyscale display problem persist. X server starts without complaints, but the X display 0 on tty7 is very dark, almost black.

As before, running:
`xinit -fg black -bg lightgrey -- /usr/bin/Xorg -depth 8 :0`

Do give a greyscale screen where I can actually see the xterm window. Listing directories with colored ls output reveal the lack of colors. It's all grey, comparable to the earlier attached image for running this command.

Running with depth 15 do give a result that is worse than with depth 8. Not even the fg/bg trick do yield a discernible xterm from the dark display.

Expected result (as experienced running `xinit -- /usr/bin/Xorg :0`):
The X display 0 is able to display colors and avoid the darkness.

Created attachment 41140 [details]
dmesg w/drm.debug=0x06 (Redux)

Created attachment 41141 [details]
Xorg.0.log, 8bpp (Redux)

Created attachment 41142 [details]
Xorg.0.log, 15bpp (Redux)

Created attachment 41163 [details]
Xorg.0.log diff, 8bpp vs 15bpp (Redux)

The difference in brightness between 15bpp and 8bpp seems strange. As the Xorg.0.log diff attached show there are a couple of lines that differ.

15bpp has default Visual TrueColor vs. 8bpp having PseudoColor.

To see if the choice of Visual did affect the brightness, I added xorg.conf:

Section "Screen"
    Identifier "MyScreen"
    SubSection "Display"
        Depth 15
        Visual "PseudoColor"
    EndSubSection
EndSection

Restarted with:
xinit -fg black -bg lightgrey -- /usr/bin/Xorg -depth 15 :0

Result: Nothing changed. 15bpp still darker than 8bpp.

Created attachment 41165 [details]
xvinfo 8bpp (Redux)

Created attachment 41166 [details]
xvinfo 15bpp (Redux)

The Xv difference between 8bpp and 15bpp in Xorg.0.log seems interesting as the attached xvinfo output shows. But I'm delving far into the unknown here...

Created attachment 41209 [details]
xorg.conf used only for the 16vs15-comparison

Created attachment 41210 [details]
Xorg.0.log, 16bpp, DRI=off, (16vs15-comparison)

Created attachment 41211 [details]
Xorg.0.log, 15bpp, DRI=off, (16vs15-comparison)

Created attachment 41212 [details]
Xorg.0.log diff, DRI=off (16vs15-comparison)

16vs15-comparison

If Xorg.0.log tell the truth and DRI really is disabled for both 16bpp and 15bpp then the only differences left that could explain the extreme difference in display output is (seen in the attachments):

* RGB weight
* video overlay key

What are they? Is this possible, or is it more to it beyond the log?

Created attachment 41664 [details] [review]
xf86cmap: Use old palette system for pseudocolour.

Does this xserver patch help?

Patch applied - colorful and unstable

System environment:
Chipset: Arrandale - Intel Core i5 M450 CPU
Arch: i686
libdrm: (git commit 550fe2ca3b29ad2191eab4fdfbed9ed21e25492d)
mesa-dri: (git commit 63528c4510e4891a13c255871b1dd5c2dafdb02c)
xorg: 1.9.99.901 (1.10.0 RC 1) 
  (git commit 6358a60065eef167d4e5f4afd981ff26deeba80d)
intel-drv: 2.14.0 (git commit fd9235ebe03a01982238cdd6e8b55f613e14b6af)
kernel: 2.6.37-2.fc15
xrandr: 1.3.4 (git commit b94179dd0538c73ff4628d43f4b8f492351ddd9c)
distro: Fedora Rawhide (14-15)
machine: Acer Aspire 3820T, model MS2292, TimelineX laptop
display connector: LVDS2

Reproducible: 100%

Steps to reproduce:
1. Install Fedora Rawhide (hmm.. somewhat reproducible)
2. Log in on first tty
3. Build X according to http://xorg.freedesktop.org/wiki/ModularDevelopersGuide
4. export LD_LIBRARY_PATH=/tmp/xorg/lib
5. Run `xinit -- /tmp/xorg/bin/Xorg -depth 8 :0`

Result: The X display 0 on tty7 is *very* colorful. See attachment: Running patched `xinit -- /tmp/xorg/bin/Xorg -depth 8 :0`

As before, running:
`xinit -fg black -bg lightgrey -- /tmp/xorg/bin/Xorg -depth 8 :0`
Image of screen included in attachment: Running patched `xinit -fg black -bg lightgrey -- /tmp/xorg/bin/Xorg -depth 8 :0`

Might give a perfect screen with black root window and white xterm, just the same as running with depth 16 or 24. Listing directories with colored ls output do yield a sudden change into the strange world of "bade taste" colors.

The result is not stable. Running xinit with -fg/-bg options directly after xinit without the options might give a screen with exactly the same colors instead of a perfect screen similar to 16 and 24 bpp. Changing VT do sometimes give a black screen after xinit, and reboot is necessary.

The expected result (as experienced running `xinit -- /tmp/xorg/bin/Xorg :0`):
The X display 0 is able to display colors and no sudden color mapish change occur if you do `ls --color /`.

Created attachment 42017 [details]
Running patched `xinit -- /tmp/xorg/bin/Xorg -depth 8 :0`

Created attachment 42018 [details]
Exiting from the X screen in attachment 42017 [details]

Created attachment 42019 [details]
Running patched `xinit -fg black -bg lightgrey -- /tmp/xorg/bin/Xorg -depth 8 :0`

Created attachment 42020 [details]
Sudden color mapish change from executing `ls` in X screen seen in attachment 42019 [details]

(In reply to comment #26)
> Created an attachment (id=41664) [details]
> xf86cmap: Use old palette system for pseudocolour.
> 
> Does this xserver patch help?

Well, it certainly does something. But it seems as if other components need some more care too for this to really be helpful.

Thanks anyway Michel.

Created attachment 42111 [details]
Xorg.0.log, 8bpp, patched X-server

Rather than trying to patch things back up to make 8bpp work, I'd rather see us just reject the config early in driver setup and not support it.

Created attachment 75380 [details] [review]
Patch to disable driver for depth 8 (it just doesn't work).

(In reply to comment #34)
> Rather than trying to patch things back up to make 8bpp work, I'd rather see
> us just reject the config early in driver setup and not support it.

Here's a patch to do exactly that.

-Carl

The attached patch has now been pushed.

Thanks, all.

-Carl

Woah. In hindsight, this bug was reported immediately after an Xorg release that broke our driver. The DDX and kernel did work with psuedo-color modes and we had an immediate regression report. No wonder we have a very bad reputation.