Hello, I am using the sway Wayland compositor and the library works on the first run but after when I run a test program again, it panics. This commit fixes it (tested by running the topmost example from the repository), see below for details.
wlroots based compositor reuse the same FD for keymap, so after a first
read is done, the file is seeked to the end and the next read fails,
causing the following error:
thread 'main' panicked at 'called Result::unwrap() on an Err
value: Error { kind: UnexpectedEof, message: "failed to fill whole buffer" }'
The Wayland documentation says the FD "can be memory-mapped to provide
a keyboard mapping description" and then "From version 7 onwards, the
fd must be mapped with MAP_PRIVATE by the recipient, as MAP_SHARED may
fail."
Although it is not very clear, it probably means that the FD must be
memory-mapped.
emoon
commented
2 years ago
Hello, I am using the sway Wayland compositor and the library works on the first run but after when I run a test program again, it panics. This commit fixes it (tested by running the
topmostexample from the repository), see below for details.wlroots based compositor reuse the same FD for keymap, so after a first read is done, the file is seeked to the end and the next read fails, causing the following error:
thread 'main' panicked at 'called
Result::unwrap()on anErrvalue: Error { kind: UnexpectedEof, message: "failed to fill whole buffer" }'The Wayland documentation says the FD "can be memory-mapped to provide a keyboard mapping description" and then "From version 7 onwards, the fd must be mapped with MAP_PRIVATE by the recipient, as MAP_SHARED may fail."
Although it is not very clear, it probably means that the FD must be memory-mapped.