Control: tags -1 + confirmed upstream
Control: forwarded -1 https://github.com/Libvisual/libvisual/issues/193
Hello,
I have completed compatibility testing of libvisual and lv-tool against the
SDL compatibility stack in Debian unstable.
libvisual 0.4.2-6 was built with libsdl1.2-dev 1.2.76-1, whose source
package
is sdl12-compat. The resulting lv-tool-0.4 binary still links to
libSDL-1.2.so.0. At runtime, sdl12-compat reports that it is using SDL2
2.32.72.
I ran lv-tool-0.4 0.4.2-6 for five frames with the debug input and lv_scope
actor in the following environments:
* X11 under Xvfb, with SDL_VIDEODRIVER=x11;
* the SDL dummy video driver;
* native Wayland under a headless Weston 16.0.0 compositor, with
SDL_VIDEODRIVER=wayland;
* Xwayland 24.1.13 under the same compositor, with SDL_VIDEODRIVER=x11.
All four runs exited successfully. I also repeated the native Wayland test
with WAYLAND_DEBUG=client and confirmed that the application connected
to and
used the Wayland compositor. For Xwayland, xdpyinfo connected
successfully and
identified the X server as Xwayland 24.1.13.
All runs emitted two libvisual critical diagnostics from
visual_video_set_depth() with a null video argument. The native Wayland run
also emitted Mesa/EGL warnings in the headless environment. I therefore
regard
these results as successful compatibility smoke tests, not complete
functional
validation.
The source still makes extensive use of SDL 1.2-only APIs, including
SDL_SetVideoMode(), SDL_WM_*(), SDL_VIDEORESIZE and SDL_GL_SwapBuffers(), in
lv-tool and the SDL examples. The current upstream source has the same
dependency, so a direct SDL2 port is non-trivial and should preferably be
coordinated upstream. I have linked this bug to the existing upstream issue.
For clarity, the pkg.libvisual.nosdl profile added for #1077534 only omits
lv-tool and the examples from bootstrap builds. It does not port them to
SDL2
and therefore does not resolve this bug.
I am leaving this bug open to track the remaining SDL 1.2 API use.
Best regards,
Federico Molara