For pure-Rust connections, there is no XCB connection that can be passed into
the display constructor. Thus, this PR enables the display to be created without
needing an XCB or Xlib handle, by providing `None` in the constructor.
cc rust-windowing/raw-window-handle#120
Signed-off-by: John Nunley <dev@notgull.net>
This function takes `Into<RawFdContainer>`. So it accepts an owned fd,
and closes it. So as long as the API is like this, we need to dup a new
fd it can close when calling it.
`Into<RawFdContainer>` is implemented for anything implementing `IntoRawFd`,
so passing `OwnedFd` works.
Fixes https://github.com/rust-windowing/softbuffer/issues/168. Should be
backported to 0.3.x.
The X11 backend used System-V shared memory to communicate shared
buffers to the server, but rustix does not support SysV SHM so we had to
use libc in this backend. However, there is an alternate X11 API which
uses POSIX shared memory, which rustix does support. This PR switches
the X11 backend to POSIX shared memory and purges the previous
usages of libc.
The goal is to remove libc totally. Therefore this PR also removes the
default libc dependency from rustix.
Signed-off-by: John Nunley <dev@notgull.net>
Partly addresses
https://github.com/rust-windowing/softbuffer/issues/147, though it would
still be desirable to have a good safe API for SYSV shm in Rustix. But
using `libc` directly for now is no worse than using the `nix::libc`
re-export, so we don't lose anything.
This adds a DRM/KMS based backend to the system, as per #42. This system finds a CRTC and a connector, then uses that to create a frame buffer and a DUMB buffer that it can render to.
There's much more to do, and is left as an exercise for anyone with a significant DRM-based use case to pick up and fix.
Signed-off-by: John Nunley <dev@notgull.net>
This fetch function has been broken and is probably unsound. This also
fixes the flakey Windows CI that we've been dealing with.
Signed-off-by: John Nunley <dev@notgull.net>
My new tiny-xlib crate takes up a fraction of the space that the x11-dl crate uses, supports
feature-based static linking and involves less of Xlib's ridiculous surface.
This function is useful for testing the window contents in certain cases. In addition,
this means that we can now have reliable tests for softbuffer's actual functionality.
Signed-off-by: John Nunley <jtnunley01@gmail.com>
Co-authored-by: dAxpeDDa <daxpedda@gmail.com>
This is based on the API that will be used for no-copy presentation. But
wraps it in `set_buffer`.
This also fixes the Wayland buffer code to set `self.width` and
`self.height` on resize, and set the length of the shared memory file
when the buffer is created.
Co-authored-by: jtnunley <jtnunley01@gmail.com>
A `Context` is created with a display handle, and a `Surface` is created
with a `&Context` and a window handle. Thus multiple windows can be
created from the same context without duplicating anything that can be
shared. This API is broadly similar to `wgpu` or `glutin`.
On Wayland, the `Context` contains the `EventQueue`, which is shared
between windows, and the `WlShm` global. On X11, `Context::new` checks
for the availability of XShm, and contains a bool representing that as
well as the `XCBConnection`. The shared context data is stored within
the window in an `Arc`.
On other platforms, the display isn't used and `Context` is empty. This
does however test that the display handle has the right type on those
platforms and fail otherwise. Previously the code didn't test that.
Closes https://github.com/rust-windowing/softbuffer/issues/37.
I believe this should be possible wherever `memfd_create` is available.
Sealing isn't required, but Wayland doesn't allow a client to shrink an
shm pool, so there's no reason we should shrink the file. And if we mmap
the file, this prevents a `SIGBUS` if the compositor (incorrectly)
shrunk it.
So we might as well do this.
This commit fixes a bug in the Core Graphics backend that causes a new
buffer not be shown immediately but instead use a quarter second fade
transition. This happens because the CALayer has a default action
associated with a change in the layer contents.
The problem was mitigated by wrapping the contents change in a
transaction and disabling all actions for the duration of this
transaction.
