xpra icon
Bug tracker and wiki

Changes between Version 27 and Version 28 of ProjectIdeas


Ignore:
Timestamp:
01/21/18 08:14:16 (4 months ago)
Author:
Antoine Martin
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProjectIdeas

    v27 v28  
    1111- contribute at least one patch to the project, that is subsequently committed to the repository
    1212- discuss a project idea with the developers, in order to build your own understanding and goals for this project
    13 
    14 The version of this page which was used for the [https://www.google-melange.com/gsoc/homepage/google/gsoc2014 ​Google Summer of Code 2014] can be found here: [/wiki/ProjectIdeas/2014].
    1513}}}
    1614
    1715{{{#!div class="box"
    18 == 1) Xorg related improvements: {{{RandR}}}, {{{DPI}}}, {{{DRI3K}}} ==
    19 
    20        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.
    21        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.
    22        * 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, see #56.
    23        * 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
    24        * [http://keithp.com/blogs/dri3k_first_steps/ DRI3K] support. Someone interested in the world of X.org may be interested in this project.
    25 
    26        '''Difficulty''': hard\\
    27        '''Keywords''': C, X11, X.org
    28 }}}
    29 
    30 {{{#!div class="box"
    31 == 2) Wayland ==
    32        With the advent of [http://wayland.freedesktop.org/ Wayland], a modern replacement to X11, the basis of Xpra (the X Composite extension) disappears. Xpra is conceptually an 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 with fully open source (aside from the existing Wayland RDP implementation).
     16== 1) Wayland ==
     17       With the advent of [http://wayland.freedesktop.org/ Wayland], a modern replacement for X11, the basis of Xpra (the X Composite extension) disappears. Xpra is conceptually an 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 with fully open source (aside from the existing Wayland RDP and VNC implementations).
    3318       Tasks are :
    3419           * Understand Wayland and its concepts ("surfaces", input devices, etc)
     
    4126
    4227{{{#!div class="box"
    43 == 3) Keyboard mapping improvements ==
    44        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.\\
     28== 2) Keyboard mapping improvements ==
     29       The applications running on the server need to receive mouse and keyboard input. It is easy to map the client-side simple 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 wire 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 sometimes 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.\\
    4530       The tasks for this project are:
    46            * Learn and understand the X11 keyboard input system (specifically {{{Xkb}}} and {{{uinput}}})
     31           * Learn and understand the X11 keyboard input system (specifically {{{Xkb}}})
    4732           * Re-implement keyboard mapping logic using {{{Xkb}}} instead of core keyboard API (probably using the [http://xkbcommon.org/doc/current/ xkbcommon] library), OR:
    48            * Implement input devices in userspace using uinput, see #173
     33           * Possibly re-implement the keyboard input device using uinput, see #173
    4934           
    5035           '''Difficulty''': hard\\
     
    5237}}}
    5338
    54 [[BR]]
    55 
    56 ----
    57 [[BR]]
    58 
    59 Non-Xorg related project ideas:
    60 
    6139
    6240{{{#!div class="box"
    63 == 4) Android client support ==
     41== 3) Android client support ==
    6442       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).\\
    6543       The tasks for Android consist in the following:
     
    6846           * Support video scaling
    6947           * Add any required feature for comfortable, seamless remote desktop
    70         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.
     48        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. An understanding of Android development is a must.
    7149       
    72             '''Difficulty''': Hard\\
     50            '''Difficulty''': Medium\\
    7351            '''Keywords''': Android
    7452}}}
    7553
    7654{{{#!div class="box"
    77 == 5) Latency improvements through hardware-accelerated video decoding ==
    78        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.\\
    79        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. This project is about improving latency of Xpra, with the following tasks :
    80            * Offload video decoding to the GPU through libva
    81            * Make this work on Windows clients as well as Linux clients
    82            * Make this work with OpenGL presentation on the client-side
    83            * Do whatever else is necessary to improve latency
    84            
    85             '''Difficulty''': medium\\
    86             '''Keywords''': OpenGL, libav, video decoding, Windows, Linux, Python, C
     55== 4) Win32 server (shadow mode) ==
     56       
     57       Xpra's client works on many platforms, but the server is only optimized for running on Unix-like operating systems (ie: Linux). The Microsoft Windows version of the server has a lot of room for improvement.
     58       This project is about improving support for Windows-based servers, so that it achieves satisfying usability. Tasks would include:
     59           * system service: the server process currently needs to be started by the logged in user, the screensaver and lock screen also prevent the screen capture, effectively stopping the server - using a system service would allow the server to bypass those restrictions
     60           * keyboard: using native win32 keycodes with win32 clients, rather than coercing the keyboard layer into using X11 keysyms
     61
     62           '''Difficulty''': Medium\\
     63           '''Keywords''': 
    8764}}}
    88 
    89 {{{#!div class="box"
    90 == 6) Win32 server (shadow mode) ==
    91        
    92        Xpra's client works on many platforms, but the server is only optimized for running on Unix-like operating systems (ie: Linux). This means that Xpra can only be used to remotely access a Linux-based desktop. The Microsoft Windows version of the server has a lot of room for improvement. Currently there is preliminary support for this feature but it uses polling which is very inefficient.\\
    93        This project is about improving support for Windows-based server, so that it achieves satisfying performance. Tasks would include:
    94            * Implement screen update detection code so xpra can forward only the parts of the screen that have actually changed (as it does on *nix)
    95            * Implement correct named pipes support code so "xpra info" can be used reliably on win32 servers
    96            * Rely on benchmarks to assess which improvements to make and
    97         Applicants are required to have some Windows development experience.
    98            '''Difficulty''': Medium\\
    99            '''Keywords''':  Windows named pipes, GDI
    100 }}}