Created attachment 126380 [details] Video of huge cursor A long time ago (at least a couple years now) either an XQuartz or an OS X update started giving me huge sized cursors in pretty much every X11 application I use (I'm displaying all my X11 windows on the Mac via SSH). I could have sworn I filed a bug report on it and have been waiting for it to get fixed for ages (it's my #1 usability issue), but having looked just now I don't see any such report, other than perhaps the closed report: https://xquartz.macosforge.org/trac/ticket/2112 It's really annoying - I work in applications editing text where the I-beam cursor is about 4 lines of text high and selecting text is problematic, the cursor being used while editing graphics covers enough of the nearby stuff to make the whole process frustrating. I'm not clear I agree with the reasons the macosforge ticket 2112 was closed (assuming it's the same issue as I'm reporting). I have attached a video of a couple small windows showing the problem. Whenever you see the smallest arrow cursor, that's the cursor size normally displaying on the Mac.
I just took another look at the video I posted and realized that when doing a QuickTime screen recording that the big cursors are curiously captured smaller than they appear in real life. I took a picture of the (paused) screen recording beside the actual window I was recording to show the difference. The bigger cursor is the uglier, more obstructing one that I see in real life, the smaller one is an artifact of some QuickTime screen recording anomaly i.e. the problem I'm describing is *far* worse than the video indicates. See photographs attached.
Created attachment 126416 [details] Actual cursors are much bigger than the screen recording
Created attachment 126417 [details] Actual cursors are much bigger than the screen recording
Yeah, that does look quite annoying, but we don't really do anything with the cursors directly. We simply allow the clients to configure the cursors and pass that data through. Since this is the only report of such issue, I urge you to try creating a new user account on your system in order to try reproducing the issue. I suspect a user configuration option (eg: toolkit preferences file) might be causing this.
Created attachment 127432 [details] My monitor setup This is my current monitor setup. It's a mid-2102 MacBook Pro with 2 external monitors connected via the 2 ThunderBolt ports.
Created attachment 127433 [details] Cursor size in my regular account is about 2.5 lines high.
Created attachment 127434 [details] Cursor size in a new, virgin account
Thanks for your response Jeremy. I (finally) did as you suggested and tried to reproduce this in a newly created virgin account. Annoyingly, the problem is still there, but only to a slightly lesser degree. I attached some pictures to highlight this. In my regular account you can see that the cursor size is about 3.5 lines high, and in the virgin account it's about 2.5 lines high (both are still awful to deal with). Like I mentioned in my initial post, years ago this wasn't the case and when it first appeared I filed a bug report (but apparently it's nowhere to be found) and I've been waiting for a fix ever since. I realize nobody else has reported this so that doesn't bode well for anything getting done. And of course you not having any free time doesn't help either!
I recently tried out NX, instead of SSH, to view my Cadence schematics on my MacBook Pro (the Cadence software is running on a remote linux box). I noticed the huge cursor sizes weren't happening at all - everything was great. Given the same version of XQuartz was in effect during the SSH/NX comparison I'm now thinking maybe this is more of an SSH problem than an XQuartz problem. I'm just too illiterate in all of this stuff to make any more of a suggestion than that - I just hope it helps in finding a fix for this.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/768.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.