[Python-apps-team] Bug#681051: xpra: menus pop up off-screen

Antoine Martin antoine at nagafix.co.uk
Thu Jul 12 06:00:06 UTC 2012


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
>







More information about the Python-apps-team mailing list