For some reason the mouse cursor is displayed at about 25% of normal size when I connect to an xpra session. It only happens in xpra-attached windows.
I've also noticed that fonts display at a smaller size--I think the xpra instance is using a lower DPI than my attached X server and screen, but I don't know if these are related.
Same questions as per #188, we need more details.
Have you tried using the
FYI: with recent versions, the dpi will be automatically adjusted to match your client's dpi once connected - this will only affect applications started after you connect the client though, others will use the value from "
I didn't realize you'd done so much work on xpra since Precise came out. I installed the version from your repo:
xpra: Installed: 0.6.3-1 Candidate: 0.6.3-1 Version table: *** 0.6.3-1 0 500 http://winswitch.org/ precise/main i386 Packages 100 /var/lib/dpkg/status
I tried setting the DPI with the switch to the one reported by the X NVIDIA driver, both on 'xpra start' and on 'xpra attach', but the cursor is still small and the fonts are still smaller than usual.
I think that's because Precise does not support Xdummy, I believe Quantal will (wheezy and sid do) so you will get a better software stack when you upgrade.
In the meantime, you can check the dpi used in an xterm through xpra by typing:
xrdb -query | grep dpi
If this matches your dpi on the client (run the same command without xpra), then there is no reason why applications should look different - as long as they are started once the dpi is set.
The information shown here will be incorrect (direct from the X11 server - but still informational):
xdpyinfo | grep -C 2 "screen #"
For more details on dpi, see #163
We may also do more for cursors in the future, see #192
$ xrdb -query | grep dpi $ xdpyinfo | grep -C 2 "screen #" number of screens: 1 screen #0: dimensions: 1280x800 pixels (290x181 millimeters) resolution: 112x112 dots per inch
I look forward to trying Xdummy in Quantal. In the meantime, this is only a minor problem, anyway. Thanks for your help.
Is the info posted above collected from within an xpra session? It looks like you have randr, which you should not have is using xpra on precise iirc. Also, the dpi looks reasonable.
I think that the best way forward is #192
Can you try trunk or the beta 0.8 packages available here and let me know if that fixes your problem?
not heard back
Reopening - tiny cursor with VMWare. No --dpi was used, this is the default configuration entirely.
Please try to see if
dpi helps, is this with
This is with Xvfb. Am I supposed to try --dpi on the client or server? Also, I assume I have to start my application *after* setting --dpi, correct?
From "xpra -h":
Advanced Options: These options apply to both client and server. Please refer to the man page for details. --dpi=DPI The 'dots per inch' value that client applications should try to honour (default: 96)
And for completeness, the man page:
--dpi=VALUE The 'dots per inch' value that client applications should try to honour. This numeric value should be in the range 10 to 500 to be useful. Many applications will only read this value when starting up, so connecting to an existing session started with a different DPI value may not have the desired effect.
So the default is 96 already and you can ignore my recommendation in comment:12.
Since #205: we now pass the cursors by name (when available), so the client then uses the matching cursor that the client application (VMWare) requested, but from the client's own theme. I think that maybe VMWare is reading the hardware screen dimensions and using a custom X11 cursor at that scale, which we then forward as raw pixels. (we don't know for sure since we can't read the source)
The proper solution is to tell Xdummy / Xvfb that the dpi is about 96 (and let it set whatever fake screen dimensions make it so). You can confirm that this is the case by setting the vfb screen dimension to something that makes the dpi close to the desired value (96), you can verify that the virtual hardware gives the right values with:
$ xdpyinfo | grep "dots per inch" resolution: 101x101 dots per inch
We could add a hack to scale those cursors, but it would be an ugly hack.
More dpi info in #163
I think I know what is going on and why it affects only certain applications.
Originally, the code was only sending the pixels for the cursor (very old code: r191) and so we needed to scale the cursor pixels because toolkits will scale their cursor sizes based on the dpi (or/and screen size?) and we didn't have randr support at the time. For example, when I run:
python -c "from gtk import gdk;print(gdk.display_get_default().get_default_cursor_size())"
(why 21 instead of 24.. beats me!)
Then in #205 we started forwarding the cursor name instead, so the client toolkit then uses the cursor at its local size and all is well. But we still have to fallback to the pixel code to deal with custom cursors with no name (which is what applications like vmware use) and those may come in at various sizes.
Now that we have randr support and the
dpi option, I believe the scaling should no longer be necessary, so I've removed it in r3423.
I am also attaching a patch which does something a little more "correct" by scaling the server cursor according to the ratio between the default size on the server and the default size on the client (using the example values above, this would be 24/21 ... which is not a great ratio to scale graphics by)
Does that work for you? (I will probably apply this to 0.9.x)
adds --cursor-scaling=pct options to choose between auto and custom scaling options
ahuillet: does using randr manually against the vfb or connecting a client before launching your app fix the cursor size?
In which case we could just use a smaller/reasonable resolution on server startup, which would fix your use case without adversely affecting anyone else.
What should I do with randr exactly?
Then, launch your app. Does this solve the small cursor problem or not?
No, this doesn't solve the small cursor problem.
Cursor is still tiny - that's with the r3517 applied.
I'm also getting the small cursor problem now with
VirtualBox (and I can't remember seeing it before..)
OSX related cursor issue: #438
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/189