Native full destop support?

[totaam]

Issue migrated from trac ticket # 1206

component: server | priority: minor | resolution: fixed | keywords: full-desktop session x11

2016-05-26 04:43:02: psycho_zs created the issue

---

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.

[totaam]

2016-05-26 06:17:31: antoine changed owner from antoine to psycho_zs

[totaam]

2016-05-26 06:17:31: antoine changed component from core to server

[totaam]

2016-05-26 06:17:31: antoine commented

---

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.

[totaam]

2016-05-26 06:30:02: psycho_zs commented

---

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.

[totaam]

2016-05-26 06:48:02: antoine changed status from new to assigned

[totaam]

2016-05-26 06:48:02: antoine changed owner from psycho_zs to antoine

[totaam]

2016-05-26 06:48:02: antoine commented

---

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.

[totaam]

2016-05-26 06:52:27: psycho_zs commented

---

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

[totaam]

2016-05-26 07:27:44: antoine commented

---

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).

[totaam]

2016-05-26 09:05:21: psycho_zs commented

---

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.

[totaam]

2016-05-26 12:48:11: antoine commented

---

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)

[totaam]

2016-05-27 07:53:10: antoine changed status from assigned to new

[totaam]

2016-05-27 07:53:10: antoine changed owner from antoine to psycho_zs

[totaam]

2016-05-27 07:53:10: antoine commented

---

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.

[totaam]

2016-05-27 08:27:29: psycho_zs commented

---

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

[totaam]

2016-05-27 08:32:36: antoine commented

---

Has something cups-related changed in package building infrastructure?
[[BR]]
I don't think so.

[[BR]]

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).
[[BR]]
The build needs to work on all supported Debian and Ubuntu supported releases, which is often tricky... patches welcome!

[[BR]]

KeyError: 'xnest_command'
[[BR]]
Oops, my bad: forgot to include a file in the commit, fixed in r12701.

[totaam]

2016-05-27 08:50:27: psycho_zs commented

---

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?

[totaam]

2016-05-27 09:31:48: psycho_zs commented

---

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.

[totaam]

2016-05-27 11:38:06: antoine commented

---

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.

[totaam]

2016-05-27 15:38:54: psycho_zs commented

---

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.

[totaam]

2016-05-28 09:35:27: antoine commented

---

Xpra starts in desktop mode when 'start' subcommand is given remotely
[[BR]]
Good catch, fixed in r12705.

Can I close this ticket?

[totaam]

2016-05-28 09:50:18: psycho_zs commented

---

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.

[totaam]

2016-05-28 12:01:52: antoine changed owner from psycho_zs to afarr

[totaam]

2016-05-28 12:01:52: antoine commented

---

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.

[totaam]

2016-06-10 21:28:25: afarr changed status from new to closed

[totaam]

2016-06-10 21:28:25: afarr set resolution to fixed

[totaam]

2016-06-10 21:28:25: afarr commented

---

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

Closing.

[totaam]

2016-07-07 10:07:09: antoine commented

---

Will follow up in #1247.

[totaam]

2016-07-12 17:52:23: antoine commented

---

Milestone renamed

[totaam]

2017-01-12 02:36:30: antoine commented

---

Added wiki page: Desktop.