Bug 63572 - commit a19da0ea517127052ae49cdd6441e8b6077ca523 (sna: Reduce DefaultDepth to 16 on older chipsets) breaks evas
Summary: commit a19da0ea517127052ae49cdd6441e8b6077ca523 (sna: Reduce DefaultDepth to ...
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-15 21:01 UTC by Bruno
Modified: 2019-11-27 13:31 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Crashdump of enlightenment (5.31 KB, text/plain)
2013-04-15 21:01 UTC, Bruno
no flags Details
xdpyinfo for 2.21.6 (2.39 KB, text/plain)
2013-04-16 20:14 UTC, Bruno
no flags Details
xpdyinfo of last good revision (4.81 KB, text/plain)
2013-04-16 20:15 UTC, Bruno
no flags Details
valgrind log of enlightenment (6.17 KB, text/plain)
2013-04-16 20:17 UTC, Bruno
no flags Details

Description Bruno 2013-04-15 21:01:11 UTC
Created attachment 78026 [details]
Crashdump of enlightenment

commit a19da0ea517127052ae49cdd6441e8b6077ca523 (sna: Reduce DefaultDepth to 16 on older chipsets) causes evas (EFL) to be killed with a signal.

System is i855
  00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
  00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)

  Acer TM660
  x11-libs/libdrm-2.4.43
  media-libs/mesa-9.1.1
  x11-base/xorg-server-1.13.1
  linux-3.8.1

  media-libs/evas-1.7.6.1
  x11-wm/enlightenment-0.17.2.1
Comment 1 Carsten Haitzler 2013-04-16 00:08:15 UTC
i just tested e in 16bpp (xephyr) and it works fine. i know i tested this long
before and just before release of e17 too and it worked. i dont test 16bpp
regularly, but every now and again...

http://www.enlightenment.org/ss/e-516c92a8841755.22448970.png

notice the dithering if you zoom in. 16bpp...

could you give more details - like it crashes immediately on start? you are is
the depth 16bpp BUT the visual is still 24bpp with 24bpp rgb masks? xdpyinfo
will tell you this. i.e.

  depth of root window:    24 planes
...
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    24 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits

or for 16bpp you SHOULD see:

  depth of root window:    16 planes
...
  default visual id:  0x21
  visual:
    visual id:    0x21
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    8 bits

more information needed. also consider using valgrind to catch the problem
earlier.
Comment 2 Bruno 2013-04-16 20:14:54 UTC
Created attachment 78109 [details]
xdpyinfo for 2.21.6
Comment 3 Bruno 2013-04-16 20:15:22 UTC
Created attachment 78110 [details]
xpdyinfo of last good revision
Comment 4 Bruno 2013-04-16 20:17:00 UTC
Created attachment 78111 [details]
valgrind log of enlightenment
Comment 5 Bruno 2013-04-16 20:27:02 UTC
> could you give more details - like it crashes immediately on start?

Yes, the crash happens during early startup of enlightenment, right after painting background and setting up cursor.

> you are is the depth 16bpp BUT the visual is still 24bpp with 24bpp rgb
> masks? xdpyinfo will tell you this. i.e.

According to xdpyinfo, with driver prior to bisected commit root window is 24bit
but with 2.21.6 it is 15bit.

Also of interest, with 2.21.6 there are much fewer visuals listed: 15bit default, 15bit and 32bit while last working one show lots of 24bit visuals.
Maybe the difference in number comes from the moment when xdpyinfo is called.
For 2.21.6 right after starting Xorg, as only X client.
For last good commit from xterm while running under enlightenment.

See attached xpdyinfo outputs.

> more information needed. also consider using valgrind to catch the problem
> earlier.

A valgrind trace is not very informative. It reports a bad write and later a segfault quite a few bytes after the address of bad write.
Comment 6 Martin Peres 2019-11-27 13:31:45 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/18.


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.