From offonoffoffonoff at gmail.com Tue Dec 10 23:18:14 2013 From: offonoffoffonoff at gmail.com (...) Date: Tue, 10 Dec 2013 17:18:14 -0600 Subject: [winswitch] NVENC and xpra Message-ID: Hello, I had some questions about NVENC. Sorry if this information is somewhere already and I didn't find it. Can xpra use a kepler enabled nvidia card to both render graphics (hardware accelerated) and h264 encode them before shipping them off to another display across the network? If not, is this something that some other VNC like program can do? If so, are there any other hardware requirements or issues that I should know about? Would any kepler/NVENC enabled nvidia card be able to do this? Does anyone have any experience with this? Thank you, Elliot From antoine at nagafix.co.uk Wed Dec 11 04:33:07 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 11 Dec 2013 11:33:07 +0700 Subject: [winswitch] NVENC and xpra In-Reply-To: References: Message-ID: <52A7EB03.30708@nagafix.co.uk> On 11/12/13 06:18, ... wrote: > Hello, > > I had some questions about NVENC. Sorry if this information is somewhere > already and I didn't find it. I assume you've already read: http://xpra.org/trac/wiki/Encodings/nvenc > Can xpra use a kepler enabled nvidia card to both render graphics (hardware > accelerated) and h264 encode them before shipping them off to another > display across the network? According to Nvidia: https://developer.nvidia.com/sites/default/files/akamai/cuda/files/CUDADownloads/NVENC_AppNote.pdf "NVIDIA's latest generation of GPUs based on the Kepler architecture, contain a hardware-based H.264 video encoder (henceforth referred to as NVENC). " So, assuming that this is a pro card or that you found a license key (...), yes you can use NVENC with such cards. This answers the second half your question. As for the "render graphics hardware accelerated", it is a little bit more complicated. Based on your description, I assume that the card is not connected to a monitor or that this monitor will not be used for viewing. If that's not the case, the answers below are going to be inadequate. First, you need to define "accelerated": * if you mean OpenGL acceleration - which is often enough, then this will do what you want and is supported: http://www.virtualgl.org/ * if you want to use the regular "nvidia" X11 driver for acceleration directly, there are ways to use a regular X11 server (usually running as root) to replace xpra's Xvfb, you may need to use the " ConnectedMonitor" option if no monitor is attached to the card. This will only work for a single user per card and your mileage may vary: it "should" work. Using "xpra shadow" to copy an existing display is not a good solution at present as it uses polling and will use far too much CPU time - though that could be fixed. The main downside of the current xpra 0.11 code is that it is not really tailored for this Nvidia specific use-case: during screen updates the pixel data will be downloaded from the GPU to the CPU and then uploaded again to the GPU for compression... which is a complete waste of valuable memory bandwidth. It shouldn't be too hard to bypass this unnecessary copying, and if there is enough demand for it then we can certainly look at it. > If not, is this something that some other VNC like program can do? Not as far as I know: xpra is the first, and at present the only open-source software to have NVENC support. > If so, > are there any other hardware requirements or issues that I should know > about? Would any kepler/NVENC enabled nvidia card be able to do this? As per above, with consumer cards (GeForce) you will need to find a license key... I do wonder if some consumer protection law could force Nvidia to provide the keys required to take advantage of the features they advertised when the cards were sold (and earlier SDKs did not require license keys either). As can be seen here in the GTX680 whitepaper: http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf "All Kepler GPUs also incorporate a new hardware-based H.264 video encoder, NVENC. " > Does anyone have any experience with this? Cheers Antoine From offonoffoffonoff at gmail.com Wed Dec 11 21:29:17 2013 From: offonoffoffonoff at gmail.com (...) Date: Wed, 11 Dec 2013 15:29:17 -0600 Subject: [winswitch] NVENC and xpra In-Reply-To: <52A7EB03.30708@nagafix.co.uk> References: <52A7EB03.30708@nagafix.co.uk> Message-ID: Antoine, Great information. Thank you! So, VirtualGL would theoretically work for multiple users per card (multiple applications on multiple displays)? My intention is to be serving modern video games, like Minecraft, League of Legends, etc. I guess I would have to look into if openGL acceleration is all that is needed. I look forward to trying out the virtualGL with my simple setup, and working towards getting having a need for NVENC. -Elliot On Tue, Dec 10, 2013 at 10:33 PM, Antoine Martin wrote: > On 11/12/13 06:18, ... wrote: > > Hello, > > > > I had some questions about NVENC. Sorry if this information is somewhere > > already and I didn't find it. > I assume you've already read: > http://xpra.org/trac/wiki/Encodings/nvenc > > Can xpra use a kepler enabled nvidia card to both render graphics > (hardware > > accelerated) and h264 encode them before shipping them off to another > > display across the network? > According to Nvidia: > > https://developer.nvidia.com/sites/default/files/akamai/cuda/files/CUDADownloads/NVENC_AppNote.pdf > "NVIDIA's latest generation of GPUs based on the Kepler architecture, > contain a > hardware-based H.264 video encoder (henceforth referred to as NVENC). " > So, assuming that this is a pro card or that you found a license key > (...), yes you can use NVENC with such cards. > This answers the second half your question. > > > As for the "render graphics hardware accelerated", it is a little bit > more complicated. Based on your description, I assume that the card is > not connected to a monitor or that this monitor will not be used for > viewing. If that's not the case, the answers below are going to be > inadequate. > > First, you need to define "accelerated": > * if you mean OpenGL acceleration - which is often enough, then this > will do what you want and is supported: > http://www.virtualgl.org/ > * if you want to use the regular "nvidia" X11 driver for acceleration > directly, there are ways to use a regular X11 server (usually running as > root) to replace xpra's Xvfb, you may need to use the " > ConnectedMonitor" option if no monitor is attached to the card. This > will only work for a single user per card and your mileage may vary: it > "should" work. > Using "xpra shadow" to copy an existing display is not a good solution > at present as it uses polling and will use far too much CPU time - > though that could be fixed. > > The main downside of the current xpra 0.11 code is that it is not really > tailored for this Nvidia specific use-case: during screen updates the > pixel data will be downloaded from the GPU to the CPU and then uploaded > again to the GPU for compression... which is a complete waste of > valuable memory bandwidth. It shouldn't be too hard to bypass this > unnecessary copying, and if there is enough demand for it then we can > certainly look at it. > > If not, is this something that some other VNC like program can do? > Not as far as I know: xpra is the first, and at present the only > open-source software to have NVENC support. > > If so, > > are there any other hardware requirements or issues that I should know > > about? Would any kepler/NVENC enabled nvidia card be able to do this? > As per above, with consumer cards (GeForce) you will need to find a > license key... > > I do wonder if some consumer protection law could force Nvidia to > provide the keys required to take advantage of the features they > advertised when the cards were sold (and earlier SDKs did not require > license keys either). > As can be seen here in the GTX680 whitepaper: > > http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf > "All Kepler GPUs also incorporate a new hardware-based H.264 video > encoder, NVENC. " > > Does anyone have any experience with this? > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From offonoffoffonoff at gmail.com Thu Dec 12 04:05:03 2013 From: offonoffoffonoff at gmail.com (...) Date: Wed, 11 Dec 2013 22:05:03 -0600 Subject: [winswitch] NVENC and xpra In-Reply-To: References: <52A7EB03.30708@nagafix.co.uk> Message-ID: Hello, I answered my own question faster than expected. I have an optimus enabled laptop and run bumblebee to access my nvidia GPU. I successfully ran two accelerated instances of glxspheres through xpra on my local machine. I'll try this over a network with a thin client tomorrow. As far as patching up the data bouncing back and forth between GPU and CPU for render and NVENC, I think I know someone who would be able to provide sufficient demand for this. Would a donation to the project cause this issue to get fixed? Do you have a rough idea of what it would take? Thanks for the great work, Elliot =================== Exactly what I did is this: on server: >xpra start :100 >xpra start :110 >DISPLAY=:100 optirun glxspheres >DISPLAY=:110 optirun glxgears On client (another terminal on same laptop): >xpra attach :100 on another terminal: >xpra attach :110 glxspheres ran at 80-90 fps instead of 120 with two instances going, but one running through xpra was just as fast as no xpra. On Wed, Dec 11, 2013 at 3:29 PM, ... wrote: > Antoine, > > Great information. Thank you! > > So, VirtualGL would theoretically work for multiple users per card > (multiple applications on multiple displays)? > > My intention is to be serving modern video games, like Minecraft, League > of Legends, etc. I guess I would have to look into if openGL acceleration > is all that is needed. > > I look forward to trying out the virtualGL with my simple setup, and > working towards getting having a need for NVENC. > > -Elliot > > > > > On Tue, Dec 10, 2013 at 10:33 PM, Antoine Martin wrote: > >> On 11/12/13 06:18, ... wrote: >> > Hello, >> > >> > I had some questions about NVENC. Sorry if this information is >> somewhere >> > already and I didn't find it. >> I assume you've already read: >> http://xpra.org/trac/wiki/Encodings/nvenc >> > Can xpra use a kepler enabled nvidia card to both render graphics >> (hardware >> > accelerated) and h264 encode them before shipping them off to another >> > display across the network? >> According to Nvidia: >> >> https://developer.nvidia.com/sites/default/files/akamai/cuda/files/CUDADownloads/NVENC_AppNote.pdf >> "NVIDIA's latest generation of GPUs based on the Kepler architecture, >> contain a >> hardware-based H.264 video encoder (henceforth referred to as NVENC). " >> So, assuming that this is a pro card or that you found a license key >> (...), yes you can use NVENC with such cards. >> This answers the second half your question. >> >> >> As for the "render graphics hardware accelerated", it is a little bit >> more complicated. Based on your description, I assume that the card is >> not connected to a monitor or that this monitor will not be used for >> viewing. If that's not the case, the answers below are going to be >> inadequate. >> >> First, you need to define "accelerated": >> * if you mean OpenGL acceleration - which is often enough, then this >> will do what you want and is supported: >> http://www.virtualgl.org/ >> * if you want to use the regular "nvidia" X11 driver for acceleration >> directly, there are ways to use a regular X11 server (usually running as >> root) to replace xpra's Xvfb, you may need to use the " >> ConnectedMonitor" option if no monitor is attached to the card. This >> will only work for a single user per card and your mileage may vary: it >> "should" work. >> Using "xpra shadow" to copy an existing display is not a good solution >> at present as it uses polling and will use far too much CPU time - >> though that could be fixed. >> >> The main downside of the current xpra 0.11 code is that it is not really >> tailored for this Nvidia specific use-case: during screen updates the >> pixel data will be downloaded from the GPU to the CPU and then uploaded >> again to the GPU for compression... which is a complete waste of >> valuable memory bandwidth. It shouldn't be too hard to bypass this >> unnecessary copying, and if there is enough demand for it then we can >> certainly look at it. >> > If not, is this something that some other VNC like program can do? >> Not as far as I know: xpra is the first, and at present the only >> open-source software to have NVENC support. >> > If so, >> > are there any other hardware requirements or issues that I should know >> > about? Would any kepler/NVENC enabled nvidia card be able to do this? >> As per above, with consumer cards (GeForce) you will need to find a >> license key... >> >> I do wonder if some consumer protection law could force Nvidia to >> provide the keys required to take advantage of the features they >> advertised when the cards were sold (and earlier SDKs did not require >> license keys either). >> As can be seen here in the GTX680 whitepaper: >> >> http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf >> "All Kepler GPUs also incorporate a new hardware-based H.264 video >> encoder, NVENC. " >> > Does anyone have any experience with this? >> >> Cheers >> Antoine >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > > From antoine at nagafix.co.uk Thu Dec 12 05:58:18 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 12 Dec 2013 12:58:18 +0700 Subject: [winswitch] NVENC and xpra In-Reply-To: References: <52A7EB03.30708@nagafix.co.uk> Message-ID: <52A9507A.7050704@nagafix.co.uk> On 12/12/13 04:29, ... wrote: > Antoine, > > Great information. Thank you! > > So, VirtualGL would theoretically work for multiple users per card > (multiple applications on multiple displays)? Yes. > My intention is to be serving modern video games, like Minecraft, League of > Legends, etc. I guess I would have to look into if openGL acceleration is > all that is needed. OpenGL is enough for games on Linux. The next problems you are likely to hit are: * screen resizing: games usually resize the screen to a lower resolution to be able to sustain a decent framerate. At present xpra makes the Xvfb server match the client's resolution - which is not what you want. You want the whole display as a window. You could run Xephyr or Xnest as an xpra child, and run the game from within that nested X11 server. Worth a try. Another way would be to modify xpra to add the ability to export the whole display as a window - not sure it would make much difference. * keyboard and mouse synchronization: http://xpra.org/trac/ticket/137 " games rely on precise mouse movements and their timing" Summary: network latency and mouse movements/acceleration are unlikely to get on well... Antoine > I look forward to trying out the virtualGL with my simple setup, and > working towards getting having a need for NVENC. > > -Elliot > > > > > On Tue, Dec 10, 2013 at 10:33 PM, Antoine Martin wrote: > >> On 11/12/13 06:18, ... wrote: >>> Hello, >>> >>> I had some questions about NVENC. Sorry if this information is somewhere >>> already and I didn't find it. >> I assume you've already read: >> http://xpra.org/trac/wiki/Encodings/nvenc >>> Can xpra use a kepler enabled nvidia card to both render graphics >> (hardware >>> accelerated) and h264 encode them before shipping them off to another >>> display across the network? >> According to Nvidia: >> >> https://developer.nvidia.com/sites/default/files/akamai/cuda/files/CUDADownloads/NVENC_AppNote.pdf >> "NVIDIA's latest generation of GPUs based on the Kepler architecture, >> contain a >> hardware-based H.264 video encoder (henceforth referred to as NVENC). " >> So, assuming that this is a pro card or that you found a license key >> (...), yes you can use NVENC with such cards. >> This answers the second half your question. >> >> >> As for the "render graphics hardware accelerated", it is a little bit >> more complicated. Based on your description, I assume that the card is >> not connected to a monitor or that this monitor will not be used for >> viewing. If that's not the case, the answers below are going to be >> inadequate. >> >> First, you need to define "accelerated": >> * if you mean OpenGL acceleration - which is often enough, then this >> will do what you want and is supported: >> http://www.virtualgl.org/ >> * if you want to use the regular "nvidia" X11 driver for acceleration >> directly, there are ways to use a regular X11 server (usually running as >> root) to replace xpra's Xvfb, you may need to use the " >> ConnectedMonitor" option if no monitor is attached to the card. This >> will only work for a single user per card and your mileage may vary: it >> "should" work. >> Using "xpra shadow" to copy an existing display is not a good solution >> at present as it uses polling and will use far too much CPU time - >> though that could be fixed. >> >> The main downside of the current xpra 0.11 code is that it is not really >> tailored for this Nvidia specific use-case: during screen updates the >> pixel data will be downloaded from the GPU to the CPU and then uploaded >> again to the GPU for compression... which is a complete waste of >> valuable memory bandwidth. It shouldn't be too hard to bypass this >> unnecessary copying, and if there is enough demand for it then we can >> certainly look at it. >>> If not, is this something that some other VNC like program can do? >> Not as far as I know: xpra is the first, and at present the only >> open-source software to have NVENC support. >>> If so, >>> are there any other hardware requirements or issues that I should know >>> about? Would any kepler/NVENC enabled nvidia card be able to do this? >> As per above, with consumer cards (GeForce) you will need to find a >> license key... >> >> I do wonder if some consumer protection law could force Nvidia to >> provide the keys required to take advantage of the features they >> advertised when the cards were sold (and earlier SDKs did not require >> license keys either). >> As can be seen here in the GTX680 whitepaper: >> >> http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf >> "All Kepler GPUs also incorporate a new hardware-based H.264 video >> encoder, NVENC. " >>> Does anyone have any experience with this? >> Cheers >> Antoine >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Thu Dec 12 06:43:13 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 12 Dec 2013 13:43:13 +0700 Subject: [winswitch] NVENC and xpra In-Reply-To: References: <52A7EB03.30708@nagafix.co.uk> Message-ID: <52A95B01.3020403@nagafix.co.uk> On 12/12/13 11:05, ... wrote: > Hello, > > I answered my own question faster than expected. I have an optimus enabled > laptop and run bumblebee to access my nvidia GPU. I successfully ran two > accelerated instances of glxspheres through xpra on my local machine. I'll > try this over a network with a thin client tomorrow. > > As far as patching up the data bouncing back and forth between GPU and CPU > for render and NVENC, I think I know someone who would be able to provide > sufficient demand for this. Would a donation to the project cause this > issue to get fixed? I am not certain that I have both the skills and the time required to succeed.. > Do you have a rough idea of what it would take? I have added some information to the existing ticket: http://xpra.org/trac/ticket/365 Antoine > > Thanks for the great work, > Elliot > > =================== > > Exactly what I did is this: > > on server: >> xpra start :100 >> xpra start :110 >> DISPLAY=:100 optirun glxspheres >> DISPLAY=:110 optirun glxgears > On client (another terminal on same laptop): >> xpra attach :100 > on another terminal: >> xpra attach :110 > glxspheres ran at 80-90 fps instead of 120 with two instances going, but > one running through xpra was just as fast as no xpra. > > > > > > On Wed, Dec 11, 2013 at 3:29 PM, ... wrote: > >> Antoine, >> >> Great information. Thank you! >> >> So, VirtualGL would theoretically work for multiple users per card >> (multiple applications on multiple displays)? >> >> My intention is to be serving modern video games, like Minecraft, League >> of Legends, etc. I guess I would have to look into if openGL acceleration >> is all that is needed. >> >> I look forward to trying out the virtualGL with my simple setup, and >> working towards getting having a need for NVENC. >> >> -Elliot >> >> >> >> >> On Tue, Dec 10, 2013 at 10:33 PM, Antoine Martin wrote: >> >>> On 11/12/13 06:18, ... wrote: >>>> Hello, >>>> >>>> I had some questions about NVENC. Sorry if this information is >>> somewhere >>>> already and I didn't find it. >>> I assume you've already read: >>> http://xpra.org/trac/wiki/Encodings/nvenc >>>> Can xpra use a kepler enabled nvidia card to both render graphics >>> (hardware >>>> accelerated) and h264 encode them before shipping them off to another >>>> display across the network? >>> According to Nvidia: >>> >>> https://developer.nvidia.com/sites/default/files/akamai/cuda/files/CUDADownloads/NVENC_AppNote.pdf >>> "NVIDIA's latest generation of GPUs based on the Kepler architecture, >>> contain a >>> hardware-based H.264 video encoder (henceforth referred to as NVENC). " >>> So, assuming that this is a pro card or that you found a license key >>> (...), yes you can use NVENC with such cards. >>> This answers the second half your question. >>> >>> >>> As for the "render graphics hardware accelerated", it is a little bit >>> more complicated. Based on your description, I assume that the card is >>> not connected to a monitor or that this monitor will not be used for >>> viewing. If that's not the case, the answers below are going to be >>> inadequate. >>> >>> First, you need to define "accelerated": >>> * if you mean OpenGL acceleration - which is often enough, then this >>> will do what you want and is supported: >>> http://www.virtualgl.org/ >>> * if you want to use the regular "nvidia" X11 driver for acceleration >>> directly, there are ways to use a regular X11 server (usually running as >>> root) to replace xpra's Xvfb, you may need to use the " >>> ConnectedMonitor" option if no monitor is attached to the card. This >>> will only work for a single user per card and your mileage may vary: it >>> "should" work. >>> Using "xpra shadow" to copy an existing display is not a good solution >>> at present as it uses polling and will use far too much CPU time - >>> though that could be fixed. >>> >>> The main downside of the current xpra 0.11 code is that it is not really >>> tailored for this Nvidia specific use-case: during screen updates the >>> pixel data will be downloaded from the GPU to the CPU and then uploaded >>> again to the GPU for compression... which is a complete waste of >>> valuable memory bandwidth. It shouldn't be too hard to bypass this >>> unnecessary copying, and if there is enough demand for it then we can >>> certainly look at it. >>>> If not, is this something that some other VNC like program can do? >>> Not as far as I know: xpra is the first, and at present the only >>> open-source software to have NVENC support. >>>> If so, >>>> are there any other hardware requirements or issues that I should know >>>> about? Would any kepler/NVENC enabled nvidia card be able to do this? >>> As per above, with consumer cards (GeForce) you will need to find a >>> license key... >>> >>> I do wonder if some consumer protection law could force Nvidia to >>> provide the keys required to take advantage of the features they >>> advertised when the cards were sold (and earlier SDKs did not require >>> license keys either). >>> As can be seen here in the GTX680 whitepaper: >>> >>> http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf >>> "All Kepler GPUs also incorporate a new hardware-based H.264 video >>> encoder, NVENC. " >>>> Does anyone have any experience with this? >>> Cheers >>> Antoine >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From brian.kihoon.lee at gmail.com Thu Dec 12 21:41:17 2013 From: brian.kihoon.lee at gmail.com (Brian Lee) Date: Thu, 12 Dec 2013 16:41:17 -0500 Subject: [winswitch] Detecting display resolution and fullscreen applications? Message-ID: I'm working on an application where people can start playing youtube videos [on firefox] on a machine with several attached displays, and I'm trying to use xpra to switch the firefox window around. Xpra is working just fine - the firefox window shows up and I can detach and reattach displays just fine, but the issue is that the window they appear in random window sizes and additionally, hitting the fullscreen button doesn't work properly. Any tips / hints as to fixing these issues? Thanks, Brian From offonoffoffonoff at gmail.com Fri Dec 13 04:59:37 2013 From: offonoffoffonoff at gmail.com (...) Date: Thu, 12 Dec 2013 22:59:37 -0600 Subject: [winswitch] games rely on precise mouse movements Message-ID: https://www.xpra.org/trac/ticket/137 I was just looking through this. I like the tablet idea, well for tablets. I'd love to see games through xpra on a linux tablet, if not android. As for actual mouse movements, I don't know squat about how things are working, but the thought I had on seeing this is having python or cython doing interpolation between mouse positions on the server (client?) side, simulating the acceleration that the game is going to try and do anyway. Has that been considered / is it workable? -Elliot From antoine at nagafix.co.uk Fri Dec 13 05:12:43 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 13 Dec 2013 12:12:43 +0700 Subject: [winswitch] Detecting display resolution and fullscreen applications? In-Reply-To: References: Message-ID: <52AA974B.8090606@nagafix.co.uk> On 13/12/13 04:41, Brian Lee wrote: > I'm working on an application where people can start playing youtube videos > [on firefox] on a machine with several attached displays, and I'm trying to > use xpra to switch the firefox window around. > > Xpra is working just fine - the firefox window shows up and I can detach > and reattach displays just fine, but the issue is that the window they > appear in random window sizes You mean a different size for each client? That would be a bug. If so, it is surprising that no-one has seen that before. > and additionally, hitting the fullscreen > button doesn't work properly. Define "doesn't work properly". > Any tips / hints as to fixing these issues? If I can reproduce them, maybe I can fix them. Cheers Antoine From antoine at nagafix.co.uk Fri Dec 13 05:25:46 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 13 Dec 2013 12:25:46 +0700 Subject: [winswitch] games rely on precise mouse movements In-Reply-To: References: Message-ID: <52AA9A5A.1060700@nagafix.co.uk> On 13/12/13 11:59, ... wrote: > https://www.xpra.org/trac/ticket/137 > > I was just looking through this. I like the tablet idea, well for tablets. > I'd love to see games through xpra on a linux tablet, if not android. The android client needs work and doesn't even handle keyboard input at all, and mouse only just. > As for actual mouse movements, I don't know squat about how things are > working, but the thought I had on seeing this is having python or cython The choice of language wouldn't really matter. > doing interpolation between mouse positions on the server (client?) side, > simulating the acceleration that the game is going to try and do anyway. > > Has that been considered / is it workable? I don't think that this would improve things, only make things more complicated. We already have the mouse events that the application should be receiving, those are the events we receive client side. No need to interpolate anything. Adding the option to send all mouse events (and not just the last one we find time to send as we do at present) would be trivial to implement, the extra bandwidth costs should be immaterial if you are targeting gaming. The difficulty is in delivering the events to the remote application with the same exact gap between them as they had when we received them. This could probably be solved by artificially delaying *all* mouse events by a delay (based on the network jitter) that restores the original gap. Antoine From offonoffoffonoff at gmail.com Fri Dec 13 05:50:51 2013 From: offonoffoffonoff at gmail.com (...) Date: Thu, 12 Dec 2013 23:50:51 -0600 Subject: [winswitch] games rely on precise mouse movements In-Reply-To: <52AA9A5A.1060700@nagafix.co.uk> References: <52AA9A5A.1060700@nagafix.co.uk> Message-ID: makes sense. its the timing and not the number of events. On Thu, Dec 12, 2013 at 11:25 PM, Antoine Martin wrote: > On 13/12/13 11:59, ... wrote: > > https://www.xpra.org/trac/ticket/137 > > > > I was just looking through this. I like the tablet idea, well for > tablets. > > I'd love to see games through xpra on a linux tablet, if not android. > The android client needs work and doesn't even handle keyboard input at > all, and mouse only just. > > As for actual mouse movements, I don't know squat about how things are > > working, but the thought I had on seeing this is having python or cython > The choice of language wouldn't really matter. > > doing interpolation between mouse positions on the server (client?) side, > > simulating the acceleration that the game is going to try and do anyway. > > > > Has that been considered / is it workable? > I don't think that this would improve things, only make things more > complicated. > We already have the mouse events that the application should be > receiving, those are the events we receive client side. No need to > interpolate anything. > Adding the option to send all mouse events (and not just the last one we > find time to send as we do at present) would be trivial to implement, > the extra bandwidth costs should be immaterial if you are targeting gaming. > The difficulty is in delivering the events to the remote application > with the same exact gap between them as they had when we received them. > This could probably be solved by artificially delaying *all* mouse > events by a delay (based on the network jitter) that restores the > original gap. > > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From offonoffoffonoff at gmail.com Fri Dec 13 05:54:08 2013 From: offonoffoffonoff at gmail.com (...) Date: Thu, 12 Dec 2013 23:54:08 -0600 Subject: [winswitch] NVENC and xpra In-Reply-To: <52AA96A2.7000301@nagafix.co.uk> References: <52A7EB03.30708@nagafix.co.uk> <52A95B01.3020403@nagafix.co.uk> <52AA96A2.7000301@nagafix.co.uk> Message-ID: Over the network (ssh), glxspheres was very aliased (as in missing frames made it look like the spheres were moving erratically). > What encoding are you using? z = 1 and RGB seems to work the best. Obviously producing 1,000 fps would produce such aliasing. glxspheresd was a bad test. With the wine game, still only 8 fps maybe with the best options I found and awkward mouse. I'll experiment with a better client and see how that fares. On Thu, Dec 12, 2013 at 11:09 PM, Antoine Martin wrote: > On 13/12/13 06:10, ... wrote: > > Over the network (ssh), glxspheres was very aliased (as in missing > frames made it look like the spheres were moving erratically). > > What encoding are you using? > > Warcraft III running through wine over the network ran in fullscreen on > the client, though fonts were too small, but you are right, the mouse is > super laggy. Also, the graphics were laggy I'm sure due to network latency > and the client being too slow at video decompression. The client is an old > Pentium 4. > > Decoding side we don't use any acceleration yet, that's a low priority as > most CPUs can decode h264 cheaply enough. A Pentium 4 however... > > Looks like tuning network usage and compression requirements is the > next thing to look at. > > All of this should be self tuning and you are unlikely to find a magic > bullet here. > > If you are on a LAN, consider using "RGB" encoding and latest trunk: > http://xpra.org/trac/wiki/Encodings#ChoosinganEncoding > You can find some more background on the wiki: > http://xpra.org/trac/wiki/WindowRefresh > > Cheers > Antoine > From antoine at nagafix.co.uk Fri Dec 13 06:04:02 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 13 Dec 2013 13:04:02 +0700 Subject: [winswitch] NVENC and xpra In-Reply-To: References: <52A7EB03.30708@nagafix.co.uk> <52A95B01.3020403@nagafix.co.uk> Message-ID: <52AAA352.9000607@nagafix.co.uk> On 13/12/13 06:10, ... wrote: > Over the network (ssh), glxspheres was very aliased (as in missing > frames made it look like the spheres were moving erratically). What encoding are you using? > Warcraft III running through wine over the network ran in fullscreen > on the client, though fonts were too small, but you are right, the > mouse is super laggy. Also, the graphics were laggy I'm sure due to > network latency and the client being too slow at video decompression. > The client is an old Pentium 4. Decoding side we don't use any acceleration yet, that's a low priority as most CPUs can decode h264 cheaply enough. A Pentium 4 however... > Looks like tuning network usage and compression requirements is the > next thing to look at. All of this should be self tuning and you are unlikely to find a magic bullet here. If you are on a LAN, consider using "RGB" encoding and latest trunk: http://xpra.org/trac/wiki/Encodings#ChoosinganEncoding You can find some more background on the wiki: http://xpra.org/trac/wiki/WindowRefresh Cheers Antoine From antoine at nagafix.co.uk Thu Dec 19 11:25:18 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 19 Dec 2013 18:25:18 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.10.10 (critical fixes) Message-ID: <52B2D79E.6000505@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This version fixes a large number of bugs, many of which are critical: crashes, leaks, etc. It also adds support for ffmpeg2 (as found in Fedora 20) and fixes a number of compatibility issues uncovered during the testing of the 0.11 beta. I am hoping that this will be the last release from the 0.10.x branch, which is why I delayed it for so long. v0.11.0 will be ready "Real-Soon-Now"(tm), I think it is worth the wait. Note: the binaries in the repository disable h264 decoding for Ubuntu 12.x and Debian Wheezy because the version of libav in these distributions does not seem stable enough. The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Beta: https://xpra.org/beta/ Cheers Antoine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKy15oACgkQGK2zHPGK1rv3UACfeRtW6geie/oovKX8eK1Ay/VG L4IAnjSO/CAaxqLId4xjqE6ol3pveSIx =ofbi -----END PGP SIGNATURE----- From ndbecker2 at gmail.com Mon Dec 23 18:33:05 2013 From: ndbecker2 at gmail.com (Neal Becker) Date: Mon, 23 Dec 2013 13:33:05 -0500 Subject: [winswitch] setting for low-latency? Message-ID: I'm using xpra/winswitch over a very high bandwidth/low latency connection. I'm annoyed by the delay in response to typing. What settings would minimize this? From antoine at nagafix.co.uk Tue Dec 24 05:53:40 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 24 Dec 2013 12:53:40 +0700 Subject: [winswitch] setting for low-latency? In-Reply-To: References: Message-ID: <52B92164.9070207@nagafix.co.uk> On 24/12/13 01:33, Neal Becker wrote: > I'm using xpra/winswitch over a very high bandwidth/low latency connection. > I'm annoyed by the delay in response to typing. What settings would > minimize this? With a high bandwidth/low latency connection, you should not be seeing any noticeable delay. This sounds like a bug or a misconfiguration. First, make sure you are using the best encoding for your setup: http://xpra.org/trac/wiki/Encodings#ChoosinganEncoding Then have a look at your session information to figure out where the latency is coming from. (even more details in "xpra info") In, v0.11 there is graph showing you precisely where latency is coming from. I cannot give you more precise information than this without knowing more about the application, "xpra info" output, etc. But the wiki has lots of pointers: http://xpra.org/trac/wiki/WindowRefresh#Debugging Cheers Antoine