I don’t officially speak on this matter, nor will I attempt to answer your question directly, as I’m unaware of any internal company efforts in this area. However, it would be beneficial to have a centralized resource to track ongoing efforts, ensuring we avoid duplicating work that might otherwise go to waste.
That said, I’ve observed some progress in improving XWayland (*), and I’ve personally tested it and submitted bug fixes. Efforts have also been made to enable Robot to work with XWayland using PipeWire, which is a great step forward. (*) XWayland is the compatibility layer that allows X11 applications to run on Wayland. Creating a simple state-based display using the pure Wayland protocol is relatively straightforward (specially with Java 22 and FFM). However, implementing all the necessary details for a fully functional and feature-complete Wayland backend is a substantial endeavor. One challenge, for instance, is that Wayland’s design choices intentionally avoid certain features (like not having a global cursor position and not allowing window management operations). I submitted a pull request to enable EGL on Prism ES2 with Wayland in mind. This enhancement allows for GL rendering using EGL, which is a critical requirement for a Wayland compositor. I also conducted some experiments and managed to display a window using only the Wayland protocol (*) in Java, leveraging jextract and the Foreign Function & Memory (FFM) API. However, this is far from achieving a fully functional Wayland Glass backend. (*) Wayland is just a specification, many compositors implement it. -- Thiago. Em dom., 1 de dez. de 2024 às 08:43, Davide Perini < perini.dav...@dpsoftware.org> escreveu: > As title. > It seems that JavaFX is not fully compliant with Linux Wayland. > > Is there an ETA for the complete wayland support? > > Thanks > >
