https://bugs.freedesktop.org/show_bug.cgi?id=78190
--- Comment #2 from Pekka Paalanen <[email protected]> --- Jason, that is a very good analysis of the problems, and I agree with your rationale. If we choose to make damage in buffer coordinates, that will affect the definition of the Presentation extension, and also the core protocol changes it requires. Therefore Presentation cannot land until this issue is solved. A fifth option came to my mind: keep all the Wayland semantics as is, but add a function to wayland-egl API: void wl_egl_window_set_damage_size(struct wl_egl_window *egl_window, int width, int height) This call would set the damage rectangle, that eglSwapBuffers() normally uses, and the size with which swapbuffers-with-damage uses to flip the rectangles. It seems to me like this would solve the immediate issue. However, I don't know if we can change the wayland-egl API at all. It has absolutely no versioning, not on header level nor runtime. Build-time version checks could be done by checking libwayland-client version for the header, and the version reported by wayland-egl.pc (provided by the libwayland-egl.so implementation) for the library version, but there is no way to check at runtime. <rant> What's worse, wayland-egl.pc from Mesa reports the Mesa version. Any other EGL implementation likely reports their own version, making the version vendor dependent instead of API dependent. (The same problem applies to egl.pc, gl.pc, glesv1_cm.pc and glesv2.pc.) I have no idea why these .pc files cannot just report the real API version, e.g. EGL 1.4. If someone wants to check the specific implementation's version, there should be an implementation-specific .pc file for that, e.g. mesa3d.pc, since obviously the build is already implementation dependent. </rant> -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Wayland-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-bugs
