xpra icon
Bug tracker and wiki

Changes between Version 22 and Version 23 of ProjectIdeas


Ignore:
Timestamp:
03/03/15 13:06:20 (5 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • ProjectIdeas

    v22 v23  
    44       Xpra is a remote desktop tool providing many exciting features as compared to other open source tools. It is developed with a [/wiki/Source#Statistics mix of Python and C], and works on many platforms. The list below describes Google Summer of Code project ideas, aimed both at improving Xpra and at teaching the students about how a remote desktop solution works.
    55
    6        Xpra is taking part in [https://www.google-melange.com/gsoc/homepage/google/gsoc2014 Google Summer of Code 2014] under the umbrella of the [http://www.x.org/ X.org] organization. Students will therefore be applying to [http://www.x.org/wiki/SummerOfCodeIdeas/ X.org GSoC] after having discussed their project with Xpra. To apply, you need to :
     6
     7       To contribute, you need to :
    78- [/wiki/Building download, build] and [/wiki/Usage use Xpra] a little
    89- join the [irc://irc.freenode.net/winswitch IRC channel]
    9 - read the [/wiki#Internals existing documentation] to get the best possible understanding of what Xpra is (you will be quizzed on the matter)
     10- read the [/wiki#Internals existing documentation] to get the best possible understanding of what Xpra is
    1011- contribute at least one patch to the project, that is subsequently committed to the repository
    1112- discuss a project idea with the developers, in order to build your own understanding and goals for this project
    12 - write the project proposal including several milestones with deliverables and an approximate timeline
    1313}}}
    1414
    … …  
    1919       For example, Xpra has to be able to dynamically adapt the remote (server-side) virtual framebuffer to match the client configuration exactly. Although this mostly works OK using {{{xf86-video-dummy}}} and [/wiki/FakeXinerama libfakeXinerama] (to fake the same number of screens), there is still much room for improvement.
    2020       * Better [http://en.wikipedia.org/wiki/RandR RandR] support in the [http://cgit.freedesktop.org/xorg/driver/xf86-video-dummy/ dummy driver] ({{{xf86-video-dummy}}}) to allow us to use any resolution we choose without needing to have it pre-defined in the [/browser/xpra/trunk/src/etc/xpra/xorg.conf xorg.conf] shipped with xpra. The changes may actually need to be applied to the core server and/or the dummy driver.
    21        * DPI issues (should probably be tied to the {{{RandR}}} issue above - though it may also interact with {{{libfakeXinerama}}}): some applications will talk to the X11 server directly to obtain the screen dimensions and calculate their own DPI value. The virtual screen we define for Xpra is not meant to have a fixed "physical" size: it is meant to adapt to what the client specifies and should be changed whenever a new client connects. Because the X11 server assumes that the dummy screen size is fixed, the DPI values calculated by the client applications will vary widely depending on the current screen resolution set at the time the DPI is calculated, causing some ugly rendering problems. The dummy driver needs to support changes to the "physical" screen dimension at runtime (and not just the resolution). '''Note''': this is now mostly solved in #163
     21       * DPI issues (this is tied to the {{{RandR}}} issue above - though it may also interact with {{{libfakeXinerama}}}): some applications will talk to the X11 server directly to obtain the screen dimensions and calculate their own DPI value. The virtual screen we define for Xpra is not meant to have a fixed "physical" size: it is meant to adapt to what the client specifies and should be changed whenever a new client connects. Because the X11 server assumes that the dummy screen size is fixed, the DPI values calculated by the client applications will vary widely depending on the current screen resolution set at the time the DPI is calculated, causing some ugly rendering problems. The dummy driver needs to support changes to the "physical" screen dimension at runtime (and not just the resolution). '''Note''': this is now mostly solved in #163
    2222       * [http://keithp.com/blogs/dri3k_first_steps/ DRI3K] support. Someone interested in the world of X.org may be interested in this project.
    2323
    … …  
    6363
    6464{{{#!div class="box"
    65 == 4) Automated problem reports ==
    66        The Xpra client, like any piece of software, has bugs. It sometimes crashes. It's not a big deal: you just have to restart the client, and you'll get your applications back (unless the server crashed also, but it happens less often). However, whenever it crashes, and especially on Win32 platforms, there is very little information that can be sent to the developers to help them fix the bug, and reproducing the crash is not always straightforward. \\
    67        This project is about making Xpra easier to debug. Ideas are :
    68            * Integrate an automated stack trace mechanism
    69            * Generate automatic crash reports, including screenshots if necessary, to enable easy bug reporting for users
    70            * Allow building of the client with debug symbols
    71            
    72            '''Difficulty''': medium\\
    73            '''Keywords''': Python, backtrace, automated bug reporting
    74 }}}
    75 
    76 {{{#!div class="box"
    77 == 5) Android client support ==
     65== 4) Android client support ==
    7866       The objective is for Xpra to support as many platforms as possible for the client. An Android client exists but is not completely up-to-date in terms of feature, and its usability is far from perfect. This project consists in improving Android client support, or, alternatively, implement Xpra client support for another mobile platform (be it Linux - Raspberry Pi, Android, or any other OS).\\
    7967       The tasks for Android consist in the following:
    … …  
    8977
    9078{{{#!div class="box"
    91 == 6) Latency improvements through hardware-accelerated video decoding ==
     79== 5) Latency improvements through hardware-accelerated video decoding ==
    9280       Remote desktop software is very sensitive to latency. Too high of a latency can kill the user experience. Latency sources are obviously the network, but also and usually more importantly, the video encoding on the server side, the video decoding on the client side, and the video presentation on the client side.\\
    9381       We have preliminary support for OpenGL presentation on the client side (doing YUV to RGB conversion and drawing), which helps with latency. However, there is the technical possibility of offloading the video decoding process to the GPU using such APIs as VAAPI (Linux) or DxVA (Windows), possibly both through libva which we already use. This project is about improving latency of Xpra, with the following tasks :
    … …  
    10290
    10391{{{#!div class="box"
    104 == 7) Encryption ==
     92== 6) Encryption ==
    10593       At the moment, Xpra can use AES encrypted communication over TCP. It supports password authentication, but the key exchange system is open to MITM attacks. \\
    10694       Xpra supports a mode where it connects through an SSH connection. That mode is good, but doesn't answer all needs: it requires an ssh server and each user connecting to the session to have shell access on the system, no matter what application needs to be run.\\
    … …  
    116104
    117105{{{#!div class="box"
    118 == 8) Win32 server (shadow mode) ==
     106== 7) Win32 server (shadow mode) ==
    119107       
    120108       Xpra's client works on many platforms, but the server is restricted to Linux. This means that Xpra can only be used to remotely access a Linux-based desktop. It would be very interesting to make Xpra's server able to work on a Windows machine. Currently there is preliminary support for this feature but it uses polling which is very inefficient.\\