Bug 75390

My opinion on the matter is still the same as in the email quoting an irc conversation:
- for wl_shm, clients do not need to care, and compositors need to be prepared to deal with huge sizes
- for EGL Wayland platform, rendering such a big size will probably fail anyway, or it should be made to fail if the compositor cannot texture from the render target.

Any crashing or hanging is of course a bug and needs to be fixed. These should be separate bug reports.

I guess the problematic case you are hitting is a software rendered client on a Weston with gl-renderer, right? I'm slightly surprised the hw can do GLESv2 to begin with, but maybe you have a huge desktop over multiple monitors?

I'm not totally sure it must be fixed, but if anyone cares, it would be a change limited inside the gl-renderer, and hence be fairly self-contained work. No protocol work would be involved. A proper fix would be to split the surface into several GL textures. A hack to prevent the window becoming invisible and hence almost unrecoverable would be to just clamp the GL texture size to what the hw can support, ignore the rest of the wl_shm buffer, and use something like GL_CLAMP_TO_EGDE for rendering the surface so it is obvious something is going wrong without misplacing the surface parts that can be rendered fine.

A stupid suggestion for users: use Weston's pixman renderer, it should not have size restrictions.

Having clients tile themselves is likely not worth it, IMO. Using wl_shm is already a fallback that should work, and clients could refuse to resize to larger than what the GL stack supports. I guess this would be another reason to have wl_egl_* size API to be able to report errors on invalid sizes before rendering.

If clients really do want to tile, they can do so with sub-surfaces.

Yes. I can reach this limit by connecting a 1920x1080 screen, with the laptop screen. Resizing a window vertically causes this limit to be reached.

And I can confirm that with the pixman renderer I can resize a window far beyond the vertical size of both screens, even a qt wayland-egl client. 

This testing laptop I am using I think is from 2006.

Right, it would be an error for clients to resize themselves larger than GL's declared limits and expect it to work. There's nothing we can do in the compositor or protocol to steer them away from this.