Mouse cursor is tiny

[totaam]

Issue migrated from trac ticket # 189

component: server | priority: major | resolution: fixed

2012-09-30 22:48:40: alphapapa created the issue

---

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.

[totaam]

2012-10-01 07:34:01: antoine changed status from new to accepted

[totaam]

2012-10-01 07:34:01: antoine commented

---

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="

[totaam]

2012-10-03 05:58:17: alphapapa commented

---

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.

[totaam]

2012-10-03 07:26:58: antoine commented

---

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

[totaam]

2012-10-03 07:26:58: antoine

[totaam]

2012-10-08 11:31:28: antoine commented

---

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

[totaam]

2012-10-09 00:45:57: alphapapa commented

---

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

[totaam]

2012-10-10 07:13:27: antoine

[totaam]

2012-10-10 07:17:48: antoine commented

---

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

[totaam]

2012-11-03 09:28:03: antoine commented

---

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

[totaam]

2012-11-11 09:29:37: antoine changed status from accepted to closed

[totaam]

2012-11-11 09:29:37: antoine changed resolution from * to needinfo*

[totaam]

2012-11-11 09:29:37: antoine commented

---

not heard back

[totaam]

2013-03-19 16:06:56: ahuillet changed priority from minor to major

[totaam]

2013-03-19 16:06:56: ahuillet changed status from closed to reopened

[totaam]

2013-03-19 16:06:56: ahuillet changed component from core to server

[totaam]

2013-03-19 16:06:56: ahuillet changed resolution from needinfo to **

[totaam]

2013-03-19 16:06:56: ahuillet

[totaam]

2013-03-19 16:06:56: ahuillet commented

---

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

[totaam]

2013-03-20 04:18:10: antoine changed status from reopened to assigned

[totaam]

2013-03-20 04:18:10: antoine changed owner from antoine to ahuillet

[totaam]

2013-03-20 04:18:10: antoine commented

---

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

[totaam]

2013-03-20 15:08:33: ahuillet commented

---

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?

[totaam]

2013-03-20 15:25:15: antoine commented

---

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

[totaam]

2013-03-20 15:25:15: antoine

[totaam]

2013-03-20 15:25:15: antoine

[totaam]

2013-03-20 15:25:15: antoine

[totaam]

2013-03-20 15:25:15: totaam

[totaam]

2013-05-18 05:29:52: antoine changed status from assigned to new

[totaam]

2013-05-18 05:29:52: antoine commented

---

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:

• 24 on my workstation
• 66 on the Xvfb at its starting resolution (big)
• 21 once it has resized to the same resolution as my workstation (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)

[totaam]

2013-05-18 05:35:02: antoine uploaded file cursor-scaling.patch (5.7 KiB)

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

[totaam]

2013-05-21 08:38:33: ahuillet commented

---

Fix confirmed.

[totaam]

2013-05-27 05:28:52: totaam commented

---

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.

[totaam]

2013-05-27 07:24:03: ahuillet commented

---

What should I do with randr exactly?

[totaam]

2013-05-27 07:33:37: totaam commented

---

• Option 1: use randr to resize the vfb to a more reasonable size
• Option 2: connect your client

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

[totaam]

2013-05-27 08:38:47: ahuillet commented

---

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

Steps:

• start server
• xrandr --output default --mode 1280x1024
• attach client
• vmplayer

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

[totaam]

2013-07-08 16:55:41: antoine changed status from new to assigned

[totaam]

2013-07-08 16:55:41: antoine changed owner from ahuillet to antoine

[totaam]

2013-07-08 16:55:41: antoine commented

---

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

[totaam]

2013-10-09 06:56:15: totaam commented

---

OSX related cursor issue: #438

[totaam]

2014-03-20 07:51:40: totaam commented

---

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

[totaam]

2014-03-20 07:51:40: totaam

[totaam]

2014-05-17 12:29:04: antoine changed status from assigned to closed

[totaam]

2014-05-17 12:29:04: antoine changed resolution from * to fixed*

[totaam]

2014-05-17 12:29:04: antoine commented

---

(actually closing)