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.

> 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.