Date: Sat, 02 Mar 2024 22:48:11 +0000 From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: [Bug 277437] x11-drivers/xf86-video-intel GT2 Iris graphics on an Alderlake apu impossible not-to-fail. Message-ID: <bug-277437-7141-R6ckMvKqYq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-277437-7141@https.bugs.freebsd.org/bugzilla/> References: <bug-277437-7141@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277437 dgilbert@eicat.ca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dgilbert@eicat.ca --- Comment #1 from dgilbert@eicat.ca --- Now... I made this stupid patch: [1:10:310]root@strike:/usr/ports/x11-drivers/xf86-video-intel> diff work/xf86-video-intel-b74b67f0f321875492968f7097b9d6e82a66d7df/src/uxa/inte= l_uxa.c* 663,664c663 < // if (bo->size < size || bo->size > intel->max_bo_size) { < if (bo->size < size) { --- > if (bo->size < size || bo->size > intel->max_bo_size) { Basically only slightly smarter than the Commodore 64 debug loop (syntax er= ror in 50 -> 50 <return> -> run -> etc). I tried figuring out where max_bo_size comes from. But the layers be thick here. But this does make it work? Does it make it more unsafe? Dunno. Probably= not the real fix. But it does show that either this max_bo_size is wrong, or .= .. well... need someone who knows up from down here. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-277437-7141-R6ckMvKqYq>