I traced it down to the use of the text input field in gtk-dem=
o's assistant.

The issue seems to be with one particular call to glamor_poly_fill_rect_gl()
with more than one prect (nrect > 1).

https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_rect=
s.c#n42

Considering that the GLSL version is < 130 with this hardware, we are in=
 the
else case:

https://cgit.freedesktop.org/xorg/xserver/tree/glamor/glamor_rect=
s.c#n83

If, in that case, with nrect > 1, we bail (to SW) then rendering is fine.

But that same code gives the correct result in may other cases, with multip=
le
rects, so it does not seem to be a bug in the glamor code though... Besides,
the same code as used in Xephyr works fine.

I captured the apitrace of both Xehpyr -glamor and Xwayland along with the =
mesa
debug and glamor debug messages with:

  WAYLAND_DISPLAY=3Dwayland-0 MESA_DEBUG=3D1,incomplete_tex,incomplete_fbo,=
context
apitrace trace ~/local/bin/Xwayland -noreset :1 |& tee Xwayland.log &am=
p;
  DISPLAY=3D:1 GDK_BACKEND=3Dx11 gtk-demo

Then same with Xephyr:

  DISPLAY=3D:0 MESA_DEBUG=3D1,incomplete_tex,incomplete_fbo,context  apitra=
ce trace
~/local/bin/Xephyr -glamor -noreset :1 |& tee Xephyr.log &
  DISPLAY=3D:1 GDK_BACKEND=3Dx11 gtk-demo

Mesa complains that "Texture Obj xxx incomplete because: TexImage[1] is
missing" but that occurs with both Xephyr and Xwayland so I guess it s=
hould not
be the problem.

By logging the prect coordinates, we can match if with the apitrace dump in
both cases. But again, I don't see much difference between the two (Xephyr
-glamor vs. Xwayland)=20

Logs and traces are available here:

   https://p=
eople.freedesktop.org/~ofourdan/bug99400/