From chaosape at gmail.com Mon Nov 2 13:02:13 2015 From: chaosape at gmail.com (Dan DaCosta) Date: Mon, 2 Nov 2015 07:02:13 -0600 Subject: [winswitch] A Hopefully Quick Question About Xpra. Message-ID: Xpra Experts: I have hacked a little code into Xpra that takes screenshots of all windows managed by Xpra and stores them locally as files. Specifically, I accomplished this by adding a bit of code to the x11/server.py file. It is nothing pretty; I was just interested in doing a little experimentation. I have two issues that seemingly should be easy to fix but I have yet to figure out how to hack around them: 1) The server seems to be ignorant of any window pixmaps until the first client attaches. Specifically, from my naive perspective, it seems like Xpra cannot find the pixmap for any windows until the first attachment. 2) If, after an initial attach there are no attached clients, I can get access to the window pixmaps but they are not updated unless someone is attached, i.e, they remain in the same state as the last time there was an attachment. Conceptually, it makes sense to avoid updating the pixmaps if no one is attached but, for the life of me, I cannot find the switch that turns pixmap updating on/off according to whether a client is attached or not. Thanks in Advance! Dan DaCosta From adarrab at gmail.com Mon Nov 2 18:47:20 2015 From: adarrab at gmail.com (Abdulaziz M. Aldarrab) Date: Mon, 2 Nov 2015 21:47:20 +0300 Subject: [winswitch] Xpra Client in Listen Mode Enquiry In-Reply-To: <563463FC.6070307@nagafix.co.uk> References: <6567AF5B-1341-4A8C-BD80-06864913EB5B@gmail.com> <563463FC.6070307@nagafix.co.uk> Message-ID: <001301d1159e$e8ac5840$ba0508c0$@gmail.com> Well, the load balancer (running on Linux) dispatches GUI job, which may or may not start immediately depending on the resources requested. It is part of a medium size grid that has both visualization and compute nodes, and unfortunately a simple load balancer gimme-host.sh kinda script won't work. Theoretically, I could have an agent that monitors the job state, then invokes xpra client once a job in running state, but that would still be buggy with unnecessary delays. I'm not familiar with Xpra proxy server (yet) but I would imagine it might complicate things. It would be nice to have those two additional options (--listen, --client) e.g. Xpra_cmd.exe attach [ssh/tcp]: EMPTY --listen=[IP:PORT] (Waits for server ready msg, with optional timeout. IP is provided in case a machine has more than 1 active address, otherwise not needed) xpra --start :XX --start-child=CMD --client=IP:PORT So once server is initiated successfully, it sends a triggering tcp message to the client containing USER at SERVER :XX to be used by the client to initiate ssh/tcp connection. This "could" be a security hazard where a bad guy broadcasts a trigger message to clients to connect to a malicious server, but I guess client won't connect to a server initiated by another user. I'm thinking of modifying Xpra in case you don't see this option in your plans, where would be the best place to start in the source code? I'm a C++ developer, familiar with sockets, and I can read python :) Thanks, Abdulaziz -----Original Message----- From: shifter-users [mailto:shifter-users-bounces at lists.devloop.org.uk] On Behalf Of Antoine Martin Sent: Saturday, October 31, 2015 9:47 AM To: shifter-users at lists.devloop.org.uk Subject: Re: [winswitch] Xpra Client in Listen Mode Enquiry On 28/10/15 17:54, Abdulaziz Aldarrab wrote: > Good day, > > Current scenario, I have set of Linux servers to run applications on. The clients, Windows machines using Exceed (running in passive mode). Clients launch an application using an application launcher that: ssh Linux master node, then ?qsub? use a schedule (UGE, PBS...etc.) to submit a job which will be allocated an appropriate machine based on the resources requested. The submission script is nothing more than setenv DISPLAY to windows client & application execution script. > > With Xpra, I couldn?t figure out a similar operation mode, where the windows client listens for connections coming from the Linux host as soon as the application starts remotely. There is no passive mode, and none is planned. Since you are running the script from the windows box, can't you just have your script tell the windows box where to connect? Something like: HOST=`ssh LOADBALANCER gimme-host.sh` xpra attach ssh:$HOST (converting this shell example into the horrible win32 batch file format left as an exercise) Or you could extend the proxy server to deal with this load balancing. The proxy server can use a simple text file to associate client connections with their final server destination. As long as you update this file, the client only needs to connect to the proxy server. Cheers Antoine > > Any hint would be really appreciated, > > Thank you, > Abdulaziz > _______________________________________________ > 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 Tue Nov 3 04:51:49 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 3 Nov 2015 11:51:49 +0700 Subject: [winswitch] Xpra Client in Listen Mode Enquiry In-Reply-To: <001301d1159e$e8ac5840$ba0508c0$@gmail.com> References: <6567AF5B-1341-4A8C-BD80-06864913EB5B@gmail.com> <563463FC.6070307@nagafix.co.uk> <001301d1159e$e8ac5840$ba0508c0$@gmail.com> Message-ID: <56383D65.4030709@nagafix.co.uk> On 03/11/15 01:47, Abdulaziz M. Aldarrab wrote: > Well, the load balancer (running on Linux) dispatches GUI job, which may or may not start immediately depending on the resources requested. It is part of a medium size grid that has both visualization and compute nodes, and unfortunately a simple load balancer gimme-host.sh kinda script won't work. Theoretically, I could have an agent that monitors the job state, then invokes xpra client once a job in running state, but that would still be buggy with unnecessary delays. > > I'm not familiar with Xpra proxy server (yet) but I would imagine it might complicate things. > > It would be nice to have those two additional options (--listen, --client) e.g. > Xpra_cmd.exe attach [ssh/tcp]: EMPTY --listen=[IP:PORT] (Waits for server ready msg, with optional timeout. IP is provided in case a machine has more than 1 active address, otherwise not needed) Or maybe even: xpra listen tcp:IP:port > xpra --start :XX --start-child=CMD --client=IP:PORT > > So once server is initiated successfully, it sends a triggering tcp message to the client containing USER at SERVER :XX to be used by the client to initiate ssh/tcp connection. This "could" be a security hazard where a bad guy broadcasts a trigger message to clients to connect to a malicious server, but I guess client won't connect to a server initiated by another user. If you use authentication and encryption, this can be made secure. For this use case, we may want to authenticate the server rather than the other way around. > I'm thinking of modifying Xpra in case you don't see this option in your plans, where would be the best place to start in the source code? I'm a C++ developer, familiar with sockets, and I can read python :) The best place to start is usually through a ticket. Another benefit of this listen option is that you can have servers that are NATed, unreachable from regular clients, since they will be the ones initiating the connection. Cheers Antoine > > Thanks, > Abdulaziz > > -----Original Message----- > From: shifter-users [mailto:shifter-users-bounces at lists.devloop.org.uk] On Behalf Of Antoine Martin > Sent: Saturday, October 31, 2015 9:47 AM > To: shifter-users at lists.devloop.org.uk > Subject: Re: [winswitch] Xpra Client in Listen Mode Enquiry > > On 28/10/15 17:54, Abdulaziz Aldarrab wrote: >> Good day, >> >> Current scenario, I have set of Linux servers to run applications on. The clients, Windows machines using Exceed (running in passive mode). Clients launch an application using an application launcher that: ssh Linux master node, then ?qsub? use a schedule (UGE, PBS...etc.) to submit a job which will be allocated an appropriate machine based on the resources requested. The submission script is nothing more than setenv DISPLAY to windows client & application execution script. >> >> With Xpra, I couldn?t figure out a similar operation mode, where the windows client listens for connections coming from the Linux host as soon as the application starts remotely. > There is no passive mode, and none is planned. > > Since you are running the script from the windows box, can't you just have your script tell the windows box where to connect? > Something like: > HOST=`ssh LOADBALANCER gimme-host.sh` > xpra attach ssh:$HOST > (converting this shell example into the horrible win32 batch file format left as an exercise) > > Or you could extend the proxy server to deal with this load balancing. > The proxy server can use a simple text file to associate client connections with their final server destination. As long as you update this file, the client only needs to connect to the proxy server. > > Cheers > Antoine >> >> Any hint would be really appreciated, >> >> Thank you, >> Abdulaziz >> _______________________________________________ >> 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 Tue Nov 3 15:57:30 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 3 Nov 2015 22:57:30 +0700 Subject: [winswitch] A Hopefully Quick Question About Xpra. In-Reply-To: References: Message-ID: <5638D96A.6090704@nagafix.co.uk> On 02/11/15 20:02, Dan DaCosta wrote: > Xpra Experts: > > I have hacked a little code into Xpra that takes screenshots of all windows > managed by Xpra and stores them locally as files. Specifically, I > accomplished this by adding a bit of code to the x11/server.py file. It is > nothing pretty; Can you post this code? We now have code that achieves something similar in trunk: http://xpra.org/trac/ticket/988 > I was just interested in doing a little experimentation. I > have two issues that seemingly should be easy to fix but I have yet to > figure out how to hack around them: > 1) The server seems to be ignorant of any window pixmaps until the first > client attaches. Specifically, from my naive perspective, it seems like > Xpra cannot find the pixmap for any windows until the first attachment. Windows are not mapped onto the virtual screen until a client maps them somewhere on their desktop. And unmapped windows do not have pixmaps.. > 2) If, after an initial attach there are no attached clients, I can get > access to the window pixmaps but they are not updated unless someone is > attached, i.e, they remain in the same state as the last time there was an > attachment. Conceptually, it makes sense to avoid updating the pixmaps if > no one is attached but, for the life of me, I cannot find the switch that > turns pixmap updating on/off according to whether a client is attached or > not. If you share your code it will be easier to talk about it. Cheers Antoine > > Thanks in Advance! > Dan DaCosta > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From chaosape at gmail.com Tue Nov 3 20:07:30 2015 From: chaosape at gmail.com (Dan DaCosta) Date: Tue, 3 Nov 2015 14:07:30 -0600 Subject: [winswitch] A Hopefully Quick Question About Xpra. In-Reply-To: <5638D96A.6090704@nagafix.co.uk> References: <5638D96A.6090704@nagafix.co.uk> Message-ID: Antoine: Responses in-line. On Tue, Nov 3, 2015 at 9:57 AM, Antoine Martin wrote: > On 02/11/15 20:02, Dan DaCosta wrote: > > Xpra Experts: > > > > I have hacked a little code into Xpra that takes screenshots of all > windows > > managed by Xpra and stores them locally as files. Specifically, I > > accomplished this by adding a bit of code to the x11/server.py file. It > is > > nothing pretty; > Can you post this code? > We now have code that achieves something similar in trunk: > http://xpra.org/trac/ticket/988 I added the following two functions to XpraServer and then started the thread on class initialization. def schedule_pictures_thread(self): while True: self.idle_add(self.get_pictures) time.sleep(1) def get_pictures(self): for wid in sorted(self._id_to_window.keys()): if wid <= 1: continue window = self._id_to_window[wid] try: w, h = window.get_dimensions() image = window.get_image( 0, 0, w, h,logger=log.info) if (image == None): continue rgb = { "XRGB" : "RGB", "BGRX" : "RGB", "RGBA" : "RGBA", "BGRA" : "RGBA", }.get(image.get_pixel_format(), image.get_pixel_format()) img = Image.frombuffer(rgb, (w, h), image.get_pixels(), "raw",image.get_pixel_format(), image.get_rowstride()) img.save("/tmp/%d-%d.png" % (wid,self._image_count), "PNG") self._image_count = self._image_count + 1 except: traceback.print_exc() > I was just interested in doing a little experimentation. I > > have two issues that seemingly should be easy to fix but I have yet to > > figure out how to hack around them: > > 1) The server seems to be ignorant of any window pixmaps until the first > > client attaches. Specifically, from my naive perspective, it seems like > > Xpra cannot find the pixmap for any windows until the first attachment. > Windows are not mapped onto the virtual screen until a client maps them > somewhere on their desktop. > And unmapped windows do not have pixmaps.. > 2) If, after an initial attach there are no attached clients, I can get > > access to the window pixmaps but they are not updated unless someone is > > attached, i.e, they remain in the same state as the last time there was > an > > attachment. Conceptually, it makes sense to avoid updating the pixmaps if > > no one is attached but, for the life of me, I cannot find the switch that > > turns pixmap updating on/off according to whether a client is attached or > > not. > If you share your code it will be easier to talk about it. > What I would like to do is keep the window mapped until its destruction. This way, I can take accurate screenshots of running programs regardless of if I am attached to them. I believe I have found that calling the setup() window method when it is initially created by the wm in _manage_client creates the pixmap. Now, I would like to change a bit of code that will a) map a window as soon as it is created by the wm and b) only unmap windows on destruction. I am looking for some hints on where I should be making these changes. Thanks! Dan DaCosta > Cheers > Antoine > > > > Thanks in Advance! > > Dan DaCosta > > _______________________________________________ > > 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 narisipalli at gmail.com Tue Nov 3 21:27:47 2015 From: narisipalli at gmail.com (Gowtham Narisipalli) Date: Tue, 3 Nov 2015 16:27:47 -0500 Subject: [winswitch] DMG available download is not signed Message-ID: I am using OSX El Caption and attempted to install xpra after downloading the dmg. Looks like the DMG is not signed as OSX is not able to identify the developer of the application. Can you please sign the package to ensure that users who are downloading package can trust it and not fear that it tinkered with? Thanks, -- *Gowtham Narisipalli* From stroller at stellar.eclipse.co.uk Wed Nov 4 15:42:34 2015 From: stroller at stellar.eclipse.co.uk (Stroller) Date: Wed, 4 Nov 2015 15:42:34 +0000 Subject: [winswitch] A Hopefully Quick Question About Xpra. In-Reply-To: References: <5638D96A.6090704@nagafix.co.uk> Message-ID: > On Tue, 3 November 2015, at 8:07 p.m., Dan DaCosta wrote: > >> Windows are not mapped onto the virtual screen until a client maps them >> somewhere on their desktop. >> And unmapped windows do not have pixmaps.. > > What I would like to do is keep the window mapped until its destruction. > This > way, I can take accurate screenshots of running programs regardless of if I > am attached to them. Sorry if this is a dumb question, but why don't you just have a program that attaches the Xpra screen, takes a screen shot and detaches? I would have thought this might well be possible with nothing more than a shell script called from a cron job. Stroller. From chaosape at gmail.com Wed Nov 4 16:47:02 2015 From: chaosape at gmail.com (Dan DaCosta) Date: Wed, 04 Nov 2015 16:47:02 +0000 Subject: [winswitch] A Hopefully Quick Question About Xpra. In-Reply-To: References: <5638D96A.6090704@nagafix.co.uk> Message-ID: On Wed, Nov 4, 2015 at 9:43 AM Stroller wrote: > > > On Tue, 3 November 2015, at 8:07 p.m., Dan DaCosta > wrote: > > > >> Windows are not mapped onto the virtual screen until a client maps them > >> somewhere on their desktop. > >> And unmapped windows do not have pixmaps.. > > > > What I would like to do is keep the window mapped until its destruction. > > This > > way, I can take accurate screenshots of running programs regardless of > if I > > am attached to them. > > Sorry if this is a dumb question, but why don't you just have a program > that attaches the Xpra screen, takes a screen shot and detaches? > I perfectly fair question! I am eventually hoping to build more functionality on to the top of this little experiment. > I would have thought this might well be possible with nothing more than a > shell script called from a cron job. > > Stroller. > Thanks! Dan DaCosta From antoine at nagafix.co.uk Thu Nov 5 13:47:20 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 5 Nov 2015 20:47:20 +0700 Subject: [winswitch] A Hopefully Quick Question About Xpra. In-Reply-To: References: <5638D96A.6090704@nagafix.co.uk> Message-ID: <563B5DE8.9050904@nagafix.co.uk> > I added the following two functions to XpraServer and then started the > thread > on class initialization. > > def schedule_pictures_thread(self): > while True: > self.idle_add(self.get_pictures) > time.sleep(1) FYI: you don't really need a new thread here, just use: self.timeout_add(1000, self.get_pictures) and return True at the end of get_pictures. > What I would like to do is keep the window mapped until its destruction. > This > way, I can take accurate screenshots of running programs regardless of if I > am attached to them. I believe I have found that calling the setup() window > method when it is initially created by the wm in _manage_client creates the > pixmap. Now, I would like to change a bit of code that will a) map a window > as soon as it is created by the wm and b) only unmap windows on > destruction. I am looking for some hints on where I should be making these > changes. The setup() method of the window model class should be called from do_manage_client already. (see the ugly call_setup invoked from the instance __init__ method) The unmap case is a little bit more difficult, you could try commenting it out in _process_unmap_window and see what breaks... Cheers Antoine From antoine at nagafix.co.uk Thu Nov 5 13:59:37 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 5 Nov 2015 20:59:37 +0700 Subject: [winswitch] DMG available download is not signed In-Reply-To: References: Message-ID: <563B60C9.5040106@nagafix.co.uk> On 04/11/15 04:27, Gowtham Narisipalli wrote: > I am using OSX El Caption and attempted to install xpra after downloading > the dmg. Looks like the DMG is not signed as OSX is not able to identify > the developer of the application. Can you please sign the package to > ensure that users who are downloading package can trust it and not fear > that it tinkered with? Jumping through the hoops that Apple has created "in the name of security" is planned: http://xpra.org/trac/ticket/641 You can already check that the packages you have downloaded have not been tinkered with using the checksums and gpg signatures found in the download area, which you can download via https - this guarantees that you are downloading from xpra.org. This has been the case for many years, we did not wait for Apple to provide this assurance. The problem is that as far as I am aware, you now have to trust Apple for everything, including managing this new signing system which is completely disconnected from the website it is hosted on... in the name of security. Last but not least, this tedious signing process requires a sufficiently new version of xcode, which is not available on our current build system. Switching to a newer version of OSX for the build system is in the works, I am sure this will break all sorts of things in new and interesting ways too. Cheers Antoine From stroller at stellar.eclipse.co.uk Thu Nov 5 15:50:41 2015 From: stroller at stellar.eclipse.co.uk (Stroller) Date: Thu, 5 Nov 2015 15:50:41 +0000 Subject: [winswitch] DMG available download is not signed In-Reply-To: <563B60C9.5040106@nagafix.co.uk> References: <563B60C9.5040106@nagafix.co.uk> Message-ID: <5DEE0A2A-636B-4CD7-A879-FC11896799B9@stellar.eclipse.co.uk> > On Thu, 5 November 2015, at 1:59 p.m., Antoine Martin wrote: > > The problem is that as far as I am aware, you now have to trust Apple > for everything, ? I'm pretty sure you can still allow unsigned apps in El Capitan's preferences. I'm currently on El Capitan, using a build of Colloquy which I compiled myself under Mavericks with no problem. http://i.imgur.com/2TuYKGg.png Stroller. From adarrab at gmail.com Sat Nov 7 16:07:35 2015 From: adarrab at gmail.com (Abdulaziz M. Aldarrab) Date: Sat, 7 Nov 2015 19:07:35 +0300 Subject: [winswitch] Xpra Client Memory Footprint Message-ID: <001701d11976$6bdfa7f0$439ef7d0$@gmail.com> Hi, Upon start, each client instance is using between 70-80MB of memory (excluding plink) and could reach 130MB just by using kwrite and opening multiple files. Is there a way to reduce it? Running 10+ applications would consume about 1GB of ram. I'm even disabling mic, speaker & tray icon options. Client: Win7 64bit (Xpra: 0.15.7) Client root window size is 3840x1200 Best regards, Abdulaziz From antoine at nagafix.co.uk Sun Nov 8 13:36:14 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 8 Nov 2015 20:36:14 +0700 Subject: [winswitch] DMG available download is not signed In-Reply-To: <5DEE0A2A-636B-4CD7-A879-FC11896799B9@stellar.eclipse.co.uk> References: <563B60C9.5040106@nagafix.co.uk> <5DEE0A2A-636B-4CD7-A879-FC11896799B9@stellar.eclipse.co.uk> Message-ID: <563F4FCE.1020302@nagafix.co.uk> On 05/11/15 22:50, Stroller wrote: >> On Thu, 5 November 2015, at 1:59 p.m., Antoine Martin wrote: >> >> The problem is that as far as I am aware, you now have to trust Apple >> for everything, ? > I'm pretty sure you can still allow unsigned apps in El Capitan's preferences. > > I'm currently on El Capitan, using a build of Colloquy which I compiled myself under Mavericks with no problem. > > http://i.imgur.com/2TuYKGg.png Thanks for the screenshot. After doing this, I believe you still have to "Control + click" to whitelist an application, more details can be found here: https://support.apple.com/en-ap/HT202491 It's not very user friendly, but it will have to do for now. Cheers Antoine From antoine at nagafix.co.uk Mon Nov 9 07:46:40 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 9 Nov 2015 14:46:40 +0700 Subject: [winswitch] Xpra Client Memory Footprint In-Reply-To: <001701d11976$6bdfa7f0$439ef7d0$@gmail.com> References: <001701d11976$6bdfa7f0$439ef7d0$@gmail.com> Message-ID: <56404F60.8030406@nagafix.co.uk> On 07/11/15 23:07, Abdulaziz M. Aldarrab wrote: > Hi, > > Upon start, each client instance is using between 70-80MB of memory > (excluding plink) and could reach 130MB just by using kwrite and opening > multiple files. Is there a way to reduce it? Not easily I am afraid. Though if you create a ticket, I'll try to look into it again. Doing the same thing on my 1080p XP virtual machine I see a memory usage of just 50MB using the task manager's "Mem Usage". The "VM size" is lower. > Running 10+ applications would consume about 1GB of ram. I'm even disabling > mic, speaker & tray icon options. Disabling sound is the biggest saving there, the rest will be barely noticeable. Using OpenGL rendering will use video ram (PBOs) for the window buffers instead of main system memory. I haven't tested this yet, but I believe that this should not always add the same amount of memory for each copy of the client: https://msdn.microsoft.com/en-us/library/windows/desktop/ms681938(v=vs.85).aspx " Multiple processes that load the same DLL at the same base address share a single copy of the DLL in physical memory. Doing this saves system memory and reduces swapping" All the DLLs we load should be re-using the same memory addresses. Cheers Antoine > Client: Win7 64bit (Xpra: 0.15.7) > > Client root window size is 3840x1200 > > > > Best regards, > > Abdulaziz > > > > _______________________________________________ > 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 Fri Nov 13 14:29:21 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 13 Nov 2015 21:29:21 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.15.8 (many fixes, some important) Message-ID: <5645F3C1.20003@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This update fixes a very large number of issues, including some important ones. You should update at the earliest opportunity. This may well be the final release from the 0.15.x branch. The OSX and MS Windows binaries are already available, the RPMs and DEBs may take a few more hours to post. The 0.14.32 release will follow shortly after that. The RPM repositories also include some updated libraries: libwebp-0.4.4, libvpx-1.5.0 and Pillow 3.0.0. PyOpenGL and its accelerate module were rebuilt to try to prevent conflicts with the newly packaged Fedora version. Release notes: * fix potential security issue with password challenge * fix missing files from build clean target * fix unnecessary auto-refresh events * fix x265 encoder * fix libvpx bitrate calculations, reduce logging spam * fix validation of mmap security token * fix handling of file transfers before authentication (disallowed) * fix handling of requests to open files (honour command line / config) * fix MS Windows multiple monitor bug (when primary monitor is re-added) * fix video encoding automatic selection for encoders that accept RGB * fix the session info sound graphs when sound stops * fix RPM packaging of the cups backend * fix the speed and quality values reported to the clients for x264 * fix OSX El Capitan sound compatibility issue * fix codec import error handler * fix compatibility with Python Pillow 3.0.0 (logging issue) * fix support for Ubuntu Vivid (Xorg still unusable) * fix batch delay heuristics during resizing and queue overload * fix "always batch" mode * fix missing network-send-speed accounting * fix error in override redirect window geometry handling * fix invalid error logging call * fix error in XSettings handling causing connection failures * fix race condition causing corrupted video streams * fix unnecessary double refresh on client decoding error * fix encoding bug triggered when dependencies are missing * fix window size hints handling * support Xorg location and arguments required by Arch Linux * improved lz4 version detection workaround code * support Xft/DPI * safer OSX power event handling code * workaround clients supplying a password when none is required * log OpenGL driver information * clamp desktop size to the maximum screen size * avoid potential errors with bytes-per-pixel confusion with rgb modes * disable workspace support (was causing compatibility issues) * always watch for property changes, even without workspace support * workaround clients supplying a password when none is required * export shadow servers flag * run the window opengl cleanup code 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 v2 iEYEARECAAYFAlZF87sACgkQGK2zHPGK1rtTvACaAjbmLKZ5DiTr1rP+Foc2HBtb IgcAni6bG7A26rzu/4otXjvoyMjkoUKX =kI9n -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Sat Nov 14 08:27:30 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 14 Nov 2015 15:27:30 +0700 Subject: [winswitch] [ANNOUNCE] [LTS] xpra 0.14.32 (many fixes) Message-ID: <5646F072.5000606@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Just like the 0.15.8 release that precedes it, this update contains a large number of fixes, including some important ones. But because this is the LTS branch, we are being more conservative here and not all fixes were included. (they may still eventually be applied in this branch at a later date) Release notes: * fix OSX El Capitan sound compatibility issue * fix potential security issue with password challenge * fix unnecessary auto-refresh events * fix x265 encoder * fix libvpx bitrate calculations * fix validation of mmap security token * fix codec import error handler * fix compatibility with Python Pillow 3.0.0 (logging issue) * fix support for Ubuntu Vivid (Xorg still unusable) * fix batch delay heuristics during resizing and queue overload * fix "always batch" mode * fix missing network-send-speed accounting * fix error in override redirect window geometry handling * fix invalid error logging call * fix error in XSettings handling causing connection failures * fix race condition causing corrupted video streams * fix encoding bug triggered when dependencies are missing * support Xorg location and arguments required by Arch Linux * improved lz4 version detection workaround code * support Xft/DPI * safer OSX power event handling code * workaround clients supplying a password when none is required * log OpenGL driver information 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 v2 iEYEARECAAYFAlZG8HIACgkQGK2zHPGK1rsfsQCdGV/MMBaRMKPZTVFXbmjvYKVx yCAAn1pgKZxPHLriX0M3QgYDAHPrQGUX =/GXU -----END PGP SIGNATURE----- From garbytrash at gmail.com Sun Nov 15 07:44:21 2015 From: garbytrash at gmail.com (Zenny) Date: Sun, 15 Nov 2015 08:44:21 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb Message-ID: Hi, xpra is very interesting, but I am encountering an issue or say cannot figure out exactly how to achieve the following. 1. Start a xvfb based virtual x instance in a resolution say 4k (3840x2160) in one machine (server) with say libreoffice impress, and broadcast using 'xpra shadow :10" 2. Access that instance from another machine (laptop) using 'xpra attach ssh:hostname:10' 3. Screencapture the :10 inside the same machine at 4K. But it does not allow me to capture in 4K but at the same resolution as of the rendering laptop. I checked Xdummy related to Ubuntu instruction at https://www.xpra.org/trac/wiki/Xdummy, but to no avail. Any hints would be highly appreciated. Thanks! Cheers, /z From antoine at nagafix.co.uk Sun Nov 15 09:12:57 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 15 Nov 2015 16:12:57 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: Message-ID: <56484C99.2030703@nagafix.co.uk> On 15/11/15 14:44, Zenny wrote: > Hi, > > xpra is very interesting, but I am encountering an issue or say cannot > figure out exactly how to achieve the following. > > 1. Start a xvfb based virtual x instance in a resolution say 4k > (3840x2160) in one machine (server) with say libreoffice impress, and > broadcast using 'xpra shadow :10" Please include the exact command line used for starting the Xvfb and libreoffice. > 2. Access that instance from another machine (laptop) using 'xpra > attach ssh:hostname:10' > 3. Screencapture the :10 inside the same machine at 4K. Using which tool? > But it does not allow me to capture in 4K but at the same resolution > as of the rendering laptop. I have tested here with Xdummy and that worked fine. > I checked Xdummy related to Ubuntu instruction at > https://www.xpra.org/trac/wiki/Xdummy, but to no avail. Are you using Xvfb or Xdummy? What distribution and version? > Any hints would be highly appreciated. Thanks! You may also be interested in the following 0.16 features: * ability to NOT change the virtual display to match the client's resolution using: XPRA_RANDR=0 xpra start ... See: http://xpra.org/trac/changeset/11229 Shadow mode is A LOT less efficient than the regular "start" mode. * desktop scaling, which allows you to upscale or downscale the server resolution when displayed on the client: http://xpra.org/trac/ticket/976 So you could render at 4k and display at 2k for example (though the main purpose of this ticket is to do the opposite to save bandwidth). * "sync-xvfb" fix for screen capture tools: http://xpra.org/trac/ticket/988 Cheers Antoine > > Cheers, > /z > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From garbytrash at gmail.com Sun Nov 15 09:51:38 2015 From: garbytrash at gmail.com (Zenny) Date: Sun, 15 Nov 2015 10:51:38 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <56484C99.2030703@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> Message-ID: On 11/15/15, Antoine Martin wrote: > On 15/11/15 14:44, Zenny wrote: >> Hi, >> >> xpra is very interesting, but I am encountering an issue or say cannot >> figure out exactly how to achieve the following. >> >> 1. Start a xvfb based virtual x instance in a resolution say 4k >> (3840x2160) in one machine (server) with say libreoffice impress, and >> broadcast using 'xpra shadow :10" > Please include the exact command line used for starting the Xvfb and > libreoffice. $ Xvfb :10 -screen 0 4096x2160x24+32 -fbdir /var/tmp & $ export DISPLAY=:10.1 $ libreoffice & / i3 & / lxsession -s LUBUNTU -e LXDE $ xpra shadow :10 >> 2. Access that instance from another machine (laptop) using 'xpra >> attach ssh:hostname:10' $ xpra attach ssh:HOSTNAME:10 >> 3. Screencapture the :10 inside the same machine at 4K. > Using which tool? initially with ffmpeg and then with xwd / maim >> But it does not allow me to capture in 4K but at the same resolution >> as of the rendering laptop. > I have tested here with Xdummy and that worked fine. With Xdummy, once I attach to the remote machine with xpra, the ffmpeg fails as it says "the capturing region lies out of the range." or something like this. >> I checked Xdummy related to Ubuntu instruction at >> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. > Are you using Xvfb or Xdummy? What distribution and version? Tried with Xvfb, didn't work and then with Xdummy. Still experimenting. ;-) $ lsb_release -a LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch Distributor ID: Ubuntu Description: Ubuntu 14.04.3 LTS Release: 14.04 Codename: trusty xpra is at v0.15.8-2 and xvfb is at v1.15.1-0ubuntu2.7 >> Any hints would be highly appreciated. Thanks! > You may also be interested in the following 0.16 features: > * ability to NOT change the virtual display to match the client's > resolution using: > XPRA_RANDR=0 xpra start ... > See: > http://xpra.org/trac/changeset/11229 > Shadow mode is A LOT less efficient than the regular "start" mode. > * desktop scaling, which allows you to upscale or downscale the server > resolution when displayed on the client: > http://xpra.org/trac/ticket/976 > So you could render at 4k and display at 2k for example (though the main > purpose of this ticket is to do the opposite to save bandwidth). > * "sync-xvfb" fix for screen capture tools: > http://xpra.org/trac/ticket/988 Very interesting. Is there a binary of this dev release? Thanks for taking time to reply. Cheers, /z > > Cheers > Antoine > >> >> Cheers, >> /z >> _______________________________________________ >> 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 garbytrash at gmail.com Sun Nov 15 13:48:35 2015 From: garbytrash at gmail.com (Zenny) Date: Sun, 15 Nov 2015 14:48:35 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <56484C99.2030703@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> Message-ID: On 11/15/15, Antoine Martin wrote: > I have tested here with Xdummy and that worked fine. Can you share your Xdummy command if different from the one in the wiki? >> I checked Xdummy related to Ubuntu instruction at >> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. > Are you using Xvfb or Xdummy? What distribution and version? >> Any hints would be highly appreciated. Thanks! > You may also be interested in the following 0.16 features: > * ability to NOT change the virtual display to match the client's > resolution using: > XPRA_RANDR=0 xpra start ... > See: > http://xpra.org/trac/changeset/11229 > Shadow mode is A LOT less efficient than the regular "start" mode. > * desktop scaling, which allows you to upscale or downscale the server > resolution when displayed on the client: > http://xpra.org/trac/ticket/976 > So you could render at 4k and display at 2k for example (though the main > purpose of this ticket is to do the opposite to save bandwidth). > * "sync-xvfb" fix for screen capture tools: > http://xpra.org/trac/ticket/988 > > Cheers > Antoine > >> >> Cheers, >> /z >> _______________________________________________ >> 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 garbytrash at gmail.com Sun Nov 15 14:15:16 2015 From: garbytrash at gmail.com (Zenny) Date: Sun, 15 Nov 2015 15:15:16 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> Message-ID: Please find some more updates: ?1 If I use Xdummy with xpra (as described in the wiki) and try to capture with ffmpeg the virtual console at 4k while displaying the remote in 1080p, it categorically reports as of below and fails to capture: [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside the screen size 1920x1080 :10: Invalid argument ?2 If I use Xvfb directly with a single application (say xterm), and run 'xpra start --use-display :10', it allows to screencapture, but the capture of the window is dead black. (see attachment) ?3. As in ?2 above, if I start a DE like (LXDE or i3), I get the xrandr errors and the remote screen freezes. Thanks! On 11/15/15, Zenny wrote: > On 11/15/15, Antoine Martin wrote: >> I have tested here with Xdummy and that worked fine. > > Can you share your Xdummy command if different from the one in the wiki? > > >>> I checked Xdummy related to Ubuntu instruction at >>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >> Are you using Xvfb or Xdummy? What distribution and version? >>> Any hints would be highly appreciated. Thanks! >> You may also be interested in the following 0.16 features: >> * ability to NOT change the virtual display to match the client's >> resolution using: >> XPRA_RANDR=0 xpra start ... >> See: >> http://xpra.org/trac/changeset/11229 >> Shadow mode is A LOT less efficient than the regular "start" mode. >> * desktop scaling, which allows you to upscale or downscale the server >> resolution when displayed on the client: >> http://xpra.org/trac/ticket/976 >> So you could render at 4k and display at 2k for example (though the main >> purpose of this ticket is to do the opposite to save bandwidth). >> * "sync-xvfb" fix for screen capture tools: >> http://xpra.org/trac/ticket/988 >> >> Cheers >> Antoine >> >>> >>> Cheers, >>> /z >>> _______________________________________________ >>> 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 garbytrash at gmail.com Sun Nov 15 14:32:32 2015 From: garbytrash at gmail.com (Zenny) Date: Sun, 15 Nov 2015 15:32:32 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> Message-ID: On 11/15/15, Zenny wrote: > Please find some more updates: > > ?1 If I use Xdummy with xpra (as described in the wiki) and try to > capture with ffmpeg the virtual console at 4k while displaying the > remote in 1080p, it categorically reports as of below and fails to > capture: > > [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside > the screen size 1920x1080 > :10: Invalid argument > > ?2 If I use Xvfb directly with a single application (say xterm), and > run 'xpra start --use-display :10', it allows to screencapture, but > the capture of the window is dead black. (see attachment) Running single application works fine except screencapture of that X instance be captured and the screencapture shows a black placeholder of the size of the remote display size where the application was running as seen in the screenshot. This one is with libreoffice impress running an animated presentation, but rendered black. Earlier was from a xterm. > > ?3. As in ?2 above, if I start a DE like (LXDE or i3), I get the > xrandr errors and the remote screen freezes. It categorically states in the xpra initialization window that: lib: extension "RANDR" missing on display ":100". And on the remote end (laptop at lower resolution) outputs: Screen1 @ 0.0,3840x2160:Calibration curves could not be loaded. and freezes. > > Thanks! > > On 11/15/15, Zenny wrote: >> On 11/15/15, Antoine Martin wrote: >>> I have tested here with Xdummy and that worked fine. >> >> Can you share your Xdummy command if different from the one in the wiki? >> >> >>>> I checked Xdummy related to Ubuntu instruction at >>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>> Are you using Xvfb or Xdummy? What distribution and version? >>>> Any hints would be highly appreciated. Thanks! >>> You may also be interested in the following 0.16 features: >>> * ability to NOT change the virtual display to match the client's >>> resolution using: >>> XPRA_RANDR=0 xpra start ... >>> See: >>> http://xpra.org/trac/changeset/11229 >>> Shadow mode is A LOT less efficient than the regular "start" mode. >>> * desktop scaling, which allows you to upscale or downscale the server >>> resolution when displayed on the client: >>> http://xpra.org/trac/ticket/976 >>> So you could render at 4k and display at 2k for example (though the main >>> purpose of this ticket is to do the opposite to save bandwidth). >>> * "sync-xvfb" fix for screen capture tools: >>> http://xpra.org/trac/ticket/988 >>> >>> Cheers >>> Antoine >>> >>>> >>>> Cheers, >>>> /z >>>> _______________________________________________ >>>> 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 garbytrash at gmail.com Sun Nov 15 14:34:26 2015 From: garbytrash at gmail.com (Zenny) Date: Sun, 15 Nov 2015 15:34:26 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> Message-ID: Forgot to mention that xpra is upgraded to the 0.16.0.1 beta before the two updates were posted and tested in order to test whether http://xpra.org/trac/ticket/976 was taken care of. Thanks! On 11/15/15, Zenny wrote: > On 11/15/15, Zenny wrote: >> Please find some more updates: >> >> ?1 If I use Xdummy with xpra (as described in the wiki) and try to >> capture with ffmpeg the virtual console at 4k while displaying the >> remote in 1080p, it categorically reports as of below and fails to >> capture: >> >> [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside >> the screen size 1920x1080 >> :10: Invalid argument >> >> ?2 If I use Xvfb directly with a single application (say xterm), and >> run 'xpra start --use-display :10', it allows to screencapture, but >> the capture of the window is dead black. (see attachment) > > Running single application works fine except screencapture of that X > instance be captured and the screencapture shows a black placeholder > of the size of the remote display size where the application was > running as seen in the screenshot. This one is with libreoffice > impress running an animated presentation, but rendered black. Earlier > was from a xterm. > >> >> ?3. As in ?2 above, if I start a DE like (LXDE or i3), I get the >> xrandr errors and the remote screen freezes. > > It categorically states in the xpra initialization window that: > > lib: extension "RANDR" missing on display ":100". > > And on the remote end (laptop at lower resolution) outputs: > > Screen1 @ 0.0,3840x2160:Calibration curves could not be loaded. > > and freezes. > >> >> Thanks! >> >> On 11/15/15, Zenny wrote: >>> On 11/15/15, Antoine Martin wrote: >>>> I have tested here with Xdummy and that worked fine. >>> >>> Can you share your Xdummy command if different from the one in the wiki? >>> >>> >>>>> I checked Xdummy related to Ubuntu instruction at >>>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>>> Are you using Xvfb or Xdummy? What distribution and version? >>>>> Any hints would be highly appreciated. Thanks! >>>> You may also be interested in the following 0.16 features: >>>> * ability to NOT change the virtual display to match the client's >>>> resolution using: >>>> XPRA_RANDR=0 xpra start ... >>>> See: >>>> http://xpra.org/trac/changeset/11229 >>>> Shadow mode is A LOT less efficient than the regular "start" mode. >>>> * desktop scaling, which allows you to upscale or downscale the server >>>> resolution when displayed on the client: >>>> http://xpra.org/trac/ticket/976 >>>> So you could render at 4k and display at 2k for example (though the >>>> main >>>> purpose of this ticket is to do the opposite to save bandwidth). >>>> * "sync-xvfb" fix for screen capture tools: >>>> http://xpra.org/trac/ticket/988 >>>> >>>> Cheers >>>> Antoine >>>> >>>>> >>>>> Cheers, >>>>> /z >>>>> _______________________________________________ >>>>> 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 philip at tidepool.ca Sun Nov 15 17:26:53 2015 From: philip at tidepool.ca (Philip Loewen) Date: Sun, 15 Nov 2015 09:26:53 -0800 Subject: [winswitch] Package libwebp-xpra is not signed Message-ID: <5648C05D.6@tidepool.ca> On RHEL Server 7.1, the command sudo yum update xpra downloads some rpm files, prints the error message below, and quits before doing anything more: Package libwebp-xpra-0.4.4-1.el7.centos.x86_64.rpm is not signed I worked around this by adding a flag to the original command: sudo yum --nogpgcheck update xpra The download got repeated, and then installation proceeded as expected. This update transaction brought in 3 packages, and the error message mentioned only the first one that yum inspected -- it may be that the others would also be considered "not signed", but that the nogpgcheck flag was applied to the whole transaction. Earlier in the same session, I had issued the command sudo rpm --import https://winswitch.org/gpg.asc Other (admiring and grateful) xpra users may benefit from this information. I am just happy to be running the latest version now. From antoine at nagafix.co.uk Sun Nov 15 18:14:44 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 01:14:44 +0700 Subject: [winswitch] Package libwebp-xpra is not signed In-Reply-To: <5648C05D.6@tidepool.ca> References: <5648C05D.6@tidepool.ca> Message-ID: <5648CB94.20907@nagafix.co.uk> On 16/11/15 00:26, Philip Loewen wrote: > On RHEL Server 7.1, the command > sudo yum update xpra > downloads some rpm files, prints the error message below, and quits > before doing anything more: > Package libwebp-xpra-0.4.4-1.el7.centos.x86_64.rpm is not signed Sorry about that. The repository scripts seem to have skipped signing a few packages in the last update. This affected all CentOS versions but not the Fedora repo. That's now fixed, to refresh you may need to do: yum clean all; yum update Thanks for the heads up. Antoine > > I worked around this by adding a flag to the original command: > sudo yum --nogpgcheck update xpra > The download got repeated, and then installation proceeded as expected. > > This update transaction brought in 3 packages, and the error message > mentioned only the first one that yum inspected -- it may be that the > others would also be considered "not signed", but that the nogpgcheck > flag was applied to the whole transaction. > > Earlier in the same session, I had issued the command > sudo rpm --import https://winswitch.org/gpg.asc > > Other (admiring and grateful) xpra users may benefit from this > information. I am just happy to be running the latest version now. > _______________________________________________ > 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 Mon Nov 16 06:23:14 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 13:23:14 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> Message-ID: <56497652.6080102@nagafix.co.uk> On 15/11/15 16:51, Zenny wrote: > On 11/15/15, Antoine Martin wrote: >> On 15/11/15 14:44, Zenny wrote: >>> Hi, >>> >>> xpra is very interesting, but I am encountering an issue or say cannot >>> figure out exactly how to achieve the following. >>> >>> 1. Start a xvfb based virtual x instance in a resolution say 4k >>> (3840x2160) in one machine (server) with say libreoffice impress, and >>> broadcast using 'xpra shadow :10" >> Please include the exact command line used for starting the Xvfb and >> libreoffice. > $ Xvfb :10 -screen 0 4096x2160x24+32 -fbdir /var/tmp & > $ export DISPLAY=:10.1 Could this be a typo? I've used this instead: export DISPLAY=:10 > $ libreoffice & / i3 & / lxsession -s LUBUNTU -e LXDE Both libreoffice and lxsession crash when I try on Fedora 23, with Xvfb or Xdummy. > $ xpra shadow :10 >>> 2. Access that instance from another machine (laptop) using 'xpra >>> attach ssh:hostname:10' > $ xpra attach ssh:HOSTNAME:10 >>> 3. Screencapture the :10 inside the same machine at 4K. >> Using which tool? > initially with ffmpeg and then with xwd / maim Command lines? I started an xterm with "xterm -geometry 600x100" and captured it fine with scrot. Both with Xvfb and Xdummy. >>> But it does not allow me to capture in 4K but at the same resolution >>> as of the rendering laptop. >> I have tested here with Xdummy and that worked fine. > With Xdummy, once I attach to the remote machine with xpra, the ffmpeg > fails as it says "the capturing region lies out of the range." or > something like this. Having the exact command line and error message may help. >>> I checked Xdummy related to Ubuntu instruction at >>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >> Are you using Xvfb or Xdummy? What distribution and version? > Tried with Xvfb, didn't work and then with Xdummy. Still experimenting. ;-) > > $ lsb_release -a > LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch > Distributor ID: Ubuntu > Description: Ubuntu 14.04.3 LTS > Release: 14.04 > Codename: trusty > > xpra is at v0.15.8-2 and xvfb is at v1.15.1-0ubuntu2.7 Xdummy is problematic on Ubuntu - it is disabled for most Ubuntu versions. >>> Any hints would be highly appreciated. Thanks! >> You may also be interested in the following 0.16 features: >> * ability to NOT change the virtual display to match the client's >> resolution using: >> XPRA_RANDR=0 xpra start ... >> See: >> http://xpra.org/trac/changeset/11229 >> Shadow mode is A LOT less efficient than the regular "start" mode. >> * desktop scaling, which allows you to upscale or downscale the server >> resolution when displayed on the client: >> http://xpra.org/trac/ticket/976 >> So you could render at 4k and display at 2k for example (though the main >> purpose of this ticket is to do the opposite to save bandwidth). >> * "sync-xvfb" fix for screen capture tools: >> http://xpra.org/trac/ticket/988 > Very interesting. Is there a binary of this dev release? There are fairly recent builds here: http://xpra.org/beta Cheers Antoine > > Thanks for taking time to reply. > > Cheers, > /z > >> Cheers >> Antoine >> >>> Cheers, >>> /z >>> _______________________________________________ >>> 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 Mon Nov 16 06:24:38 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 13:24:38 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> Message-ID: <564976A6.2030806@nagafix.co.uk> On 15/11/15 20:48, Zenny wrote: > On 11/15/15, Antoine Martin wrote: >> I have tested here with Xdummy and that worked fine. > Can you share your Xdummy command if different from the one in the wiki? I am using the one that gets generated in the xpra.conf like so: export DISPLAY=:10 xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d -config /etc/xpra/xorg.conf $DISPLAY Antoine > > >>> I checked Xdummy related to Ubuntu instruction at >>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >> Are you using Xvfb or Xdummy? What distribution and version? >>> Any hints would be highly appreciated. Thanks! >> You may also be interested in the following 0.16 features: >> * ability to NOT change the virtual display to match the client's >> resolution using: >> XPRA_RANDR=0 xpra start ... >> See: >> http://xpra.org/trac/changeset/11229 >> Shadow mode is A LOT less efficient than the regular "start" mode. >> * desktop scaling, which allows you to upscale or downscale the server >> resolution when displayed on the client: >> http://xpra.org/trac/ticket/976 >> So you could render at 4k and display at 2k for example (though the main >> purpose of this ticket is to do the opposite to save bandwidth). >> * "sync-xvfb" fix for screen capture tools: >> http://xpra.org/trac/ticket/988 >> >> Cheers >> Antoine >> >>> Cheers, >>> /z >>> _______________________________________________ >>> 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 Mon Nov 16 06:30:21 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 13:30:21 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> Message-ID: <564977FD.8060100@nagafix.co.uk> On 15/11/15 21:15, Zenny wrote: > Please find some more updates: > > ?1 If I use Xdummy with xpra (as described in the wiki) and try to > capture with ffmpeg the virtual console at 4k while displaying the > remote in 1080p, it categorically reports as of below and fails to > capture: > > [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside > the screen size 1920x1080 > :10: Invalid argument That's expected: Xdummy supports RandR and we resize the server's virtual screen to match the size of the client's screen. That's one of the main reasons why you should avoid using Xvfb. You can verify this by running xdpyinfo on that virtual display (or "xrandr" or whatever). You can disable this behaviour using: XPRA_RANDR=0 xpra start ... As long as you're running a very recent beta build. You will also need "sync-xvfb" to make screen capture tools work: http://xpra.org/trac/ticket/988 > ?2 If I use Xvfb directly with a single application (say xterm), and > run 'xpra start --use-display :10', it allows to screencapture, but > the capture of the window is dead black. (see attachment) Use "sync-xvfb". > ?3. As in ?2 above, if I start a DE like (LXDE or i3), I get the > xrandr errors and the remote screen freezes. Use Xdummy, Xvfb does not support RandR. Cheers Antoine > > Thanks! > > On 11/15/15, Zenny wrote: >> On 11/15/15, Antoine Martin wrote: >>> I have tested here with Xdummy and that worked fine. >> Can you share your Xdummy command if different from the one in the wiki? >> >> >>>> I checked Xdummy related to Ubuntu instruction at >>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>> Are you using Xvfb or Xdummy? What distribution and version? >>>> Any hints would be highly appreciated. Thanks! >>> You may also be interested in the following 0.16 features: >>> * ability to NOT change the virtual display to match the client's >>> resolution using: >>> XPRA_RANDR=0 xpra start ... >>> See: >>> http://xpra.org/trac/changeset/11229 >>> Shadow mode is A LOT less efficient than the regular "start" mode. >>> * desktop scaling, which allows you to upscale or downscale the server >>> resolution when displayed on the client: >>> http://xpra.org/trac/ticket/976 >>> So you could render at 4k and display at 2k for example (though the main >>> purpose of this ticket is to do the opposite to save bandwidth). >>> * "sync-xvfb" fix for screen capture tools: >>> http://xpra.org/trac/ticket/988 >>> >>> Cheers >>> Antoine >>> >>>> Cheers, >>>> /z >>>> _______________________________________________ >>>> 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 garbytrash at gmail.com Mon Nov 16 12:14:20 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 13:14:20 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <56497652.6080102@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> <56497652.6080102@nagafix.co.uk> Message-ID: On 11/16/15, Antoine Martin wrote: > On 15/11/15 16:51, Zenny wrote: >> On 11/15/15, Antoine Martin wrote: >>> On 15/11/15 14:44, Zenny wrote: >>>> Hi, >>>> >>>> xpra is very interesting, but I am encountering an issue or say cannot >>>> figure out exactly how to achieve the following. >>>> >>>> 1. Start a xvfb based virtual x instance in a resolution say 4k >>>> (3840x2160) in one machine (server) with say libreoffice impress, and >>>> broadcast using 'xpra shadow :10" >>> Please include the exact command line used for starting the Xvfb and >>> libreoffice. >> $ Xvfb :10 -screen 0 4096x2160x24+32 -fbdir /var/tmp & >> $ export DISPLAY=:10.1 > Could this be a typo? I've used this instead: > export DISPLAY=:10 Yep that was a typo. Apology for the oversight. >> $ libreoffice & / i3 & / lxsession -s LUBUNTU -e LXDE > Both libreoffice and lxsession crash when I try on Fedora 23, with Xvfb > or Xdummy. >> $ xpra shadow :10 >>>> 2. Access that instance from another machine (laptop) using 'xpra >>>> attach ssh:hostname:10' >> $ xpra attach ssh:HOSTNAME:10 >>>> 3. Screencapture the :10 inside the same machine at 4K. >>> Using which tool? >> initially with ffmpeg and then with xwd / maim > Command lines? > I started an xterm with "xterm -geometry 600x100" and captured it fine > with scrot. > Both with Xvfb and Xdummy. >>>> But it does not allow me to capture in 4K but at the same resolution >>>> as of the rendering laptop. >>> I have tested here with Xdummy and that worked fine. >> With Xdummy, once I attach to the remote machine with xpra, the ffmpeg >> fails as it says "the capturing region lies out of the range." or >> something like this. > Having the exact command line and error message may help. >>>> I checked Xdummy related to Ubuntu instruction at >>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>> Are you using Xvfb or Xdummy? What distribution and version? >> Tried with Xvfb, didn't work and then with Xdummy. Still experimenting. >> ;-) >> >> $ lsb_release -a >> LSB >> Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch >> Distributor ID: Ubuntu >> Description: Ubuntu 14.04.3 LTS >> Release: 14.04 >> Codename: trusty >> >> xpra is at v0.15.8-2 and xvfb is at v1.15.1-0ubuntu2.7 > Xdummy is problematic on Ubuntu - it is disabled for most Ubuntu versions. I have got xserver-xorg-video-dummy 1:0.3.7-1build1 installed. Yet do you mean it will be problematic?! >>>> Any hints would be highly appreciated. Thanks! >>> You may also be interested in the following 0.16 features: >>> * ability to NOT change the virtual display to match the client's >>> resolution using: >>> XPRA_RANDR=0 xpra start ... >>> See: >>> http://xpra.org/trac/changeset/11229 >>> Shadow mode is A LOT less efficient than the regular "start" mode. >>> * desktop scaling, which allows you to upscale or downscale the server >>> resolution when displayed on the client: >>> http://xpra.org/trac/ticket/976 >>> So you could render at 4k and display at 2k for example (though the main >>> purpose of this ticket is to do the opposite to save bandwidth). >>> * "sync-xvfb" fix for screen capture tools: >>> http://xpra.org/trac/ticket/988 >> Very interesting. Is there a binary of this dev release? > There are fairly recent builds here: > http://xpra.org/beta > > Cheers > Antoine > >> >> Thanks for taking time to reply. >> >> Cheers, >> /z >> >>> Cheers >>> Antoine >>> >>>> Cheers, >>>> /z >>>> _______________________________________________ >>>> 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 garbytrash at gmail.com Mon Nov 16 12:17:25 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 13:17:25 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <564976A6.2030806@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> Message-ID: On 11/16/15, Antoine Martin wrote: > On 15/11/15 20:48, Zenny wrote: >> On 11/15/15, Antoine Martin wrote: >>> I have tested here with Xdummy and that worked fine. >> Can you share your Xdummy command if different from the one in the wiki? > I am using the one that gets generated in the xpra.conf like so: > > export DISPLAY=:10 > xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR > +extension RENDER -auth $XAUTHORITY -logfile > ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d > -config /etc/xpra/xorg.conf $DISPLAY Thanks for sharing, but ould not figure out 'xpra_Xdummy' : Is that underscore a typo? Else let me know what I am missing? I am on v0.16.0-1 beta. Cheers, /z > > Antoine > >> >> >>>> I checked Xdummy related to Ubuntu instruction at >>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>> Are you using Xvfb or Xdummy? What distribution and version? >>>> Any hints would be highly appreciated. Thanks! >>> You may also be interested in the following 0.16 features: >>> * ability to NOT change the virtual display to match the client's >>> resolution using: >>> XPRA_RANDR=0 xpra start ... >>> See: >>> http://xpra.org/trac/changeset/11229 >>> Shadow mode is A LOT less efficient than the regular "start" mode. >>> * desktop scaling, which allows you to upscale or downscale the server >>> resolution when displayed on the client: >>> http://xpra.org/trac/ticket/976 >>> So you could render at 4k and display at 2k for example (though the main >>> purpose of this ticket is to do the opposite to save bandwidth). >>> * "sync-xvfb" fix for screen capture tools: >>> http://xpra.org/trac/ticket/988 >>> >>> Cheers >>> Antoine >>> >>>> Cheers, >>>> /z >>>> _______________________________________________ >>>> 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 Mon Nov 16 12:27:40 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 19:27:40 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> Message-ID: <5649CBBC.5010701@nagafix.co.uk> On 16/11/15 19:17, Zenny wrote: > On 11/16/15, Antoine Martin wrote: >> On 15/11/15 20:48, Zenny wrote: >>> On 11/15/15, Antoine Martin wrote: >>>> I have tested here with Xdummy and that worked fine. >>> Can you share your Xdummy command if different from the one in the wiki? >> I am using the one that gets generated in the xpra.conf like so: >> >> export DISPLAY=:10 >> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >> +extension RENDER -auth $XAUTHORITY -logfile >> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >> -config /etc/xpra/xorg.conf $DISPLAY > Thanks for sharing, but ould not figure out 'xpra_Xdummy' : http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy > Is that underscore a typo? No. > Else let me know what I am missing? I am on v0.16.0-1 beta. This wrapper script may or may not be needed for running Xorg as a non-root user. In some cases, you may be able to just replace it with a plain "Xorg". Cheers Antoine > > Cheers, > /z > >> Antoine >> >>> >>>>> I checked Xdummy related to Ubuntu instruction at >>>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>>> Are you using Xvfb or Xdummy? What distribution and version? >>>>> Any hints would be highly appreciated. Thanks! >>>> You may also be interested in the following 0.16 features: >>>> * ability to NOT change the virtual display to match the client's >>>> resolution using: >>>> XPRA_RANDR=0 xpra start ... >>>> See: >>>> http://xpra.org/trac/changeset/11229 >>>> Shadow mode is A LOT less efficient than the regular "start" mode. >>>> * desktop scaling, which allows you to upscale or downscale the server >>>> resolution when displayed on the client: >>>> http://xpra.org/trac/ticket/976 >>>> So you could render at 4k and display at 2k for example (though the main >>>> purpose of this ticket is to do the opposite to save bandwidth). >>>> * "sync-xvfb" fix for screen capture tools: >>>> http://xpra.org/trac/ticket/988 >>>> >>>> Cheers >>>> Antoine >>>> >>>>> Cheers, >>>>> /z >>>>> _______________________________________________ >>>>> 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 garbytrash at gmail.com Mon Nov 16 12:30:27 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 13:30:27 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <564977FD.8060100@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> <564977FD.8060100@nagafix.co.uk> Message-ID: On 11/16/15, Antoine Martin wrote: > On 15/11/15 21:15, Zenny wrote: >> Please find some more updates: >> >> ?1 If I use Xdummy with xpra (as described in the wiki) and try to >> capture with ffmpeg the virtual console at 4k while displaying the >> remote in 1080p, it categorically reports as of below and fails to >> capture: >> >> [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside >> the screen size 1920x1080 >> :10: Invalid argument > That's expected: Xdummy supports RandR and we resize the server's > virtual screen to match the size of the client's screen. Actually I want the server's virtual screen to remain at the same 4K resolution while downsizing the one of the client's screen to say 1K (in order to save bandwidth and for other reasons if any). > That's one of the main reasons why you should avoid using Xvfb. > You can verify this by running xdpyinfo on that virtual display (or > "xrandr" or whatever). > > You can disable this behaviour using: > XPRA_RANDR=0 xpra start ... > As long as you're running a very recent beta build. > You will also need "sync-xvfb" to make screen capture tools work: > http://xpra.org/trac/ticket/988 The track specifies: xpra start --sync-vfb=50 and there is no mention in the man page about --sync-xvfb. Is there a some info about the the --sync-xvfb flag and its parameters about usage?! >> ?2 If I use Xvfb directly with a single application (say xterm), and >> run 'xpra start --use-display :10', it allows to screencapture, but >> the capture of the window is dead black. (see attachment) > Use "sync-xvfb". >> ?3. As in ?2 above, if I start a DE like (LXDE or i3), I get the >> xrandr errors and the remote screen freezes. > Use Xdummy, Xvfb does not support RandR. Yep, following your suggestion, I tried to use the xpra_Xdummy, but that is nowhere found in my machine which is running v0.16.0-1 beta. Thanks again for your very useful inputs. Cheers, /z > > Cheers > Antoine >> >> Thanks! >> >> On 11/15/15, Zenny wrote: >>> On 11/15/15, Antoine Martin wrote: >>>> I have tested here with Xdummy and that worked fine. >>> Can you share your Xdummy command if different from the one in the wiki? >>> >>> >>>>> I checked Xdummy related to Ubuntu instruction at >>>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>>> Are you using Xvfb or Xdummy? What distribution and version? >>>>> Any hints would be highly appreciated. Thanks! >>>> You may also be interested in the following 0.16 features: >>>> * ability to NOT change the virtual display to match the client's >>>> resolution using: >>>> XPRA_RANDR=0 xpra start ... >>>> See: >>>> http://xpra.org/trac/changeset/11229 >>>> Shadow mode is A LOT less efficient than the regular "start" mode. >>>> * desktop scaling, which allows you to upscale or downscale the server >>>> resolution when displayed on the client: >>>> http://xpra.org/trac/ticket/976 >>>> So you could render at 4k and display at 2k for example (though the >>>> main >>>> purpose of this ticket is to do the opposite to save bandwidth). >>>> * "sync-xvfb" fix for screen capture tools: >>>> http://xpra.org/trac/ticket/988 >>>> >>>> Cheers >>>> Antoine >>>> >>>>> Cheers, >>>>> /z >>>>> _______________________________________________ >>>>> 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 Mon Nov 16 12:32:40 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 19:32:40 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <56497652.6080102@nagafix.co.uk> Message-ID: <5649CCE8.20107@nagafix.co.uk> >>> $ lsb_release -a >>> LSB >>> Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch >>> Distributor ID: Ubuntu >>> Description: Ubuntu 14.04.3 LTS >>> Release: 14.04 >>> Codename: trusty >>> xpra is at v0.15.8-2 and xvfb is at v1.15.1-0ubuntu2.7 >> Xdummy is problematic on Ubuntu - it is disabled for most Ubuntu versions. > I have got xserver-xorg-video-dummy 1:0.3.7-1build1 installed. Yet do > you mean it will be problematic?! Just a warning about Ubuntu' s changes to Xorg. If Xdummy does work reliably on Ubuntu Trusty (TBC), then we should change the default config that we ship for this particular release. Cheers Antoine From garbytrash at gmail.com Mon Nov 16 13:00:20 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 14:00:20 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <5649CBBC.5010701@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> Message-ID: On 11/16/15, Antoine Martin wrote: > On 16/11/15 19:17, Zenny wrote: >> On 11/16/15, Antoine Martin wrote: >>> On 15/11/15 20:48, Zenny wrote: >>>> On 11/15/15, Antoine Martin wrote: >>>>> I have tested here with Xdummy and that worked fine. >>>> Can you share your Xdummy command if different from the one in the >>>> wiki? >>> I am using the one that gets generated in the xpra.conf like so: >>> >>> export DISPLAY=:10 >>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>> +extension RENDER -auth $XAUTHORITY -logfile >>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >>> -config /etc/xpra/xorg.conf $DISPLAY >> Thanks for sharing, but ould not figure out 'xpra_Xdummy' : > http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy Thanks for very useful pointer: But how to specify the screen resolution with xpra_Xdummy (as you have suggested as quoted below)? In my case I need 4K in the virtual x server in server and 1K in the client, fyi export DISPLAY=:10 xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -auth $XAUTHORITY -logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d -config /etc/xpra/xorg.conf $DISPLAY Cheers, /z >> Is that underscore a typo? > No. >> Else let me know what I am missing? I am on v0.16.0-1 beta. > This wrapper script may or may not be needed for running Xorg as a > non-root user. > In some cases, you may be able to just replace it with a plain "Xorg". > > Cheers > Antoine > > > >> >> Cheers, >> /z >> >>> Antoine >>> >>>> >>>>>> I checked Xdummy related to Ubuntu instruction at >>>>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>>>> Are you using Xvfb or Xdummy? What distribution and version? >>>>>> Any hints would be highly appreciated. Thanks! >>>>> You may also be interested in the following 0.16 features: >>>>> * ability to NOT change the virtual display to match the client's >>>>> resolution using: >>>>> XPRA_RANDR=0 xpra start ... >>>>> See: >>>>> http://xpra.org/trac/changeset/11229 >>>>> Shadow mode is A LOT less efficient than the regular "start" mode. >>>>> * desktop scaling, which allows you to upscale or downscale the server >>>>> resolution when displayed on the client: >>>>> http://xpra.org/trac/ticket/976 >>>>> So you could render at 4k and display at 2k for example (though the >>>>> main >>>>> purpose of this ticket is to do the opposite to save bandwidth). >>>>> * "sync-xvfb" fix for screen capture tools: >>>>> http://xpra.org/trac/ticket/988 >>>>> >>>>> Cheers >>>>> Antoine >>>>> >>>>>> Cheers, >>>>>> /z >>>>>> _______________________________________________ >>>>>> 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 garbytrash at gmail.com Mon Nov 16 13:11:28 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 14:11:28 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> Message-ID: On 11/16/15, Zenny wrote: > On 11/16/15, Antoine Martin wrote: >> On 16/11/15 19:17, Zenny wrote: >>> On 11/16/15, Antoine Martin wrote: >>>> On 15/11/15 20:48, Zenny wrote: >>>>> On 11/15/15, Antoine Martin wrote: >>>>>> I have tested here with Xdummy and that worked fine. >>>>> Can you share your Xdummy command if different from the one in the >>>>> wiki? >>>> I am using the one that gets generated in the xpra.conf like so: >>>> >>>> export DISPLAY=:10 >>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>> +extension RENDER -auth $XAUTHORITY -logfile >>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >>>> -config /etc/xpra/xorg.conf $DISPLAY >>> Thanks for sharing, but ould not figure out 'xpra_Xdummy' : >> http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy > > Thanks for very useful pointer: > > But how to specify the screen resolution with xpra_Xdummy (as you have > suggested as quoted below)? In my case I need 4K in the virtual x > server in server and 1K in the client, fyi > > export DISPLAY=:10 > xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR > +extension RENDER -auth $XAUTHORITY -logfile > ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d > -config /etc/xpra/xorg.conf $DISPLAY UPDATE: I started an xpra instance with the above command, but no xpra sessions are listed: $ xpra list xpra initialization error: No xpra sessions found The xpra_Xdummy command above displays following in the console: http://hastebin.com/tudewavuxe.avrasm Thanks, /z > > Cheers, > /z > >>> Is that underscore a typo? >> No. >>> Else let me know what I am missing? I am on v0.16.0-1 beta. >> This wrapper script may or may not be needed for running Xorg as a >> non-root user. >> In some cases, you may be able to just replace it with a plain "Xorg". >> >> Cheers >> Antoine >> >> >> >>> >>> Cheers, >>> /z >>> >>>> Antoine >>>> >>>>> >>>>>>> I checked Xdummy related to Ubuntu instruction at >>>>>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>>>>> Are you using Xvfb or Xdummy? What distribution and version? >>>>>>> Any hints would be highly appreciated. Thanks! >>>>>> You may also be interested in the following 0.16 features: >>>>>> * ability to NOT change the virtual display to match the client's >>>>>> resolution using: >>>>>> XPRA_RANDR=0 xpra start ... >>>>>> See: >>>>>> http://xpra.org/trac/changeset/11229 >>>>>> Shadow mode is A LOT less efficient than the regular "start" mode. >>>>>> * desktop scaling, which allows you to upscale or downscale the >>>>>> server >>>>>> resolution when displayed on the client: >>>>>> http://xpra.org/trac/ticket/976 >>>>>> So you could render at 4k and display at 2k for example (though the >>>>>> main >>>>>> purpose of this ticket is to do the opposite to save bandwidth). >>>>>> * "sync-xvfb" fix for screen capture tools: >>>>>> http://xpra.org/trac/ticket/988 >>>>>> >>>>>> Cheers >>>>>> Antoine >>>>>> >>>>>>> Cheers, >>>>>>> /z >>>>>>> _______________________________________________ >>>>>>> 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 garbytrash at gmail.com Mon Nov 16 13:15:08 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 14:15:08 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> Message-ID: On 11/16/15, Zenny wrote: > On 11/16/15, Zenny wrote: >> On 11/16/15, Antoine Martin wrote: >>> On 16/11/15 19:17, Zenny wrote: >>>> On 11/16/15, Antoine Martin wrote: >>>>> On 15/11/15 20:48, Zenny wrote: >>>>>> On 11/15/15, Antoine Martin wrote: >>>>>>> I have tested here with Xdummy and that worked fine. >>>>>> Can you share your Xdummy command if different from the one in the >>>>>> wiki? >>>>> I am using the one that gets generated in the xpra.conf like so: >>>>> >>>>> export DISPLAY=:10 >>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >>>>> -config /etc/xpra/xorg.conf $DISPLAY >>>> Thanks for sharing, but ould not figure out 'xpra_Xdummy' : >>> http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy >> >> Thanks for very useful pointer: >> >> But how to specify the screen resolution with xpra_Xdummy (as you have >> suggested as quoted below)? In my case I need 4K in the virtual x >> server in server and 1K in the client, fyi >> >> export DISPLAY=:10 >> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >> +extension RENDER -auth $XAUTHORITY -logfile >> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >> -config /etc/xpra/xorg.conf $DISPLAY > > UPDATE: I started an xpra instance with the above command, but no xpra > sessions are listed: > > $ xpra list > xpra initialization error: > No xpra sessions found > > The xpra_Xdummy command above displays following in the console: > http://hastebin.com/tudewavuxe.avrasm The relevant log is at: http://hastebin.com/miqaxajusa.vhdl > > Thanks, > /z > >> >> Cheers, >> /z >> >>>> Is that underscore a typo? >>> No. >>>> Else let me know what I am missing? I am on v0.16.0-1 beta. >>> This wrapper script may or may not be needed for running Xorg as a >>> non-root user. >>> In some cases, you may be able to just replace it with a plain "Xorg". >>> >>> Cheers >>> Antoine >>> >>> >>> >>>> >>>> Cheers, >>>> /z >>>> >>>>> Antoine >>>>> >>>>>> >>>>>>>> I checked Xdummy related to Ubuntu instruction at >>>>>>>> https://www.xpra.org/trac/wiki/Xdummy, but to no avail. >>>>>>> Are you using Xvfb or Xdummy? What distribution and version? >>>>>>>> Any hints would be highly appreciated. Thanks! >>>>>>> You may also be interested in the following 0.16 features: >>>>>>> * ability to NOT change the virtual display to match the client's >>>>>>> resolution using: >>>>>>> XPRA_RANDR=0 xpra start ... >>>>>>> See: >>>>>>> http://xpra.org/trac/changeset/11229 >>>>>>> Shadow mode is A LOT less efficient than the regular "start" mode. >>>>>>> * desktop scaling, which allows you to upscale or downscale the >>>>>>> server >>>>>>> resolution when displayed on the client: >>>>>>> http://xpra.org/trac/ticket/976 >>>>>>> So you could render at 4k and display at 2k for example (though the >>>>>>> main >>>>>>> purpose of this ticket is to do the opposite to save bandwidth). >>>>>>> * "sync-xvfb" fix for screen capture tools: >>>>>>> http://xpra.org/trac/ticket/988 >>>>>>> >>>>>>> Cheers >>>>>>> Antoine >>>>>>> >>>>>>>> Cheers, >>>>>>>> /z >>>>>>>> _______________________________________________ >>>>>>>> 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 Mon Nov 16 13:43:55 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 20:43:55 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> Message-ID: <5649DD9B.8050100@nagafix.co.uk> >>> Please find some more updates: >>> >>> ?1 If I use Xdummy with xpra (as described in the wiki) and try to >>> capture with ffmpeg the virtual console at 4k while displaying the >>> remote in 1080p, it categorically reports as of below and fails to >>> capture: >>> >>> [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside >>> the screen size 1920x1080 >>> :10: Invalid argument >> That's expected: Xdummy supports RandR and we resize the server's >> virtual screen to match the size of the client's screen. > Actually I want the server's virtual screen to remain at the same 4K > resolution while downsizing the one of the client's screen to say 1K > (in order to save bandwidth and for other reasons if any). That doesn't make sense: if you render at 4K and downscale the image to about 1K, then it will be unreadable on the client. (16 times smaller) There are ways to achieve server-side scaling with the video encoders, but that's meant to be used for saving bandwidth on video content and is mostly done automagically. >>>>>>>> I have tested here with Xdummy and that worked fine. >>>>>>> Can you share your Xdummy command if different from the one in the >>>>>>> wiki? >>>>>> I am using the one that gets generated in the xpra.conf like so: >>>>>> >>>>>> export DISPLAY=:10 >>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >>>>>> -config /etc/xpra/xorg.conf $DISPLAY >>>>> Thanks for sharing, but ould not figure out 'xpra_Xdummy' : >>>> http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy >>> Thanks for very useful pointer: >>> >>> But how to specify the screen resolution with xpra_Xdummy (as you have >>> suggested as quoted below)? In my case I need 4K in the virtual x >>> server in server and 1K in the client, fyi >>> >>> export DISPLAY=:10 >>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>> +extension RENDER -auth $XAUTHORITY -logfile >>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >>> -config /etc/xpra/xorg.conf $DISPLAY Use xrandr to change the resolution. >> UPDATE: I started an xpra instance with the above command, but no xpra >> sessions are listed: >> >> $ xpra list >> xpra initialization error: >> No xpra sessions found Then the session did not start. Check your server log file, which will probably tell you that the Xvfb failed to start. >> >> The xpra_Xdummy command above displays following in the console: >> http://hastebin.com/tudewavuxe.avrasm > The relevant log is at: > > http://hastebin.com/miqaxajusa.vhdl I've just tried it in an Ubuntu Trusty virtual machine and got the dreaded message: "xf86OpenConsole: cannot open /dev/tty0" Different error, but the same result: as I expected, Xdummy does not work on Ubuntu. Cheers Antoine From garbytrash at gmail.com Mon Nov 16 15:48:01 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 16:48:01 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <5649DD9B.8050100@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> Message-ID: On 11/16/15, Antoine Martin wrote: > >>>> Please find some more updates: >>>> >>>> ?1 If I use Xdummy with xpra (as described in the wiki) and try to >>>> capture with ffmpeg the virtual console at 4k while displaying the >>>> remote in 1080p, it categorically reports as of below and fails to >>>> capture: >>>> >>>> [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside >>>> the screen size 1920x1080 >>>> :10: Invalid argument >>> That's expected: Xdummy supports RandR and we resize the server's >>> virtual screen to match the size of the client's screen. >> Actually I want the server's virtual screen to remain at the same 4K >> resolution while downsizing the one of the client's screen to say 1K >> (in order to save bandwidth and for other reasons if any). > That doesn't make sense: if you render at 4K and downscale the image to > about 1K, then it will be unreadable on the client. (16 times smaller) a bit confusing how come 4K (3840x2169) screen is 16 times smaller than 1K (1920x1080), 4 times, I guess. Oh I would have said Full HD instead of 1K (my mistake). > There are ways to achieve server-side scaling with the video encoders, > but that's meant to be used for saving bandwidth on video content and is > mostly done automagically. This is not what is happening. I want to capture in 4K from the virtual X fb server in the server while rendering in FullHD (1080) in the client's machine for interaction purpose. >>>>>>>>> I have tested here with Xdummy and that worked fine. >>>>>>>> Can you share your Xdummy command if different from the one in the >>>>>>>> wiki? >>>>>>> I am using the one that gets generated in the xpra.conf like so: >>>>>>> >>>>>>> export DISPLAY=:10 >>>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir >>>>>>> ${HOME}/.xpra/xorg.conf.d >>>>>>> -config /etc/xpra/xorg.conf $DISPLAY >>>>>> Thanks for sharing, but ould not figure out 'xpra_Xdummy' : >>>>> http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy >>>> Thanks for very useful pointer: >>>> >>>> But how to specify the screen resolution with xpra_Xdummy (as you have >>>> suggested as quoted below)? In my case I need 4K in the virtual x >>>> server in server and 1K in the client, fyi >>>> >>>> export DISPLAY=:10 >>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>> +extension RENDER -auth $XAUTHORITY -logfile >>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >>>> -config /etc/xpra/xorg.conf $DISPLAY > Use xrandr to change the resolution. >>> UPDATE: I started an xpra instance with the above command, but no xpra >>> sessions are listed: >>> >>> $ xpra list >>> xpra initialization error: >>> No xpra sessions found > Then the session did not start. > Check your server log file, which will probably tell you that the Xvfb > failed to start. >>> >>> The xpra_Xdummy command above displays following in the console: >>> http://hastebin.com/tudewavuxe.avrasm >> The relevant log is at: >> >> http://hastebin.com/miqaxajusa.vhdl > I've just tried it in an Ubuntu Trusty virtual machine and got the > dreaded message: > "xf86OpenConsole: cannot open /dev/tty0" > Different error, but the same result: as I expected, Xdummy does not > work on Ubuntu. That means Xdummy is ruled out in the Ubuntu's case. So rely on xvfb, Right? Wbr, /z > > Cheers > Antoine > From garbytrash at gmail.com Mon Nov 16 15:50:36 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 16:50:36 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> Message-ID: On 11/16/15, Zenny wrote: > On 11/16/15, Antoine Martin wrote: >> >>>>> Please find some more updates: >>>>> >>>>> ?1 If I use Xdummy with xpra (as described in the wiki) and try to >>>>> capture with ffmpeg the virtual console at 4k while displaying the >>>>> remote in 1080p, it categorically reports as of below and fails to >>>>> capture: >>>>> >>>>> [x11grab @ 0x2b2dc00] Capture area 3840x2160 at position 0.0 outside >>>>> the screen size 1920x1080 >>>>> :10: Invalid argument >>>> That's expected: Xdummy supports RandR and we resize the server's >>>> virtual screen to match the size of the client's screen. >>> Actually I want the server's virtual screen to remain at the same 4K >>> resolution while downsizing the one of the client's screen to say 1K >>> (in order to save bandwidth and for other reasons if any). >> That doesn't make sense: if you render at 4K and downscale the image to >> about 1K, then it will be unreadable on the client. (16 times smaller) > > a bit confusing how come 4K (3840x2169) screen is 16 times smaller > than 1K (1920x1080), 4 times, I guess. Oh I would have said Full HD > instead of 1K (my mistake). > >> There are ways to achieve server-side scaling with the video encoders, >> but that's meant to be used for saving bandwidth on video content and is >> mostly done automagically. > > This is not what is happening. I want to capture in 4K from the > virtual X fb server in the server while rendering in FullHD (1080) in > the client's machine for interaction purpose. > >>>>>>>>>> I have tested here with Xdummy and that worked fine. >>>>>>>>> Can you share your Xdummy command if different from the one in the >>>>>>>>> wiki? >>>>>>>> I am using the one that gets generated in the xpra.conf like so: >>>>>>>> >>>>>>>> export DISPLAY=:10 >>>>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>>>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir >>>>>>>> ${HOME}/.xpra/xorg.conf.d >>>>>>>> -config /etc/xpra/xorg.conf $DISPLAY >>>>>>> Thanks for sharing, but ould not figure out 'xpra_Xdummy' : >>>>>> http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy >>>>> Thanks for very useful pointer: >>>>> >>>>> But how to specify the screen resolution with xpra_Xdummy (as you have >>>>> suggested as quoted below)? In my case I need 4K in the virtual x >>>>> server in server and 1K in the client, fyi >>>>> >>>>> export DISPLAY=:10 >>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >>>>> -config /etc/xpra/xorg.conf $DISPLAY >> Use xrandr to change the resolution. How to make changes in the virtual X server with xrandr. It could be possible with xrandr, however my requirement is 4K in the server while displaying the same content in FullHD or lower in the clients. It is a bit confusing how to use xrandr to get two different resolutions in server and client! Would you mind elaborating? >>>> UPDATE: I started an xpra instance with the above command, but no xpra >>>> sessions are listed: >>>> >>>> $ xpra list >>>> xpra initialization error: >>>> No xpra sessions found >> Then the session did not start. >> Check your server log file, which will probably tell you that the Xvfb >> failed to start. >>>> >>>> The xpra_Xdummy command above displays following in the console: >>>> http://hastebin.com/tudewavuxe.avrasm >>> The relevant log is at: >>> >>> http://hastebin.com/miqaxajusa.vhdl >> I've just tried it in an Ubuntu Trusty virtual machine and got the >> dreaded message: >> "xf86OpenConsole: cannot open /dev/tty0" >> Different error, but the same result: as I expected, Xdummy does not >> work on Ubuntu. > > That means Xdummy is ruled out in the Ubuntu's case. So rely on xvfb, > Right? > > Wbr, > /z > > >> >> Cheers >> Antoine >> > From antoine at nagafix.co.uk Mon Nov 16 15:58:35 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 22:58:35 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> Message-ID: <5649FD2B.1060008@nagafix.co.uk> >> There are ways to achieve server-side scaling with the video encoders, >> but that's meant to be used for saving bandwidth on video content and is >> mostly done automagically. > This is not what is happening. I want to capture in 4K from the > virtual X fb server in the server while rendering in FullHD (1080) in > the client's machine for interaction purpose. With 0.16, you can do this using "desktop scaling": xpra attach --desktop-scaling=0.5 BUT this is the opposite of what this feature was designed for, and so this will waste a lot of bandwidth and CPU. IF your server is going to be sending mostly video content, which should get encoded using one of the video encoders, you may want to start the server with: SCALING_HARDCODED=1/2 xpra start ... This should ensure that we downscale the pixel data by half in each dimension before the encoding step. >>>> The xpra_Xdummy command above displays following in the console: >>>> http://hastebin.com/tudewavuxe.avrasm >>> The relevant log is at: >>> >>> http://hastebin.com/miqaxajusa.vhdl >> I've just tried it in an Ubuntu Trusty virtual machine and got the >> dreaded message: >> "xf86OpenConsole: cannot open /dev/tty0" >> Different error, but the same result: as I expected, Xdummy does not >> work on Ubuntu. > That means Xdummy is ruled out in the Ubuntu's case. So rely on xvfb, Right? Yes, and Xvfb is more limited: no RandR, no OpenGL, etc... Cheers Antoine From antoine at nagafix.co.uk Mon Nov 16 16:07:04 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 23:07:04 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> Message-ID: <5649FF28.3030604@nagafix.co.uk> >>>>>>>>>>> I have tested here with Xdummy and that worked fine. >>>>>>>>>> Can you share your Xdummy command if different from the one in the >>>>>>>>>> wiki? >>>>>>>>> I am using the one that gets generated in the xpra.conf like so: >>>>>>>>> >>>>>>>>> export DISPLAY=:10 >>>>>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>>>>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir >>>>>>>>> ${HOME}/.xpra/xorg.conf.d >>>>>>>>> -config /etc/xpra/xorg.conf $DISPLAY >>>>>>>> Thanks for sharing, but ould not figure out 'xpra_Xdummy' : >>>>>>> http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy >>>>>> Thanks for very useful pointer: >>>>>> >>>>>> But how to specify the screen resolution with xpra_Xdummy (as you have >>>>>> suggested as quoted below)? In my case I need 4K in the virtual x >>>>>> server in server and 1K in the client, fyi >>>>>> >>>>>> export DISPLAY=:10 >>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir ${HOME}/.xpra/xorg.conf.d >>>>>> -config /etc/xpra/xorg.conf $DISPLAY >>> Use xrandr to change the resolution. > How to make changes in the virtual X server with xrandr. It could be > possible with xrandr, however my requirement is 4K in the server while > displaying the same content in FullHD or lower in the clients. It is a > bit confusing how to use xrandr to get two different resolutions in > server and client! Would you mind elaborating? Using xrandr to change resolutions can be useful in two cases: * you start the Xvfb yourself and use xpra in shadow mode, in this case xpra does not try to change the resolution for you * you tell xpra not to do randr (with XPRA_RANDR=0) If you are certain that you will only need a single resolution, then you could also use a customized xorg.conf The "desktop-scaling" option in 0.16 looks easier to me than either of those options. That's assuming that you are using Xdummy. If you use Xvfb, then this is all moot. Cheers Antoine From garbytrash at gmail.com Mon Nov 16 16:12:43 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 17:12:43 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <5649FF28.3030604@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> Message-ID: On 11/16/15, Antoine Martin wrote: >>>>>>>>>>>> I have tested here with Xdummy and that worked fine. >>>>>>>>>>> Can you share your Xdummy command if different from the one in >>>>>>>>>>> the >>>>>>>>>>> wiki? >>>>>>>>>> I am using the one that gets generated in the xpra.conf like so: >>>>>>>>>> >>>>>>>>>> export DISPLAY=:10 >>>>>>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension >>>>>>>>>> RANDR >>>>>>>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>>>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir >>>>>>>>>> ${HOME}/.xpra/xorg.conf.d >>>>>>>>>> -config /etc/xpra/xorg.conf $DISPLAY >>>>>>>>> Thanks for sharing, but ould not figure out 'xpra_Xdummy' : >>>>>>>> http://xpra.org/trac/browser/xpra/trunk/src/scripts/xpra_Xdummy >>>>>>> Thanks for very useful pointer: >>>>>>> >>>>>>> But how to specify the screen resolution with xpra_Xdummy (as you >>>>>>> have >>>>>>> suggested as quoted below)? In my case I need 4K in the virtual x >>>>>>> server in server and 1K in the client, fyi >>>>>>> >>>>>>> export DISPLAY=:10 >>>>>>> xpra_Xdummy -noreset -nolisten tcp +extension GLX +extension RANDR >>>>>>> +extension RENDER -auth $XAUTHORITY -logfile >>>>>>> ${HOME}/.xpra/Xorg.${DISPLAY}.log -configdir >>>>>>> ${HOME}/.xpra/xorg.conf.d >>>>>>> -config /etc/xpra/xorg.conf $DISPLAY >>>> Use xrandr to change the resolution. >> How to make changes in the virtual X server with xrandr. It could be >> possible with xrandr, however my requirement is 4K in the server while >> displaying the same content in FullHD or lower in the clients. It is a >> bit confusing how to use xrandr to get two different resolutions in >> server and client! Would you mind elaborating? > Using xrandr to change resolutions can be useful in two cases: > * you start the Xvfb yourself and use xpra in shadow mode, in this case > xpra does not try to change the resolution for you > * you tell xpra not to do randr (with XPRA_RANDR=0) Yep, that could be a way to go since Xdummy does not work in Ubuntu 14.04. > > If you are certain that you will only need a single resolution, then you > could also use a customized xorg.conf > > The "desktop-scaling" option in 0.16 looks easier to me than either of > those options. any man pages about desktop-scaling? > > That's assuming that you are using Xdummy. If you use Xvfb, then this is > all moot. > > Cheers > Antoine > From antoine at nagafix.co.uk Mon Nov 16 16:18:47 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 16 Nov 2015 23:18:47 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> Message-ID: <564A01E7.3060103@nagafix.co.uk> >> If you are certain that you will only need a single resolution, then you >> could also use a customized xorg.conf >> >> The "desktop-scaling" option in 0.16 looks easier to me than either of >> those options. > any man pages about desktop-scaling? Can you please check before asking? man xpra And also here (the second link on the wiki): http://xpra.org/manual.html Antoine From garbytrash at gmail.com Mon Nov 16 16:51:38 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 17:51:38 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <564A01E7.3060103@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> <564A01E7.3060103@nagafix.co.uk> Message-ID: On 11/16/15, Antoine Martin wrote: > >>> If you are certain that you will only need a single resolution, then you >>> could also use a customized xorg.conf >>> >>> The "desktop-scaling" option in 0.16 looks easier to me than either of >>> those options. >> any man pages about desktop-scaling? > Can you please check before asking? > man xpra > And also here (the second link on the wiki): > http://xpra.org/manual.html > Sorry I skipped the part in the man-page. Still I could not figure out the sync-xvfb part in the man pages. After reading the --desktop-scaling part, the parameter allows to control the server's x resolution on the fly. But I am trying to do the other way round. The server's virtual X remains at the 4K resolution while the client's varies according to the physical screen attached. Thanks again, /z > Antoine > From garbytrash at gmail.com Mon Nov 16 17:41:04 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 18:41:04 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> <564A01E7.3060103@nagafix.co.uk> Message-ID: Okay, what I did was: On the xpra server: $ Xvfb :10 -screen 0 3840x2160x24+32 -fbdir /var/tmp & $ export DISPLAY=:10 $ xterm && leafpad & On the client: $ XPRA_RANDR=0 xpra start --use-display :10 Only disabling OpenGL allowed to render opened windows. However, other options in the xpra menu like Encodings, Quality and Speed are greyed out and cannot be changed. On the server: $ ffmpeg -f x11grab -s 3840x2160 -i :10 -r 24 -deadline realtimeb:v 1M -threads 5 -qmin 0 -qmax 50 -crf 5 -preset ultrafast -f matroska 4k_screencap_xpra.mpv The screencapture shows everything black including changes made in the xpra attached windows except cursors movements are captured. Any hint why the capture is not displaying the contents of the windows other than mouse movements? Thanks! /z On 11/16/15, Zenny wrote: > On 11/16/15, Antoine Martin wrote: >> >>>> If you are certain that you will only need a single resolution, then >>>> you >>>> could also use a customized xorg.conf >>>> >>>> The "desktop-scaling" option in 0.16 looks easier to me than either of >>>> those options. >>> any man pages about desktop-scaling? >> Can you please check before asking? >> man xpra >> And also here (the second link on the wiki): >> http://xpra.org/manual.html >> > > Sorry I skipped the part in the man-page. Still I could not figure out > the sync-xvfb part in the man pages. > > After reading the --desktop-scaling part, the parameter allows to > control the server's x resolution on the fly. > > But I am trying to do the other way round. The server's virtual X > remains at the 4K resolution while the client's varies according to > the physical screen attached. > > Thanks again, > /z > >> Antoine >> > From garbytrash at gmail.com Mon Nov 16 17:49:24 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 16 Nov 2015 18:49:24 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> <564A01E7.3060103@nagafix.co.uk> Message-ID: *Apology for oversight in my previous mail: On the xpra server: $ Xvfb :10 -screen 0 3840x2160x24+32 -fbdir /var/tmp & $ export DISPLAY=:10 $ xterm && leafpad & $ XPRA_RANDR=0 xpra start --use-display :10 On the client: $ xpra attach ssh:localhost:10 --desktop-scaling=0.5 Only disabling OpenGL allowed to render opened windows. However, other options in the xpra menu like Encodings, Quality and Speed are greyed out, thus cannot be changed. On the server: $ ffmpeg -f x11grab -s 3840x2160 -i :10 -r 24 -deadline realtimeb:v 1M -threads 5 -qmin 0 -qmax 50 -crf 5 -preset ultrafast -f matroska 4k_screencap_xpra.mpv The screencapture shows everything black including changes made in the xpra attached windows except cursors movements are captured. Any hint why the capture is not displaying the contents of the windows other than mouse movements? Thanks! /z On 11/16/15, Zenny wrote: > Okay, what I did was: > > On the xpra server: > > $ Xvfb :10 -screen 0 3840x2160x24+32 -fbdir /var/tmp & > $ export DISPLAY=:10 > $ xterm && leafpad & > > On the client: > $ XPRA_RANDR=0 xpra start --use-display :10 > > Only disabling OpenGL allowed to render opened windows. However, other > options in the xpra menu like Encodings, Quality and Speed are greyed > out and cannot be changed. > > On the server: > > $ ffmpeg -f x11grab -s 3840x2160 -i :10 -r 24 -deadline realtimeb:v 1M > -threads 5 -qmin 0 -qmax 50 -crf 5 -preset ultrafast -f matroska > 4k_screencap_xpra.mpv > > The screencapture shows everything black including changes made in > the xpra attached windows except cursors movements are captured. > > Any hint why the capture is not displaying the contents of the windows > other than mouse movements? > > Thanks! > > /z > > > > > > On 11/16/15, Zenny wrote: >> On 11/16/15, Antoine Martin wrote: >>> >>>>> If you are certain that you will only need a single resolution, then >>>>> you >>>>> could also use a customized xorg.conf >>>>> >>>>> The "desktop-scaling" option in 0.16 looks easier to me than either of >>>>> those options. >>>> any man pages about desktop-scaling? >>> Can you please check before asking? >>> man xpra >>> And also here (the second link on the wiki): >>> http://xpra.org/manual.html >>> >> >> Sorry I skipped the part in the man-page. Still I could not figure out >> the sync-xvfb part in the man pages. >> >> After reading the --desktop-scaling part, the parameter allows to >> control the server's x resolution on the fly. >> >> But I am trying to do the other way round. The server's virtual X >> remains at the 4K resolution while the client's varies according to >> the physical screen attached. >> >> Thanks again, >> /z >> >>> Antoine >>> >> > From antoine at nagafix.co.uk Tue Nov 17 04:40:37 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 17 Nov 2015 11:40:37 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> <564A01E7.3060103@nagafix.co.uk> Message-ID: <564AAFC5.60507@nagafix.co.uk> On 17/11/15 00:41, Zenny wrote: > Okay, what I did was: > > On the xpra server: > $ Xvfb :10 -screen 0 3840x2160x24+32 -fbdir /var/tmp & > $ export DISPLAY=:10 > $ xterm && leafpad & > > On the client: > $ XPRA_RANDR=0 xpra start --use-display :10 > Only disabling OpenGL allowed to render opened windows. AFAIK, Xvfb does not support OpenGL. And if you use Xdummy, you often need to use VirtualGL: http://xpra.org/trac/wiki/Usage/OpenGL > However, other > options in the xpra menu like Encodings, Quality and Speed are greyed > out and cannot be changed. That's because they are meaningless in this case as you are probably using mmap. This can be seen in your server log file. > On the server: > > $ ffmpeg -f x11grab -s 3840x2160 -i :10 -r 24 -deadline realtimeb:v 1M > -threads 5 -qmin 0 -qmax 50 -crf 5 -preset ultrafast -f matroska > 4k_screencap_xpra.mpv > > The screencapture shows everything black including changes made in > the xpra attached windows except cursors movements are captured. > > Any hint why the capture is not displaying the contents of the windows > other than mouse movements? Since you are not using "sync-xvfb", the xvfb will remain black. This thread now almost has as many posts as the mailing list has had in September and October combined. Please slow down, read the manual, the wiki and the links provided. Cheers Antoine > > Thanks! > > /z > > > > > > On 11/16/15, Zenny wrote: >> On 11/16/15, Antoine Martin wrote: >>>>> If you are certain that you will only need a single resolution, then >>>>> you >>>>> could also use a customized xorg.conf >>>>> >>>>> The "desktop-scaling" option in 0.16 looks easier to me than either of >>>>> those options. >>>> any man pages about desktop-scaling? >>> Can you please check before asking? >>> man xpra >>> And also here (the second link on the wiki): >>> http://xpra.org/manual.html >>> >> Sorry I skipped the part in the man-page. Still I could not figure out >> the sync-xvfb part in the man pages. >> >> After reading the --desktop-scaling part, the parameter allows to >> control the server's x resolution on the fly. >> >> But I am trying to do the other way round. The server's virtual X >> remains at the 4K resolution while the client's varies according to >> the physical screen attached. >> >> Thanks again, >> /z >> >>> Antoine >>> From antoine at nagafix.co.uk Tue Nov 17 07:02:07 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 17 Nov 2015 14:02:07 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> <564A01E7.3060103@nagafix.co.uk> Message-ID: <564AD0EF.8080501@nagafix.co.uk> On 16/11/15 23:51, Zenny wrote: > On 11/16/15, Antoine Martin wrote: >>>> If you are certain that you will only need a single resolution, then you >>>> could also use a customized xorg.conf >>>> >>>> The "desktop-scaling" option in 0.16 looks easier to me than either of >>>> those options. >>> any man pages about desktop-scaling? >> Can you please check before asking? >> man xpra >> And also here (the second link on the wiki): >> http://xpra.org/manual.html >> > Sorry I skipped the part in the man-page. Still I could not figure out > the sync-xvfb part in the man pages. > > After reading the --desktop-scaling part, the parameter allows to > control the server's x resolution on the fly. > > But I am trying to do the other way round. The server's virtual X > remains at the 4K resolution while the client's varies according to > the physical screen attached. If you know your client's resolution before you connect, you can calculate the ratio which will give you 4k on the server. It just won't handle monitor hotplugging. Antoine > > Thanks again, > /z > >> Antoine >> From garbytrash at gmail.com Tue Nov 17 13:25:41 2015 From: garbytrash at gmail.com (Zenny) Date: Tue, 17 Nov 2015 14:25:41 +0100 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: <564AD0EF.8080501@nagafix.co.uk> References: <56484C99.2030703@nagafix.co.uk> <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> <564A01E7.3060103@nagafix.co.uk> <564AD0EF.8080501@nagafix.co.uk> Message-ID: Thanks again. The only bottleneck remained is refreshing the display in the client (not matter which encoding or quality is used). Please note that it is with Xvfb (not Xdummy). When display change takes place, say a slide in libreoffice impress, only a quarter of display changes in client running at (1920x1080), while the screecapture from the virtual X server running in 4K is okay. I start xpra server like: $ XPRA_RANDR=0 xpra start --use-display :10 --sync-xvfb=50 --bind-tcp=localhost:10000 and xpra client like: $ xpra attach tcp:localhost:10000:10 --desktop-scaling=0.5 --sync-xvfb=50 --opengl=no --encoding=jpeg --quality=85 Appreciate if there is any inputs on automatically refresh the full screen (not just quarter of the screen) in xpra client. Thanks, /z On 11/17/15, Antoine Martin wrote: > On 16/11/15 23:51, Zenny wrote: >> On 11/16/15, Antoine Martin wrote: >>>>> If you are certain that you will only need a single resolution, then >>>>> you >>>>> could also use a customized xorg.conf >>>>> >>>>> The "desktop-scaling" option in 0.16 looks easier to me than either of >>>>> those options. >>>> any man pages about desktop-scaling? >>> Can you please check before asking? >>> man xpra >>> And also here (the second link on the wiki): >>> http://xpra.org/manual.html >>> >> Sorry I skipped the part in the man-page. Still I could not figure out >> the sync-xvfb part in the man pages. >> >> After reading the --desktop-scaling part, the parameter allows to >> control the server's x resolution on the fly. >> >> But I am trying to do the other way round. The server's virtual X >> remains at the 4K resolution while the client's varies according to >> the physical screen attached. > If you know your client's resolution before you connect, you can > calculate the ratio which will give you 4k on the server. > It just won't handle monitor hotplugging. > > Antoine >> >> Thanks again, >> /z >> >>> Antoine >>> > > From antoine at nagafix.co.uk Thu Nov 19 16:14:11 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 19 Nov 2015 23:14:11 +0700 Subject: [winswitch] issue with forwarding x to a lower res monitor from a virtual Xvfb In-Reply-To: References: <564976A6.2030806@nagafix.co.uk> <5649CBBC.5010701@nagafix.co.uk> <5649DD9B.8050100@nagafix.co.uk> <5649FF28.3030604@nagafix.co.uk> <564A01E7.3060103@nagafix.co.uk> <564AD0EF.8080501@nagafix.co.uk> Message-ID: <564DF553.3010606@nagafix.co.uk> On 17/11/15 20:25, Zenny wrote: > Thanks again. > > The only bottleneck remained is refreshing the display in the client > (not matter which encoding or quality is used). Please note that it > is with Xvfb (not Xdummy). When display change takes place, say a > slide in libreoffice impress, only a quarter of display changes in > client running at (1920x1080), while the screecapture from the virtual > X server running in 4K is okay. > > I start xpra server like: > $ XPRA_RANDR=0 xpra start --use-display :10 --sync-xvfb=50 > --bind-tcp=localhost:10000 > > and xpra client like: > $ xpra attach tcp:localhost:10000:10 --desktop-scaling=0.5 > --sync-xvfb=50 --opengl=no --encoding=jpeg --quality=85 > > Appreciate if there is any inputs on automatically refresh the full > screen (not just quarter of the screen) in xpra client. Just a final message to close this thread - I hope. We continued to debug this issue in a ticket: http://xpra.org/trac/ticket/1036 And the requested feature now works as expected, even with OpenGL disabled, etc. The important points being: * a recent 0.16 build is required for the features below (and a few bugs were found in the process) * "XPRA_RANDR=0" to keep the server's Xvfb at its starting resolution (or you have to ensure the desktop-scaling value will give the desired resolution on the server side) * "sync-xvfb" enabled to actually paint window updates on the virtual screen * "desktop-scaling" to make the server's screen size fit on to the client Cheers Antoine > > Thanks, > > /z > > > On 11/17/15, Antoine Martin wrote: >> On 16/11/15 23:51, Zenny wrote: >>> On 11/16/15, Antoine Martin wrote: >>>>>> If you are certain that you will only need a single resolution, then >>>>>> you >>>>>> could also use a customized xorg.conf >>>>>> >>>>>> The "desktop-scaling" option in 0.16 looks easier to me than either of >>>>>> those options. >>>>> any man pages about desktop-scaling? >>>> Can you please check before asking? >>>> man xpra >>>> And also here (the second link on the wiki): >>>> http://xpra.org/manual.html >>>> >>> Sorry I skipped the part in the man-page. Still I could not figure out >>> the sync-xvfb part in the man pages. >>> >>> After reading the --desktop-scaling part, the parameter allows to >>> control the server's x resolution on the fly. >>> >>> But I am trying to do the other way round. The server's virtual X >>> remains at the 4K resolution while the client's varies according to >>> the physical screen attached. >> If you know your client's resolution before you connect, you can >> calculate the ratio which will give you 4k on the server. >> It just won't handle monitor hotplugging. >> >> Antoine >>> Thanks again, >>> /z >>> >>>> Antoine >>>> >> From rdtennent at gmail.com Sat Nov 21 17:37:53 2015 From: rdtennent at gmail.com (Bob Tennent) Date: Sat, 21 Nov 2015 12:37:53 -0500 Subject: [winswitch] PyOpenGl on Centos 6 Message-ID: <20151121173753.MDHo6FX31Acq%rdtennent@gmail.com> Yum seems to think PyOpenGL-3.1.1a1final-1.el6 is an update to PyOpenGL-3.1.1a1-2.el6 Bob T. From rdt at cs.queensu.ca Sat Nov 21 17:30:34 2015 From: rdt at cs.queensu.ca (Bob Tennent) Date: Sat, 21 Nov 2015 12:30:34 -0500 Subject: [winswitch] PyOpenGL on Centos 6 Message-ID: <20151121173034.sl5Qof_v_8gH%rdt@cs.queensu.ca> Yum seems to think PyOpenGL-3.1.1a1final-1.el6 is an update to PyOpenGL-3.1.1a1-2.el6 Bob T. From rdtennent at gmail.com Sat Nov 21 17:30:34 2015 From: rdtennent at gmail.com (rdtennent at gmail.com) Date: Sat, 21 Nov 2015 12:30:34 -0500 Subject: [winswitch] PyOpenGL on Centos 6 Message-ID: <20151121173034.sl5Qof_v_8gH%rdt@cs.queensu.ca> Yum seems to think PyOpenGL-3.1.1a1final-1.el6 is an update to PyOpenGL-3.1.1a1-2.el6 Bob T. From johnss1221 at gmail.com Mon Nov 30 01:48:59 2015 From: johnss1221 at gmail.com (John Smith) Date: Mon, 30 Nov 2015 08:48:59 +0700 Subject: [winswitch] [Xpra] Sound problem Message-ID: Hi all, I'm running Xpra with version 0.15.8( server, trusty amd64) and 0.16.0 r11304 (client, MS Windows 7 64bit). Recently, I have had problem with the sound. Sometimes, the sound is broken/interrupted, it will reappear after reattaching several times. I checked on the server (using top -c ), and noticed that when the sound from client was interrupted, the sound xpra process(/usr/bin/python /usr/bin/xpra _sound_record - - pulsesrc mp3 1.0 -d) was inactive, it was just switched on only when it was attached. How to switch on the sound from client without attaching? Thanks :) From antoine at nagafix.co.uk Mon Nov 30 15:38:43 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 30 Nov 2015 22:38:43 +0700 Subject: [winswitch] [Xpra] Sound problem In-Reply-To: References: Message-ID: <565C6D83.8070708@nagafix.co.uk> On 30/11/15 08:48, John Smith wrote: > Hi all, > > I'm running Xpra with version 0.15.8( server, trusty amd64) and 0.16.0 > r11304 (client, MS Windows 7 64bit). > Recently, I have had problem with the sound. Sometimes, the sound is > broken/interrupted, it will reappear after reattaching several times. > I checked on the server (using top -c ), and noticed that when the sound > from client was interrupted, the sound xpra process(/usr/bin/python > /usr/bin/xpra _sound_record - - pulsesrc mp3 1.0 -d) was inactive, it was > just switched on only when it was attached. Please define "inactive" and "switched on". Note: quite a few sound related bugs are fixed in the 0.16.0 server. > How to switch on the sound from client without attaching? You should be able to use the systray to toggle the sound on and off. Cheers Antoine From antoine at nagafix.co.uk Mon Nov 30 15:42:15 2015 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 30 Nov 2015 22:42:15 +0700 Subject: [winswitch] PyOpenGl on Centos 6 In-Reply-To: <20151121173753.MDHo6FX31Acq%rdtennent@gmail.com> References: <20151121173753.MDHo6FX31Acq%rdtennent@gmail.com> Message-ID: <565C6E56.5040204@nagafix.co.uk> On 22/11/15 00:37, Bob Tennent wrote: > > > Yum seems to think > > PyOpenGL-3.1.1a1final-1.el6 > > is an update to > > PyOpenGL-3.1.1a1-2.el6 Sorry for taking so long to reply to this email. There were some problems with the PyOpenGL versioning, also not helped by the Fedora package naming conflicts (and this one is still ongoing). I have pushed new RPMs with the new release name "3.1.1a1r1" which should be seen by yum as being an update to all previous release names. I had seen some strange behaviour earlier, but this seems to have fixed itself. If that happens, you may need to: yum clean all yum remove xpra xpra-common PyOpenGL PyOpenGL-accelerate yum install xpra Cheers Antoine From garbytrash at gmail.com Mon Nov 30 06:17:26 2015 From: garbytrash at gmail.com (Zenny) Date: Mon, 30 Nov 2015 07:17:26 +0100 Subject: [winswitch] mirror instance of xpra client Message-ID: Hi, Xpra has been a great experience, particularly Antoine's proactive replies. :D Is it possible to mirror a single xpra instance in two devices (one just for display, say tablet, and another for interaction)? Thanks a zillion, Cheers, /z