xpra icon
Bug tracker and wiki

Opened 13 months ago

Closed 13 months ago

Last modified 6 months ago

#1206 closed enhancement (fixed)

Native full destop support?

Reported by: psycho_zs Owned by: alas
Priority: minor Milestone: 1.0
Component: server Version: trunk
Keywords: full-desktop session x11 Cc:

Description

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.

Change History (21)

comment:1 Changed 13 months ago by Antoine Martin

Component: coreserver
Keywords: x11 added
Owner: changed from Antoine Martin to psycho_zs

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.

comment:2 Changed 13 months ago by 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.

Last edited 13 months ago by psycho_zs (previous) (diff)

comment:3 Changed 13 months ago by Antoine Martin

Owner: changed from psycho_zs to Antoine Martin
Status: newassigned

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.

comment:4 Changed 13 months ago by psycho_zs

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

comment:5 Changed 13 months ago by 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).

comment:6 Changed 13 months ago by 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.

comment:7 Changed 13 months ago by Antoine Martin

Milestone: future0.18

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)

comment:8 Changed 13 months ago by Antoine Martin

Owner: changed from Antoine Martin to psycho_zs
Status: assignednew

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.

comment:9 Changed 13 months ago by 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

comment:10 Changed 13 months ago by 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.

comment:11 Changed 13 months ago by 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?

comment:12 Changed 13 months ago by 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.

comment:13 Changed 13 months ago by 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.

comment:14 Changed 13 months ago by 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.

Last edited 13 months ago by psycho_zs (previous) (diff)

comment:15 Changed 13 months ago by Antoine Martin

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


Good catch, fixed in r12705.

Can I close this ticket?

comment:16 Changed 13 months ago by 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.

comment:17 Changed 13 months ago by Antoine Martin

Owner: changed from psycho_zs to alas

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.

comment:18 Changed 13 months ago by alas

Resolution: fixed
Status: newclosed

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

Closing.

comment:19 Changed 12 months ago by Antoine Martin

Will follow up in #1247.

comment:20 Changed 12 months ago by Antoine Martin

Milestone: 0.181.0

Milestone renamed

comment:21 Changed 6 months ago by Antoine Martin

Added wiki page: wiki/Desktop.

Note: See TracTickets for help on using tickets.