Changes between Version 11 and Version 12 of ProjectIdeas
- Timestamp:
- 02/25/14 10:53:40 (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ProjectIdeas
v11 v12 1 {{{#!div class="box" 1 2 = Project Ideas = 2 3 … … 10 11 - discuss a project idea with the developers, in order to build your own understanding and goals for this project 11 12 - write the project proposal including several milestones with deliverables and an approximate timeline 13 }}} 12 14 15 {{{#!div class="box" 13 16 == 1) Xorg related improvements: DPI, screens, DRI3K == 14 17 … … 18 21 '''Difficulty''': hard\\ 19 22 '''Keywords''': C, X11, X.org 23 }}} 20 24 25 {{{#!div class="box" 21 26 == 2) Wayland == 22 27 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.\\ … … 28 33 '''Difficulty''': medium/easy\\ 29 34 '''Keywords''': Wayland, compositor, X.org, X11, network transparency 30 35 }}} 31 36 37 {{{#!div class="box" 32 38 == 3) Keyboard mapping improvements == 33 39 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.\\ … … 38 44 '''Difficulty''': hard\\ 39 45 '''Keywords''': Xkb, X11, input, C 40 46 }}} 41 47 42 43 44 45 48 [[BR]] 49 [[BR]] 50 [[BR]] 46 51 47 52 ---- 48 53 49 50 [[BR]]51 54 [[BR]] 52 55 [[BR]] … … 56 59 57 60 61 {{{#!div class="box" 58 62 == 1) Automated problem reports == 59 63 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. \\ … … 65 69 '''Difficulty''': medium\\ 66 70 '''Keywords''': Python, backtrace, automated bug reporting 71 }}} 67 72 68 73 {{{#!div class="box" 69 74 == 2) Android client support == 70 75 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).\\ … … 78 83 '''Difficulty''': Hard\\ 79 84 '''Keywords''': Android 85 }}} 80 86 81 82 87 {{{#!div class="box" 83 88 == 3) Latency improvements through hardware-accelerated video decoding == 84 89 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.\\ … … 91 96 '''Difficulty''': medium\\ 92 97 '''Keywords''': OpenGL, libav, video decoding, Windows, Linux, Python, C 98 }}} 93 99 100 {{{#!div class="box" 94 101 == 4) Encryption == 95 102 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. \\ … … 103 110 '''Difficulty''': Medium, knowledge of good crypto practices\\ 104 111 '''Keywords''': (py)crypto, AES 112 }}} 105 113 114 {{{#!div class="box" 106 115 == 5) Win32 server (shadow mode) == 107 116 … … 114 123 '''Difficulty''': Medium\\ 115 124 '''Keywords''': Windows named pipes, GDI 125 }}}