xpra icon
Bug tracker and wiki

Changes between Version 10 and Version 11 of ProjectIdeas


Ignore:
Timestamp:
02/25/14 10:51:45 (6 years ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProjectIdeas

    v10 v11  
    11= Project Ideas =
    22
    3 '''Warning: this page is out of date...'''
    4 
    5 
    6 [[BR]]
    7 [[BR]]
    8 [[BR]]
    9 [[BR]]
    10 [[BR]]
    11 [[BR]]
    12 [[BR]]
    13 
    14 
    15 
    16        
    173       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.
    184       
     
    2511- write the project proposal including several milestones with deliverables and an approximate timeline
    2612
    27 == 1) Xorg-related improvements ==
     13== 1) Xorg related improvements: DPI, screens, DRI3K ==
    2814
    2915       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.\\
    30        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 ([http://keithp.com/blogs/dri3k_first_steps/ dri3k] may help here). 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.
     16       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 ([http://keithp.com/blogs/dri3k_first_steps/ dri3k] may help here). Someone interested in the world of X.org may be interested in this project.
    3117       
    3218       '''Difficulty''': hard\\
    3319       '''Keywords''': C, X11, X.org
    3420
    35 == 2) Automated problem reports ==
     21== 2) Wayland ==
     22       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.\\
     23       Tasks are :
     24           * Understand Wayland
     25           * Make Xpra behave (optionally and in addition to X11) as a Wayland compositor
     26           * Promote the work towards the Wayland community, and submit it for review
     27           
     28           '''Difficulty''': medium/easy\\
     29           '''Keywords''': Wayland, compositor, X.org, X11, network transparency
     30       
     31
     32== 3) Keyboard mapping improvements ==
     33       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.\\
     34       The tasks for this project are:
     35           * Learn and understand the X11 keyboard input system (specifically Xkb)
     36           * Re-implement keyboard mapping logic using Xkb instead of core keyboard API (probably using the [http://xkbcommon.org/doc/current/ xkbcommon] library)
     37           
     38           '''Difficulty''': hard\\
     39           '''Keywords''': Xkb, X11, input, C
     40       
     41
     42
     43
     44
     45
     46
     47----
     48
     49
     50[[BR]]
     51[[BR]]
     52[[BR]]
     53[[BR]]
     54
     55Non-Xorg related ideas:
     56
     57
     58== 1) Automated problem reports ==
    3659       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. \\
    3760       This project is about making Xpra easier to debug. Ideas are :
     
    4366           '''Keywords''': Python, backtrace, automated bug reporting
    4467
    45 == 3) Android client support ==
     68
     69== 2) Android client support ==
    4670       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).\\
    4771       The tasks for Android consist in the following:
     
    5579            '''Keywords''': Android
    5680
    57 == 4) Wayland ==
    58        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.\\
    59        Tasks are :
    60            * Understand Wayland
    61            * Make Xpra behave (optionally and in addition to X11) as a Wayland compositor
    62            * Promote the work towards the Wayland community, and submit it for review
    63            
    64            '''Difficulty''': medium/easy\\
    65            '''Keywords''': Wayland, compositor, X.org, X11, network transparency
    66        
    67 == 5) Latency improvements through hardware-accelerated video decoding ==
     81
     82
     83== 3) Latency improvements through hardware-accelerated video decoding ==
    6884       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.\\
    6985       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 :
     
    7591            '''Difficulty''': medium\\
    7692            '''Keywords''': OpenGL, libav, video decoding, Windows, Linux, Python, C
    77            
    78 == 6) Keyboard mapping improvements ==
    79        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.\\
    80        The tasks for this project are:
    81            * Learn and understand the X11 keyboard input system (specifically Xkb)
    82            * Re-implement keyboard mapping logic using Xkb instead of core keyboard API (probably using the [http://xkbcommon.org/doc/current/ xkbcommon] library)
    83            
    84            '''Difficulty''': hard\\
    85            '''Keywords''': Xkb, X11, input, C
    86        
    87 == 7) Encryption ==
     93
     94== 4) Encryption ==
    8895       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. \\
    8996       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.\\
     
    96103           '''Difficulty''': Medium, knowledge of good crypto practices\\
    97104           '''Keywords''':  (py)crypto, AES
    98            
    99 == 8) Win32 server (shadow mode) ==
     105
     106== 5) Win32 server (shadow mode) ==
    100107       
    101108       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.\\