-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x11: Implement image transfer using the MIT-SHM extension #46
Conversation
a2617ed
to
bf39ede
Compare
I'm waiting for #55 to make progress before I continue on this, since I'll probably reuse whatever SHM mechanism that uses here. |
55 is merged |
bf39ede
to
a2ef94f
Compare
Will this gracefully fall back to the old method if MIT-SHM is not available? Would that be the case when using X11 forwarding, like with SSH? |
Yes, this falls back to the wire method if it determines that SHM is not available. This is still marked as draft because I realized that I left a leak in it before I left for the gym. Let me fix that before I mark it as ready. |
I guess on vaguely modern versions of X11, we have the option to use https://docs.rs/x11rb/0.11.0/x11rb/protocol/shm/trait.ConnectionExt.html#method.shm_attach_fd instead of using That could share code for allocating/growing with Wayland. |
The main drawback would be not being able to use |
I think all I said about I guess there's no real need to change it. (Or at least, not that I'm familiar with.) Though needing to deal with the limitations of |
If it's all the same, then I'd rather keep the idiomatic SHM wrapper I have right now. |
I think this can be merged once @ids1024 approves |
The code generally looks good now. Has it been tested that it correctly falls back to not using shm on a remote X server? With XShm, any other X client could get the shm segment for our window, map it, and read or write to our window buffer, right? This is a bit of a concern for #40. I think(?) that shouldn't be a soundness concern with |
I've tested it, and it successfully falls back to the wire method for transfer, so we're good there.
I don't believe that there is a way for an X client to get the SHM ID in use by another X client unless there's a server bug.
Okay, I'll merge this PR! |
Ah. I was thinking that a compositor/compositing WM would read directly from the shm buffer, but I guess that's handled in a different way. |
Uhm... I have no idea what Xorg does in this case for non-local connections, but I wouldn't be surprised if this fails by breaking the whole X11 connection. At least I would suggest some testing before trying to use this.
I think there is always a Also, the
is a parameter called |
This PR implements image transfer using the MIT-SHM extension, allowing us to avoid image transfers over the wire.
At the moment I can't test this on my machine, as the x11-dl crate has a bug that prevents it from loading the MIT-SHM extension (AltF02/x11-rs#164).Circumvented this by moving tox11rb
.Closes #38
(This is a port of rust-windowing/swbuf#23 to the new repository)