Xpra: Ticket #1206: Native full destop support?

While it is possible to launch nested X server inside Xpra, it has disadvantages: addition of another DISPLAY, inability to properly use 'run command' feature, existence of sometimes largely unused framebuffer around nested desktop.

Please add native full-desktop mode.



Thu, 26 May 2016 05:17:31 GMT - Antoine Martin: keywords, owner, component changed

I don't understand what it is that you are trying to achieve. What do you mean by native?

The xpra seamless X11 server needs a display, so you have to start one or use an existing one.

If you want to forward a display server running on a non-virtual GPU, then that is already possible using the --use-display flag.

I'm not sure why the "run command" feature would not work.


Thu, 26 May 2016 05:30:02 GMT - psycho_zs:

I don't understand what it is that you are trying to achieve. What do you mean by native?

Ability to run remote full-desktop virtual session without Xephyr.

I'm not sure why the "run command" feature would not work.

"run command" would use xpra server's DISPLAY, while Xephyr uses another DISPLAY.


Thu, 26 May 2016 05:48:02 GMT - Antoine Martin: owner, status changed

Ah, I think I get it: you want a fixed size display that we would export in its entirety, running a full desktop - including a DE or window manager, and shown as a window on the client, VNC style.

This cannot work with xpra as it is: xpra is a window manager and you can only have a single window manager per display. That's why you need Xephyr.

VNC like solutions use "vnc.so" Xorg sever modules or just a modified X11 server (Xvnc) in order to get the screen damage notifications without being the window manager.

That would be a lot of work.


Thu, 26 May 2016 05:52:26 GMT - psycho_zs:

Is it possible to reuse bits of shadow mechanics for this purpose?


Thu, 26 May 2016 06:27:44 GMT - Antoine Martin:

Not really, shadow uses a timer to poll the screen for screen updates, which is very inefficient. You need the X11 server to tell you when the screen is updated. (and without being the window manager).


Thu, 26 May 2016 08:05:21 GMT - psycho_zs:

How about using Xephyr with special treatment? In full-desktop mode start Xpra server as normal, but with large random X DISPLAY number, exclusively start Xephyr as child with proper DISPLAY number and use it from that point for everything.


Thu, 26 May 2016 11:48:10 GMT - Antoine Martin: milestone changed

OK, I guess we could do something like that.

xpra start-desktop --start=xterm

Would start Xephyr and spin up all clients (ie: xterm) against that display instead. The display number would be chosen by Xephyr automatically using the existing displayfd code. (#172)


Fri, 27 May 2016 06:53:09 GMT - Antoine Martin: owner, status changed

Done in r12697 by adding a new "start-desktop" subcommand, please close if this works for you.

Usage:

xpra start-desktop --start=xterm

You can configure the Xnest / Xephyr command line using the --xnest= command line argument or config file entry.


Fri, 27 May 2016 07:27:29 GMT - psycho_zs:

Has something cups-related changed in package building infrastructure?

You might want to add python-cups, cups-client to build-depends and somehow work around lpclient being located in /usr/sbin (Ensuring that it is in $PATH somewhere in build scripts).

I've worked around that, but stuck with this:

running build_scripts
creating build/scripts-2.7
copying and adjusting scripts/xpra -> build/scripts-2.7
copying and adjusting scripts/xpra_launcher -> build/scripts-2.7
changing mode of build/scripts-2.7/xpra from 644 to 755
changing mode of build/scripts-2.7/xpra_launcher from 644 to 755
running build_conf
probing cups printer definitions
Traceback (most recent call last):
  File "setup.py", line 2426, in <module>
    main()
  File "setup.py", line 2422, in main
    setup(**setup_options)
  File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "setup.py", line 1817, in run
    self.run_command("build_conf")
  File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "setup.py", line 1825, in run
    build_xpra_conf(build_base)
  File "setup.py", line 951, in build_xpra_conf
    conf = template % SUBS
KeyError: 'xnest_command'
dh_auto_build: python setup.py build --force --with-Xdummy --without-Xdummy_wrapper returned exit code 1
debian/rules:15: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1
make[1]: Leaving directory '/home/psycho/src/xpra/xpra-0.18'
debian/rules:10: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Fri, 27 May 2016 07:32:36 GMT - Antoine Martin:

Has something cups-related changed in package building infrastructure?


I don't think so.


You might want to add python-cups, cups-client to build-depends and somehow work around lpclient being located in /usr/sbin (Ensuring that it is in $PATH somewhere in build scripts).


The build needs to work on all supported Debian and Ubuntu supported releases, which is often tricky... patches welcome!


KeyError: 'xnest_command'


Oops, my bad: forgot to include a file in the commit, fixed in r12701.


Fri, 27 May 2016 07:50:27 GMT - psycho_zs:

You might want to add python-cups, cups-client to build-depends and somehow work around lpclient being located in /usr/sbin (Ensuring that it is in $PATH somewhere in build scripts).

The build needs to work on all supported Debian and Ubuntu supported releases, which is often tricky... patches welcome!

Those two packages are in Debian at least since wheezy, but probably even older than that. It is safe to add them.

Regarding PATH, I assume that build environment somehow got user's PATH which does not include any 'sbin' locations. I do not know where is the proper place for setting PATH in this build infrastructure, but something like this would do: printf "$PATH" | grep -q '^/usr/sbin\|:/usr/sbin' || export PATH="${PATH}:/usr/sbin" ; printf "$PATH" | grep -q '^/sbin\|:/sbin' || export PATH="${PATH}:/sbin"

In my case, I've just linked lpinfo to /usr/bin.

Also, are these patches currently needed: new-libav-codec2.patch new-libav-no0RGB.patch no-strict-prototypes-gtkitemfactory.patch?


Fri, 27 May 2016 08:31:48 GMT - psycho_zs:

It works! With recent keyboard grab feature it handles pretty well. If you add -resizeable to Xephyr cli, it could get even cooler.

But unfortunately Xephyr has troubles with DPI, which changes with screen size. I've filed a bug: https://bugs.freedesktop.org/show_bug.cgi?id=96240

In the mean time, have you any idea for a workaround? xrandr --dpi does not work for Xephyr.


Fri, 27 May 2016 10:38:05 GMT - Antoine Martin:

Making Xephyr resizable does not work well at all - you can try it by editing "xnest" in your xpra.conf. xrandr --dpi will not work, for the same reason that it does not work with the dummy driver: Xephyr does not implement the required randr protocol.

As for the build updates, does r12702 fix your /usr/sbin/lpinfo issue?

Regarding patches: apply whatever is needed to fix build errors. Probably all of them.


Fri, 27 May 2016 14:38:53 GMT - psycho_zs:

Yep, lpinfo issue is fixed.

Xpra starts in desktop mode when 'start' subcommand is given remotely

xpra start ssh:user@server:100

Starting on server works as expected.


Sat, 28 May 2016 08:35:27 GMT - Antoine Martin:

Xpra starts in desktop mode when 'start' subcommand is given remotely


Good catch, fixed in r12705.

Can I close this ticket?


Sat, 28 May 2016 08:50:18 GMT - psycho_zs:

I would suggest to make Xephyr's DISPLAY defining in the desktop session, and X's DISPLAY automatic and temporary. If user runs xpra start-desktop :100 he would expect DISPLAY=:100 some-app to launch inside Xephyr. Otherwise case is closed.


Sat, 28 May 2016 11:01:52 GMT - Antoine Martin: owner changed

We can't really use the specified display for Xephyr because xpra uses the display for too many things (ie: many subcommands) and those all refer to the display that is managed by xpra directly... which is the X11 display.

@afarr: you don't need this feature so this is just a FYI, feel free to close.


Fri, 10 Jun 2016 20:28:25 GMT - alas: status changed; resolution set

Interesting. We don't use, but interesting to try at some point.

Closing.


Thu, 07 Jul 2016 09:07:08 GMT - Antoine Martin:

Will follow up in #1247.


Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed


Thu, 12 Jan 2017 02:36:29 GMT - Antoine Martin:

Added wiki page: wiki/Desktop.


Sat, 23 Jan 2021 05:17:53 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1206