*** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY I'm currently developing a Wayland protocol implementation (not using libwayland) with Node.js, and am running into an issue where for the `wl_keyboard#keymap` event I frequently receive an FD that seems to contain no content (trying to read it returns zero bytes), despite the event claiming that it's 64798 bytes long. On one occasion I *did* receive actual keymap data of the correct length, suggesting that the code on my end is not *fundamentally* broken, and is able to read out FDs correctly. Since this successful read happened on the first run of my testing code after a KWin crash-and-restart, and failed on every subsequent run, my suspicion is that there's some state somewhere that's getting corrupted in some way. Since my testing code is currently stateless, that state could not be on my side. There *was* what seems like a bug in my code (the documentation on Wayland does not seem to specify this either way), in that it failed to close FDs that it received previously, and it is possible that this is what triggered the bug on the KWin side. Fixing the bug on my side has not resolved the issue of zero-length files on subsequent runs in the same existing KWin session (I am testing directly against my development system's Wayland session). STEPS TO REPRODUCE 1. Connect Wayland client to KWin 2. Bind to `wl_seat` global and `get_keyboard` 3. Wait for the `wl_keyboard#keymap` event to be emitted 4. Try to read the included FD to completion OBSERVED RESULT An empty Buffer (ie. string of bytes) resulting from the FD read, despite the `size` attribute claiming 64798 bytes, and the `format` claiming to be `xkb_v1`. EXPECTED RESULT Either the keymap data (if one is available, which seems to be the case), or a `size` attribute of 0 bytes (if not). SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION It's difficult to provide a minimal testcase, as there's an entire as-of-yet-unpublished in-progress protocol implementation involved - if a testcase is wanted, please let me know what the desired shape is. For completeness, my implementation uses jhs67's USocket library due to missing FD-sending support in Node.js core, but a reduced testcase of just USocket talking to another instance of itself could not replicate the empty-reads issue - it only seems to happen when talking to Kwin. I have not tested against other compositors. I have also not gotten around to testing other parts of the protocol that involve FDs, so I don't know if this is specific to keymaps. I also cannot fully rule out an issue on my side, but I've run out of potential causes that I can think of, especially because of the successful read that happened once.
Some additional context that may or may not be relevant: prior to the crash-and-restart, I was also getting `0` as the value for both `rate` and `delay` in the `wl_keyboard#repeat_info` event. This has not reoccurred at least since the crash-and-restart, but may have already stopped occurring earlier. I do not know how to reproduce it, so I don't know how actionable this information is, but it might hint at a common cause with the keymap issue.
Can you run your app with WAYLAND_DEBUG=1 envvar and attach the output to this bug report?
Setting NEEDSINFO
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
Hi, unfortunately for health reasons I have not gotten around to collecting the requested information yet. I do not know when I will be able to properly do so (as it will require some code reverts on my end to reproduce again). In the meantime, my most recent findings are that the issue only occurs when I try to read the FD as a file to the end, even after attempting to reset the read offset/pointer. When I mmap it instead, the issue does not occur and it works fine. Likewise, when I read any other FD to the end, it works fine.
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.