On 11/07/12 00:21, Michal Suchanek wrote:
Excerpts from Antoine Martin's message of Tue Jul 10 17:11:02 +0200 2012:
On 10/07/12 21:18, Michal Suchanek wrote:
Excerpts from Antoine Martin's message of Tue Jul 10 13:46:34 +0200 2012:
On 10/07/12 18:37, Michal Suchanek wrote:
Excerpts from Antoine Martin's message of Tue Jul 10 11:29:03 +0200 2012:
Please see here:
https://www.xpra.org/Xdummy.html
This is the only workable fix for this problem.
These are packaged in Debian.
Why is the bug happening still?
Because you are using the default Xvfb and not Xdummy.
See the bottom of the page on how to setup xpra to use Xdummy using the
"--xvfb=" switch.
Then the part of the man page saying
xpra start
This command starts a new xpra server, including any necessary
setup.
is misleading at best if not outright wrong.
I don't understand what you are saying. It does what it says, it is just
that for an optimal setup you should use Xdummy instead of Xvfb.
The man page is not the place to start writing a novel about the best
way to setup your x11 server (Xdummy vs Xvfb, dbus, various agents and
whatnot)
Indeed, it is not.
However, the SEE ALSO section is meant to provide pointers to more
exhaustive documentation.
Only the BUGS section mentions Xdummy but no information on how it is
used.
I've updated it as it was out of date, and added a link to the Xdummy page:
https://www.xpra.org/trac/changeset/1082
I guess README.Debian would be suitable place for articles at least.
A novel would be somewhat excessive in this case.
I don't think there's anything specific to Debian here.
This is mostly a dependency and packaging issue though: at present xpra
depends on Xvfb. Making Xdummy the default is a long term goal, but
until most distributions start packaging recent versions of Xorg (1.12
or later) and of the dummy driver (0.3.5), Xvfb will remain the default.
Debian is one of such distribution but still defaults to Xvfb.
There is a ticket for providing global xpra defaults in a config file:
https://www.xpra.org/trac/ticket/123
Once that is implemented, it should be pretty easy to provide a
different config file for each distribution, one which would use Xdummy
if available (and include the xorg.conf for it too)
Feel free to provide this better wording you speak of.
Looking at Debian Xsession man page, the wiki, and the Xvfb defaults
from the xpra man page you could possibly start a somewhat workable X
session with
xpra --xvfb="Xorg -nolisten tcp -noreset +extension GLX +extension RANDR +extension RENDER
-logfile ./10.log -config ./xorg.conf" --start-child="/etc/X11/Xsession true" start
:10
Note the -noreset option which is omitted on the wiki and without which
the session setup will not work.
I've added "-noreset" and a note on that:
https://www.xpra.org/trac/changeset/1081
(although it's not strictly required, it's much better to have it, thanks)
Note also that the true command exits immediately so any dbus,
ssh-agent, and similar daemons started by the session will exit
immediately as well.
You could run a non-ending process instead but then the session daemons
would stay even after the X server exits.
A client that connects to the X server and waits for it to terminate
would be ideal but I know of none that does just this.
Odd, because it would be trivial to write.
Perhaps some sample script in documentation, or perhaps even a
xorg.conf.dummy and a script in /usr/bin using it could be installed
with xpra so that everyone does not have to figure out how the hell is
that thing supposed to work.
A sample script using xorg.conf.dummy could look like this:
xpra --xvfb="Xorg -nolisten tcp -config xorg.conf.dummy -noreset +extension GLX +extension
RANDR +extension RENDER -logfile ~/.xpra/xserver-$DISPLAY.log"
--start-child="/etc/X11/Xsession true" start :$DISPLAY
It is sad that you can't know what display xpra picks when starting it
but without actually patching xpra you can't do more than that.
I think the config file option above is the easiest way to improve
things quickly?
Cheers
Antoine
Thanks
Michal
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
