mirror of
https://github.com/gnif/LookingGlass.git
synced 2024-11-12 17:38:19 +00:00
updated the readme
This commit is contained in:
parent
01b10b3ee1
commit
3ec4ff2c8a
36
README.md
36
README.md
@ -139,10 +139,12 @@ guest.
|
|||||||
Results
|
Results
|
||||||
-------
|
-------
|
||||||
|
|
||||||
Latency has not been measured but it is sufficient to say that it would be
|
Latency has not yet been measured, but in practice to this author it is
|
||||||
difficult to obtain an accurate measurement. In practice to this author it is
|
extremely hard to notice any latency between the physical display and host
|
||||||
impossible to see any latency between the physical display and host client
|
client output when streaming 24bit RGB. When streaming YUV422P there no
|
||||||
output.
|
percevable latency at all, this indicates that the memory copy is the slowest
|
||||||
|
part of the process. To combat this multi-threaded memory copy has been
|
||||||
|
implemented on both the host and guest ends of the transfer.
|
||||||
|
|
||||||
At this time we are waiting for a signed ivshmem driver by Red Hat to be
|
At this time we are waiting for a signed ivshmem driver by Red Hat to be
|
||||||
released but since this may take quite some time we are currently in the
|
released but since this may take quite some time we are currently in the
|
||||||
@ -151,12 +153,15 @@ process of obtaining a driver signing certificate.
|
|||||||
Status
|
Status
|
||||||
------
|
------
|
||||||
|
|
||||||
The guest software at current needs to be rewritten, in it's current state it
|
The host software is considered 90% complete for devices that are capable of
|
||||||
is simply proof of concept.
|
NvFBC and has been written in such as way to allow for other capture interfaces
|
||||||
|
to be easily added to support other platforms.
|
||||||
|
|
||||||
The host software is considered 90% complete, features such as copy & paste
|
The client software is considered 90% complete, features such as copy & paste
|
||||||
between client and guest are missing and it would be nice if it could also
|
between client and host are missing and it would be nice if it could also
|
||||||
serve as the ivshmem-server.
|
serve as the ivshmem-server. The client is able to support a variaty of pixel
|
||||||
|
formats types depending on the capability and performance of the capture API
|
||||||
|
that is in use.
|
||||||
|
|
||||||
Security
|
Security
|
||||||
--------
|
--------
|
||||||
@ -169,6 +174,19 @@ At this time this is not a concern as our use case of this application at this
|
|||||||
time is in a completely trusted environment, but before it is more widely put
|
time is in a completely trusted environment, but before it is more widely put
|
||||||
into use this will need to be addressed.
|
into use this will need to be addressed.
|
||||||
|
|
||||||
|
Improvements
|
||||||
|
------------
|
||||||
|
|
||||||
|
It may be possible to avoid the additional copy by handing the guest a block
|
||||||
|
of memory directly from the hosts graphics device. This would allow the guest
|
||||||
|
to stream directly into the texture on the host. This however could be another
|
||||||
|
avenue of escape for malicious code on the guest and would need very careful
|
||||||
|
consideration before any attempt is made to implement this.
|
||||||
|
|
||||||
|
To achieve the above it would be required to modify qemu integrating the
|
||||||
|
features of this client directly so that a SDL\_Texture's RAM could be mapped
|
||||||
|
directly into the guest.
|
||||||
|
|
||||||
License
|
License
|
||||||
-------
|
-------
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user