From antoine at nagafix.co.uk Sat Sep 1 10:05:59 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 1 Sep 2018 16:05:59 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <1581983f-df8e-a3de-3cff-7fea4088435c@nagafix.co.uk> Message-ID: <170366d5-121f-5d21-fdfb-228c3993b612@nagafix.co.uk> On 01/09/18 01:14, Ben Sferrazza wrote: > On Fri, Aug 31, 2018 at 2:06 AM Antoine Martin > wrote: > > On 31/08/18 01:20, Ben Sferrazza wrote: > > Tried the Python3 builds of the Xpra 2.4 Windows client and > > unfortunately it has a lot of graphics artifacts (ghosting when > moving a > > terminal, some applications being completely washed out and illegible, > > etc). I'll continue to use the standard 2.4 build for the time being. > Oh! The GTK3 port is meant to be almost complete... (at least for the > client, the server will need a lot more work) > This could be because of transparency issues. (I have no idea why a > terminal applications would use an alpha channel but some do..) > Was this with xfce_terminal again? > Did you have OpenGL enabled or disabled? (see systray menu toggle) > > > OK. I'm still on 2.3.3 for the server. I had tried the latest 2.4 Python > 3 beta for Windows but had those issues. You're right that the terminal > background transparency was the cause for its ghosting (not sure if > there's a way to actually have the transparency work, as that would be > pretty cool). But still had washed out colors with the Cadence > applications I've mentioned (picture attached). OpenGL was disabled > (showing as n/a on the client) and have attached a picture of the > session information. Perhaps I should try getting OpenGL enabled? Transparency normally works just fine, bar some platform quirks: https://www.xpra.org/trac/ticket/1570 ie: we just don't use OpenGL on mswindows for windows with transparency because it cannot be done with GTK3: https://www.xpra.org/trac/ticket/1682 The visual artifacts you are seeing could be something caused by the outdated libraries or bugs in CentOS 5.11, this is an unusual / unsupported setup you have after all. Anyway, you can turn off transparency completely on the server or on the client with: XPRA_ALPHA=0 xpra start ... or XPRA_ALPHA=0 xpra attach .. > > This was working just fine in Xpra 2.2, and the correct theme > >? ? ?and icons are shown when I VNC into the same machine. Oddly > enough, > >? ? ?Emacs does use the correct decorations even with the latest Xpra. > Ah, the everlasting joy of themes and xsettings. > You may want to try --xsettings=no > > (..) > >? ? ? ? ?>? ? ?> 6. flickering clipboard icon in systray > >? ? ?Is there a way to turn off the flickering, just to avoid the > >? ? ?annoyance of it? > There is now, in 2.4: > http://xpra.org/trac/changeset/20251 > To use it: > XPRA_CLIPBOARD_NOTIFY=0 xpra attach ... > > > Nice. I don't see a r20251 download yet in the beta builds, but look > forward to it. Done. Regarding your other points: * seeing that no-one else has reported the "window stuck on top" focus issue for a while, I am going to assume that this has been fixed until someone can give me steps to reproduce the problem. * the latest beta 2.4 builds work with any login shell (including csh and tcsh) both with the new paramiko backend and even the plink.exe one, I will try to backport these fixes to the 2.3 branch. * gvim position and menu bar issues: I have failed to reproduce any of the problems you describe using a stock CentOS 7.5 server with a MS Windows 7, CentOS 7 and Fedora clients. I have tried both 2.3.3 and 2.4 beta builds at both ends. I even tried it on a CentOS 6.x server with xpra 1.0.12, which does place the window in the top left corner, but only with a 1.0 client. I believe that covers all the points in your original email. You should have fixes or workarounds for all the issues that can be reproduced - let me know if I have missed something. Cheers, Antoine From ajs1 at cam.ac.uk Sun Sep 2 10:51:27 2018 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Sun, 2 Sep 2018 10:51:27 +0100 Subject: [winswitch] Can't start xpra session In-Reply-To: <7989c5d4-6ce6-35d4-5b74-1c55981a1358@cam.ac.uk> References: <9cd9fd8b-5d01-4ee3-f036-a2da69cba3cd@nagafix.co.uk> <5fac5f73-4a7e-bc6a-5888-308e22661066@cam.ac.uk> <95791a4d-fa39-50fa-b4cf-c1045c2a1b74@nagafix.co.uk> <7989c5d4-6ce6-35d4-5b74-1c55981a1358@cam.ac.uk> Message-ID: <7cc5c36b-d214-94d9-b790-4944df9ae8b2@cam.ac.uk> Antoine, For the record: I find that after I stop an xpra session, I can't start a new session on the same display with the same command that I have always used previously, i.e. xpra start ssh/whirligig/100 --start="gnome-terminal ..." The log tells me that the lock file for the previous session needs to be deleted, or that there is already an X session with that name, even if I have exited from the terminal shell. However I can start a session with the same display using xpra start ssh/whirligig/100 --use-display=yes --start="gnome-terminal ..." In this case any terminal windows from the previous session that I haven't closed explicitly reappear along with the new one. Previously they were closed automatically when I invoked "xpra stop", which is what I would prefer to happen. Anthony On 31/08/18 10:10, Anthony Stone via shifter-users wrote: > Antoine, > > As recommended, I have set > start-via-proxy=no > in /etc/xpra/conf.d/60_server.conf > (and restarted the server) > and xpra now starts normally. > > Many thanks for the prompt and helpful advice. > > Anthony > > On 30/08/18 18:13, Antoine Martin wrote: >> On 30/08/18 23:41, Anthony Stone wrote: >>> Antoine, >>> >>> Thanks for the suggestions. This is what happens: >> Please always keep the list CCed. >> >>> On 30/08/18 04:22, Antoine Martin via shifter-users wrote: >>>> Directly on the server (ie: via ssh), try to start the session locally: >>>> xpra start :100 --start="gnome-terminal --window-with-profile=Blue" >>> >>> 17:22:05 $ xpra start :100 --start="gnome-terminal >>> --window-with-profile=Blue" >>> 2018-08-30 17:22:46,020 server failure: disconnected before the session >>> could be established >>> 2018-08-30 17:22:46,020 server requested disconnect: server error >>> (failed to start a new session) >>> Warning: cannot use the system proxy for 'start' subcommand, >>> unknown general failure >>> more information may be available in your system log >>> >>> The system log contains the following. This seems to be an >>> authentication failure, but I don't know how to fix it. >>> >>> Aug 30 17:22:32 whirligig systemd[1]: Started Session 2509 of user ajs1. >>> Aug 30 17:22:32 whirligig xpra[1192]: reenter password for >>> pam_mount:(pam_mount.c:477): warning: could not obtain password >>> interactively either >>> Aug 30 17:22:32 whirligig xpra[1192]: reenter password for >>> pam_mount:(pam_mount.c:477): warning: could not obtain password >>> interactively either >> Here is what I think is happening: when we start a proper pam session >> via root (this is what the "starting via proxy" does), we go through the >> pam session configuration. >> Your OS seems to include "pam_mount" in there, and that seems to want to >> ask for a password to do its job. >> I have no idea why that is, or why it isn't failing more gracefully. >> >>> Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,475 Error: >>> pam_open_session failed: 6 >>> Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,476 >>> Permission denied >>> Aug 30 17:22:32 whirligig xpra[1192]: Entering daemon mode; any further >>> errors will be reported to: >>> Aug 30 17:22:32 whirligig xpra[1192]: /run/user/1013/xpra/:100.log >>> Aug 30 17:22:46 whirligig xpra[1192]: Error: failed to start server >>> subprocess: >>> Aug 30 17:22:46 whirligig xpra[1192]: failed to identify the new server >>> display! >> The easiest solution to this problem is to not use the proxy, set: >> start-via-proxy=no >> in your /etc/xpra/conf.d/60_server.conf >> >> On this subject, there seems to be so many ways that distributions >> manage to configure (break) pam sessions, and logind's KillUserProcesses >> still defaults to "no" after all these years, so future versions will >> revert to not using the system wide proxy by default. >> Those who want the features that require it will have to re-enable it. >> >> Cheers, >> Antoine >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Sun Sep 2 11:18:19 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 2 Sep 2018 17:18:19 +0700 Subject: [winswitch] Can't start xpra session In-Reply-To: <7cc5c36b-d214-94d9-b790-4944df9ae8b2@cam.ac.uk> References: <9cd9fd8b-5d01-4ee3-f036-a2da69cba3cd@nagafix.co.uk> <5fac5f73-4a7e-bc6a-5888-308e22661066@cam.ac.uk> <95791a4d-fa39-50fa-b4cf-c1045c2a1b74@nagafix.co.uk> <7989c5d4-6ce6-35d4-5b74-1c55981a1358@cam.ac.uk> <7cc5c36b-d214-94d9-b790-4944df9ae8b2@cam.ac.uk> Message-ID: On 02/09/18 16:51, Anthony Stone via shifter-users wrote: > Antoine, > > For the record: I find that after I stop an xpra session, I can't start > a new session on the same display with the same command that I have > always used previously, i.e. > xpra start ssh/whirligig/100 --start="gnome-terminal ..." > The log tells me that the lock file for the previous session needs to be > deleted, or that there is already an X session with that name, even if I > have exited from the terminal shell. > > However I can start a session with the same display using > xpra start ssh/whirligig/100 --use-display=yes --start="gnome-terminal ..." > In this case any terminal windows from the previous session that I > haven't closed explicitly reappear along with the new one. Previously > they were closed automatically when I invoked "xpra stop", which is what > I would prefer to happen. Which version are you running? I believe you are hitting this bug: http://xpra.org/trac/ticket/1943 The workaround will be included in the next stable update. In the meantime, since the fix is a trivial one-liner, you could apply it by hand to your existing installation. Cheers, Antoine > > Anthony > > On 31/08/18 10:10, Anthony Stone via shifter-users wrote: >> Antoine, >> >> As recommended, I have set >> start-via-proxy=no >> in /etc/xpra/conf.d/60_server.conf >> (and restarted the server) >> and xpra now starts normally. >> >> Many thanks for the prompt and helpful advice. >> >> Anthony >> >> On 30/08/18 18:13, Antoine Martin wrote: >>> On 30/08/18 23:41, Anthony Stone wrote: >>>> Antoine, >>>> >>>> Thanks for the suggestions. This is what happens: >>> Please always keep the list CCed. >>> >>>> On 30/08/18 04:22, Antoine Martin via shifter-users wrote: >>>>> Directly on the server (ie: via ssh), try to start the session locally: >>>>> xpra start :100 --start="gnome-terminal --window-with-profile=Blue" >>>> >>>> 17:22:05 $ xpra start :100 --start="gnome-terminal >>>> --window-with-profile=Blue" >>>> 2018-08-30 17:22:46,020 server failure: disconnected before the session >>>> could be established >>>> 2018-08-30 17:22:46,020 server requested disconnect: server error >>>> (failed to start a new session) >>>> Warning: cannot use the system proxy for 'start' subcommand, >>>> unknown general failure >>>> more information may be available in your system log >>>> >>>> The system log contains the following. This seems to be an >>>> authentication failure, but I don't know how to fix it. >>>> >>>> Aug 30 17:22:32 whirligig systemd[1]: Started Session 2509 of user ajs1. >>>> Aug 30 17:22:32 whirligig xpra[1192]: reenter password for >>>> pam_mount:(pam_mount.c:477): warning: could not obtain password >>>> interactively either >>>> Aug 30 17:22:32 whirligig xpra[1192]: reenter password for >>>> pam_mount:(pam_mount.c:477): warning: could not obtain password >>>> interactively either >>> Here is what I think is happening: when we start a proper pam session >>> via root (this is what the "starting via proxy" does), we go through the >>> pam session configuration. >>> Your OS seems to include "pam_mount" in there, and that seems to want to >>> ask for a password to do its job. >>> I have no idea why that is, or why it isn't failing more gracefully. >>> >>>> Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,475 Error: >>>> pam_open_session failed: 6 >>>> Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,476 >>>> Permission denied >>>> Aug 30 17:22:32 whirligig xpra[1192]: Entering daemon mode; any further >>>> errors will be reported to: >>>> Aug 30 17:22:32 whirligig xpra[1192]: /run/user/1013/xpra/:100.log >>>> Aug 30 17:22:46 whirligig xpra[1192]: Error: failed to start server >>>> subprocess: >>>> Aug 30 17:22:46 whirligig xpra[1192]: failed to identify the new server >>>> display! >>> The easiest solution to this problem is to not use the proxy, set: >>> start-via-proxy=no >>> in your /etc/xpra/conf.d/60_server.conf >>> >>> On this subject, there seems to be so many ways that distributions >>> manage to configure (break) pam sessions, and logind's KillUserProcesses >>> still defaults to "no" after all these years, so future versions will >>> revert to not using the system wide proxy by default. >>> Those who want the features that require it will have to re-enable it. >>> >>> Cheers, >>> Antoine >>> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From perry at piermont.com Wed Sep 12 12:55:39 2018 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 12 Sep 2018 07:55:39 -0400 Subject: [winswitch] xpra dpi woes with a server running Ubuntu cosmic Message-ID: <20180912075539.760cfb61@jabberwock.cb.piermont.com> Howdy! I'm testing out xpra with a remote server running Ubuntu Cosmic and a client running MacOS, and I've been having some challenges with the setup setting the DPI to weird values. My impression from reading old trouble tickets is that I need to install a patched version of the Xdummy stuff but I'm not exactly sure. What do I need to do, roughly? (I searched and couldn't really find exact instructions...) Thanks in advance! Perry -- Perry E. Metzger perry at piermont.com From antoine at nagafix.co.uk Wed Sep 12 13:17:36 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 12 Sep 2018 19:17:36 +0700 Subject: [winswitch] xpra dpi woes with a server running Ubuntu cosmic In-Reply-To: <20180912075539.760cfb61@jabberwock.cb.piermont.com> References: <20180912075539.760cfb61@jabberwock.cb.piermont.com> Message-ID: On 12/09/2018 18:55, Perry E. Metzger via shifter-users wrote: > Howdy! I'm testing out xpra with a remote server running > Ubuntu Cosmic and a client running MacOS, and I've been having some > challenges with the setup setting the DPI to weird values. What values and where did you find them? > My impression from reading old trouble tickets is that I need to > install a patched version of the Xdummy stuff but I'm not exactly > sure. What do I need to do, roughly? (I searched and couldn't really > find exact instructions...) Everything you need should be here: http://xpra.org/trac/browser/xpra/trunk/debian/xserver-xorg-video-dummy As the Ubuntu 18.10 release nears, we will start pushing packages to the beta repository, this will include the patched dummy driver. Until then, you will need to compile the driver yourself or use another workaround. Cheers, Antoine > > Thanks in advance! > > Perry > From perry at piermont.com Wed Sep 12 13:43:56 2018 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 12 Sep 2018 08:43:56 -0400 Subject: [winswitch] xpra dpi woes with a server running Ubuntu cosmic In-Reply-To: References: <20180912075539.760cfb61@jabberwock.cb.piermont.com> Message-ID: <20180912084356.6fa32e91@jabberwock.cb.piermont.com> On Wed, 12 Sep 2018 19:17:36 +0700 Antoine Martin via shifter-users wrote: > On 12/09/2018 18:55, Perry E. Metzger via shifter-users wrote: > > Howdy! I'm testing out xpra with a remote server running > > Ubuntu Cosmic and a client running MacOS, and I've been having > > some challenges with the setup setting the DPI to weird values. > What values and where did you find them? I found the values in the log. Opening up applications leads to crazy display sizes, and I saw this: 2018-09-11 20:54:07,844 client @18.265 Xpra X11 server version 2.3.2-r19729 64-b it 2018-09-11 20:54:07,845 client @18.266 running on Linux Ubuntu 18.10 cosmic 2018-09-11 20:54:07,849 DPI set to 17 x 21 (wanted 72 x 72) 2018-09-11 20:54:07,849 you may experience scaling problems, such as huge or sm all fonts, etc 2018-09-11 20:54:07,849 to fix this issue, try the dpi switch, or use a patched Xorg dummy driver > > My impression from reading old trouble tickets is that I need to > > install a patched version of the Xdummy stuff but I'm not exactly > > sure. What do I need to do, roughly? (I searched and couldn't > > really find exact instructions...) > Everything you need should be here: > http://xpra.org/trac/browser/xpra/trunk/debian/xserver-xorg-video-dummy Do I just patch xserver-xorg-video-dummy with what's in patches/ ? I presume I can use the Ubuntu source package to do this? Is there a chance of contributing these patches upstream? It would help. And can I install the patched Xdummy somewhere non-standard and point xpra at it? I imagine that something in /etc/xpra/* will let me do that but I don't know how. > As the Ubuntu 18.10 release nears, we will start pushing packages > to the beta repository, this will include the patched dummy driver. > Until then, you will need to compile the driver yourself or use > another workaround. Perry -- Perry E. Metzger perry at piermont.com From perry at piermont.com Wed Sep 12 14:07:00 2018 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 12 Sep 2018 09:07:00 -0400 Subject: [winswitch] xpra dpi woes with a server running Ubuntu cosmic In-Reply-To: <20180912084356.6fa32e91@jabberwock.cb.piermont.com> References: <20180912075539.760cfb61@jabberwock.cb.piermont.com> <20180912084356.6fa32e91@jabberwock.cb.piermont.com> Message-ID: <20180912090700.1d10ee8d@jabberwock.cb.piermont.com> On Wed, 12 Sep 2018 08:43:56 -0400 "Perry E. Metzger via shifter-users" wrote: > > > My impression from reading old trouble tickets is that I need to > > > install a patched version of the Xdummy stuff but I'm not > > > exactly sure. What do I need to do, roughly? (I searched and > > > couldn't really find exact instructions...) > > > Everything you need should be here: > > http://xpra.org/trac/browser/xpra/trunk/debian/xserver-xorg-video-dummy BTW, thanks! > Do I just patch xserver-xorg-video-dummy with what's in patches/ ? > I presume I can use the Ubuntu source package to do this? That worked for me. I'm still not quite sure what the _correct_ dpi for my setup is (how can I figure that out?) but setting things to 72 is now accepted and the emacs I launch no longer looks crazy. When I set the DPI to 110 (which is closer to what is actually true on my screen) the emacs ends up a bit distorted again, with the width of the display not being 80 columns when it first comes up. I'm not sure why. > Is there a chance of contributing these patches upstream? It would > help. It really would.... > And can I install the patched Xdummy somewhere non-standard and > point xpra at it? I imagine that something in /etc/xpra/* will let > me do that but I don't know how. For now I just did a dpkg -i on the generated .deb but I have to confess I don't know what will happen if the thing gets overwritten. My unix fu is stronger than my dpkg fu. Perry -- Perry E. Metzger perry at piermont.com From perry at piermont.com Wed Sep 12 14:34:24 2018 From: perry at piermont.com (Perry E. Metzger) Date: Wed, 12 Sep 2018 09:34:24 -0400 Subject: [winswitch] Default settings for features in Mac Xpra Message-ID: <20180912093424.70ad483f@jabberwock.cb.piermont.com> Howdy! On my Mac, the Xpra menu features several "features", like swapping the control and command key (which I want to disable) and inverting the direction of the mouse wheel (which I'd like to enable). I'm not clear on what to set in my xpra.conf to do these things. I tried "xpra showconfig" but nothing popped out at me. Is there a good place (even in the source!) to look at these settings? Perry -- Perry E. Metzger perry at piermont.com From antoine at nagafix.co.uk Thu Sep 13 09:52:03 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 13 Sep 2018 15:52:03 +0700 Subject: [winswitch] xpra dpi woes with a server running Ubuntu cosmic In-Reply-To: <20180912084356.6fa32e91@jabberwock.cb.piermont.com> References: <20180912075539.760cfb61@jabberwock.cb.piermont.com> <20180912084356.6fa32e91@jabberwock.cb.piermont.com> Message-ID: On 12/09/2018 19:43, Perry E. Metzger wrote: > On Wed, 12 Sep 2018 19:17:36 +0700 Antoine Martin via shifter-users > wrote: >> On 12/09/2018 18:55, Perry E. Metzger via shifter-users wrote: >>> Howdy! I'm testing out xpra with a remote server running >>> Ubuntu Cosmic and a client running MacOS, and I've been having >>> some challenges with the setup setting the DPI to weird values. >> What values and where did you find them? > > I found the values in the log. Opening up applications leads to crazy > display sizes, and I saw this: > > 2018-09-11 20:54:07,844 client @18.265 Xpra X11 server version 2.3.2-r19729 64-b > it > 2018-09-11 20:54:07,845 client @18.266 running on Linux Ubuntu 18.10 cosmic > 2018-09-11 20:54:07,849 DPI set to 17 x 21 (wanted 72 x 72) > 2018-09-11 20:54:07,849 you may experience scaling problems, such as huge or sm > all fonts, etc > 2018-09-11 20:54:07,849 to fix this issue, try the dpi switch, or use a patched > Xorg dummy driver Right, that's the simulated "hardware DPI" that some applications use. Out of curiosity, which application misbehaved? (everything would be much easier if they just used some user-configurable value like Xft/DPI instead) >>> My impression from reading old trouble tickets is that I need to >>> install a patched version of the Xdummy stuff but I'm not exactly >>> sure. What do I need to do, roughly? (I searched and couldn't >>> really find exact instructions...) >> Everything you need should be here: >> http://xpra.org/trac/browser/xpra/trunk/debian/xserver-xorg-video-dummy > > Do I just patch xserver-xorg-video-dummy with what's in patches/ ? Yes. > I presume I can use the Ubuntu source package to do this? Yes. > Is there a chance of contributing these patches upstream? It would > help. That's very very unlikely to be merged upstream. The DPI patch is really hackish. > And can I install the patched Xdummy somewhere non-standard and point > xpra at it? I imagine that something in /etc/xpra/* will let me do > that but I don't know how. You can use ModulePath in xorg.conf: ftp://www.x.org/pub/X11R7.7-RC1/doc/man/man5/xorg.conf.5.xhtml >> As the Ubuntu 18.10 release nears, we will start pushing packages >> to the beta repository, this will include the patched dummy driver. >> Until then, you will need to compile the driver yourself or use >> another workaround. I have started pushing packages to the xpra "cosmic" repositories, including the patched dummy driver. Simply adding the repository and updating should give you all you need. If those packages work for you, please comment or close this ticket: https://xpra.org/trac/ticket/1959 Cheers, Antoine > > Perry > From antoine at nagafix.co.uk Thu Sep 13 10:14:37 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 13 Sep 2018 16:14:37 +0700 Subject: [winswitch] xpra dpi - (was: woes with a server running Ubuntu cosmic) In-Reply-To: <20180912090700.1d10ee8d@jabberwock.cb.piermont.com> References: <20180912075539.760cfb61@jabberwock.cb.piermont.com> <20180912084356.6fa32e91@jabberwock.cb.piermont.com> <20180912090700.1d10ee8d@jabberwock.cb.piermont.com> Message-ID: <5e339905-c23a-5c1d-384e-1ea2ad8f27ab@nagafix.co.uk> On 12/09/2018 20:07, Perry E. Metzger via shifter-users wrote: > On Wed, 12 Sep 2018 08:43:56 -0400 "Perry E. Metzger via > shifter-users" wrote: >>>> My impression from reading old trouble tickets is that I need to >>>> install a patched version of the Xdummy stuff but I'm not >>>> exactly sure. What do I need to do, roughly? (I searched and >>>> couldn't really find exact instructions...) >> >>> Everything you need should be here: >>> http://xpra.org/trac/browser/xpra/trunk/debian/xserver-xorg-video-dummy > > BTW, thanks! > >> Do I just patch xserver-xorg-video-dummy with what's in patches/ ? >> I presume I can use the Ubuntu source package to do this? > > That worked for me. I'm still not quite sure what the _correct_ dpi > for my setup is (how can I figure that out?) In theory, xpra will figure out the DPI in use by the client (taken from the command line option if it is specified, then trying user-configurable places like Xft/DPI, and falling back to a calculated "hardware DPI" if nothing else is available), it then tells the server to apply this DPI value to the virtual framebuffer. With the patched dummy driver, the virtual framebuffer used by the server should have the exact virtual "hardware" geometry requested by the client. Applications started after this framebuffer resizing event should see the correct screen resolution no matter how they look it up. (ie: use --start-after-connect=whatever) For multimonitor setups, libfakeXinerama helps in some rare cases: https://xpra.org/trac/wiki/FakeXinerama But this is not packaged for Debian or Ubuntu yet. The alternative is to use Xvfb in /etc/xpra/conf.d/55_server_x11.conf Xvfb starts with a fixed DPI value and will not adapt to the client's screen resolution. Which means that applications that honour Xft/DPI will have the "correct" DPI, whereas applications that use a calculated "hardware DPI" will get the fixed DPI value. Xvfb has the small disadvantage of not supporting some of the more advanced input device virtualization features like precise scrolling: https://xpra.org/trac/ticket/1611 > but setting things to 72 How? > is now accepted and the emacs I launch no longer looks crazy. When I > set the DPI to 110 (which is closer to what is actually true on my > screen) the emacs ends up a bit distorted again, with the width of the > display not being 80 columns when it first comes up. I'm not sure why. If you think this is a bug that should be fixed, please file a ticket. >> Is there a chance of contributing these patches upstream? It would >> help. > > It really would.... As I said in my other reply, that's very unlikely to be accepted, ever. (even though we are the primary users of the dummy driver and the solution is small and reliable, it is just not very "clean") >> And can I install the patched Xdummy somewhere non-standard and >> point xpra at it? I imagine that something in /etc/xpra/* will let >> me do that but I don't know how. > > For now I just did a dpkg -i on the generated .deb but I have to > confess I don't know what will happen if the thing gets > overwritten. My unix fu is stronger than my dpkg fu. This build has a newer version number than the one available in the standard Ubuntu repositories, so it is very unlikely to be replaced during system updates. Cheers, Antoine > > Perry > From antoine at nagafix.co.uk Thu Sep 13 10:30:18 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 13 Sep 2018 16:30:18 +0700 Subject: [winswitch] Default settings for features in Mac Xpra In-Reply-To: <20180912093424.70ad483f@jabberwock.cb.piermont.com> References: <20180912093424.70ad483f@jabberwock.cb.piermont.com> Message-ID: <233d0573-f8c9-f1da-3aee-f9032186421e@nagafix.co.uk> On 12/09/2018 20:34, Perry E. Metzger via shifter-users wrote: > Howdy! > > On my Mac, the Xpra menu features several "features", like swapping > the control and command key (which I want to disable) and inverting > the direction of the mouse wheel (which I'd like to enable). I'm not > clear on what to set in my xpra.conf to do these things. I tried > "xpra showconfig" but nothing popped out at me. Is there a good place > (even in the source!) to look at these settings? xpra showconfig | egrep -i "wheel|swap" Should show: mousewheel = 'on' swap-keys = True You can override these settings on the command line or place them in your xpra.conf: echo "mousewheel = invert-y" >> ~/.xpra/xpra.conf echo "swap-keys = no" >> ~/.xpra/xpra.conf Then running that same command again should now show: mousewheel = 'invert-y' swap-keys = False These options are shown in the command line help: xpra -h It was missing from the manual, but this has been rectified and will be in the next version, in the meantime you can use the online version: https://xpra.org/manual.html Cheers, Antoine > > Perry > From perry at piermont.com Thu Sep 13 15:28:08 2018 From: perry at piermont.com (Perry E. Metzger) Date: Thu, 13 Sep 2018 10:28:08 -0400 Subject: [winswitch] xpra dpi woes with a server running Ubuntu cosmic In-Reply-To: References: <20180912075539.760cfb61@jabberwock.cb.piermont.com> <20180912084356.6fa32e91@jabberwock.cb.piermont.com> Message-ID: <20180913102808.08bcea3c@jabberwock.cb.piermont.com> On Thu, 13 Sep 2018 15:52:03 +0700 Antoine Martin wrote: > > I found the values in the log. Opening up applications leads to > > crazy display sizes, and I saw this: > > > > 2018-09-11 20:54:07,844 client @18.265 Xpra X11 server version > > 2.3.2-r19729 64-b it > > 2018-09-11 20:54:07,845 client @18.266 running on Linux Ubuntu > > 18.10 cosmic 2018-09-11 20:54:07,849 DPI set to 17 x 21 (wanted > > 72 x 72) 2018-09-11 20:54:07,849 you may experience scaling > > problems, such as huge or sm all fonts, etc > > 2018-09-11 20:54:07,849 to fix this issue, try the dpi switch, > > or use a patched Xorg dummy driver > Right, that's the simulated "hardware DPI" that some applications > use. Out of curiosity, which application misbehaved? Emacs. It behaved very, very badly. > > Is there a chance of contributing these patches upstream? It would > > help. > > That's very very unlikely to be merged upstream. > The DPI patch is really hackish. Is a less hackish version possible that upstream would take? It would eliminate the maintenance issue with every release. > You can use ModulePath in xorg.conf: > ftp://www.x.org/pub/X11R7.7-RC1/doc/man/man5/xorg.conf.5.xhtml > > >> As the Ubuntu 18.10 release nears, we will start pushing packages > >> to the beta repository, this will include the patched dummy > >> driver. Until then, you will need to compile the driver yourself > >> or use another workaround. > I have started pushing packages to the xpra "cosmic" repositories, > including the patched dummy driver. Simply adding the repository and > updating should give you all you need. What's the correct line for my sources.list? > If those packages work for you, please comment or close this ticket: > https://xpra.org/trac/ticket/1959 Will do. -- Perry E. Metzger perry at piermont.com From antoine at nagafix.co.uk Thu Sep 13 15:41:54 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 13 Sep 2018 21:41:54 +0700 Subject: [winswitch] xpra dpi woes with a server running Ubuntu cosmic In-Reply-To: <20180913102808.08bcea3c@jabberwock.cb.piermont.com> References: <20180912075539.760cfb61@jabberwock.cb.piermont.com> <20180912084356.6fa32e91@jabberwock.cb.piermont.com> <20180913102808.08bcea3c@jabberwock.cb.piermont.com> Message-ID: <3c3e08c0-48e3-04a1-a54c-e01c64a0d946@nagafix.co.uk> On 13/09/2018 21:28, Perry E. Metzger wrote: > On Thu, 13 Sep 2018 15:52:03 +0700 Antoine Martin > wrote: >>> I found the values in the log. Opening up applications leads to >>> crazy display sizes, and I saw this: >>> >>> 2018-09-11 20:54:07,844 client @18.265 Xpra X11 server version >>> 2.3.2-r19729 64-b it >>> 2018-09-11 20:54:07,845 client @18.266 running on Linux Ubuntu >>> 18.10 cosmic 2018-09-11 20:54:07,849 DPI set to 17 x 21 (wanted >>> 72 x 72) 2018-09-11 20:54:07,849 you may experience scaling >>> problems, such as huge or sm all fonts, etc >>> 2018-09-11 20:54:07,849 to fix this issue, try the dpi switch, >>> or use a patched Xorg dummy driver >> Right, that's the simulated "hardware DPI" that some applications >> use. Out of curiosity, which application misbehaved? > > Emacs. It behaved very, very badly. > >>> Is there a chance of contributing these patches upstream? It would >>> help. >> >> That's very very unlikely to be merged upstream. >> The DPI patch is really hackish. > > Is a less hackish version possible that upstream would take? It would > eliminate the maintenance issue with every release. Not in its present form. There have been talks of merging proper randr support, but things have gone very quiet: https://lists.freedesktop.org/archives/xorg/2016-June/058128.html randr 1.5 support would allow us to configure virtual monitors. Here's xpra's tracker ticket for this issue: https://xpra.org/trac/ticket/56 >> You can use ModulePath in xorg.conf: >> ftp://www.x.org/pub/X11R7.7-RC1/doc/man/man5/xorg.conf.5.xhtml >> >>>> As the Ubuntu 18.10 release nears, we will start pushing packages >>>> to the beta repository, this will include the patched dummy >>>> driver. Until then, you will need to compile the driver yourself >>>> or use another workaround. >> I have started pushing packages to the xpra "cosmic" repositories, >> including the patched dummy driver. Simply adding the repository and >> updating should give you all you need. > > What's the correct line for my sources.list? Place one of those in /etc/apt/sources.list.d/ https://xpra.org/repos/cosmic/xpra.list or: https://xpra.org/repos/cosmic/xpra-beta.list Cheers, Antoine >> If those packages work for you, please comment or close this ticket: >> https://xpra.org/trac/ticket/1959 > > Will do. > From perry at piermont.com Fri Sep 14 20:53:41 2018 From: perry at piermont.com (Perry E. Metzger) Date: Fri, 14 Sep 2018 15:53:41 -0400 Subject: [winswitch] Build procedure for Mac... Message-ID: <20180914155341.6a26d890@jabberwock.cb.piermont.com> Howdy! I am a MacPorts committer, and was thinking of adding a Portfile to build the Mac client to MacPorts. Is there a good explanation of the build process for the Mac client somewhere on the web site? Perry -- Perry E. Metzger perry at piermont.com From antoine at nagafix.co.uk Sat Sep 15 05:37:40 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 15 Sep 2018 11:37:40 +0700 Subject: [winswitch] Build procedure for Mac... In-Reply-To: <20180914155341.6a26d890@jabberwock.cb.piermont.com> References: <20180914155341.6a26d890@jabberwock.cb.piermont.com> Message-ID: <5b6ff89d-dda2-2f6d-d989-8a00ad2f9344@nagafix.co.uk> On 15/09/2018 02:53, Perry E. Metzger via shifter-users wrote: > Howdy! I am a MacPorts committer, and was thinking of adding a > Portfile to build the Mac client to MacPorts. > > Is there a good explanation of the build process for the Mac > client somewhere on the web site? https://xpra.org/trac/wiki/Building/MacOSX Building and installing xpra itself is trivial: ./setup.py build ./setup.py install Tracking down all the dependencies is harder. For that, you should be able to use the jhbuild moduleset files that we use: https://xpra.org/trac/browser/xpra/trunk/osx/jhbuild Feel free to ask any questions if you get stuck. Note that xpra does not use X11 at all on MacOS, so you will need a native build of GTK. Cheers, Antoine > > Perry > From perry at piermont.com Sat Sep 15 15:43:48 2018 From: perry at piermont.com (Perry E. Metzger) Date: Sat, 15 Sep 2018 10:43:48 -0400 Subject: [winswitch] Build procedure for Mac... In-Reply-To: <5b6ff89d-dda2-2f6d-d989-8a00ad2f9344@nagafix.co.uk> References: <20180914155341.6a26d890@jabberwock.cb.piermont.com> <5b6ff89d-dda2-2f6d-d989-8a00ad2f9344@nagafix.co.uk> Message-ID: <20180915104348.3597f37b@jabberwock.cb.piermont.com> On Sat, 15 Sep 2018 11:37:40 +0700 Antoine Martin via shifter-users wrote: > On 15/09/2018 02:53, Perry E. Metzger via shifter-users wrote: > > Howdy! I am a MacPorts committer, and was thinking of adding a > > Portfile to build the Mac client to MacPorts. > > > > Is there a good explanation of the build process for the Mac > > client somewhere on the web site? > https://xpra.org/trac/wiki/Building/MacOSX > > Building and installing xpra itself is trivial: > ./setup.py build > ./setup.py install > Tracking down all the dependencies is harder. For that, you should > be able to use the jhbuild moduleset files that we use: MacPorts handles dependencies internally. > https://xpra.org/trac/browser/xpra/trunk/osx/jhbuild > Feel free to ask any questions if you get stuck. > Note that xpra does not use X11 at all on MacOS, so you will need a > native build of GTK. Yah, I'm aware. This gets slightly sticky because we can't currently install both native and x11 GTK at the same time, but I'm thinking of fixing that anyway. -- Perry E. Metzger perry at piermont.com From perry at piermont.com Sun Sep 16 01:13:02 2018 From: perry at piermont.com (Perry E. Metzger) Date: Sat, 15 Sep 2018 20:13:02 -0400 Subject: [winswitch] Weird problem with display going transparent? Message-ID: <20180915201302.3326611c@jabberwock.cb.piermont.com> I'm on MacOS 10.13.6. At times, xprm windows I'm using become partially or fully transparent for no obvious reason. (Partially = portions of the window become transparent, not that the window becomes semi-transparent.) This clearly is a bug of some sort. Any idea what might be triggering it or what workarounds might be? Perry -- Perry E. Metzger perry at piermont.com From antoine at nagafix.co.uk Sun Sep 16 04:35:33 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 16 Sep 2018 10:35:33 +0700 Subject: [winswitch] Weird problem with display going transparent? In-Reply-To: <20180915201302.3326611c@jabberwock.cb.piermont.com> References: <20180915201302.3326611c@jabberwock.cb.piermont.com> Message-ID: <7b1454d7-85e9-e931-3271-37a4aea2635d@nagafix.co.uk> On 16/09/2018 07:13, Perry E. Metzger via shifter-users wrote: > I'm on MacOS 10.13.6. At times, xprm Do you mean xpra? > windows I'm using become > partially or fully transparent for no obvious reason. (Partially = > portions of the window become transparent, not that the window > becomes semi-transparent.) Does this affect all windows or only the ones from specific applications? You can try running the client with "--debug metadata". The log output should tell us if the window is meant to be using transparency to begin with. (ie: window opacity or alpha channel) > This clearly is a bug of some sort. Any idea what might be triggering > it or what workarounds might be? run your client or server with: XPRA_ALPHA=0 xpra ... This is a big hammer which will disable transparency completely for all windows. (not ideal but acceptable as a workaround) Since only part of the windows are transparent, this could also be caused by one of the picture encoders wrongly setting the alpha channel - you should be able to confirm that by changing the picture encodings. (ie run with: --encodings=rgb,png) Otherwise, the bug may be triggered by the client rendering backend, try turning OpenGL on or off. Cheers, Antoine > > Perry > From antoine at nagafix.co.uk Sun Sep 16 04:40:48 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 16 Sep 2018 10:40:48 +0700 Subject: [winswitch] Build procedure for Mac... In-Reply-To: <20180915104348.3597f37b@jabberwock.cb.piermont.com> References: <20180914155341.6a26d890@jabberwock.cb.piermont.com> <5b6ff89d-dda2-2f6d-d989-8a00ad2f9344@nagafix.co.uk> <20180915104348.3597f37b@jabberwock.cb.piermont.com> Message-ID: <3957abbd-9802-e8a4-e302-d108f63bd0ca@nagafix.co.uk> On 15/09/2018 21:43, Perry E. Metzger wrote: > On Sat, 15 Sep 2018 11:37:40 +0700 Antoine Martin via shifter-users > wrote: >> On 15/09/2018 02:53, Perry E. Metzger via shifter-users wrote: >>> Howdy! I am a MacPorts committer, and was thinking of adding a >>> Portfile to build the Mac client to MacPorts. >>> >>> Is there a good explanation of the build process for the Mac >>> client somewhere on the web site? >> https://xpra.org/trac/wiki/Building/MacOSX >> >> Building and installing xpra itself is trivial: >> ./setup.py build >> ./setup.py install >> Tracking down all the dependencies is harder. For that, you should >> be able to use the jhbuild moduleset files that we use: > > MacPorts handles dependencies internally. That's my point: we ship a full-featured DMG (or PKG) on MacOS. With MacPorts, you have more freedom which means you will need to decide which dependencies are enabled by default and which ones are optional. You can use the Debian control file and/or the RPM specfile to help you figure out which dependencies are not strictly required. >> https://xpra.org/trac/browser/xpra/trunk/osx/jhbuild >> Feel free to ask any questions if you get stuck. >> Note that xpra does not use X11 at all on MacOS, so you will need a >> native build of GTK. > > Yah, I'm aware. This gets slightly sticky because we can't currently > install both native and x11 GTK at the same time, but I'm thinking of > fixing that anyway. That would be great. This would allow us to build a "real" xpra server for seamless X11 apps on MacOS and have it co-exist with the native client. Cheers, Antoine From perry at piermont.com Tue Sep 18 19:54:18 2018 From: perry at piermont.com (Perry E. Metzger) Date: Tue, 18 Sep 2018 14:54:18 -0400 Subject: [winswitch] Weird problem with display going transparent? In-Reply-To: <7b1454d7-85e9-e931-3271-37a4aea2635d@nagafix.co.uk> References: <20180915201302.3326611c@jabberwock.cb.piermont.com> <7b1454d7-85e9-e931-3271-37a4aea2635d@nagafix.co.uk> Message-ID: <20180918145418.1f44078a@jabberwock.cb.piermont.com> On Sun, 16 Sep 2018 10:35:33 +0700 Antoine Martin via shifter-users wrote: > On 16/09/2018 07:13, Perry E. Metzger via shifter-users wrote: > > I'm on MacOS 10.13.6. At times, xprm > Do you mean xpra? Sorry, keyboard slip, yes, xpra. > > windows I'm using become > > partially or fully transparent for no obvious reason. (Partially = > > portions of the window become transparent, not that the window > > becomes semi-transparent.) > > Does this affect all windows or only the ones from specific > applications? I notice it more often with terminal applications, but it seems to be happening without much rhyme or reason. > You can try running the client with "--debug metadata". > The log output should tell us if the window is meant to be using > transparency to begin with. (ie: window opacity or alpha channel) I'll try that, and the rest of your suggestions. > > > This clearly is a bug of some sort. Any idea what might be > > triggering it or what workarounds might be? > run your client or server with: > XPRA_ALPHA=0 xpra ... > This is a big hammer which will disable transparency completely for > all windows. (not ideal but acceptable as a workaround) > Since only part of the windows are transparent, this could also be > caused by one of the picture encoders wrongly setting the alpha > channel > - you should be able to confirm that by changing the picture > encodings. (ie run with: --encodings=rgb,png) > Otherwise, the bug may be triggered by the client rendering > backend, try turning OpenGL on or off. > > Cheers, > Antoine > > > > > Perry > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > -- Perry E. Metzger perry at piermont.com From antoine at nagafix.co.uk Sun Sep 23 06:09:09 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 23 Sep 2018 12:09:09 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.3.4 : many fixes, some important Message-ID: <0419e8bd-bbfb-8a2d-e255-286c4fb301e0@nagafix.co.uk> Hi, Once again, this release contains a very large number of fixes. At least one of these fixes is important: the server shutdown fix could leave dangling virtual displays and sockets on exit. Otherwise the areas that received the most fixes are: Python3 builds, VNC clients, build and test fixes, better OS compatibility (shells, libraries, display detection, packaging, etc) and UI fixes (mixed clicks on tray, scaling, tray icon corruption, etc). Updating is strongly recommended. Release notes: * fix server does not shutdown cleanly (Xvfb not killed) * fix signals not emitted (ie: delay-tray command line option) * fix client desktop-scaling corner cases * fix handling of mixed clicks on system tray and the menu entries * fix MS Windows shadow server's cursor capture * fix URL parsing from launcher (ie: MacOS URL association) * fix MacOS crash with GTK3 builds and file chooser * fix non-opengl windows missing spinner with GTK3 * fix RPM license information * fix mDNS zeroconf library version on MS Windows with Python 2 * fix connection errors from making the client launcher exit * fix python3 errors in dbus server code * fix spurious error messages caused by video pipeline changes * fix proxy-video-encoders=all substitution * fix unicode string errors with RFB protocol and Python 3 * fix missing idle and clipboard server information * fix .xpra file association with DEB packaging * fix pointer polling error with RFB connections (pointer going AWOL) * fix handling of closed RFB connections * fix unmanaged X11 call from shadow servers (potential crashes) * fix fallback pynotify notification handler * fix Python 3 shadow servers with RFB * fix Python 3 string errors writing run-xpra scripts * fix deadlocks with RFB connections * fix missing key mapping errors with RFB clients * fix session name not honoured or exposed via mdns for shadow servers * fix X11 display detection (socket may be owned by root) * fix compatibility with csh and tcsh * fix spurious modifier key events from the HTML5 client * fix tray icon corruption on MS Windows * fix Motif WM hints parsing * fix DEB packaging dependencies * fix NVENC encoder wrongly exposing encodings which are not available * fix error running unit tests on MS Windows * fix potential file descriptor leak * fix valid XAuthority path potentially not found because unexpanded * fix proxy servers not honouring passwords in connection strings * fix sqlite authentication backend issue with identical usernames * support CUDA 10 and optimizations for Volta GPUs * Fedora 29 compatibility * fix race condition in unit tests which was causing random failures * add dependency required for running the unit tests with rpmbuild * prevent repeated clipboard warnings * let the server choose the best initial quality to use * add file missing from clean build target * add missing entries in man page * add missing desktop file icons * shadow the current display if none is specified * remove unneeded import, spurious debug logging * limit the amount of information exposed via the proxy's dbus service * support base64 encoded SSL certificate data The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From ajs1 at cam.ac.uk Wed Sep 26 10:27:17 2018 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Wed, 26 Sep 2018 10:27:17 +0100 Subject: [winswitch] Xpra niggle Message-ID: <95117aa1-c628-856a-f597-e37cce35bdf0@cam.ac.uk> The latest version of xpra behaves much better on startup and closedown -- thanks for fixing this. There is still a minor peculiarity: on startup I get the following (Ubuntu 16.04): ... 2018-09-26 10:10:42,832 desktop size is 1920x1080 with 1 screen: 2018-09-26 10:10:42,832 :0.0 (508x285 mm - DPI: 96x96) workarea: 1867x1056 at 53x24 2018-09-26 10:10:42,832 monitor 1 (521x293 mm - DPI: 93x93) 2018-09-26 10:10:42,833 keyboard settings: rules=evdev, model=hpi6, layout=gb,us 2018-09-26 10:10:42,856 Warning: invalid frame extents value '[0, 0, 28, 0]' 2018-09-26 10:10:42,856 this is probably a bug in 'Compiz' 2018-09-26 10:10:42,856 using '[0, 0, 28, 0]' instead ... Is the frame extents value '[0, 0, 28, 0]' really invalid? Is this a bug in Compiz or in xpra? Anthony From antoine at nagafix.co.uk Wed Sep 26 13:10:57 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 26 Sep 2018 19:10:57 +0700 Subject: [winswitch] Xpra niggle In-Reply-To: <95117aa1-c628-856a-f597-e37cce35bdf0@cam.ac.uk> References: <95117aa1-c628-856a-f597-e37cce35bdf0@cam.ac.uk> Message-ID: <119f9357-8a28-daaf-0077-6dde45e29b44@nagafix.co.uk> On 26/09/2018 16:27, Anthony Stone via shifter-users wrote: > The latest version of xpra behaves much better on startup and closedown > -- thanks for fixing this. There is still a minor peculiarity: on > startup I get the following (Ubuntu 16.04): > > ... > 2018-09-26 10:10:42,832 desktop size is 1920x1080 with 1 screen: > 2018-09-26 10:10:42,832 :0.0 (508x285 mm - DPI: 96x96) workarea: > 1867x1056 at 53x24 > 2018-09-26 10:10:42,832 monitor 1 (521x293 mm - DPI: 93x93) > 2018-09-26 10:10:42,833 keyboard settings: rules=evdev, model=hpi6, > layout=gb,us > 2018-09-26 10:10:42,856 Warning: invalid frame extents value '[0, 0, 28, 0]' > 2018-09-26 10:10:42,856 this is probably a bug in 'Compiz' > 2018-09-26 10:10:42,856 using '[0, 0, 28, 0]' instead > ... > > Is the frame extents value '[0, 0, 28, 0]' really invalid? Is this a bug > in Compiz or in xpra? It's been like this for as long as we've been parsing frame extents. The warning message was wrong and printed the already-truncated value twice, that's now fixed: https://xpra.org/trac/changeset/20535 More details here: https://xpra.org/trac/ticket/1279 For the record, since the compiz code looked correct, I also suspected a bug in xpra but I couldn't find one so I even tried to query the frame extents using "xprop" and found the same invalid values that way. Cheers, Antoine From wssddc-xpra at wssddc.com Sat Sep 29 06:08:34 2018 From: wssddc-xpra at wssddc.com (Bob Babcock) Date: Sat, 29 Sep 2018 01:08:34 -0400 Subject: [winswitch] OpenGL Setup Failure Message-ID: <7ea1775a-1030-c0cd-bec6-487c2a6b9458@wssddc.com> When I connect from Windows 7 to Linux with Xpra, I get a graphical popup: OpenGL Setup Failure constructFunction() got an unexpected keyword argument 'force_extension' This doesn't seem to break anything.? I suspect it means I need to update something on the Linux side, but I don't know what. Windows side is Xpra 2.3.4 or 2.4-r20214 beta (32-bit) (Windows version 2.1.1.0 does not trigger this message) Linux side is Fedora 28.? Xpra routines installed: rpm -qa|grep -i xpra xpra-common-server-2.3.4-1.r20509.fc28.noarch xpra-common-client-2.3.4-1.r20509.fc28.noarch python2-xpra-server-2.3.4-1.r20509.fc28.x86_64 xpra-html5-2.3.4-1.r20509.fc28.noarch ffmpeg-xpra-4.0.2-1.fc28.x86_64 xpra-2.3.4-1.r20509.fc28.x86_64 x264-xpra-20180401-0.fc28.x86_64 xpra-common-2.3.4-1.r20509.fc28.noarch python2-xpra-client-2.3.4-1.r20509.fc28.x86_64 xorg-x11-drv-dummy-0.3.8-1.xpra1.fc28.x86_64 python2-xpra-audio-2.3.4-1.r20509.fc28.x86_64 python2-xpra-2.3.4-1.r20509.fc28.x86_64 OpenGL routines installed: rpm -qa|grep -i opengl python3-pyopengl-3.1.1a1-10.fc28.x86_64 python2-pyopengl-3.1.1a1-10.fc28.x86_64 libglvnd-opengl-1.1.0-1.fc28.x86_64 A windows bat file sets various environment variables, then starts xpra with the line: start xpra start --start-child="xterm -xrm XTerm.vt100.allowTitleOps:false -title %username%@%host%:%display%" --speaker=off --ssh="plink -ssh -agent -P %port%" ssh/%username%@%host%:%port%/%display% Any suggestions?? Thanks. From antoine at nagafix.co.uk Sat Sep 29 09:12:05 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 29 Sep 2018 15:12:05 +0700 Subject: [winswitch] OpenGL Setup Failure In-Reply-To: <7ea1775a-1030-c0cd-bec6-487c2a6b9458@wssddc.com> References: <7ea1775a-1030-c0cd-bec6-487c2a6b9458@wssddc.com> Message-ID: <308e0883-51a5-11e8-9aa9-39cf4b85e2a1@nagafix.co.uk> On 29/09/2018 12:08, Bob Babcock via shifter-users wrote: > When I connect from Windows 7 to Linux with Xpra, I get a graphical popup: > > OpenGL Setup Failure > constructFunction() got an unexpected keyword argument 'force_extension' You're hitting this issue from the PyOpenGL project: https://github.com/mcfletch/pyopengl/issues/15 I had updated PyOpenGL on the MS Windows build systems (this was only mandatory for the Python 3 builds) without realizing that this broke something in the Python 2 builds. Thanks for pointing that out. > This doesn't seem to break anything.? I suspect it means I need to > update something on the Linux side, but I don't know what. It means that your client will be running without OpenGL acceleration, which will make it slower. > Windows side is Xpra 2.3.4 or 2.4-r20214 beta (32-bit) > (Windows version 2.1.1.0 does not trigger this message) Is there a particular reason why you're using the 32-bit version? We are planning on dropping 32-bit support after the next LTS release. (..) > A windows bat file sets various environment variables, then starts xpra > with the line: > > ?? start xpra start --start-child="xterm -xrm > XTerm.vt100.allowTitleOps:false > ?? -title %username%@%host%:%display%" --speaker=off --ssh="plink -ssh > -agent > ?? -P %port%" ssh/%username%@%host%:%port%/%display% FYI: you are specifying the ssh port twice, I'm not sure which one will take precedence, but specifying it once in the connection string ought to be enough. > Any suggestions?? Thanks. I've uploaded newer builds for both 2.3.4 and 2.4 beta, those include the correct version of PyOpenGL and should fix this problem. Cheers, Antoine From wssddc-xpra at wssddc.com Sat Sep 29 21:14:33 2018 From: wssddc-xpra at wssddc.com (Bob Babcock) Date: Sat, 29 Sep 2018 16:14:33 -0400 Subject: [winswitch] OpenGL Setup Failure In-Reply-To: <308e0883-51a5-11e8-9aa9-39cf4b85e2a1@nagafix.co.uk> References: <7ea1775a-1030-c0cd-bec6-487c2a6b9458@wssddc.com> <308e0883-51a5-11e8-9aa9-39cf4b85e2a1@nagafix.co.uk> Message-ID: Antoine Martin via shifter-users wrote: > Is there a particular reason why you're using the 32-bit version? > We are planning on dropping 32-bit support after the next LTS release. I've got a cheap ($99) 32-bit laptop running Windows 8.1 that I use when traveling.? It's slow, but typical hotel internet connections are even slower.? I installed the same version on my desktop for consistency.? (Just now I replaced it with the 64-bit beta.)? Side note: on this laptop, xpra 2.3.4 initially failed (missing dll) because it needed a visual c++ runtime.? Easy to fix, but shouldn't the installer detect this dependency and send you off to Microsoft to get the runtime? > FYI: you are specifying the ssh port twice, I'm not sure which one will > take precedence, but specifying it once in the connection string ought > to be enough. I remember lots of fiddling to get a command line that worked.? One complication is that I use a non-standard ssh port when coming in from the outside world, so any changes have to be tested both locally and remotely. > I've uploaded newer builds for both 2.3.4 and 2.4 beta, those include > the correct version of PyOpenGL and should fix this problem. I tested both 2.3.4 and 2.4 beta; the openGL error is gone in both cases.? Thanks for the quick fix.