Making wayrs-client generic over different wayland transports

[madushan1000]

Currently wayrs-client crate only supports unix socket as the transport for wayland protocol.

Right now, I'm trying to modify the crate to be generic over the transport so I can use it with virtio-gpu cross-domain protocol(used to allow programs running on crosvm/qemu guests to open windows in host wayland compositor).

Are you interested in merging the changes here? It will break the public crate api, because things like Connection struct will have to be generic over the transport.

[MaxVerevkin]

Will it be a breaking change if the new generic has a default, like the allocator in Vec<T, A=Global>?

[madushan1000]

Oh I didn't realize that was a thing, I'll try to set a default and see if I can avoid breaking the public api, I'll make a PR when I'm done. Thank you :)

[madushan1000]

@MaxVerevkin do you have any suggestions on how to handle async_fd field in Connection struct? I'm thinking of moving it to BufferedSocket struct and adding helper functions to manipulate it.

[MaxVerevkin]

@MaxVerevkin do you have any suggestions on how to handle async_fd field in Connection struct? I'm thinking of moving it to BufferedSocket struct and adding helper functions to manipulate it.

Hard to say since I don't know which problems you've encountered, and how the alternative transport you are working on works.

[madushan1000]

The biggest problem is the virtio protocol won't use a file descriptor, it works by basically opening /dev/dri/card0 drm device and then doing a bunch of IOCTLs and memcpys to copy wayland packets back and forth.
I looked into implementing file descriptor related traits for this but that looks like a lot of work. If there is no other way, I'll end up doing it anyway.

[MaxVerevkin]

How do you know then a new message is available to be read?

You can open a draft PR so I can have some idea how wayland over virtio works, since I've never used it.

[MaxVerevkin]

Also, may I ask what you are planning to do with this? Are you writing a forwarding compositor? Just curious.

[madushan1000]

There is an overview of the protocol here. To receive you have to do a blocking IOCTL and poll the channel, see the receiving data section.

I didn't actually start writing the virtio stuff yet because I couldn't settle on a proper abstraction for transport. I was doing something like this, but looks like that's not going to be enough because of the async functions.

pub trait WaylandSocket: AsRawFd {
    fn connect() -> Result<Self, ConnectError>
    where
        Self: Sized;
    fn get_free_msg_args_as_ref(&mut self) -> &mut Vec<Vec<ArgValue>>;
    fn flush(&mut self, mode: IoMode) -> io::Result<()>;
    fn peek_message_header(&mut self, mode: IoMode) -> io::Result<MessageHeader>;
    fn write_message(&mut self, msg: Message, mode: IoMode) -> Result<(), SendMessageError>;
    fn recv_message(
        &mut self,
        header: MessageHeader,
        iface: &'static Interface,
        version: u32,
        mode: IoMode,
    ) -> io::Result<Message>;
}

impl WaylandSocket for BufferedSocket {
    fn connect() -> Result<Self, ConnectError>
    where
        Self: Sized,
    {
        Self::connect()
    }

    fn get_free_msg_args_as_ref(&mut self) -> &mut Vec<Vec<ArgValue>> {
        &mut self.free_msg_args
    }

    fn peek_message_header(&mut self, mode: IoMode) -> io::Result<MessageHeader> {
        self.peek_message_header(mode)
    }

    fn recv_message(
        &mut self,
        header: MessageHeader,
        iface: &'static Interface,
        version: u32,
        mode: IoMode,
    ) -> io::Result<Message> {
        self.recv_message(header, iface, version, mode)
    }

    fn write_message(&mut self, msg: Message, mode: IoMode) -> Result<(), SendMessageError> {
        self.write_message(msg, mode)
    }

    fn flush(&mut self, mode: IoMode) -> io::Result<()> {
        self.flush(mode)
    }
}

And yes, I'm trying to write a forwarding compositor for android. Something like waydroid but running in a vm.

[MaxVerevkin]

Thanks for the link!

To receive you have to do a blocking IOCTL and poll the channel, see the receiving data section.

The ioctl is not blocking, the read is, right? It doesn't explicitly state this, but I would be very surprised if the fd you are supposed to read 8 bytes from is not poll()-able. If this is true everything is good, and Connection can use that fd for the async stuff.

And yes, I'm trying to write a forwarding compositor for android. Something like waydroid but running in a vm.

Cool! Since you will also write server-side wayland code, do you think it would be worth it to make BufferedSocket generic enough to be used on the server side too? I've written one wayland server (https://github.com/MaxVerevkin/ewc), but I basically copy-pasted the socket code, adapting it as needed.

By the way, I don't mind a v2 release. For example I wanted to slightly change the Proxy trait so that I could reuse argument buffers from events too. And maybe change some of ArgValue variants.

[madushan1000]

The ioctl is not blocking, the read is, right?

Oh yes, that's true. I will try to actually implement the cross domain protocol using the device fd and see how far I can get, thanks for the advice :)

do you think it would be worth it to make BufferedSocket generic enough to be used on the server side too?

I think this would be useful in general, but not for what I'm doing. My compositor will accept AIDl calls from android system compositor(surfaceflinger) and basically translate them back and forth into wayland calls.

[MaxVerevkin]

pub trait WaylandSocket: AsRawFd {
    fn connect() -> Result<Self, ConnectError>
    where
        Self: Sized;
    fn get_free_msg_args_as_ref(&mut self) -> &mut Vec<Vec<ArgValue>>;
    fn flush(&mut self, mode: IoMode) -> io::Result<()>;
    fn peek_message_header(&mut self, mode: IoMode) -> io::Result<MessageHeader>;
    fn write_message(&mut self, msg: Message, mode: IoMode) -> Result<(), SendMessageError>;
    fn recv_message(
        &mut self,
        header: MessageHeader,
        iface: &'static Interface,
        version: u32,
        mode: IoMode,
    ) -> io::Result<Message>;
}

is it required to send messages one-by-one? If no (from a quick look at sommelier I couldn't find any evidence that it is), I think an API with just sendmsg/recvmsg would be better and avoid a lot of duplication.

[madushan1000]

I think that makes sense, I will refactor once I have a working example.

[MaxVerevkin]

I went ahead and made the low-level BufferedSocket generic over

wayrs/wayrs-core/src/transport.rs

Lines 34 to 49 in 9f865b2

	/// An abstraction over Wayland transport methods
	pub trait Transport: AsRawFd {
	fn send(
	&mut self,
	bytes: &[IoSlice],
	fds: &VecDeque<OwnedFd>,
	mode: IoMode,
	) -> io::Result<usize>;
	fn recv(
	&mut self,
	bytes: &mut [IoSliceMut],
	fds: &mut VecDeque<OwnedFd>,
	mode: IoMode,
	) -> io::Result<usize>;
	}

Connection is not generic yet, though.

[madushan1000]

Nice, I will rebase my work on this :D I have something slimier locally now. for connect, I just added a connect method to the Tansport trait and called implementation specific connect from BufferedSocket::connect

[MaxVerevkin]

I'm not sure about connect being part of Transport, since it may be used by both clients and servers, and connect doesn't make sense for servers. Perhaps we can define a supertrait in wayrs-client, like trait ClientTransport: Transport { fn connect() -> Result<Self> }, which is specific to clients?