Use smaller cursor sizes

[stefan11111]

Split from #734

Still incomplete, as on most hw this just uses the largest cursor available, and coloring the cursor buffer is really inefficient, but I have to pick somewhere to split the above pr.

Part-of: #549
Part-of: #675

[stefan11111]

@notbabaisyou Ping, as I couldn't add you as a reviewer through the github interface.

[metux]

@stefan11111 theoretically you should also be able to assign @X11Libre/wranglers as reviewers.
Semantically, @X11Libre/reviewers would be more correct, but I don't know why this isn't offered as reviewers yet.
@callmetango any idea whether we need some github config tweak for that ?

[metux]

Picked the first two commits, for the remaining like to hear some more other oppinions.
(for strange reasons github doesn't show that the first two already in master)

@notbabaisyou Ping, as I couldn't add you as a reviewer through the github interface.

@callmetango can you care of adding him to our org / groups ?

[stefan11111]

Picked the first two commits, for the remaining like to hear some more other oppinions. (for strange reasons github doesn't show that the first two already in master)

Rebased now.

[stefan11111]

Do we ever want to use a larger cursor that this?

This function determines the smallest cursor size that is at least as big as the smallest size supported by all crtc's.

As I understand it, after we pass this size to xf86_cursors_init, the cursor image will have this size, and the cursor glyph will be at most this size.

When we then set the hw cursor size, we always pick the smallest one, that is at least as big as the cursor glyph, and I also added checks to make sure that we never go over this size.

yes large cursors are great for presentations or being old as dirt with bad eyes

Originally posted by @HaplessIdiot in #734 (comment)

[callmetango]

@callmetango can you care of adding him (@notbabaisyou) to our org / groups ?

Yes, I just invited him.

[stefan11111]

Do we ever want to use a larger cursor that this?
This function determines the smallest cursor size that is at least as big as the smallest size supported by all crtc's.
As I understand it, after we pass this size to xf86_cursors_init, the cursor image will have this size, and the cursor glyph will be at most this size.
When we then set the hw cursor size, we always pick the smallest one, that is at least as big as the cursor glyph, and I also added checks to make sure that we never go over this size.

yes large cursors are great for presentations or being old as dirt with bad eyes

Originally posted by @HaplessIdiot in #734 (comment)

As this pr is written right now, the cursor buffer is at least 64x64, which is quite big already.
To see how big that is, change the paint cursor function from this pr to paint the entire cursor buffer black (memset to -1) and send the width and height to 64x64.

Also, in the bigger pr I also add an option for setting the cursor to be as big as desired, so this will be adjustable in xorg.conf.

Also, the cursor buffer size is just an upper bound for the cursor glyph. If the glyph is 9 x 16, like it is on my machine usually, the rendered cursor will look that same regardless of if the cursor buffer is 32x32, 64x64 or 256x256.

[notbabaisyou]

I don't like this approach since this just thrashes the kernel with probe attempts, there really isn't a good way to figure out an optimal cursor without the drivers actually telling us.

Aside from that, a bunch of nits but I won't stop you from doing this.

[notbabaisyou]

Is using a single size for everything really a good idea? This'll cause issues for anyone using a larger than the smallest functioning cursor.

[stefan11111]

It was already a single size for everything in the old code.

[notbabaisyou]

The old code used min_cursor_[width|height] for the minimum cursor size which it got through probing and max_cursor_[width|height] was the assumed maximum cursor size which was given through DRM_CAP_CURSOR_[WIDTH|HEIGHT]

[notbabaisyou]

Using the smallest cursor available will break hardware cursors the moment you go above the smallest size as explained above. My PR did exactly what was done before and that is use the largest cursor available for the buffer but tell the hardware to only use a part of it.

[stefan11111]

The way the hw cursor code is designed, the cursor glyph will never be bigger than the size we tell it to use as the max, so we should never go over this size when setting the actual hw cursor size with ioctl's.

[HaplessIdiot]

The work so far on the cursor is seriously cool thanks for working on this with such precision.

[metux]

once all conversations are finished up and getting some more acks, I'm going to merge this :)

great work, thanks.

[stefan11111]

@notbabaisyou @metux @callmetango
Split the second commit into #983

[stefan11111]

@notbabaisyou @b-aaz
I split the pitch commit into #983
Could you comment there about pitch-related changes instead of here.

[stefan11111]

@metux @callmetango @b-aaz @cepelinas9000 @notbabaisyou @algrid @X11Libre/wranglers
I rebased this and resolved conversations about code that was already merged.
I also rewrote some things.

ping and please review.

[HaplessIdiot]

This is a very important change if we arent using the full cursor buffer why waste latency running the whole buffer this is excellent!

[stefan11111]

Rebased and simplified following #1109

@metux @callmetango @b-aaz @cepelinas9000 @algrid @X11Libre/reviewers ping

[callmetango]

@stefan11111 Unfortunately, I can't comment on the technical aspects. But I am definitely in favor of a solution.

[metux]

Looks good to me, but maybe somebody with more actual HW can test it ?
@josephcrowell @cepelinas9000

[stefan11111]

ping @metux @callmetango @cepelinas9000 @josephcrowell @notbabaisyou

[stefan11111]

Looks good to me, but maybe somebody with more actual HW can test it ? @josephcrowell @cepelinas9000

Note that this pr only changes behavior on systems where SIZE_HINTS is implemented, which AFAIK is only intel cards with very new kernels.

[cepelinas9000]

ACK. With this patch on my laptop now cursor behaves correctly and fixes this problem when there visible parts of cursor during switching.

There how it looks on my laptop with added printfs

XLibre X Server 1.25.0
X Protocol Version 11, Revision 0
Current Operating System: Linux localhost.localdomain 6.15.0-tautvis #1 SMP PREEMPT_DYNAMIC Fri Oct 10 15:51:33 EEST 2025 x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-6.15.0-tautvis enc_root=/dev/sda3:/dev/nvme0n1p1 lvm luks selinux=1 enforcing=0 real_root=/dev/mapper/vg-root rootfstype=ext4 drm.rnodes=1 mitigations=off root=/dev/mapper/vg-root rootflags=discard,acl rootfstype=ext4 rand_id=Y17O7G2X
 
Current version of pixman: 0.43.4
	Before reporting problems, check https://github.com/X11Libre/xserver
	to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/tmp/lx1/var/log/Xorg.2.log", Time: Fri Oct 10 19:49:51 2025
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/tmp/lx1/share/X11/xorg.conf.d"
populating cursor sizes:
size wh 64x64
size wh 128x128
size wh 256x256
end of cursor sizes
populating cursor sizes:
size wh 64x64
size wh 128x128
size wh 256x256
end of cursor sizes
populating cursor sizes:
size wh 64x64
size wh 128x128
size wh 256x256
end of cursor sizes
^C(II) Server terminated successfully (0). Closing log file.