[RFC weston] remote access interface module

[Hardening]

Le 18/10/2013 16:50, Andrew Wedgbury a écrit :
> Hi,
>
> I've been working on a weston module to support an interface for remote access systems such as VNC. This is now at a point where it's usable (and works rather well with a suitably modified version of our VNC server) so I wanted to present it here with a view to including it in weston at some point.
>
> The module is named remote-access - which is intended to be a suitably generic name since it could be used by VNC or RDP (or others). It exposes a new global interface called remote-access, which can be used to create instances of remote-capture and remote-seat interfaces as required.
>
> The remote-capture interface allows a particular output to be captured. It is created by specifying a shared memory region of the required size, and the output to capture. The interface allows a single refresh to be requested, in which case an update event will signal when the update is ready to be read from the buffer. It can also operate in continuous mode, when update events are sent whenever the output changes and the buffer has been updated. The update event contains the coordinates of the rectangle that changed (in coordinates relative to the output). This part is loosely based on weston's screenshooter code.
>
> The remote-seat interface allows input events to be injected via a weston seat. The interface allows multiple remote-seat objects to be created, each of which can use an existing seat, or create a new seat. That way the remote access system has the flexibility of creating a separate seat for each connected user, or simply control an a single seat, as required.
>
> There are (at least!) two outstanding issues that I am aware of:
>
> * Access to these interfaces should be restricted somehow. This could be achieved in a way similar to screenshooter, where weston could launch the VNC/RDP server. Or weston could prompt the user somehow (although this would not be effective when trying to access a remote, unattended machine).
>
> * We need to be able to capture the pointer sprite, and detect when this changes. This would need to be part of the remote-seat interface since each seat can have a pointer. So far I've not found a method to reliably detect when the pointer changes, so I would appreciate some help on this one.
>
> I've also written a test client, but this is very much work-in-progress at this point.
>
> Any feedback would be greatly appreciated, diff follows below:
>

Hello Andrew, thank you for this interesting proposal.

Based on this, I think most of the RDP compositor could be implemented 
as a privileged client. I still have a few remarks:
* a null locale is given for the keyboard of the remote_seat, I'm not 
sure that we can handle all case that way. Especially with RDP that is 
quite complicated on that side (anyway it's probably a question for 
daniel or any input expert);
* I can't see any interest for continuous update mode, that could lead 
to send partial or "corrupted" frames to the remote clients;
* about the pointer sprite, I think the problem is even more complicated 
with multi-seat (we should draw everything but the cursor of the current 
seat). I have done some tests to _not_ draw the cursor by writing a 
special assign_planes callback in the RDP compositor. But RDP has some 
limitations with client cursors (can only be a bitmap), so i was too 
lazy to finish the code that would detect the working cases. I'm 
interested too if someone can tell how to be notified of the cursor 
sprite being modified.


Regards.