Re: Return values in Wayland XML specification
In Wayland array can contain only integers. See how listing of outputs is done. Server creates one global `wl_output` per output, client binds to the global, server sends events with output parameters (list of modes among them) and then event `done` to indicate it stopped sending info about this output. You probably don't want one global per window. I'd go with one global `window_manager` which sends events (one per window) after bind and after creation of window (or on request, depending on your needs). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Skylane - implementation of Wayland in Rust
Hi, Sorry about stupid noobish questions. Now I dived in a bit and know eglCreateImageKHR is everything I need. After whole day I have weston-simple-dmabuf-intel and EGL apps (weston-simple-egl, Qt) running on `perceptia` using linux-dmabuf-unstable-v1 and wayland-drm (yes, I know it's implementation detail, but that's the only way I can think of to make EGL applications talk to me.) Plan for client is to use offscreen GBM buffers + dmabuf protocol. After today I'm optimistic about that. Thank you for help! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Skylane - implementation of Wayland in Rust
> Borrowing the idea from Daniel Stone from whom I heard it first, the > only other option is to reimplement libwayland *including* its C ABI in > Rust. You need to completely throw away the C implementation of > libwayland and replace that with your own libwayland-*.so built with > Rust. Then you will get libEGL calling into your implementation and it > will be the sole implementation, which should let things work. This is some solution but it's huge workaround. I would rather use bindings. > If you want an EGL driver to > talk to Wayland, you need the driver and the server to share a C > implementation of the protocol library. > With this approach there either - has to be the one and only implementation or - every implementation provides its own stuff to mesa or - (what I meant in second point in my first message) mesa is generic enough to be used by any implementation. EGL_WL_bind_wayland_display takes wl_display and fills wl_buffer_interface and wl_drm_interface with pointers to functions taking wl_resource in arguments. I can imagine extension which takes implementation-independent structure and fills it with implementation-independent functions which can be used to construct (by server) implementation-dependent wl_drm in Rust, Haskell, or whatever that talks C ABI. But... > Yes, you don't need to use the EGL extension. You can implement wl_drm > or the dma-buf extension directly in your rust based compositor. ... if so, then I'm more than good with that. I will see what I can do. Thanks! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Skylane - implementation of Wayland in Rust
Hello, This was supposed to be only a short announcement of Skylane - implementation of Wayland in Rust - but it was pointed to me that one can not use hardware acceleration without original libwayland so I have to also ask some questions. On client side there's not much to worry about (as far as I could see) but server has to use mesa extension which adds global object to display, relying on concrete implementation. - I can guess but was the reason to make such dependence? - Would that be feasible to add another more generic extension providing data needed to create wl_drm global by server instead of implicitly adding it in mesa? - I didn't look at details of implementation. Probably not, but would it be feasible to provide wl_drm global without any extension, using only available drm/gbm API? In many places Wayland (not only Weston) is referred as "reference implementation" so I didn't really expect such obstacles. I guess questions like "why new implementation?" or "why not bindings?" will appear, so here are some words in advance. There is one project aiming to create Rust bindings, but at the time I started there was no support for server side (I don't know how about now) and whole think was about adding another complicated abstraction layer dumping straightforwardness (and performance). On the other hand Rust provides great support for multi-threading so it would be wasteful to impose on users how they create wayland thread. Removing that what left is creating sockets, dispatching and generating some marshaling code. Not much. And without using libwayland this can be clean and slick. For interested ones, links to skylane and perceptia (window manager / compositor in Rust using it): https://github.com/perceptia/skylane https://github.com/perceptia/perceptia Best regards, Wojciech Kluczka ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
