xsrc/58318: Slow/incremental updating of Firefox menu entries

[Rhialto <rhialto%falu.nl@localhost>]

>Number:         58318
>Category:       xsrc
>Synopsis:       Slow/incremental updating of Firefox menu entries
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    xsrc-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 06 20:00:00 +0000 2024
>Originator:     Rhialto
>Release:        NetBSD 10.0
>Organization:
>Environment:
	<The following information is extracted from your kernel. Please>
	<append output of "ldd", "ident" where relevant (multiple lines).>
System: NetBSD murthe.falu.nl 10.0 NetBSD 10.0 (GENERIC) #0: Sat May 18 22:55:37 CEST 2024 rhialto%murthe.falu.nl@localhost:/mnt/scratch/scratch/tmp/xcrash/usr/src/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
        This is using Intel integrated graphics, and the modesetting driver
        for X.
	Start Firefox (I used version 123.0.1 from pkgsrc stable branch).
	Click on one of the menus in the menu bar. A menu drops open.
	Move the mouse down along the menu items.
	The item under the mouse is supposed to be highlighted by
	inverting the colours.

	However the pixels are not updated immediately. It happens
	incrementally over the course of sometimes several seconds. It
	is like the data is written into some kind of cache which isn't
	copied to its final destination immediately, but only as parts
	of it get pushed out because of evictions. 

	I saw the same effect on different machines with different
	generations of Intel graphics (several years in between).
 
	Running xcompmgr is partially a workaround for this.
	But it is clearly not a full fix:
	xpdf4 doesn't work with it (probably a bug in xpdf4, but still).
	Other cases of caches not being pushed do still happen.
	I have a case where really strange things are rendered while just
	resizing an xterm with text in it. (video available on request)

	Originally I thought that fixing a similar effect with updating
	mouse cursors (PR xsrc/58307) would automatically fix this
	problem, but apparently this is not the case.

>How-To-Repeat:
	as above.
>Fix:
	Not yet known.

	For diagnostics, here is a list of unique ioctls that the X
	server issues while logging in from xdm and then going through
	the above scenario.

   817    510 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_CURSOR,)
   817    817 X        CALL  ioctl(0x15,TIOCGETA,)
   817    817 X        CALL  ioctl(0x15,WSMOUSEIO_SETVERSION,)
   817    817 X        CALL  ioctl(0xe,KDGETLED,)
   817    817 X        CALL  ioctl(0xe,KDSETMODE,)
   817    817 X        CALL  ioctl(0xe,KDSKBMODE,)
   817    817 X        CALL  ioctl(0xe,TIOCFLUSH,)
   817    817 X        CALL  ioctl(0xe,TIOCSETA,)
   817    817 X        CALL  ioctl(0xe,VT_ACTIVATE,)
   817    817 X        CALL  ioctl(0xe,VT_RELDISP,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_AUTH_MAGIC,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_CRTC_GET_SEQUENCE,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_DROP_MASTER,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_GEM_CLOSE,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_GEM_FLINK,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_CREATEPROPBLOB,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_CURSOR,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_CURSOR2,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_DESTROYPROPBLOB,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_DIRTYFB,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_GETCONNECTOR,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_GETPROPBLOB,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_GETPROPERTY,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_GETRESOURCES,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_LIST_LESSEES,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_OBJ_SETPROPERTY,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_SETCRTC,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_MODE_SETPROPERTY,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_RADEON_CP_RESUME,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_RADEON_GEM_OP,)
   817    817 X        CALL  ioctl(0xf,DRM_IOCTL_SET_MASTER,)
   817    817 X        CALL  ioctl(0xf,_IOW('d',0x5d,0x20),)
   817    817 X        CALL  ioctl(0xf,_IOW('d',0x5f,0xc),)
   817    817 X        CALL  ioctl(0xf,_IOW('d',0x69,0x40),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x57,0x8),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x5b,0x10),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x5e,0x28),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x61,0x10),)
   817    817 X        CALL  ioctl(0xf,_IOWR('d',0x66,0xc),)

	I suppose that the names with RADEON are about ioctl numbers
	that have multiple names.

>Unformatted:
 	<Please check that the above is correct for the bug being reported,>
 	<and append source date of snapshot, if applicable (one line).>