From joshiggins at gmail.com Sun Apr 7 01:23:28 2013 From: joshiggins at gmail.com (Joshua Higgins) Date: Sat, 6 Apr 2013 21:23:28 -0300 Subject: [winswitch] correct syntax for xpra --bind-tcp using ipv6? Message-ID: Hi list what is the correct syntax for xpra start --bind-tcp when using IPv6? I've tried xpra start --bind-tcp="[::1]:60000", which brings the error: invalid literal for int() with base 10: ':]:60000 It looks like xpra attach parses IPv6 correctly ( http://xpra.org/trac/ticket/119) with a different syntax so was wondering if there is a similar case for the bind-tcp option instead of this being a bug. Thanks, Josh -- *Josh Higgins* joshiggins at gmail.com From nick at sqrt.co.uk Sun Apr 7 09:07:16 2013 From: nick at sqrt.co.uk (Nick Burrett) Date: Sun, 7 Apr 2013 09:07:16 +0100 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: <51448317.20209@nagafix.co.uk> References: <51448317.20209@nagafix.co.uk> Message-ID: I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on Ubuntu quantal (12.10) Rendering is certainly faster, however just moving the mouse across the various menu items at the top of the window will flick between the current image and a previous window image and will regularly produce this: 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 Compatibility Profile Context 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects available 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program available 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle available 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program available 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press Control-C to detach) 2013-04-07 09:05:00,204 do_paint_rgb24 error Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", line 371, in do_paint_rgb24 self._do_paint_rgb24(img_data, x, y, width, height, rowstride, options, callbacks) File "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", line 181, in _do_paint_rgb24 self.gl_end(drawable) File "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", line 127, in gl_end if drawable.is_double_buffered(): AttributeError: 'NoneType' object has no attribute 'is_double_buffered' On 16 March 2013 14:35, Antoine Martin wrote: > Hi, > > The OpenGL client rendering has been enabled again, and this time it > looks like it should work in almost all cases (the "nouveau" driver on > Linux is blacklisted however - and OSX is unlikely to be supported). > Please give it a whirl and report any display visual artifacts / bugs so > that the 0.9.0 release can include it enabled by default, more details > here: > http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes > Updated beta packages here: > http://xpra.org/beta/ > > Thanks > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From nick at sqrt.co.uk Sun Apr 7 09:26:35 2013 From: nick at sqrt.co.uk (Nick Burrett) Date: Sun, 7 Apr 2013 09:26:35 +0100 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: References: <51448317.20209@nagafix.co.uk> Message-ID: I fixed this by upgrading the Python OpenGL-accelerate module: easy_install OpenGL-accelerate On 7 April 2013 09:07, Nick Burrett wrote: > I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on Ubuntu > quantal (12.10) > > Rendering is certainly faster, however just moving the mouse across the > various menu items at the top of the window will flick between the current > image and a previous window image and will regularly produce this: > > 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 Compatibility Profile > Context > 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects available > 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program available > 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle available > 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program available > 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press Control-C to > detach) > > 2013-04-07 09:05:00,204 do_paint_rgb24 error > Traceback (most recent call last): > File "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", > line 371, in do_paint_rgb24 > self._do_paint_rgb24(img_data, x, y, width, height, rowstride, > options, callbacks) > File > "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", line > 181, in _do_paint_rgb24 > self.gl_end(drawable) > File > "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", line > 127, in gl_end > if drawable.is_double_buffered(): > AttributeError: 'NoneType' object has no attribute 'is_double_buffered' > > > On 16 March 2013 14:35, Antoine Martin wrote: > >> Hi, >> >> The OpenGL client rendering has been enabled again, and this time it >> looks like it should work in almost all cases (the "nouveau" driver on >> Linux is blacklisted however - and OSX is unlikely to be supported). >> Please give it a whirl and report any display visual artifacts / bugs so >> that the 0.9.0 release can include it enabled by default, more details >> here: >> http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes >> Updated beta packages here: >> http://xpra.org/beta/ >> >> Thanks >> Antoine >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > > From nick at sqrt.co.uk Sun Apr 7 09:31:40 2013 From: nick at sqrt.co.uk (Nick Burrett) Date: Sun, 7 Apr 2013 09:31:40 +0100 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: References: <51448317.20209@nagafix.co.uk> Message-ID: Sorry, no, doing that just broken OpenGL-accelerate. So it appears that with OpenGL enabled, the double-buffering is often the previous buffer when moving through menus or doing any sort of window updates. On 7 April 2013 09:26, Nick Burrett wrote: > I fixed this by upgrading the Python OpenGL-accelerate module: > > easy_install OpenGL-accelerate > > > On 7 April 2013 09:07, Nick Burrett wrote: > >> I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on Ubuntu >> quantal (12.10) >> >> Rendering is certainly faster, however just moving the mouse across the >> various menu items at the top of the window will flick between the current >> image and a previous window image and will regularly produce this: >> >> 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 Compatibility Profile >> Context >> 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects available >> 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program available >> 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle available >> 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program available >> 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press Control-C to >> detach) >> >> 2013-04-07 09:05:00,204 do_paint_rgb24 error >> Traceback (most recent call last): >> File "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", >> line 371, in do_paint_rgb24 >> self._do_paint_rgb24(img_data, x, y, width, height, rowstride, >> options, callbacks) >> File >> "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", line >> 181, in _do_paint_rgb24 >> self.gl_end(drawable) >> File >> "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", line >> 127, in gl_end >> if drawable.is_double_buffered(): >> AttributeError: 'NoneType' object has no attribute 'is_double_buffered' >> >> >> On 16 March 2013 14:35, Antoine Martin wrote: >> >>> Hi, >>> >>> The OpenGL client rendering has been enabled again, and this time it >>> looks like it should work in almost all cases (the "nouveau" driver on >>> Linux is blacklisted however - and OSX is unlikely to be supported). >>> Please give it a whirl and report any display visual artifacts / bugs so >>> that the 0.9.0 release can include it enabled by default, more details >>> here: >>> http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes >>> Updated beta packages here: >>> http://xpra.org/beta/ >>> >>> Thanks >>> 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 Apr 7 12:33:54 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 07 Apr 2013 12:33:54 +0100 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: References: <51448317.20209@nagafix.co.uk> Message-ID: <516159A2.5040606@nagafix.co.uk> Hi Nick, Many thanks for the feedback. The error with menu items should be fixed by this change: https://www.xpra.org/trac/changeset/3053/xpra If you still get visual artefacts, you may want to try this patch: --- src/xpra/gl/gl_check.py (revision 3046) +++ src/xpra/gl/gl_check.py (working copy) @@ -22,7 +22,7 @@ def get_DISPLAY_MODE(): import gtk.gdkgl #return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DEPTH | gtk.gdkgl.MODE_DOUBLE - return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DOUBLE + return gtk.gdkgl.MODE_RGB #by default, we raise an ImportError as soon as we find something missing: def raise_error(msg): Cheers Antoine On 07/04/13 09:31, Nick Burrett wrote: > Sorry, no, doing that just broken OpenGL-accelerate. So it appears that > with OpenGL enabled, the double-buffering is often the previous buffer when > moving through menus or doing any sort of window updates. > > On 7 April 2013 09:26, Nick Burrett wrote: > >> I fixed this by upgrading the Python OpenGL-accelerate module: >> >> easy_install OpenGL-accelerate >> >> >> On 7 April 2013 09:07, Nick Burrett wrote: >> >>> I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on Ubuntu >>> quantal (12.10) >>> >>> Rendering is certainly faster, however just moving the mouse across the >>> various menu items at the top of the window will flick between the current >>> image and a previous window image and will regularly produce this: >>> >>> 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 Compatibility Profile >>> Context >>> 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects available >>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program available >>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle available >>> 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program available >>> 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press Control-C to >>> detach) >>> >>> 2013-04-07 09:05:00,204 do_paint_rgb24 error >>> Traceback (most recent call last): >>> File "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", >>> line 371, in do_paint_rgb24 >>> self._do_paint_rgb24(img_data, x, y, width, height, rowstride, >>> options, callbacks) >>> File >>> "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", line >>> 181, in _do_paint_rgb24 >>> self.gl_end(drawable) >>> File >>> "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", line >>> 127, in gl_end >>> if drawable.is_double_buffered(): >>> AttributeError: 'NoneType' object has no attribute 'is_double_buffered' >>> >>> >>> On 16 March 2013 14:35, Antoine Martin wrote: >>> >>>> Hi, >>>> >>>> The OpenGL client rendering has been enabled again, and this time it >>>> looks like it should work in almost all cases (the "nouveau" driver on >>>> Linux is blacklisted however - and OSX is unlikely to be supported). >>>> Please give it a whirl and report any display visual artifacts / bugs so >>>> that the 0.9.0 release can include it enabled by default, more details >>>> here: >>>> http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes >>>> Updated beta packages here: >>>> http://xpra.org/beta/ >>>> >>>> Thanks >>>> Antoine >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> >>> From nick at sqrt.co.uk Sun Apr 7 12:52:34 2013 From: nick at sqrt.co.uk (Nick Burrett) Date: Sun, 7 Apr 2013 12:52:34 +0100 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: <516159A2.5040606@nagafix.co.uk> References: <51448317.20209@nagafix.co.uk> <516159A2.5040606@nagafix.co.uk> Message-ID: With changeset 3053, the visual artefacts remain. When your suggested change to gl_check.py, I appear to be viewing the penultimate window update e.g. if I click on "File", then the background of "File" changes colour, but the actual File menu does not appear until I move the mouse to the position of the first menu entry, which forces a background colour change for that menu entry and the whole menu gets drawn. Regards, Nick. On 7 April 2013 12:33, Antoine Martin wrote: > Hi Nick, > > Many thanks for the feedback. > The error with menu items should be fixed by this change: > https://www.xpra.org/trac/changeset/3053/xpra > > If you still get visual artefacts, you may want to try this patch: > > --- src/xpra/gl/gl_check.py (revision 3046) > +++ src/xpra/gl/gl_check.py (working copy) > @@ -22,7 +22,7 @@ > def get_DISPLAY_MODE(): > import gtk.gdkgl > #return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DEPTH | > gtk.gdkgl.MODE_DOUBLE > - return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DOUBLE > + return gtk.gdkgl.MODE_RGB > > #by default, we raise an ImportError as soon as we find something missing: > def raise_error(msg): > > Cheers > Antoine > > > On 07/04/13 09:31, Nick Burrett wrote: > > Sorry, no, doing that just broken OpenGL-accelerate. So it appears that > > with OpenGL enabled, the double-buffering is often the previous buffer > when > > moving through menus or doing any sort of window updates. > > > > On 7 April 2013 09:26, Nick Burrett wrote: > > > >> I fixed this by upgrading the Python OpenGL-accelerate module: > >> > >> easy_install OpenGL-accelerate > >> > >> > >> On 7 April 2013 09:07, Nick Burrett wrote: > >> > >>> I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on > Ubuntu > >>> quantal (12.10) > >>> > >>> Rendering is certainly faster, however just moving the mouse across the > >>> various menu items at the top of the window will flick between the > current > >>> image and a previous window image and will regularly produce this: > >>> > >>> 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 Compatibility Profile > >>> Context > >>> 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects available > >>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program available > >>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle available > >>> 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program available > >>> 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press Control-C to > >>> detach) > >>> > >>> 2013-04-07 09:05:00,204 do_paint_rgb24 error > >>> Traceback (most recent call last): > >>> File "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", > >>> line 371, in do_paint_rgb24 > >>> self._do_paint_rgb24(img_data, x, y, width, height, rowstride, > >>> options, callbacks) > >>> File > >>> "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", > line > >>> 181, in _do_paint_rgb24 > >>> self.gl_end(drawable) > >>> File > >>> "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", > line > >>> 127, in gl_end > >>> if drawable.is_double_buffered(): > >>> AttributeError: 'NoneType' object has no attribute 'is_double_buffered' > >>> > >>> > >>> On 16 March 2013 14:35, Antoine Martin wrote: > >>> > >>>> Hi, > >>>> > >>>> The OpenGL client rendering has been enabled again, and this time it > >>>> looks like it should work in almost all cases (the "nouveau" driver on > >>>> Linux is blacklisted however - and OSX is unlikely to be supported). > >>>> Please give it a whirl and report any display visual artifacts / bugs > so > >>>> that the 0.9.0 release can include it enabled by default, more details > >>>> here: > >>>> http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes > >>>> Updated beta packages here: > >>>> http://xpra.org/beta/ > >>>> > >>>> Thanks > >>>> 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 Apr 7 12:56:33 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 07 Apr 2013 12:56:33 +0100 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: References: <51448317.20209@nagafix.co.uk> <516159A2.5040606@nagafix.co.uk> Message-ID: <51615EF1.8090509@nagafix.co.uk> Hi Nick, Can you tell us what graphics driver you are using (as shown by "session info" window preferably)? And what application triggers the problem most reliably. Thanks Antoine On 07/04/13 12:52, Nick Burrett wrote: > With changeset 3053, the visual artefacts remain. When your suggested > change to gl_check.py, I appear to be viewing the penultimate window update > e.g. if I click on "File", then the background of "File" changes colour, > but the actual File menu does not appear until I move the mouse to the > position of the first menu entry, which forces a background colour change > for that menu entry and the whole menu gets drawn. > > Regards, > > Nick. > > On 7 April 2013 12:33, Antoine Martin wrote: > >> Hi Nick, >> >> Many thanks for the feedback. >> The error with menu items should be fixed by this change: >> https://www.xpra.org/trac/changeset/3053/xpra >> >> If you still get visual artefacts, you may want to try this patch: >> >> --- src/xpra/gl/gl_check.py (revision 3046) >> +++ src/xpra/gl/gl_check.py (working copy) >> @@ -22,7 +22,7 @@ >> def get_DISPLAY_MODE(): >> import gtk.gdkgl >> #return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DEPTH | >> gtk.gdkgl.MODE_DOUBLE >> - return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DOUBLE >> + return gtk.gdkgl.MODE_RGB >> >> #by default, we raise an ImportError as soon as we find something missing: >> def raise_error(msg): >> >> Cheers >> Antoine >> >> >> On 07/04/13 09:31, Nick Burrett wrote: >>> Sorry, no, doing that just broken OpenGL-accelerate. So it appears that >>> with OpenGL enabled, the double-buffering is often the previous buffer >> when >>> moving through menus or doing any sort of window updates. >>> >>> On 7 April 2013 09:26, Nick Burrett wrote: >>> >>>> I fixed this by upgrading the Python OpenGL-accelerate module: >>>> >>>> easy_install OpenGL-accelerate >>>> >>>> >>>> On 7 April 2013 09:07, Nick Burrett wrote: >>>> >>>>> I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on >> Ubuntu >>>>> quantal (12.10) >>>>> >>>>> Rendering is certainly faster, however just moving the mouse across the >>>>> various menu items at the top of the window will flick between the >> current >>>>> image and a previous window image and will regularly produce this: >>>>> >>>>> 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 Compatibility Profile >>>>> Context >>>>> 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects available >>>>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program available >>>>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle available >>>>> 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program available >>>>> 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press Control-C to >>>>> detach) >>>>> >>>>> 2013-04-07 09:05:00,204 do_paint_rgb24 error >>>>> Traceback (most recent call last): >>>>> File "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", >>>>> line 371, in do_paint_rgb24 >>>>> self._do_paint_rgb24(img_data, x, y, width, height, rowstride, >>>>> options, callbacks) >>>>> File >>>>> "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", >> line >>>>> 181, in _do_paint_rgb24 >>>>> self.gl_end(drawable) >>>>> File >>>>> "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", >> line >>>>> 127, in gl_end >>>>> if drawable.is_double_buffered(): >>>>> AttributeError: 'NoneType' object has no attribute 'is_double_buffered' >>>>> >>>>> >>>>> On 16 March 2013 14:35, Antoine Martin wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> The OpenGL client rendering has been enabled again, and this time it >>>>>> looks like it should work in almost all cases (the "nouveau" driver on >>>>>> Linux is blacklisted however - and OSX is unlikely to be supported). >>>>>> Please give it a whirl and report any display visual artifacts / bugs >> so >>>>>> that the 0.9.0 release can include it enabled by default, more details >>>>>> here: >>>>>> http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes >>>>>> Updated beta packages here: >>>>>> http://xpra.org/beta/ >>>>>> >>>>>> Thanks >>>>>> Antoine >>>>>> _______________________________________________ >>>>>> shifter-users mailing list >>>>>> shifter-users at lists.devloop.org.uk >>>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>>> >> From nick at sqrt.co.uk Sun Apr 7 13:54:45 2013 From: nick at sqrt.co.uk (Nick Burrett) Date: Sun, 7 Apr 2013 13:54:45 +0100 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: <51615EF1.8090509@nagafix.co.uk> References: <51448317.20209@nagafix.co.uk> <516159A2.5040606@nagafix.co.uk> <51615EF1.8090509@nagafix.co.uk> Message-ID: I see the problem with any attached session, be that emacs, gnome-terminal, thunderbird etc. It's 100% reliable. I do not seem to have a session->info window. nickb at nickb-pc:~/src/xpra/src$ dpkg -l | grep fglrx ii fglrx 2:9.000-0ubuntu3 amd64 Video driver for the AMD graphics accelerators ii fglrx-amdcccle 2:9.000-0ubuntu3 amd64 Catalyst Control Center for the AMD graphics accelerators nickb at nickb-pc:~/src/xpra/src$ fglrxinfo display: :0 screen: 0 OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: ATI Radeon HD 5670 OpenGL version string: 4.2.11903 Compatibility Profile Context However I do not see the issue when I create a local xpra session and access that locally. Though if I try to start a xpra local server with --no-mmap, I currently get this error 2013-04-07 13:51:48,582 pulseaudio server started with pid 2586 2013-04-07 13:51:48,589 xpra server version 0.9.0 E: [pulseaudio] pid.c: Daemon already running. /usr/local/lib/python2.7/dist-packages/xpra/server_base.py:297: GtkWarning: IA__gdk_error_trap_pop: assertion `gdk_error_traps != NULL' failed gtk.main() 2013-04-07 13:51:48,777 xpra is ready. (emacs:2589): Gdk-CRITICAL **: IA__gdk_error_trap_pop: assertion `gdk_error_traps != NULL' failed 2013-04-07 13:51:50,584 Warning: pulseaudio has terminated. Either fix the pulseaudio command line or use --no-pulseaudio to avoid this warning. 2013-04-07 13:51:52,153 New connection received: SocketConnection(/home/nickb/.xpra/nickb-pc-52) 2013-04-07 13:51:53,036 Handshake complete; enabling connection 2013-04-07 13:51:53,043 Python/Gtk2 Linux client version 0.9.0 connected from 'nickb-pc' 2013-04-07 13:51:53,043 using x264 as primary encoding 2013-04-07 13:51:53,044 max client resolution is 1920x1080 (from [[1920, 1080]]), current server resolution is 5120x3200 2013-04-07 13:51:53,051 new resolution matching 1920x1080 : screen now set to 1920x1080 2013-04-07 13:51:53,052 setting key repeat rate from client: 660ms delay / 40ms interval 2013-04-07 13:51:53,056 setting keymap: {'rules': 'evdev', 'model': 'pc105', 'layout': 'ie'} 2013-04-07 13:51:53,075 setting full keymap definition from client via xkbcomp 2013-04-07 13:51:53,172 sending updated screen size to clients: 1920x1080 (max 5120x3200) 2013-04-07 13:51:53,173 using sound codec mp3 2013-04-07 13:51:53,209 identical pulseaudio server, refusing to create a sound loop - sound disabled 2013-04-07 13:51:53,280 Uh-oh, our size doesn't fit window sizing constraints: 756x657 vs 756x641 On 7 April 2013 12:56, Antoine Martin wrote: > Hi Nick, > > Can you tell us what graphics driver you are using (as shown by "session > info" window preferably)? > And what application triggers the problem most reliably. > > Thanks > Antoine > > On 07/04/13 12:52, Nick Burrett wrote: > > With changeset 3053, the visual artefacts remain. When your suggested > > change to gl_check.py, I appear to be viewing the penultimate window > update > > e.g. if I click on "File", then the background of "File" changes colour, > > but the actual File menu does not appear until I move the mouse to the > > position of the first menu entry, which forces a background colour change > > for that menu entry and the whole menu gets drawn. > > > > Regards, > > > > Nick. > > > > On 7 April 2013 12:33, Antoine Martin wrote: > > > >> Hi Nick, > >> > >> Many thanks for the feedback. > >> The error with menu items should be fixed by this change: > >> https://www.xpra.org/trac/changeset/3053/xpra > >> > >> If you still get visual artefacts, you may want to try this patch: > >> > >> --- src/xpra/gl/gl_check.py (revision 3046) > >> +++ src/xpra/gl/gl_check.py (working copy) > >> @@ -22,7 +22,7 @@ > >> def get_DISPLAY_MODE(): > >> import gtk.gdkgl > >> #return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DEPTH | > >> gtk.gdkgl.MODE_DOUBLE > >> - return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DOUBLE > >> + return gtk.gdkgl.MODE_RGB > >> > >> #by default, we raise an ImportError as soon as we find something > missing: > >> def raise_error(msg): > >> > >> Cheers > >> Antoine > >> > >> > >> On 07/04/13 09:31, Nick Burrett wrote: > >>> Sorry, no, doing that just broken OpenGL-accelerate. So it appears > that > >>> with OpenGL enabled, the double-buffering is often the previous buffer > >> when > >>> moving through menus or doing any sort of window updates. > >>> > >>> On 7 April 2013 09:26, Nick Burrett wrote: > >>> > >>>> I fixed this by upgrading the Python OpenGL-accelerate module: > >>>> > >>>> easy_install OpenGL-accelerate > >>>> > >>>> > >>>> On 7 April 2013 09:07, Nick Burrett wrote: > >>>> > >>>>> I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on > >> Ubuntu > >>>>> quantal (12.10) > >>>>> > >>>>> Rendering is certainly faster, however just moving the mouse across > the > >>>>> various menu items at the top of the window will flick between the > >> current > >>>>> image and a previous window image and will regularly produce this: > >>>>> > >>>>> 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 Compatibility > Profile > >>>>> Context > >>>>> 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects available > >>>>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program > available > >>>>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle > available > >>>>> 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program available > >>>>> 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press Control-C > to > >>>>> detach) > >>>>> > >>>>> 2013-04-07 09:05:00,204 do_paint_rgb24 error > >>>>> Traceback (most recent call last): > >>>>> File > "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", > >>>>> line 371, in do_paint_rgb24 > >>>>> self._do_paint_rgb24(img_data, x, y, width, height, rowstride, > >>>>> options, callbacks) > >>>>> File > >>>>> > "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", > >> line > >>>>> 181, in _do_paint_rgb24 > >>>>> self.gl_end(drawable) > >>>>> File > >>>>> > "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", > >> line > >>>>> 127, in gl_end > >>>>> if drawable.is_double_buffered(): > >>>>> AttributeError: 'NoneType' object has no attribute > 'is_double_buffered' > >>>>> > >>>>> > >>>>> On 16 March 2013 14:35, Antoine Martin > wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> The OpenGL client rendering has been enabled again, and this time it > >>>>>> looks like it should work in almost all cases (the "nouveau" driver > on > >>>>>> Linux is blacklisted however - and OSX is unlikely to be supported). > >>>>>> Please give it a whirl and report any display visual artifacts / > bugs > >> so > >>>>>> that the 0.9.0 release can include it enabled by default, more > details > >>>>>> here: > >>>>>> http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes > >>>>>> Updated beta packages here: > >>>>>> http://xpra.org/beta/ > >>>>>> > >>>>>> Thanks > >>>>>> Antoine > >>>>>> _______________________________________________ > >>>>>> shifter-users mailing list > >>>>>> shifter-users at lists.devloop.org.uk > >>>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>>>>> > >> > > From totaam at gmail.com Sun Apr 7 14:27:33 2013 From: totaam at gmail.com (Antoine Martin) Date: Sun, 7 Apr 2013 14:27:33 +0100 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: References: <51448317.20209@nagafix.co.uk> <516159A2.5040606@nagafix.co.uk> <51615EF1.8090509@nagafix.co.uk> Message-ID: The "session info" window is in the system tray near the top. The opengl details will be in the second tab iirc. Can you clarify which log message is the error that you only see with local connections and no-mmap? Thanks Antoine On 7 Apr, 2013 1:55 PM, "Nick Burrett" wrote: > I see the problem with any attached session, be that emacs, gnome-terminal, > thunderbird etc. It's 100% reliable. I do not seem to have a > session->info window. > > nickb at nickb-pc:~/src/xpra/src$ dpkg -l | grep fglrx > ii fglrx 2:9.000-0ubuntu3 > amd64 Video driver for the AMD > graphics accelerators > ii fglrx-amdcccle 2:9.000-0ubuntu3 > amd64 Catalyst Control Center for the > AMD graphics accelerators > > nickb at nickb-pc:~/src/xpra/src$ fglrxinfo > display: :0 screen: 0 > OpenGL vendor string: Advanced Micro Devices, Inc. > OpenGL renderer string: ATI Radeon HD 5670 > OpenGL version string: 4.2.11903 Compatibility Profile Context > > > However I do not see the issue when I create a local xpra session and > access that locally. Though if I try to start a xpra local server with > --no-mmap, I currently get this error > > 2013-04-07 13:51:48,582 pulseaudio server started with pid 2586 > 2013-04-07 13:51:48,589 xpra server version 0.9.0 > E: [pulseaudio] pid.c: Daemon already running. > /usr/local/lib/python2.7/dist-packages/xpra/server_base.py:297: GtkWarning: > IA__gdk_error_trap_pop: assertion `gdk_error_traps != NULL' failed > gtk.main() > 2013-04-07 13:51:48,777 xpra is ready. > > (emacs:2589): Gdk-CRITICAL **: IA__gdk_error_trap_pop: assertion > `gdk_error_traps != NULL' failed > 2013-04-07 13:51:50,584 Warning: pulseaudio has terminated. Either fix the > pulseaudio command line or use --no-pulseaudio to avoid this warning. > 2013-04-07 13:51:52,153 New connection received: > SocketConnection(/home/nickb/.xpra/nickb-pc-52) > 2013-04-07 13:51:53,036 Handshake complete; enabling connection > 2013-04-07 13:51:53,043 Python/Gtk2 Linux client version 0.9.0 connected > from 'nickb-pc' > 2013-04-07 13:51:53,043 using x264 as primary encoding > 2013-04-07 13:51:53,044 max client resolution is 1920x1080 (from [[1920, > 1080]]), current server resolution is 5120x3200 > 2013-04-07 13:51:53,051 new resolution matching 1920x1080 : screen now set > to 1920x1080 > 2013-04-07 13:51:53,052 setting key repeat rate from client: 660ms delay / > 40ms interval > 2013-04-07 13:51:53,056 setting keymap: {'rules': 'evdev', 'model': > 'pc105', 'layout': 'ie'} > 2013-04-07 13:51:53,075 setting full keymap definition from client via > xkbcomp > 2013-04-07 13:51:53,172 sending updated screen size to clients: 1920x1080 > (max 5120x3200) > 2013-04-07 13:51:53,173 using sound codec mp3 > 2013-04-07 13:51:53,209 identical pulseaudio server, refusing to create a > sound loop - sound disabled > 2013-04-07 13:51:53,280 Uh-oh, our size doesn't fit window sizing > constraints: 756x657 vs 756x641 > > > On 7 April 2013 12:56, Antoine Martin wrote: > > > Hi Nick, > > > > Can you tell us what graphics driver you are using (as shown by "session > > info" window preferably)? > > And what application triggers the problem most reliably. > > > > Thanks > > Antoine > > > > On 07/04/13 12:52, Nick Burrett wrote: > > > With changeset 3053, the visual artefacts remain. When your suggested > > > change to gl_check.py, I appear to be viewing the penultimate window > > update > > > e.g. if I click on "File", then the background of "File" changes > colour, > > > but the actual File menu does not appear until I move the mouse to the > > > position of the first menu entry, which forces a background colour > change > > > for that menu entry and the whole menu gets drawn. > > > > > > Regards, > > > > > > Nick. > > > > > > On 7 April 2013 12:33, Antoine Martin wrote: > > > > > >> Hi Nick, > > >> > > >> Many thanks for the feedback. > > >> The error with menu items should be fixed by this change: > > >> https://www.xpra.org/trac/changeset/3053/xpra > > >> > > >> If you still get visual artefacts, you may want to try this patch: > > >> > > >> --- src/xpra/gl/gl_check.py (revision 3046) > > >> +++ src/xpra/gl/gl_check.py (working copy) > > >> @@ -22,7 +22,7 @@ > > >> def get_DISPLAY_MODE(): > > >> import gtk.gdkgl > > >> #return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DEPTH | > > >> gtk.gdkgl.MODE_DOUBLE > > >> - return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DOUBLE > > >> + return gtk.gdkgl.MODE_RGB > > >> > > >> #by default, we raise an ImportError as soon as we find something > > missing: > > >> def raise_error(msg): > > >> > > >> Cheers > > >> Antoine > > >> > > >> > > >> On 07/04/13 09:31, Nick Burrett wrote: > > >>> Sorry, no, doing that just broken OpenGL-accelerate. So it appears > > that > > >>> with OpenGL enabled, the double-buffering is often the previous > buffer > > >> when > > >>> moving through menus or doing any sort of window updates. > > >>> > > >>> On 7 April 2013 09:26, Nick Burrett wrote: > > >>> > > >>>> I fixed this by upgrading the Python OpenGL-accelerate module: > > >>>> > > >>>> easy_install OpenGL-accelerate > > >>>> > > >>>> > > >>>> On 7 April 2013 09:07, Nick Burrett wrote: > > >>>> > > >>>>> I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on > > >> Ubuntu > > >>>>> quantal (12.10) > > >>>>> > > >>>>> Rendering is certainly faster, however just moving the mouse across > > the > > >>>>> various menu items at the top of the window will flick between the > > >> current > > >>>>> image and a previous window image and will regularly produce this: > > >>>>> > > >>>>> 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 Compatibility > > Profile > > >>>>> Context > > >>>>> 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects > available > > >>>>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program > > available > > >>>>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle > > available > > >>>>> 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program > available > > >>>>> 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press Control-C > > to > > >>>>> detach) > > >>>>> > > >>>>> 2013-04-07 09:05:00,204 do_paint_rgb24 error > > >>>>> Traceback (most recent call last): > > >>>>> File > > "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", > > >>>>> line 371, in do_paint_rgb24 > > >>>>> self._do_paint_rgb24(img_data, x, y, width, height, rowstride, > > >>>>> options, callbacks) > > >>>>> File > > >>>>> > > "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", > > >> line > > >>>>> 181, in _do_paint_rgb24 > > >>>>> self.gl_end(drawable) > > >>>>> File > > >>>>> > > "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", > > >> line > > >>>>> 127, in gl_end > > >>>>> if drawable.is_double_buffered(): > > >>>>> AttributeError: 'NoneType' object has no attribute > > 'is_double_buffered' > > >>>>> > > >>>>> > > >>>>> On 16 March 2013 14:35, Antoine Martin > > wrote: > > >>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> The OpenGL client rendering has been enabled again, and this time > it > > >>>>>> looks like it should work in almost all cases (the "nouveau" > driver > > on > > >>>>>> Linux is blacklisted however - and OSX is unlikely to be > supported). > > >>>>>> Please give it a whirl and report any display visual artifacts / > > bugs > > >> so > > >>>>>> that the 0.9.0 release can include it enabled by default, more > > details > > >>>>>> here: > > >>>>>> http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes > > >>>>>> Updated beta packages here: > > >>>>>> http://xpra.org/beta/ > > >>>>>> > > >>>>>> Thanks > > >>>>>> 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 thejunk.b at gmail.com Sun Apr 7 16:25:08 2013 From: thejunk.b at gmail.com (Randy) Date: Sun, 7 Apr 2013 11:25:08 -0400 Subject: [winswitch] xpra issuses In-Reply-To: <5158A3D6.80607@nagafix.co.uk> References: <201303291519.45144.thejunk.b@gmail.com> <201303311423.25114.thejunk.b@gmail.com> <5158A3D6.80607@nagafix.co.uk> Message-ID: <201304071125.09019.thejunk.b@gmail.com> On Sunday, March 31, 2013, Antoine Martin wrote: > Wait, ... are you trying to use NX or Xpra sessions? xpra OK, so I started over. I am using 2 machine, one is a laptop, the other a desktop. Both of these machine worked with each other before I upgaded from the older version. Both machines run debian wheezy 64 /w kde. The desktop (TV) is hardwired to my local network, the laptop (BumbleBee) uses wifi. I am able to ssh back and forth between machine manually with out issue and run gui apps from cli. To start over I uninstalled both winswitch and xpra from both machines. Then I manually deleted the .winswitch and .xpra folders from users ~/user. Then I reinstalled both packages and reinstall the dependant packages from synaptic. Neither machine has selinux installed. I have not modifed the default config except to enable debug. I get no joy trying to run apps remotly. The servers seem to connect to each other correctly. I am able to remotly launch guvcview (webcam app) on the desktop from the laptop, but I am still seeing the app briefly appear on the laptop then dissapear with a popup message that I can not interpret. I also don't see that message text in the logs. If I go over to the desktop the app is there and I can reconnect to it and it displays just fine locally. I have tared the config files and log files off both machine and they can be seen at https://www.dropbox.com/sh/trsi9d82yvsuuk0/yiXmoIi-jk if you have issues reading them let me know and we can try something else. Thanks -- If it ain't broke tweek it From antoine at nagafix.co.uk Sun Apr 14 18:06:57 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 15 Apr 2013 00:06:57 +0700 Subject: [winswitch] xpra issuses In-Reply-To: <201304071125.09019.thejunk.b@gmail.com> References: <201303291519.45144.thejunk.b@gmail.com> <201303311423.25114.thejunk.b@gmail.com> <5158A3D6.80607@nagafix.co.uk> <201304071125.09019.thejunk.b@gmail.com> Message-ID: <516AE231.7050209@nagafix.co.uk> On 04/07/2013 10:25 PM, Randy wrote: > On Sunday, March 31, 2013, Antoine Martin wrote: >> Wait, ... are you trying to use NX or Xpra sessions? > xpra > > OK, so I started over. I am using 2 machine, one is a laptop, the other a > desktop. Both of these machine worked with each other before I upgaded from > the older version. Both machines run debian wheezy 64 /w kde. The desktop > (TV) is hardwired to my local network, the laptop (BumbleBee) uses wifi. I am > able to ssh back and forth between machine manually with out issue and run gui > apps from cli. > > To start over I uninstalled both winswitch and xpra from both machines. Then > I manually deleted the .winswitch and .xpra folders from users ~/user. Then I > reinstalled both packages and reinstall the dependant packages from synaptic. > Neither machine has selinux installed. > > I have not modifed the default config except to enable debug. I get no joy > trying to run apps remotly. The servers seem to connect to each other > correctly. I am able to remotly launch guvcview (webcam app) on the desktop > from the laptop, but I am still seeing the app briefly appear on the laptop > then dissapear with a popup message that I can not interpret. I also don't > see that message text in the logs. > > If I go over to the desktop the app is there and I can reconnect to it and it > displays just fine locally. > > I have tared the config files and log files off both machine and they can be seen > at > https://www.dropbox.com/sh/trsi9d82yvsuuk0/yiXmoIi-jk > if you have issues reading them let me know and we can try something else. > > > Thanks > Sorry for the late reply, I've skimmed through your log files and found this in laptop/applet-20130406-224841.log: **** [NULL @ 0x35ef8a0] Value 4686111960511545344.000000 for parameter 'b' out of range (snip) A process has ended with a probable error condition: process ended by signal 6 **** Looks to me like there are problems with x264. I can tell you are using x264 from this line in the server log: 2013-04-06 22:52:38,420 using x264 as primary encoding You should be able to workaround this problem by defining another default encoding, either in /etc/xpra/xpra.conf or in ~/.xpra/xpra.conf I suspect this is yet-another problem caused by the API changes to libav.. I accepted a patch to make it work with newer versions, which seems to have caused endless problems with 99% of the versions currently deployed instead. I'll try to run a VM with wheezy/+-testing and see if I can reproduce. I also found this in desktop/applet-20130406-225118.log: **** 2013-04-07 07:00:31,910 Password matches! Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/wimpiggy/util.py", line 26, in do_get_property return getattr(self, getter)(pspec.name) File "/usr/lib/python2.7/dist-packages/wimpiggy/window.py", line 316, in do_get_property_client_contents return self._composite.get_property("contents") AttributeError: 'NoneType' object has no attribute 'get_property' 2013-04-07 07:00:32,083 Connection lost **** That's an odd one, but probably not the cause of your problems. I think it is a consequence of it. Looks like we're trying to make calls on a window which is not/no-longer managed. Have you got a screenshot or copy of the "popup message that I can not interpret"? Thanks Antoine From antoine at nagafix.co.uk Sun Apr 14 20:21:48 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 15 Apr 2013 02:21:48 +0700 Subject: [winswitch] correct syntax for xpra --bind-tcp using ipv6? In-Reply-To: References: Message-ID: <516B01CC.7090105@nagafix.co.uk> On 04/07/2013 07:23 AM, Joshua Higgins wrote: > Hi list > > what is the correct syntax for xpra start --bind-tcp when using IPv6? > > I've tried xpra start --bind-tcp="[::1]:60000", which brings the error: > invalid literal for int() with base 10: ':]:60000 > > It looks like xpra attach parses IPv6 correctly ( > http://xpra.org/trac/ticket/119) with a different syntax so was wondering > if there is a similar case for the bind-tcp option instead of this being a > bug. This was a bug, and it is now fixed: http://xpra.org/trac/changeset/3061/xpra And you can use it like so: xpra start :10 --bind-tcp=::1:10000 I don't use IPv6 much, so please do let me know if you encounter any problems. Cheers Antoine > > Thanks, > Josh > From antoine at nagafix.co.uk Mon Apr 15 08:07:19 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 15 Apr 2013 14:07:19 +0700 Subject: [winswitch] testing required: OpenGL client rendering In-Reply-To: References: <51448317.20209@nagafix.co.uk> <516159A2.5040606@nagafix.co.uk> <51615EF1.8090509@nagafix.co.uk> Message-ID: <516BA727.9080207@nagafix.co.uk> On 04/07/2013 07:54 PM, Nick Burrett wrote: > I see the problem with any attached session, be that emacs, > gnome-terminal, thunderbird etc. It's 100% reliable. I do not seem to > have a session->info window. The session-info window is in the system-tray applet menu. Some DEs, like gnome3, make it very hard to use. I have failed to reproduce the problem with any of the applications you listed, which makes me think that something else is at play. Which DE are you using? (a compositing window manager perhaps?) And which distro / version / etc? (will try it in a VM) I assume that the problem goes away if you change the encoding from the system tray to a non video encoding (not vpx or x264)? > nickb at nickb-pc:~/src/xpra/src$ dpkg -l | grep fglrx > ii fglrx 2:9.000-0ubuntu3 > amd64 Video driver for the AMD > graphics accelerators > ii fglrx-amdcccle 2:9.000-0ubuntu3 > amd64 Catalyst Control Center for > the AMD graphics accelerators $ rpm -qa | grep -i catalyst | grep x86_64 xorg-x11-drv-catalyst-libs-13.1-1.fc18.x86_64 xorg-x11-drv-catalyst-13.1-1.fc18.x86_64 akmod-catalyst-13.1-2.fc18.x86_64 > nickb at nickb-pc:~/src/xpra/src$ fglrxinfo > display: :0 screen: 0 > OpenGL vendor string: Advanced Micro Devices, Inc. > OpenGL renderer string: ATI Radeon HD 5670 > OpenGL version string: 4.2.11903 Compatibility Profile Context $ fglrxinfo display: :0 screen: 0 OpenGL vendor string: Advanced Micro Devices, Inc. OpenGL renderer string: ATI Radeon HD 5450 OpenGL version string: 4.2.12002 Compatibility Profile Context 9.002 > However I do not see the issue when I create a local xpra session and > access that locally. Though if I try to start a xpra local server with > --no-mmap, I currently get this error Do you mean that the server fails to start if you use "--no-mmap"? > 2013-04-07 13:51:48,582 pulseaudio server started with pid 2586 > 2013-04-07 13:51:48,589 xpra server version 0.9.0 > E: [pulseaudio] pid.c: Daemon already running. > /usr/local/lib/python2.7/dist-packages/xpra/server_base.py:297: > GtkWarning: IA__gdk_error_trap_pop: assertion `gdk_error_traps != NULL' > failed > gtk.main() ^ this is the only real error, and unfortunately it is a gdk internal error and those often get reported against the main loop invocation point, which is not helpful for figuring out the real cause.. This will produce *a lot* mode debugging info, which may help: XPRA_X11_DEBUG=1 xpra ... > 2013-04-07 13:51:48,777 xpra is ready. > > (emacs:2589): Gdk-CRITICAL **: IA__gdk_error_trap_pop: assertion > `gdk_error_traps != NULL' failed ^ same again... (snip) Cheers Antoine > > > On 7 April 2013 12:56, Antoine Martin > wrote: > > Hi Nick, > > Can you tell us what graphics driver you are using (as shown by "session > info" window preferably)? > And what application triggers the problem most reliably. > > Thanks > Antoine > > On 07/04/13 12:52, Nick Burrett wrote: > > With changeset 3053, the visual artefacts remain. When your suggested > > change to gl_check.py, I appear to be viewing the penultimate > window update > > e.g. if I click on "File", then the background of "File" changes > colour, > > but the actual File menu does not appear until I move the mouse to the > > position of the first menu entry, which forces a background colour > change > > for that menu entry and the whole menu gets drawn. > > > > Regards, > > > > Nick. > > > > On 7 April 2013 12:33, Antoine Martin > wrote: > > > >> Hi Nick, > >> > >> Many thanks for the feedback. > >> The error with menu items should be fixed by this change: > >> https://www.xpra.org/trac/changeset/3053/xpra > >> > >> If you still get visual artefacts, you may want to try this patch: > >> > >> --- src/xpra/gl/gl_check.py (revision 3046) > >> +++ src/xpra/gl/gl_check.py (working copy) > >> @@ -22,7 +22,7 @@ > >> def get_DISPLAY_MODE(): > >> import gtk.gdkgl > >> #return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DEPTH | > >> gtk.gdkgl.MODE_DOUBLE > >> - return gtk.gdkgl.MODE_RGB | gtk.gdkgl.MODE_DOUBLE > >> + return gtk.gdkgl.MODE_RGB > >> > >> #by default, we raise an ImportError as soon as we find > something missing: > >> def raise_error(msg): > >> > >> Cheers > >> Antoine > >> > >> > >> On 07/04/13 09:31, Nick Burrett wrote: > >>> Sorry, no, doing that just broken OpenGL-accelerate. So it > appears that > >>> with OpenGL enabled, the double-buffering is often the previous > buffer > >> when > >>> moving through menus or doing any sort of window updates. > >>> > >>> On 7 April 2013 09:26, Nick Burrett > wrote: > >>> > >>>> I fixed this by upgrading the Python OpenGL-accelerate module: > >>>> > >>>> easy_install OpenGL-accelerate > >>>> > >>>> > >>>> On 7 April 2013 09:07, Nick Burrett > wrote: > >>>> > >>>>> I'm trying this out with the xfce4 terminal - /usr/bin/Terminal on > >> Ubuntu > >>>>> quantal (12.10) > >>>>> > >>>>> Rendering is certainly faster, however just moving the mouse > across the > >>>>> various menu items at the top of the window will flick between the > >> current > >>>>> image and a previous window image and will regularly produce this: > >>>>> > >>>>> 2013-04-07 09:03:51,306 OpenGL Version: 4.2.11903 > Compatibility Profile > >>>>> Context > >>>>> 2013-04-07 09:03:51,333 GL Extension GL_ARB_shader_objects > available > >>>>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_fragment_program > available > >>>>> 2013-04-07 09:03:51,353 GL Extension GL_ARB_texture_rectangle > available > >>>>> 2013-04-07 09:03:51,354 GL Extension GL_ARB_vertex_program > available > >>>>> 2013-04-07 09:04:00,139 Attached to ssh:devbox:100 (press > Control-C to > >>>>> detach) > >>>>> > >>>>> 2013-04-07 09:05:00,204 do_paint_rgb24 error > >>>>> Traceback (most recent call last): > >>>>> File > "/usr/local/lib/python2.7/dist-packages/xpra/window_backing.py", > >>>>> line 371, in do_paint_rgb24 > >>>>> self._do_paint_rgb24(img_data, x, y, width, height, rowstride, > >>>>> options, callbacks) > >>>>> File > >>>>> > "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", > >> line > >>>>> 181, in _do_paint_rgb24 > >>>>> self.gl_end(drawable) > >>>>> File > >>>>> > "/usr/local/lib/python2.7/dist-packages/xpra/gl/gl_window_backing.py", > >> line > >>>>> 127, in gl_end > >>>>> if drawable.is_double_buffered(): > >>>>> AttributeError: 'NoneType' object has no attribute > 'is_double_buffered' > >>>>> > >>>>> > >>>>> On 16 March 2013 14:35, Antoine Martin > wrote: > >>>>> > >>>>>> Hi, > >>>>>> > >>>>>> The OpenGL client rendering has been enabled again, and this > time it > >>>>>> looks like it should work in almost all cases (the "nouveau" > driver on > >>>>>> Linux is blacklisted however - and OSX is unlikely to be > supported). > >>>>>> Please give it a whirl and report any display visual > artifacts / bugs > >> so > >>>>>> that the 0.9.0 release can include it enabled by default, > more details > >>>>>> here: > >>>>>> http://xpra.org/trac/wiki/ClientRendering#OpenGLNotes > >>>>>> Updated beta packages here: > >>>>>> http://xpra.org/beta/ > >>>>>> > >>>>>> Thanks > >>>>>> Antoine > >>>>>> _______________________________________________ > >>>>>> shifter-users mailing list > >>>>>> shifter-users at lists.devloop.org.uk > > >>>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>>>>> > >> > > From thejunk.b at gmail.com Mon Apr 15 15:35:42 2013 From: thejunk.b at gmail.com (Randy) Date: Mon, 15 Apr 2013 10:35:42 -0400 Subject: [winswitch] xpra issuses In-Reply-To: <516AE231.7050209@nagafix.co.uk> References: <201303291519.45144.thejunk.b@gmail.com> <201304071125.09019.thejunk.b@gmail.com> <516AE231.7050209@nagafix.co.uk> Message-ID: <201304151035.42629.thejunk.b@gmail.com> Thanks. > You should be able to workaround this problem by defining another > default encoding, either in /etc/xpra/xpra.conf or in ~/.xpra/xpra.conf Just got back from vacation myself only to find my systems crashed. That and work, when I get a chance I will look into this. -- If it ain't broke tweek it From kristof.ralovich at gmail.com Tue Apr 23 15:08:17 2013 From: kristof.ralovich at gmail.com (kristof.ralovich at gmail.com) Date: Tue, 23 Apr 2013 16:08:17 +0200 Subject: [winswitch] xpra using cygwin ssh Message-ID: Dear All, I'm using xpra with great satisfaction. Recently I bumped into a issue while trying to attach to a server from a client behind a proxy. I've set up cygwin, ssh and connect-proxy to work hand-in-hand, for command line communication this pipeline is functional. Now, I would also like to use this working ssh setup for xpra too. To this end, I've changed this line ssh = c:/cygwin/bin/ssh.exe in c:\Program Files (x86)\Xpra\xpra.conf to point ssh to cygwin's. Then running Xpra_cmd.exe from a cygwin shell produced the output below: user at laptop /cygdrive/c/Program Files (x86)/Xpra $ ./Xpra_cmd.exe attach ssh:user at example.com:1001 ** Message: pygobject_register_sinkfunc is deprecated (GstObject) xpra client version 0.8.8 cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', 'example.com', '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', ':1001']: the SSH process has terminated with exit code=255 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 bytes) and 0 packets sent (0 bytes) Exception in thread format (most likely raised during interpreter shutdown): Is there a way to print the output of ssh for debugging? Or any hints that I should consider? Thanks in advance, Kristof From antoine at nagafix.co.uk Tue Apr 23 15:20:00 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 23 Apr 2013 21:20:00 +0700 Subject: [winswitch] xpra using cygwin ssh In-Reply-To: References: Message-ID: <51769890.6030104@nagafix.co.uk> On 04/23/2013 09:08 PM, kristof.ralovich at gmail.com wrote: > Dear All, > > I'm using xpra with great satisfaction. Recently I bumped into a issue > while trying to attach to a server from a client behind a proxy. I've set > up cygwin, ssh and connect-proxy to work hand-in-hand, for command line > communication this pipeline is functional. Now, I would also like to use > this working ssh setup for xpra too. To this end, I've changed this line > > ssh = c:/cygwin/bin/ssh.exe > > in c:\Program Files (x86)\Xpra\xpra.conf to point ssh to cygwin's. You should be modifying the user's xpra.conf rather than the system default, creating one if it doesn't exist. IIRC, on win32 this would be %APPDATA%\Xpra\xpra.conf This way it won't get overwritten with every Xpra software update. > Then > running Xpra_cmd.exe from a cygwin shell produced the output below: > > user at laptop /cygdrive/c/Program Files (x86)/Xpra > $ ./Xpra_cmd.exe attach ssh:user at example.com:1001 > ** Message: pygobject_register_sinkfunc is deprecated (GstObject) > xpra client version 0.8.8 > cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', 'example.com', > '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', > ':1001']: the SSH process has terminated with exit code=255 > 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 > bytes) and 0 packets sent (0 bytes) > Exception in thread format (most likely raised during interpreter shutdown): > > Is there a way to print the output of ssh for debugging? Or any hints that > I should consider? On win32 we don't use putty.exe but plink.exe (and not the one from putty, but the one from tortoise to get a GUI for accepting host keys and asking for passwords). The connection stage is too early to get any meaningful debugging information using the "xpra -d all" flag I think. Have you tried running that ssh command line by hand to make sure it does work? I'm pretty sure it won't because it assumes that we're dealing with "plink.exe" on win32, so the flags "-ssh" and "-agent" are probably causing ssh.exe to abort with an error. If the patch below works for you, I guess I could use the "ssh" syntax when the ssh command looks like a proper ssh... ugly, but that's win32 for you. Cheers Antoine ### Eclipse Workspace Patch 1.0 #P Xpra Index: src/xpra/scripts/main.py =================================================================== --- src/xpra/scripts/main.py (revision 3132) +++ src/xpra/scripts/main.py (working copy) @@ -531,7 +531,7 @@ dtype = display_desc["type"] if dtype == "ssh": cmd = display_desc["full_ssh"] - if sys.platform.startswith("win"): + if False: password = display_desc.get("password") if password: cmd += ["-pw", password] From antoine at nagafix.co.uk Tue Apr 23 17:34:05 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 23 Apr 2013 23:34:05 +0700 Subject: [winswitch] xpra using cygwin ssh In-Reply-To: <51769890.6030104@nagafix.co.uk> References: <51769890.6030104@nagafix.co.uk> Message-ID: <5176B7FD.2000407@nagafix.co.uk> (snip) >> cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', 'example.com', >> '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', >> ':1001']: the SSH process has terminated with exit code=255 >> 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 >> bytes) and 0 packets sent (0 bytes) >> Exception in thread format (most likely raised during interpreter shutdown): (snip) > If the patch below works for you, I guess I could use the "ssh" syntax > when the ssh command looks like a proper ssh... ugly, but that's win32 > for you. The solution seemed simple enough so I've merged it already: http://xpra.org/trac/changeset/3136/xpra You can find the latest beta win32 packages with this change included here (r3136): http://xpra.org/beta/windows/ Cheers Antoine From mrahusain at gmail.com Wed Apr 24 18:11:00 2013 From: mrahusain at gmail.com (Ammar Husain) Date: Wed, 24 Apr 2013 13:11:00 -0400 Subject: [winswitch] Web browser based Xpra viewer Message-ID: Hi All, Xpra has greatly helped me to remotely connect to applications on my work computer. However I was wondering if there is an Xpra viewer that is entirely web-based? I was reading through the documentation and it seems like the Xpra viewer utilises the windowing system on the client machine. Has anyone given it a try to embed the windowing in a web browser, possibly using HTML5 canvas / AJAX? I mean something similar to NX WebPlayer or noVNC. Would it even be possible to do something like that with Xpra viewer? That would be of great help to me. Thanks, Ammar From antoine at nagafix.co.uk Wed Apr 24 18:15:10 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 25 Apr 2013 00:15:10 +0700 Subject: [winswitch] Web browser based Xpra viewer In-Reply-To: References: Message-ID: <5178131E.7060803@nagafix.co.uk> Hi Ammar, There are Java versions of the client (AWT and Swing) which could be delivered to a browser. But: * this Java code is not production ready by any means * I've never tried doing that * you would lose many of the benefits of Xpra (mainly: seamlessness) Cheers Antoine On 04/25/2013 12:11 AM, Ammar Husain wrote: > Hi All, > Xpra has greatly helped me to remotely connect to applications on my work > computer. However I was wondering if there is an Xpra viewer that is > entirely web-based? I was reading through the documentation and it seems > like the Xpra viewer utilises the windowing system on the client machine. > Has anyone given it a try to embed the windowing in a web browser, possibly > using HTML5 canvas / AJAX? I mean something similar to NX WebPlayer or > noVNC. Would it even be possible to do something like that with Xpra > viewer? That would be of great help to me. > Thanks, > Ammar > _______________________________________________ > 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 Wed Apr 24 19:49:40 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 25 Apr 2013 01:49:40 +0700 Subject: [winswitch] [ANNOUNCE] xpra 0.9.0 Message-ID: <51782944.6010203@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This new major release brings many new features, but more importantly a large number of important bug fixes throughout. Here are some of the key new features and fixes: * remote session start: xpra start ssh:host:DISP --start-child=cmd * more sound codec support (wav, flac, opus..) * MS Windows fixes (clipboard, caps and num lock synchronization) * Platform fixes: IPv6 server, Python 2.4 fixes, SELinux labels, etc * better launcher and support for launching from ".xpra" session files The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Cheers Antoine PS: as usual, the Mac OSX build failed some last minute testing and will be posted later. Full releases notes: - - fix focus problems with old Xvfb display servers - - fix RPM SELinux labelling of static codec builds (CentOS) - - fix CentOS 5.x compatibility - - fix Python 2.4 and 2.5 compatibility (many) - - fix clipboard with MS Windows clients - - fix failed server upgrades killing the virtual display - - fix screenshot command with "OR" windows - - fix support for "OR" windows that move and resize - - IPv6 server support - - support for many more audio codecs: flac, opus, wavpack, wav, speex - - support starting remote sessions with "xpra start" - - support for Xdummy with CentOS 6.4 onwards - - add --log-file command line option - - add clipboard regex string filtering - - add clipboard transfer in progress animation via system tray - - detect broken/slow connections and temporarily grey out windows - - reduce regular packet header sizes using numeric lookup tables - - allow more options in xpra config and launcher files - - MS Windows fixes for Caps Lock and Num Lock synchronization - - MS Windows and OSX builds trim the amount of GStreamer plugins shipped - - MS Windows, OSX and static codec builds (Ubuntu Lucid, Debian Squeeze) updated to libav 9.4 - - MS Windows and OSX builds updated to use Python 2.7.4 - - MS Windows library updates (pyasn1, numpy, webp) - - OSX library updates (mpfr, x264, pyasn1, numpy, webp), fixed sound packaging - - safer test for windows to ignore (window IDs starts at 1 again) - - expose more version and statistical data via xpra info - - improved OpenGL client rendering (still disabled by default) - - upgrade to rencode 1.0.2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF4KT4ACgkQGK2zHPGK1rsargCeLDdEZp1wZX2KQfywAnagSr3A k3YAn1MbLozE9JJex/V9fc4MdbYwx+Sd =5Aw+ -----END PGP SIGNATURE----- From kristof.ralovich at gmail.com Thu Apr 25 10:45:27 2013 From: kristof.ralovich at gmail.com (kristof.ralovich at gmail.com) Date: Thu, 25 Apr 2013 11:45:27 +0200 Subject: [winswitch] xpra using cygwin ssh In-Reply-To: <5176B7FD.2000407@nagafix.co.uk> References: <51769890.6030104@nagafix.co.uk> <5176B7FD.2000407@nagafix.co.uk> Message-ID: On Tue, Apr 23, 2013 at 6:34 PM, Antoine Martin wrote: > (snip) > >> cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', ' > example.com', > >> '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', > >> ':1001']: the SSH process has terminated with exit code=255 > >> 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 > >> bytes) and 0 packets sent (0 bytes) > >> Exception in thread format (most likely raised during interpreter > shutdown): > (snip) > > If the patch below works for you, I guess I could use the "ssh" syntax > > when the ssh command looks like a proper ssh... ugly, but that's win32 > > for you. > The solution seemed simple enough so I've merged it already: > http://xpra.org/trac/changeset/3136/xpra > > You can find the latest beta win32 packages with this change included > here (r3136): > http://xpra.org/beta/windows/ > > Cheers > Antoine > Dear Antoine, thank your for the quick reply! I don't have the build environment to try the source patch, and http://xpra.org/beta/windows/ seems to be empty when I've checked. I'll probably wait for the next release to try this out. Thanks a lot! Kristof > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Thu Apr 25 11:04:40 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 25 Apr 2013 17:04:40 +0700 Subject: [winswitch] xpra using cygwin ssh In-Reply-To: References: <51769890.6030104@nagafix.co.uk> <5176B7FD.2000407@nagafix.co.uk> Message-ID: <5178FFB8.8030109@nagafix.co.uk> On 04/25/2013 04:45 PM, kristof.ralovich at gmail.com wrote: > On Tue, Apr 23, 2013 at 6:34 PM, Antoine Martin > wrote: > > (snip) > >> cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', > 'example.com ', > >> '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', > >> ':1001']: the SSH process has terminated with exit code=255 > >> 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 > >> bytes) and 0 packets sent (0 bytes) > >> Exception in thread format (most likely raised during interpreter > shutdown): > (snip) > > If the patch below works for you, I guess I could use the "ssh" syntax > > when the ssh command looks like a proper ssh... ugly, but that's win32 > > for you. > The solution seemed simple enough so I've merged it already: > http://xpra.org/trac/changeset/3136/xpra > > You can find the latest beta win32 packages with this change included > here (r3136): > http://xpra.org/beta/windows/ > > Cheers > Antoine > > > Dear Antoine, > > thank your for the quick reply! I don't have the build environment to > try the source patch, and http://xpra.org/beta/windows/ seems to be > empty when I've checked. I'll probably wait for the next release to try > this out. 0.9.0 was released last night, which is why the beta area got cleared out. (and the win32 build just got updated a minute ago to fix an ssh issue which had been caused by this untested patch..) Cheers Antoine > > Thanks a lot! > Kristof > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > From utku at um-ic.com Thu Apr 25 13:08:52 2013 From: utku at um-ic.com (Utku Altunkaya) Date: Thu, 25 Apr 2013 15:08:52 +0300 Subject: [winswitch] xpra-0.9.0 RPM installation Message-ID: <51791CD4.9050900@um-ic.com> When I tried to update XPRA on a CentOS 6.4 machine, I got the following error: Updating: xpra-0.9.0-25.el6.x86_64 Non-fatal POSTIN scriptlet failure in rpm package xpra-0.9.0-25.el6.x86_64 chcon: can't apply partial context to unlabeled file `/usr/lib/python2.6/site-packages/xpra/x264/codec.so' chcon: can't apply partial context to unlabeled file `/usr/lib/python2.6/site-packages/xpra/vpx/codec.so' warning: %post(xpra-0.9.0-25.el6.x86_64) scriptlet failed, exit status 1 Cleanup: xpra-0.8.8-1.el6.x86_64 SELinux is disabled on this machine, which is probably the reason for this error. Although the message says "non-fatal", I'm worried that the RPM post-installation script was interrupted and may have left some configuration incomplete. Can you update the script to take into account the case where SELinux is diasabled and files don't have any security context assigned to them? Another issue is that everytime I do an update the RPM overwrites my custom site-wide configuration in /etc/xpra/xpra.conf. It should check the existence of xpra.conf (which can be a regular file or, as is in my case, a symbolic link) and leave it untouched, preferably saving the new default configuration in a file such as xpra.conf.rpmorig. Regards, Utku Altunkaya From antoine at nagafix.co.uk Thu Apr 25 14:55:29 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 25 Apr 2013 20:55:29 +0700 Subject: [winswitch] xpra-0.9.0 RPM installation In-Reply-To: <51791CD4.9050900@um-ic.com> References: <51791CD4.9050900@um-ic.com> Message-ID: <517935D1.4020109@nagafix.co.uk> On 04/25/2013 07:08 PM, Utku Altunkaya wrote: > When I tried to update XPRA on a CentOS 6.4 machine, I got the following > error: > > Updating: xpra-0.9.0-25.el6.x86_64 > Non-fatal POSTIN scriptlet failure in rpm package xpra-0.9.0-25.el6.x86_64 > chcon: can't apply partial context to unlabeled file > `/usr/lib/python2.6/site-packages/xpra/x264/codec.so' > chcon: can't apply partial context to unlabeled file > `/usr/lib/python2.6/site-packages/xpra/vpx/codec.so' > warning: %post(xpra-0.9.0-25.el6.x86_64) scriptlet failed, exit status 1 > Cleanup: xpra-0.8.8-1.el6.x86_64 I'm pretty sure it isn't a problem. > SELinux is disabled on this machine, which is probably the reason for > this error. Although the message says "non-fatal", I'm worried that the > RPM post-installation script was interrupted and may have left some > configuration incomplete. That's the only post-installation script there is, so even if it did stop (which I believe it did not), it would not be a problem. > Can you update the script to take into account > the case where SELinux is diasabled and files don't have any security > context assigned to them? I'm not sure how, or if it is even worth doing. > Another issue is that everytime I do an update the RPM overwrites my > custom site-wide configuration in /etc/xpra/xpra.conf. It should check > the existence of xpra.conf (which can be a regular file or, as is in my > case, a symbolic link) and leave it untouched, preferably saving the new > default configuration in a file such as xpra.conf.rpmorig. Isn't that rpm's responsability to manage how those are handled? Note: depending on how many users you do this for, you may simply want to keep your overrides in ~/.xpra/xpra.conf Cheers Antoine > > Regards, > Utku Altunkaya > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Thu Apr 25 15:03:09 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 25 Apr 2013 21:03:09 +0700 Subject: [winswitch] xpra-0.9.0 RPM installation In-Reply-To: <517935D1.4020109@nagafix.co.uk> References: <51791CD4.9050900@um-ic.com> <517935D1.4020109@nagafix.co.uk> Message-ID: <5179379D.5080803@nagafix.co.uk> (snip) >> Another issue is that everytime I do an update the RPM overwrites my >> custom site-wide configuration in /etc/xpra/xpra.conf. It should check >> the existence of xpra.conf (which can be a regular file or, as is in my >> case, a symbolic link) and leave it untouched, preferably saving the new >> default configuration in a file such as xpra.conf.rpmorig. > Isn't that rpm's responsability to manage how those are handled? Sorry, I'm totally wrong on this. It looks like we should be using the %config directive here and we don't. Will fix. Cheers Antoine From kristof.ralovich at gmail.com Thu Apr 25 15:12:44 2013 From: kristof.ralovich at gmail.com (kristof.ralovich at gmail.com) Date: Thu, 25 Apr 2013 16:12:44 +0200 Subject: [winswitch] xpra using cygwin ssh In-Reply-To: <5178FFB8.8030109@nagafix.co.uk> References: <51769890.6030104@nagafix.co.uk> <5176B7FD.2000407@nagafix.co.uk> <5178FFB8.8030109@nagafix.co.uk> Message-ID: On Thu, Apr 25, 2013 at 12:04 PM, Antoine Martin wrote: > On 04/25/2013 04:45 PM, kristof.ralovich at gmail.com wrote: > > On Tue, Apr 23, 2013 at 6:34 PM, Antoine Martin > > wrote: > > > > (snip) > > >> cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', > > 'example.com ', > > >> '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', > '_proxy', > > >> ':1001']: the SSH process has terminated with exit code=255 > > >> 2013-04-23 15:03:08,441 connection closed after 0 packets > received (0 > > >> bytes) and 0 packets sent (0 bytes) > > >> Exception in thread format (most likely raised during interpreter > > shutdown): > > (snip) > > > If the patch below works for you, I guess I could use the "ssh" > syntax > > > when the ssh command looks like a proper ssh... ugly, but that's > win32 > > > for you. > > The solution seemed simple enough so I've merged it already: > > http://xpra.org/trac/changeset/3136/xpra > > > > You can find the latest beta win32 packages with this change included > > here (r3136): > > http://xpra.org/beta/windows/ > > > > Cheers > > Antoine > > > > > > Dear Antoine, > > > > thank your for the quick reply! I don't have the build environment to > > try the source patch, and http://xpra.org/beta/windows/ seems to be > > empty when I've checked. I'll probably wait for the next release to try > > this out. > 0.9.0 was released last night, which is why the beta area got cleared > out. (and the win32 build just got updated a minute ago to fix an ssh > issue which had been caused by this untested patch..) > > Cheers > Antoine It is working now! Thanks, Kristof > > > > > Thanks a lot! > > Kristof > > > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > From utku at um-ic.com Thu Apr 25 15:14:28 2013 From: utku at um-ic.com (Utku Altunkaya) Date: Thu, 25 Apr 2013 17:14:28 +0300 Subject: [winswitch] xpra-0.9.0 RPM installation In-Reply-To: <517935D1.4020109@nagafix.co.uk> References: <51791CD4.9050900@um-ic.com> <517935D1.4020109@nagafix.co.uk> Message-ID: <51793A44.5020101@um-ic.com> On 25/04/13 16:55, Antoine Martin wrote: > On 04/25/2013 07:08 PM, Utku Altunkaya wrote: >> When I tried to update XPRA on a CentOS 6.4 machine, I got the following >> error: >> >> Updating: xpra-0.9.0-25.el6.x86_64 >> Non-fatal POSTIN scriptlet failure in rpm package xpra-0.9.0-25.el6.x86_64 >> chcon: can't apply partial context to unlabeled file >> `/usr/lib/python2.6/site-packages/xpra/x264/codec.so' >> chcon: can't apply partial context to unlabeled file >> `/usr/lib/python2.6/site-packages/xpra/vpx/codec.so' >> warning: %post(xpra-0.9.0-25.el6.x86_64) scriptlet failed, exit status 1 >> Cleanup: xpra-0.8.8-1.el6.x86_64 > I'm pretty sure it isn't a problem. > >> SELinux is disabled on this machine, which is probably the reason for >> this error. Although the message says "non-fatal", I'm worried that the >> RPM post-installation script was interrupted and may have left some >> configuration incomplete. > That's the only post-installation script there is, so even if it did > stop (which I believe it did not), it would not be a problem. > >> Can you update the script to take into account >> the case where SELinux is diasabled and files don't have any security >> context assigned to them? > I'm not sure how, or if it is even worth doing. Thank you, I'm relieved. If this is the only task that the script handles, then it wouldn't be worth the effort to go check for SELinux. >> Another issue is that everytime I do an update the RPM overwrites my >> custom site-wide configuration in /etc/xpra/xpra.conf. It should check >> the existence of xpra.conf (which can be a regular file or, as is in my >> case, a symbolic link) and leave it untouched, preferably saving the new >> default configuration in a file such as xpra.conf.rpmorig. > Isn't that rpm's responsability to manage how those are handled? > > Note: depending on how many users you do this for, you may simply want > to keep your overrides in ~/.xpra/xpra.conf As far as I could find, you need to mark config files in the RPM spec so that they are not replaced during an update. The syntax is something like %config(noreplace) /etc/xpra/xpra.conf Regards, Utku Altunkaya From utku at um-ic.com Thu Apr 25 15:16:10 2013 From: utku at um-ic.com (Utku Altunkaya) Date: Thu, 25 Apr 2013 17:16:10 +0300 Subject: [winswitch] xpra-0.9.0 RPM installation In-Reply-To: <5179379D.5080803@nagafix.co.uk> References: <51791CD4.9050900@um-ic.com> <517935D1.4020109@nagafix.co.uk> <5179379D.5080803@nagafix.co.uk> Message-ID: <51793AAA.3090304@um-ic.com> On 25/04/13 17:03, Antoine Martin wrote: > (snip) >>> Another issue is that everytime I do an update the RPM overwrites my >>> custom site-wide configuration in /etc/xpra/xpra.conf. It should check >>> the existence of xpra.conf (which can be a regular file or, as is in my >>> case, a symbolic link) and leave it untouched, preferably saving the new >>> default configuration in a file such as xpra.conf.rpmorig. >> Isn't that rpm's responsability to manage how those are handled? > Sorry, I'm totally wrong on this. It looks like we should be using the > %config directive here and we don't. Will fix. Ah, you have beaten me to it :) Thanks again, and best regards. Utku From ammarh at andrew.cmu.edu Thu Apr 25 16:40:31 2013 From: ammarh at andrew.cmu.edu (Ammar Husain) Date: Thu, 25 Apr 2013 11:40:31 -0400 Subject: [winswitch] shifter-users Digest, Vol 26, Issue 4 In-Reply-To: References: Message-ID: Hi Antoine, Thanks for the response. While the Java Swing app might serve the purpose, I was looking for something that would require no client side install. I know the Xpra protocol works a little differently, in that it does not stream frame buffers as in VNC. However, I was wondering if there is a way to latch onto an Xpra DISPLAY on the server site through a web page and stream the application (not necessarily embedded into the browser). I guess, the main idea is to take away any client side configuration and deliver the application through a website. There are several people in my project group, who do not use a terminal/ have winswitch installed etc. Thanks! Ammar On Thu, Apr 25, 2013 at 5:46 AM, wrote: > Send shifter-users mailing list submissions to > shifter-users at lists.devloop.org.uk > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > or, via email, send a message with subject or body 'help' to > shifter-users-request at lists.devloop.org.uk > > You can reach the person managing the list at > shifter-users-owner at lists.devloop.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of shifter-users digest..." > > > Today's Topics: > > 1. Re: xpra issuses (Randy) > 2. xpra using cygwin ssh (kristof.ralovich at gmail.com) > 3. Re: xpra using cygwin ssh (Antoine Martin) > 4. Re: xpra using cygwin ssh (Antoine Martin) > 5. Web browser based Xpra viewer (Ammar Husain) > 6. Re: Web browser based Xpra viewer (Antoine Martin) > 7. [ANNOUNCE] xpra 0.9.0 (Antoine Martin) > 8. Re: xpra using cygwin ssh (kristof.ralovich at gmail.com) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 15 Apr 2013 10:35:42 -0400 > From: Randy > To: shifter-users at lists.devloop.org.uk > Subject: Re: [winswitch] xpra issuses > Message-ID: <201304151035.42629.thejunk.b at gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thanks. > > > You should be able to workaround this problem by defining another > > default encoding, either in /etc/xpra/xpra.conf or in ~/.xpra/xpra.conf > > Just got back from vacation myself only to find my systems crashed. That > and > work, when I get a chance I will look into this. > > -- > If it ain't broke tweek it > > > ------------------------------ > > Message: 2 > Date: Tue, 23 Apr 2013 16:08:17 +0200 > From: "kristof.ralovich at gmail.com" > To: shifter-users at lists.devloop.org.uk > Subject: [winswitch] xpra using cygwin ssh > Message-ID: > < > CAMfbS5MwmXQKE9h8F4He_nfbyRjbiufB04F3arQMxyy4a7kO6w at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Dear All, > > I'm using xpra with great satisfaction. Recently I bumped into a issue > while trying to attach to a server from a client behind a proxy. I've set > up cygwin, ssh and connect-proxy to work hand-in-hand, for command line > communication this pipeline is functional. Now, I would also like to use > this working ssh setup for xpra too. To this end, I've changed this line > > ssh = c:/cygwin/bin/ssh.exe > > in c:\Program Files (x86)\Xpra\xpra.conf to point ssh to cygwin's. Then > running Xpra_cmd.exe from a cygwin shell produced the output below: > > user at laptop /cygdrive/c/Program Files (x86)/Xpra > $ ./Xpra_cmd.exe attach ssh:user at example.com:1001 > ** Message: pygobject_register_sinkfunc is deprecated (GstObject) > xpra client version 0.8.8 > cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', ' > example.com', > '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', > ':1001']: the SSH process has terminated with exit code=255 > 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 > bytes) and 0 packets sent (0 bytes) > Exception in thread format (most likely raised during interpreter > shutdown): > > Is there a way to print the output of ssh for debugging? Or any hints that > I should consider? > > Thanks in advance, > Kristof > > > ------------------------------ > > Message: 3 > Date: Tue, 23 Apr 2013 21:20:00 +0700 > From: Antoine Martin > To: shifter-users at lists.devloop.org.uk > Subject: Re: [winswitch] xpra using cygwin ssh > Message-ID: <51769890.6030104 at nagafix.co.uk> > Content-Type: text/plain; charset=ISO-8859-1 > > On 04/23/2013 09:08 PM, kristof.ralovich at gmail.com wrote: > > Dear All, > > > > I'm using xpra with great satisfaction. Recently I bumped into a issue > > while trying to attach to a server from a client behind a proxy. I've set > > up cygwin, ssh and connect-proxy to work hand-in-hand, for command line > > communication this pipeline is functional. Now, I would also like to use > > this working ssh setup for xpra too. To this end, I've changed this line > > > > ssh = c:/cygwin/bin/ssh.exe > > > > in c:\Program Files (x86)\Xpra\xpra.conf to point ssh to cygwin's. > You should be modifying the user's xpra.conf rather than the system > default, creating one if it doesn't exist. > IIRC, on win32 this would be %APPDATA%\Xpra\xpra.conf > > This way it won't get overwritten with every Xpra software update. > > > Then > > running Xpra_cmd.exe from a cygwin shell produced the output below: > > > > user at laptop /cygdrive/c/Program Files (x86)/Xpra > > $ ./Xpra_cmd.exe attach ssh:user at example.com:1001 > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject) > > xpra client version 0.8.8 > > cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', ' > example.com', > > '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', > > ':1001']: the SSH process has terminated with exit code=255 > > 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 > > bytes) and 0 packets sent (0 bytes) > > Exception in thread format (most likely raised during interpreter > shutdown): > > > > Is there a way to print the output of ssh for debugging? Or any hints > that > > I should consider? > On win32 we don't use putty.exe but plink.exe (and not the one from > putty, but the one from tortoise to get a GUI for accepting host keys > and asking for passwords). > The connection stage is too early to get any meaningful debugging > information using the "xpra -d all" flag I think. > > Have you tried running that ssh command line by hand to make sure it > does work? I'm pretty sure it won't because it assumes that we're > dealing with "plink.exe" on win32, so the flags "-ssh" and "-agent" are > probably causing ssh.exe to abort with an error. > > If the patch below works for you, I guess I could use the "ssh" syntax > when the ssh command looks like a proper ssh... ugly, but that's win32 > for you. > > Cheers > Antoine > > > > > ### Eclipse Workspace Patch 1.0 > #P Xpra > Index: src/xpra/scripts/main.py > =================================================================== > --- src/xpra/scripts/main.py (revision 3132) > +++ src/xpra/scripts/main.py (working copy) > @@ -531,7 +531,7 @@ > dtype = display_desc["type"] > if dtype == "ssh": > cmd = display_desc["full_ssh"] > - if sys.platform.startswith("win"): > + if False: > password = display_desc.get("password") > if password: > cmd += ["-pw", password] > > > > ------------------------------ > > Message: 4 > Date: Tue, 23 Apr 2013 23:34:05 +0700 > From: Antoine Martin > To: shifter-users at lists.devloop.org.uk > Subject: Re: [winswitch] xpra using cygwin ssh > Message-ID: <5176B7FD.2000407 at nagafix.co.uk> > Content-Type: text/plain; charset=ISO-8859-1 > > (snip) > >> cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', ' > example.com', > >> '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', > >> ':1001']: the SSH process has terminated with exit code=255 > >> 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 > >> bytes) and 0 packets sent (0 bytes) > >> Exception in thread format (most likely raised during interpreter > shutdown): > (snip) > > If the patch below works for you, I guess I could use the "ssh" syntax > > when the ssh command looks like a proper ssh... ugly, but that's win32 > > for you. > The solution seemed simple enough so I've merged it already: > http://xpra.org/trac/changeset/3136/xpra > > You can find the latest beta win32 packages with this change included > here (r3136): > http://xpra.org/beta/windows/ > > Cheers > Antoine > > > ------------------------------ > > Message: 5 > Date: Wed, 24 Apr 2013 13:11:00 -0400 > From: Ammar Husain > To: shifter-users at lists.devloop.org.uk > Subject: [winswitch] Web browser based Xpra viewer > Message-ID: > < > CAPMS+Rgzoea+VmsEUOuTzDo-aJAXfmVdd4H4tBzKzHAjJGfdng at mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi All, > Xpra has greatly helped me to remotely connect to applications on my work > computer. However I was wondering if there is an Xpra viewer that is > entirely web-based? I was reading through the documentation and it seems > like the Xpra viewer utilises the windowing system on the client machine. > Has anyone given it a try to embed the windowing in a web browser, possibly > using HTML5 canvas / AJAX? I mean something similar to NX WebPlayer or > noVNC. Would it even be possible to do something like that with Xpra > viewer? That would be of great help to me. > Thanks, > Ammar > > > ------------------------------ > > Message: 6 > Date: Thu, 25 Apr 2013 00:15:10 +0700 > From: Antoine Martin > To: shifter-users at lists.devloop.org.uk > Subject: Re: [winswitch] Web browser based Xpra viewer > Message-ID: <5178131E.7060803 at nagafix.co.uk> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Ammar, > > There are Java versions of the client (AWT and Swing) which could be > delivered to a browser. But: > * this Java code is not production ready by any means > * I've never tried doing that > * you would lose many of the benefits of Xpra (mainly: seamlessness) > > Cheers > Antoine > > On 04/25/2013 12:11 AM, Ammar Husain wrote: > > Hi All, > > Xpra has greatly helped me to remotely connect to applications on my work > > computer. However I was wondering if there is an Xpra viewer that is > > entirely web-based? I was reading through the documentation and it seems > > like the Xpra viewer utilises the windowing system on the client machine. > > Has anyone given it a try to embed the windowing in a web browser, > possibly > > using HTML5 canvas / AJAX? I mean something similar to NX WebPlayer or > > noVNC. Would it even be possible to do something like that with Xpra > > viewer? That would be of great help to me. > > Thanks, > > Ammar > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > ------------------------------ > > Message: 7 > Date: Thu, 25 Apr 2013 01:49:40 +0700 > From: Antoine Martin > To: "shifter-users at lists.devloop.org.uk" > > Subject: [winswitch] [ANNOUNCE] xpra 0.9.0 > Message-ID: <51782944.6010203 at nagafix.co.uk> > Content-Type: text/plain; charset=ISO-8859-1 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > This new major release brings many new features, but more importantly > a large number of important bug fixes throughout. > > Here are some of the key new features and fixes: > * remote session start: xpra start ssh:host:DISP --start-child=cmd > * more sound codec support (wav, flac, opus..) > * MS Windows fixes (clipboard, caps and num lock synchronization) > * Platform fixes: IPv6 server, Python 2.4 fixes, SELinux labels, etc > * better launcher and support for launching from ".xpra" session files > > > The source: > https://xpra.org/src/ > Binaries/repositories: > https://winswitch.org/downloads/ > Direct binary downloads: > https://xpra.org/dists/ > > Cheers > Antoine > > PS: as usual, the Mac OSX build failed some last minute testing and > will be posted later. > > > Full releases notes: > - - fix focus problems with old Xvfb display servers > - - fix RPM SELinux labelling of static codec builds (CentOS) > - - fix CentOS 5.x compatibility > - - fix Python 2.4 and 2.5 compatibility (many) > - - fix clipboard with MS Windows clients > - - fix failed server upgrades killing the virtual display > - - fix screenshot command with "OR" windows > - - fix support for "OR" windows that move and resize > - - IPv6 server support > - - support for many more audio codecs: flac, opus, wavpack, wav, speex > - - support starting remote sessions with "xpra start" > - - support for Xdummy with CentOS 6.4 onwards > - - add --log-file command line option > - - add clipboard regex string filtering > - - add clipboard transfer in progress animation via system tray > - - detect broken/slow connections and temporarily grey out windows > - - reduce regular packet header sizes using numeric lookup tables > - - allow more options in xpra config and launcher files > - - MS Windows fixes for Caps Lock and Num Lock synchronization > - - MS Windows and OSX builds trim the amount of GStreamer plugins shipped > - - MS Windows, OSX and static codec builds (Ubuntu Lucid, Debian > Squeeze) updated to libav 9.4 > - - MS Windows and OSX builds updated to use Python 2.7.4 > - - MS Windows library updates (pyasn1, numpy, webp) > - - OSX library updates (mpfr, x264, pyasn1, numpy, webp), fixed sound > packaging > - - safer test for windows to ignore (window IDs starts at 1 again) > - - expose more version and statistical data via xpra info > - - improved OpenGL client rendering (still disabled by default) > - - upgrade to rencode 1.0.2 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.13 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlF4KT4ACgkQGK2zHPGK1rsargCeLDdEZp1wZX2KQfywAnagSr3A > k3YAn1MbLozE9JJex/V9fc4MdbYwx+Sd > =5Aw+ > -----END PGP SIGNATURE----- > > > ------------------------------ > > Message: 8 > Date: Thu, 25 Apr 2013 11:45:27 +0200 > From: "kristof.ralovich at gmail.com" > To: Antoine Martin > Cc: shifter-users at lists.devloop.org.uk > Subject: Re: [winswitch] xpra using cygwin ssh > Message-ID: > < > CAMfbS5OvyhR22aC__5asH2gnn+qi4qq0kTLwgePOqBz3mAgBNg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Apr 23, 2013 at 6:34 PM, Antoine Martin >wrote: > > > (snip) > > >> cannot read using ['c:/cygwin/bin/ssh.exe', '-l', 'user', '-T', ' > > example.com', > > >> '-ssh', '-agent', '.xpra/run-xpra', '--socket-dir=~/.xpra', '_proxy', > > >> ':1001']: the SSH process has terminated with exit code=255 > > >> 2013-04-23 15:03:08,441 connection closed after 0 packets received (0 > > >> bytes) and 0 packets sent (0 bytes) > > >> Exception in thread format (most likely raised during interpreter > > shutdown): > > (snip) > > > If the patch below works for you, I guess I could use the "ssh" syntax > > > when the ssh command looks like a proper ssh... ugly, but that's win32 > > > for you. > > The solution seemed simple enough so I've merged it already: > > http://xpra.org/trac/changeset/3136/xpra > > > > You can find the latest beta win32 packages with this change included > > here (r3136): > > http://xpra.org/beta/windows/ > > > > Cheers > > Antoine > > > > Dear Antoine, > > thank your for the quick reply! I don't have the build environment to try > the source patch, and http://xpra.org/beta/windows/ seems to be empty when > I've checked. I'll probably wait for the next release to try this out. > > Thanks a lot! > Kristof > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > ------------------------------ > > End of shifter-users Digest, Vol 26, Issue 4 > ******************************************** > From antoine at nagafix.co.uk Thu Apr 25 19:21:52 2013 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 26 Apr 2013 01:21:52 +0700 Subject: [winswitch] Web browser based Xpra viewer In-Reply-To: References: Message-ID: <51797440.1070808@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/25/2013 10:40 PM, Ammar Husain wrote: > Thanks for the response. While the Java Swing app might serve the > purpose, I was looking for something that would require no client > side install. The point of the Java client is that it *could* be delivered as a Java applet and run within the browser's Java plugin. Provided you have Java installed on the client machines obviously, then no install would be required. Cheers Antoine -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF5dEAACgkQGK2zHPGK1rs5fACfXmcWp5QR/L4tNQvmrZebKfL7 5pgAn23/2BYqL4Fi5/hc8N2O7VSqf1ig =Qq1U -----END PGP SIGNATURE----- From thejunk.b at gmail.com Sun Apr 28 19:13:52 2013 From: thejunk.b at gmail.com (Randy) Date: Sun, 28 Apr 2013 14:13:52 -0400 Subject: [winswitch] xpra issuses In-Reply-To: <516AE231.7050209@nagafix.co.uk> References: <201303291519.45144.thejunk.b@gmail.com> <201304071125.09019.thejunk.b@gmail.com> <516AE231.7050209@nagafix.co.uk> Message-ID: <201304281413.52512.thejunk.b@gmail.com> On Sunday, April 14, 2013, Antoine Martin wrote: > On 04/07/2013 10:25 PM, Randy wrote: > > On Sunday, March 31, 2013, Antoine Martin wrote: > >> Wait, ... are you trying to use NX or Xpra sessions? > > > > xpra > > > > OK, so I started over. I am using 2 machine, one is a laptop, the other > > a desktop. Both of these machine worked with each other before I > > upgaded from the older version. Both machines run debian wheezy 64 /w > > kde. The desktop (TV) is hardwired to my local network, the laptop > > (BumbleBee) uses wifi. I am able to ssh back and forth between machine > > manually with out issue and run gui apps from cli. > > > > To start over I uninstalled both winswitch and xpra from both machines. > > Then I manually deleted the .winswitch and .xpra folders from users > > ~/user. Then I reinstalled both packages and reinstall the dependant > > packages from synaptic. Neither machine has selinux installed. > > > > I have not modifed the default config except to enable debug. I get no > > joy trying to run apps remotly. The servers seem to connect to each > > other correctly. I am able to remotly launch guvcview (webcam app) on > > the desktop from the laptop, but I am still seeing the app briefly > > appear on the laptop then dissapear with a popup message that I can not > > interpret. I also don't see that message text in the logs. > > > > If I go over to the desktop the app is there and I can reconnect to it > > and it displays just fine locally. > > > > I have tared the config files and log files off both machine and they can > > be seen at > > https://www.dropbox.com/sh/trsi9d82yvsuuk0/yiXmoIi-jk > > if you have issues reading them let me know and we can try something > > else. > > > > > > Thanks > > Sorry for the late reply, I've skimmed through your log files and found > this in laptop/applet-20130406-224841.log: > **** > [NULL @ 0x35ef8a0] Value 4686111960511545344.000000 for parameter 'b' > out of range > (snip) > A process has ended with a probable error condition: process ended by > signal 6 > **** > Looks to me like there are problems with x264. I can tell you are using > x264 from this line in the server log: > 2013-04-06 22:52:38,420 using x264 as primary encoding > > You should be able to workaround this problem by defining another > default encoding, either in /etc/xpra/xpra.conf or in ~/.xpra/xpra.conf > > I suspect this is yet-another problem caused by the API changes to > libav.. I accepted a patch to make it work with newer versions, which > seems to have caused endless problems with 99% of the versions currently > deployed instead. > I'll try to run a VM with wheezy/+-testing and see if I can reproduce. > > > > I also found this in desktop/applet-20130406-225118.log: > **** > 2013-04-07 07:00:31,910 Password matches! > Traceback (most recent call last): > File "/usr/lib/python2.7/dist-packages/wimpiggy/util.py", line 26, in > do_get_property > return getattr(self, getter)(pspec.name) > File "/usr/lib/python2.7/dist-packages/wimpiggy/window.py", line 316, > in do_get_property_client_contents > return self._composite.get_property("contents") > AttributeError: 'NoneType' object has no attribute 'get_property' > 2013-04-07 07:00:32,083 Connection lost > **** > That's an odd one, but probably not the cause of your problems. I think > it is a consequence of it. > Looks like we're trying to make calls on a window which is not/no-longer > managed. > > > Have you got a screenshot or copy of the "popup message that I can not > interpret"? > > Thanks > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users So I finally got a chance to play with xpra a little. To start with there was an update so I installed it. Now I at least get a properly titled window on the remote host. When it first launched guvcviewer I had the control window and the camera window. The control window was fully populated but the camera window was blank. As soon as I tried to use the controls the window went white. Trying to close either window fails, eventually the kde window manager asks if you want to force close. Forcing the window closed from the winswitch menu seams to close the session but leaves the windows open. I tried to get a screen shot of the error that use to pop up but it did not show up this time. Short pause for dinner and some honey-do's. Next I tried launching gimp remotly. This time it acted just like before. I was able to get a screen shot of the error. Then I changed the default seamless session type to nx on the desktop, but not via the config files, and tried again, same results. Looking at the information menu item for the session it showed the session type as xpra. So I rechecked the settings and confirmed that I had successfully changed it, and yes. So I restarted winswitch. Then I went to the laptop and changed the default session type to nx and restarted winswitch there too. The I relaunched guvcviewer with the same results as before, captured the error in a screenshot. I then checked the menu info item and it still shows the session type as xpra, hmmm. I reconfirmed that the settings are set to nx and grabbed some screenshots for you of the destop setup. Apps started locally via winswitch are displayed correctly. Vbox wm's can be moved between machines successfully, although starting them remotly does not seem to work correctly. The vm is started but not displayed remotly untill it is fully up and then moved to the remote machine. Not a big issue at this time for me. So I decided a complete restart was in order on both machines. After the rebooot I have a guvcviewer menu item that is not movable nor openable on either machine. So to avoid confilct with that session I tried launching K3b (cd burning app) and it failed as before. And checking the session type in the info menu item shows that it is still using xpra and not nx. Looking at the desktop server settings from the laptop shows that it is set to use xpar, but looking at the server setting on the desktop shows it set to nx. But if I go to the server tab it the setings and right click on the desktop server and check the settings there they show xpra as the seamless default and it can not be changed, hmmmm. I was able to capture the screen error. As I mentioned at the start the only thing that has been changed is that I updated xpra before this round of debugging. What else can I try to assist you? Oh yea, I did disable the firewalls after the reboot to be sure they were not the problem. Autolaunch is enabled on the desktop but not on the laptop. I also noted that when looking at the available servers on the desktop, the desktop server does not have ssh capablities, yet I ssh in and out of the desktop all the time, and I can successfully connect to it via winswitch. It just does not seam to have ssh with its self. OK. After rereading the instructions you sent me I discovered that I was not doing as you requested. Guess I should not rely on my memory so much. I have looked at the xpra.conf files and can not find anywhere that x264 encoding is set. A hardcoded defalut? The attached configs are as they exist before I enable a different encoding. From /etc/xpra/xpra.conf # Default encoding (not all encodings may be available in your environment): #encoding = x264 #encoding = vpx #encoding = png #encoding = jpeg #encoding = rgb24 #encoding = webp is there one that would be better or worse? Png seams to work fine. After resting winswitch on both the laptop and the desktop I still have the old guvcviewer menu entry. How do I make it go away? Now to go play with the other machines to see if I can finally get them to work :) Thanks for the work around. If I can do anything further to help debug let me know. The image files and logs are at https://www.dropbox.com/home/Public/winswitch The old ones have been deleted. Thanks Randy -- If it ain't broke tweek it