A visual describes how colors are laid out by the X11 server. So far,
softbuffer did not do anything with visuals and just passed them around.
This commit adds checks that should ensure that a given visual actually
lays out pixels in the only format supported by softbuffer:
- 32 bit per pixel
- 00RRGGBB byte order
In this patch, I also try to handle big endian systems and mixed endian
situations where we are e.g. running on a big endian system and talking
to a little endian X11 server. However, this is all theoretical and
completely untested. I only tested my X11 server's default visual works
and some ARGB visual is rejected.
Fixes: https://github.com/rust-windowing/softbuffer/issues/184
Signed-off-by: Uli Schlachter <psychon@znc.in>
Co-authored-by: John Nunley <dev@notgull.net>
Drm-rs now no longer requires separate generated bindings for each
platform, so this fixes the build on architectures/OSes where drm didn't
have bindings.
It also now uses Rustix instead of Nix, but Nix is still used by the
Wayland and X11 backends, until the next wayland-rs and x11rb release.
This is not a breaking change since `drm` isn't exposed in the API.
It seems #132 contains a copy-paste typo to trigger draw logic on
`CloseRequested` instead of on `RedrawRequested`.
Signed-off-by: Marijn Suijten <marijns95@gmail.com>
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.
Softbuffer is broken on recent builds of Redox without the fix here, so
it's helpful to have a new release that fixes it. We seem to have
accumulated a few non-breaking fixes, so it seems like a good enough
time to do a release anyway.
Disabling `fetch` on Windows could be considered breaking, but it
doesn't change the API, was broken anyway, and is likely unused. So I
don't think that's an issue.
They are currently failing due to what we believe is a bug in the
Windows bindings for Rust. For now, disable these until this bug is
resolved.
Closes#142
Signed-off-by: John Nunley <dev@notgull.net>
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>
