xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#777 closed defect (invalid)

remote window size issue

Reported by: Jiang Owned by: Jiang
Priority: minor Milestone:
Component: core Version: 0.14.x
Keywords: Cc:

Description

An application window being forwarded from remote desktop to local window, such as a firefox or chrome window, does not detect the boundary of the desktop properly. For example, if I right-click to bring up a browser context menu, and the place I right click is close to the lower right corner (the application is maximized to occupy the entire desktop), the context menu still pops up to the right and below the pointer, thus become invisible and outside the desktop, rather than like native window, where a right click on on the lower right corner will result in menu popping up to the left and above the pointer.

This is even more of a problem for pop up window on the status bar, such as download progress on firefox or weather information on forecastfox menu. These menus are unusable unless the window is shrunk to be much smaller than desktop.

I use xpra version 0.14.13 and the only relevant option is --dpi=110. This is not a dealbreaker for an excellent application like xpra. But it is certainly a defect that makes it harder to use.

By the way, I used to be able to browser the mailing-list archive at
http://lists.devloop.org.uk/mailman/listinfo/shifter-users
But now it seems it is no longer available. I check the mailing list archive to see new upgrade. I am now pinning my application to 0.14.13, since 0.14.14 introduces a serious bug that makes xpra unusable for me. It'll be great if I could figure out when the next version comes out, what features it has and if it fix that bug

Change History (9)

comment:1 Changed 5 years ago by Antoine Martin

Owner: changed from Antoine Martin to Jiang

the mailing-list archive at ...


apache had crashed, it's back up, thanks!


As for the bug, if you don't use the bug report tool, please make sure to include all the usual bug details, as per wiki/ReportingBugs. ie: distro, etc


This is even more of a problem for pop up window on the status bar, such as download progress on firefox or weather information on forecastfox menu. These menus are unusable unless the window is shrunk to be much smaller than desktop.


Do you have fakexinerama installed? Xdummy?
What is your resolution? multiple monitors?
xrandr output? client output? server output?

etc...

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 5 years ago by Jiang

Both my server and client run Ubuntu 14.04, xpra 0.14.13 (the server is 64 bit and client 32 bit).
Server command:

xpra --dpi=110 start :100 --bind-tcp=0.0.0.0:10000

client command

xpra --packet-encoder=rencode --speaker-codec=wavpack --compressor=lz4 --dpi=110 attach tcp:workstation:10000

Client has standard set up. Just a single laptop window, no xinerama or xdummy. Just the laptop display (old 15.4 inch macbook pro, 1440x900. Yes, I'm running ubuntu on this mac, not virtual machine. but on bare metal.)
xrandr

Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
LVDS connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 331mm x 207mm

Servers output mention nothing about resolution, only keymap after handsakes.

Let me know what more information you need. Thank you for making this very useful piece of software! It is by far the best application for thin client. I use it everyday to offload most computing from my ancient macbook pro to my workstation connected via gigabit.(including web browsing, which nowadays involve so much html5 and javascript that it noticeably faster on a workstation!). It is on of few pieces of software that improves my computing life drastically!

By the way, is bug #766, about the dialog window not usable, fixed in 0.14.15? That's what forced me to stay in 0.14.13.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 5 years ago by Antoine Martin

Resolution: invalid
Status: newclosed

Sorry, but this sounds like a bug that Xdummy fixes - so I am closing this as invalid, if you can reproduce it with Xdummy instead of Xvfb then we can re-open it. Until then, I suggest that you switch to a distro that does not make it so difficult to run Xdummy.

BTW:

Client has standard set up. Just a single laptop window, no xinerama or xdummy.


Xdummy and FakeXinerama are server side things, not client.


By the way, is bug #766, about the dialog window not usable, fixed in 0.14.15?


As per the ticket, there are beta 0.14.16 packages available which should fix this - the sooner I get feedback on this, the sooner I can release the fix.

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 5 years ago by Jiang

I'm sorry that I did not read the xdummy page. However, I would like to try it out to see if it resolves the issue. Unfortunately, switching distribution is too cumbersome at this stage for me. However, I do have full administrative right (I can log in as root) to ubuntu. I chown all /dev/tty* to my own. But it still complains "no screen found". Is it not possible to use xdummy at all? Or is there some more additional permission that I need to change?

If there is a way for someone with root permission on the server to use xdummy on ubuntu, I'd really appreciate it! Thanks!

comment:5 Changed 5 years ago by Antoine Martin

I don't know if it is possible to run Xdummy on Ubuntu, best to ask them what changes they've made and how to work around them.

If you do find a positive answer to that, please contribute it back here so we can add it to the wiki.

comment:6 Changed 5 years ago by Jiang

After about three hours of trial and error, I did figure out how to get xpra to use xdummy, but the drawback is so severe that I won't use it in my daily use with Ubuntu:
I boot up the machine, then ssh into it as root. Do the following two commands:
chmod 777 /dev/tty*
chmod 777 /dev/fb0
then, again over ssh, I can start the xpra server using this command
xpra --xvfb='Xorg -dpi 110 -noreset -nolisten tcp -logfile ${HOME}/.xpra/Xvfb-10.log' --dpi=110 start :100 --bind-tcp=0.0.0.0:10000
And it will work. And, as you said, the bug I am reporting in #777 disappears once I use xdummny this way.

HOWEVER, after doing this, *any x session running on the server*, as shown in the screen attached to the server, will go blank and becomes unusable. As I also use my server as a standlone machine/entertainment center, this solution is untenable for me. But someone else who use server only to server xpra session will not have such a problem.

Some observations:

  1. It is very strange, but /dev/fb0 belongs to the group video and has permission 660. But when I add myself to group video, rather than changing the /dev/fb0 to 777, the solution above fails.
  1. If I log in to the server locally via GUI, and then change the permissions as above on the screen directly attached to the server, then try to start xpra server over ssh as above, it fails to work, either.

I now admit ubuntu really screwed this up. Does Linux Mint work? The reason I've stuck with Ubuntu, despite serious misgiving about its direction, is that so many third party software give packages to it directly. Changing to redhat is too big a shift at this stage (though I started linux with redhat 7.3 back in 2001).

comment:7 Changed 5 years ago by Jiang

OK, I think I figured out how to make ubuntu use xdummy, without messing up any other existing Xorg session running on the server. I'm new to the wiki, so perhaps you could add it to the right session such that later users would be able to finally use xdummy on ubuntu!
What I did is the following:
1.aptitude install xserver-xorg-video-dummy
(Of course, but I forgot in the first try!)

  1. Add the user who is going to be logging into the server to the proper group. I think this is the crucial step---doing this rather than changing the permission of /dev/tty8 and /dev/fb0
    adduser USERNAME video
    adduser USERNAME tty
    adduser USERNAME dialout
    
  2. fully reboot. I skipped this step in the last try, which is why adding user didn't work. One need to log out as user and log back in to make it fully effective.
  3. This may or may not be important: but I always start the xpra server over an ssh session *before* logging into any GUI session on the server. Otherwise it may complain about unable to get drm and fail.

I start xpra on the server using this command:

xpra --xvfb='Xorg -dpi 110 -noreset -nolisten tcp +extension GLX +extension RANDR \
    +extension RENDER -logfile ${HOME}/.xpra/Xvfb-10.log  -config ${HOME}/.xpra/xorg.conf' \
   --dpi=110 start :100 --bind-tcp=0.0.0.0:10000

The xorg.conf file is downloaded from xpra.org

I hope this helps others who is trying to run xpra with xdummy on ubuntu! I filed another minor bug of OpenGL. But that's not as important as this one.

After using xdummy, all the bounding and pop up window works properly. Thank you for making this nice piece of software!

Last edited 5 years ago by Antoine Martin (previous) (diff)

comment:8 Changed 5 years ago by Jiang

I have added these tips to the wikipage of Xdummy, as well as some hints about enabling full openGL accelerating, which I struggled for a while.

comment:9 Changed 5 years ago by Antoine Martin

Thanks, I've edited the comment above and the wiki/Xdummy wiki page a bit: added code tags, missing xorg.conf from the Xorg command line, etc

On the subject of the xorg.conf file, you shouldn't need to download it from anywhere, it is still installed in /etc/xpra - even on Ubuntu.

You also don't need to specify these options every time you use them, that's what the global config file is for! (or even your per-user config override file ~/.xpra/xpra.conf).

Note: See TracTickets for help on using tickets.