[winswitch] xpra session to other account on localhost

[Marc Haber]

Hi Antoine,

thanks for helping.

On Tue, Dec 11, 2018 at 10:36:00AM -0800, Antoine Martin via shifter-users wrote:
> > Both accounts are member of the xpra group. I start the server with
> > ssh marc at localhost xpra start --mmap=/var/tmp/mh-mmap -d mmap
> > --mmap-group --socket-dir=/var/tmp
> Why change the socket-dir?

Leftover from my experiments to get mmap to work. The mmap file cannot
be in /run/xpra though.

> The defaults should include /run/xpra which should be writable by
> members of the xpra group.
> > --speaker=off --encoding=png/P
> Don't change the encoding unless you really know what you are doing.
> Especially not for png/P which is very rarely a good option.

Removed. That made things a bit better, but still miles apart from
native X, especially when scrolling. Is Firefox an especially badly
behaving application?

> > 2018-12-11 18:36:48,411 found client mmap area: None, 0 bytes - min mmap size=67108864
> > and then the mmap file disappears again.
> I think you need to make the 'xpra' group the primary group of the user.

I am tempted to say that this is an unreasonable suggestion.
Traditionally, the primary groups of users have always been the local
admin's domain; they're frequently used to control access of other users
to one user's home directory. Having arbitrary software demand that the
user's primary group is set to a software-specific group is not only an
intrusion into that domain it also doesn't scale beyond one single piece
of software making that demand.

Do you need a bug report for this?

> > What am I doing wrong?
> Not much, cross-user shared memory requires some tweaking.
> (the feature has not really been updated much for the last 6 years..)
> 
> To make it easier, we should enhance the mmap-group option so users can
> specify the group they want to use directly:
> https://xpra.org/trac/ticket/2075
> ie: --mmap-group=xpra

Thanks, that would greatly ease things.

> > I'd rather refrain from having to patch my xorg,
> You're not patching xorg, just the dummy driver.

If you mean /usr/lib/xorg/modules/drivers/dummy_drv.so, that one is, on
Debian, from the package xserver-xorg-video-dummy. I could patch that,
but I'd prefer to look for a cleaner solution first.

> > I can live with giving
> > hard-coded dpi values (which I usually do, but didn't do when creating
> > these mails to make things simpler).
> OK.
> Note that there is at least one more non-DPI bug you may encounter with
> the unpatched driver.

For example? Will the patch be part of a future xorg release?

> >> (..)> In the panel applet, I have set Picture => Fixed speed to "Lowest
> >>> latency". The session information claims that I have 60 ms frame total
> >>> latency, but it feels like a multiple of that. Any networked RDP session
> >>> to a Windows machine feels much faster.
> >> Even remote connections should be as fast as RDP, let alone local ones.
> > 
> > They're not.
> > 
> >> Feel free to create a ticket to fix the non-mmap case.
> > 
> > Like "xrdp very slow" and giving the same information like in the thread
> > starting message?
> That's a good start, more guidelines can be found here:
> https://xpra.org/trac/wiki/ReportingBugs
> Based on recent similar reports, you may want to attach the server's
> debug log with "-d bandwidth,stats" added to the command line.

Will do in due time.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421