xpra icon
Bug tracker and wiki

Changes between Version 1 and Version 2 of ProjectIdeas


Ignore:
Timestamp:
03/25/13 10:37:22 (7 years ago)
Author:
ahuillet
Comment:

Improve formatting, still not great.

Legend:

Unmodified
Added
Removed
Modified
  • ProjectIdeas

    v1 v2  
    33       Xpra is a remote desktop tool providing many exciting features as compared to other open source tools. It is developed with a 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.
    44       
    5        1) Xorg-related improvements
    6        Xpra acts as an X11 compositor, and uses many different X APIs and features to achieve its purpose. We have run into some limitations related to X11 features.
     5== 1) Xorg-related improvements ==
     6
     7       Xpra acts as an X11 compositor, and uses many different X APIs and features to achieve its purpose. We have run into some limitations related to X11 features.\\
    78       For example, Xpra has to be able to dynamically adapt the remote (server-side) virtual framebuffer to match the client configuration. This is not feasible on-the-fly even with xf86-video-dummy, so an improvement in this area is needed - ability to change the resolution, and DPI, on the fly. There also are some tearing issues when using Xpra, because of seemingly incorrect use of VSync. Someone interested in the world of X.org may be interested in this project. All changes will have to be incorporated in upstream X.org.
    89       
    9        Difficulty: hard
    10        Keywords: C, X11, X.org
    11        
    12        2) Automated problem reports
    13        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.
     10       '''Difficulty''': hard\\
     11       '''Keywords''': C, X11, X.org
     12
     13== 2) Automated problem reports ==
     14       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. \\
    1415       This project is about making Xpra easier to debug. Ideas are :
    1516           * Integrate an automated stack trace mechanism
     
    1718           * Allow building of the client with debug symbols
    1819           
    19            Difficulty: medium
    20            Keywords: Python, backtrace, automated bug reporting
    21        3) Android client support
    22        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).
     20           '''Difficulty''': medium\\
     21           '''Keywords''': Python, backtrace, automated bug reporting
     22
     23== 3) Android client support ==
     24       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).\\
    2325       The tasks for Android consist in the following:
    2426           * Support keyboard
     
    2830        The applicant is encouraged to propose implementing support for any other low-power/mobile platform, with an extensive list of tasks to be carried out and prior technical research.
    2931       
    30             Difficulty: Hard
    31             Keywords: Android
    32        4) Wayland
    33        With the advent of Wayland, a modern replacement to X11, the basis of Xpra (the X Composite extension) disappears. Xpra is conceptually a X compositor, and it could be modified to also become a Wayland compositor. This project is about making Xpra Wayland-compatible so that Wayland gets a network "transparency" layer that is efficient.
     32            '''Difficulty''': Hard\\
     33            '''Keywords''': Android
     34
     35== 4) Wayland ==
     36       With the advent of Wayland, a modern replacement to X11, the basis of Xpra (the X Composite extension) disappears. Xpra is conceptually a X compositor, and it could be modified to also become a Wayland compositor. This project is about making Xpra Wayland-compatible so that Wayland gets a network "transparency" layer that is efficient.\\
    3437       Tasks are :
    3538           * Understand Wayland
     
    3740           * Promote the work towards the Wayland community, and submit it for review
    3841           
    39            Difficulty: medium/easy
    40            Keywords: Wayland, compositor, X.org, X11, network transparency
     42           '''Difficulty''': medium/easy\\
     43           '''Keywords''': Wayland, compositor, X.org, X11, network transparency
    4144       
    42        5) Latency improvements through hardware-accelerated video decoding
    43        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.
     45== 5) Latency improvements through hardware-accelerated video decoding ==
     46       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.\\
    4447       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 :
    4548           * Offload video decoding to the GPU through libva
     
    4851           * Do whatever else is necessary to improve latency
    4952           
    50             Difficulty: medium
    51             Keywords: OpenGL, libav, video decoding, Windows, Linux, Python, C
     53            '''Difficulty''': medium\\
     54            '''Keywords''': OpenGL, libav, video decoding, Windows, Linux, Python, C
    5255           
    53        8) Keyboard mapping improvements
    54        The applications running on the server need to receive mouse and keyboard input. It is easy to map the client-side mouse-input to mouse events on the server side, but it's more difficult for the keyboard, because the keyboard mapping on the client side can be different from one client to another (US, french, german, ...). What transits over the wires are keycodes (the physical position of the key on the keyboard), and they are translated back to keysyms (the keymap-dependant symbol produced when the key is pressed) on the server side. Xpra uses obsolete X APIs to do this translation work, and often gets it wrong. In addition, running virtual machines with e.g. VirtualBox inside Xpra adds another layer of keyboard translation, and the end result is often wrong.
     56== 6) Keyboard mapping improvements ==
     57       The applications running on the server need to receive mouse and keyboard input. It is easy to map the client-side mouse-input to mouse events on the server side, but it's more difficult for the keyboard, because the keyboard mapping on the client side can be different from one client to another (US, french, german, ...). What transits over the wires are keycodes (the physical position of the key on the keyboard), and they are translated back to keysyms (the keymap-dependant symbol produced when the key is pressed) on the server side. Xpra uses obsolete X APIs to do this translation work, and often gets it wrong. In addition, running virtual machines with e.g. VirtualBox inside Xpra adds another layer of keyboard translation, and the end result is often wrong.\\
    5558       The tasks for this project are:
    5659           * Learn and understand the X11 keyboard input system (specifically Xkb)
    5760           * Re-implement keyboard mapping logic using Xkb instead of core keyboard API
    5861           
    59            Difficulty: hard
    60            Keywords: Xkb, X11, input, C
     62           '''Difficulty''': hard\\
     63           '''Keywords''': Xkb, X11, input, C
    6164       
    62        9) Encryption
    63        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.
    64        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.
    65        The objective of this project is to implement a secure transport mechanism, based on known good cryptographic algorithms.
     65== 7) Encryption ==
     66       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. \\
     67       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.\\
     68       The objective of this project is to implement a secure transport mechanism, based on known good cryptographic algorithms.\\
    6669       Tasks are:
    6770           * Implement secure key exchange
     
    6972           * Assess performance impact in terms of latency, bandwidth, and CPU requirements
    7073           
    71            Difficulty: Medium, knowledge of good crypto practices
    72            Keywords:  (py)crypto, AES
     74           '''Difficulty''': Medium, knowledge of good crypto practices\\
     75           '''Keywords''':  (py)crypto, AES
    7376           
    74        10) Win32 server (shadow mode)
     77== 8) Win32 server (shadow mode) ==
    7578       
    76        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.
     79       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.\\
    7780       This project is about improving support for Windows-based server, so that it achieves satisfying performance. Tasks would include:
    7881           * Implement screen update detection code so xpra can forward only the parts of the screen that have actually changed (as it does on *nix)
     
    8083           * Rely on benchmarks to assess which improvements to make and
    8184        Applicants are required to have some Windows development experience.
    82            Difficulty: Medium
    83            Keywords:  Windows named pipes, GDI
     85           '''Difficulty''': Medium\\
     86           '''Keywords''':  Windows named pipes, GDI