xpra icon
Bug tracker and wiki

Opened 7 years ago

Closed 5 years ago

#189 closed defect (fixed)

Mouse cursor is tiny

Reported by: alphapapa Owned by: Antoine Martin
Priority: major Milestone: 0.9
Component: server Version: trunk
Keywords: Cc:

Description

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.

Attachments (1)

cursor-scaling.patch (5.7 KB) - added by Antoine Martin 6 years ago.
adds --cursor-scaling=pct options to choose between auto and custom scaling options

Download all attachments as: .zip

Change History (24)

comment:1 Changed 7 years ago by Antoine Martin

Status: newaccepted

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

comment:2 Changed 7 years ago by alphapapa

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.

comment:3 Changed 7 years ago by 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

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

comment:4 Changed 7 years ago by Antoine Martin

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

comment:5 Changed 7 years ago by 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.

comment:6 Changed 7 years ago by Antoine Martin

Milestone: 0.70.8
Version: 0.0.7.36trunk

comment:7 Changed 7 years ago by 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

comment:8 Changed 7 years ago by Antoine Martin

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

comment:9 Changed 7 years ago by Antoine Martin

Resolution: needinfo
Status: acceptedclosed

not heard back

comment:10 Changed 6 years ago by ahuillet

Component: coreserver
Milestone: 0.80.9
Priority: minormajor
Resolution: needinfo
Status: closedreopened

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

comment:11 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to ahuillet
Status: reopenedassigned

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

comment:12 Changed 6 years ago by 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?

comment:13 Changed 6 years ago by 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:

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

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

comment:14 Changed 6 years ago by Antoine Martin

Status: assignednew

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)

Changed 6 years ago by Antoine Martin

Attachment: cursor-scaling.patch added

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

comment:15 Changed 6 years ago by ahuillet

Fix confirmed.

comment:16 Changed 6 years ago by 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.

comment:17 Changed 6 years ago by ahuillet

What should I do with randr exactly?

comment:18 Changed 6 years ago by Antoine Martin

  • 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?

comment:19 Changed 6 years ago by ahuillet

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 r3517 applied.

comment:20 Changed 6 years ago by Antoine Martin

Owner: changed from ahuillet to Antoine Martin
Status: newassigned

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

comment:21 Changed 6 years ago by Antoine Martin

OSX related cursor issue: #438

comment:22 Changed 5 years ago by Antoine Martin

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

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

comment:23 Changed 5 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

(actually closing)

Note: See TracTickets for help on using tickets.