Xpra: Ticket #189: Mouse cursor is tiny

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.

Mon, 01 Oct 2012 06:34:01 GMT - Antoine Martin: status changed

Same questions as per #188, we need more details.

Have you tried using the --dpi=NN switch? 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 "--dpi="

Wed, 03 Oct 2012 04:58:16 GMT - alphapapa:

I didn't realize you'd done so much work on xpra since Precise came out. I installed the version from your repo:

  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.

Wed, 03 Oct 2012 06:26:58 GMT - Antoine Martin:

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

Mon, 08 Oct 2012 10:31:27 GMT - Antoine Martin:

We may also do more for cursors in the future, see #192

Mon, 08 Oct 2012 23:45:57 GMT - alphapapa:

$ 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.

Wed, 10 Oct 2012 06:13:26 GMT - Antoine Martin: version, milestone changed

Wed, 10 Oct 2012 06:17:47 GMT - Antoine Martin:

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

Sat, 03 Nov 2012 09:28:02 GMT - Antoine Martin:

Can you try trunk or the beta 0.8 packages available here and let me know if that fixes your problem?

Sun, 11 Nov 2012 09:29:37 GMT - Antoine Martin: status changed; resolution set

not heard back

Tue, 19 Mar 2013 16:06:56 GMT - ahuillet: priority, status, component, milestone changed; resolution deleted

Reopening - tiny cursor with VMWare. No --dpi was used, this is the default configuration entirely.

Wed, 20 Mar 2013 04:18:10 GMT - Antoine Martin: owner, status changed

Please try to see if dpi helps, is this with Xvfb or Xdummy ?

Wed, 20 Mar 2013 15:08:32 GMT - ahuillet:

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?

Wed, 20 Mar 2013 15:25:15 GMT - Antoine Martin:

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:

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

Sat, 18 May 2013 04:29:51 GMT - Antoine Martin: status changed

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())"

I see:

(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)

Sat, 18 May 2013 04:35:02 GMT - Antoine Martin: attachment set

adds --cursor-scaling=pct options to choose between auto and custom scaling options

Tue, 21 May 2013 07:38:33 GMT - ahuillet:

Fix confirmed.

Mon, 27 May 2013 04:28:52 GMT - Antoine Martin:

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.

Mon, 27 May 2013 06:24:02 GMT - ahuillet:

What should I do with randr exactly?

Mon, 27 May 2013 06:33:37 GMT - Antoine Martin:

Then, launch your app. Does this solve the small cursor problem or not?

Mon, 27 May 2013 07:38:46 GMT - ahuillet:

No, this doesn't solve the small cursor problem.


Cursor is still tiny - that's with the r3517 applied.

Mon, 08 Jul 2013 15:55:41 GMT - Antoine Martin: owner, status changed

I'm also getting the small cursor problem now with VirtualBox (and I can't remember seeing it before..)

Wed, 09 Oct 2013 05:56:15 GMT - Antoine Martin:

OSX related cursor issue: #438

Thu, 20 Mar 2014 07:51:40 GMT - Antoine Martin:

Closing, will follow up in #513 which has more up to date information. See also #163.

Sat, 17 May 2014 11:29:03 GMT - Antoine Martin: status changed; resolution set

(actually closing)

Sat, 23 Jan 2021 04:47:57 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/189