On Tue, Jul 15, 2025 at 09:41:12AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 14.07.25 um 14:39 schrieb Simona Vetter:
> > On Fri, Jul 11, 2025 at 11:35:15AM +0200, Thomas Zimmermann wrote:
> > > Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
> > > in the affected places.
Hi
Am 14.07.25 um 14:39 schrieb Simona Vetter:
On Fri, Jul 11, 2025 at 11:35:15AM +0200, Thomas Zimmermann wrote:
Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
in the affected places. Also revert any fixes on top. Separates references
to imported and exported DMA bufs
On Fri, Jul 11, 2025 at 11:35:15AM +0200, Thomas Zimmermann wrote:
> Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
> in the affected places. Also revert any fixes on top. Separates references
> to imported and exported DMA bufs within a GEM object; as before.
>
> Using th
On Fri, Jul 11, 2025 at 11:37:30AM -0700, Linus Torvalds wrote:
> On Fri, 11 Jul 2025 at 10:35, Linus Torvalds
> wrote:
> >
> > I'm hoping the login time timeout / hang ends up being due to a known
> > netlink regression, and it just happened to look like a drm issue
> > because it exposes itself
On Fri, 11 Jul 2025 at 10:35, Linus Torvalds
wrote:
>
> I'm hoping the login time timeout / hang ends up being due to a known
> netlink regression, and it just happened to look like a drm issue
> because it exposes itself as a hang at the first graphical login
>
> A netlink regression *might* fit
On Fri, 11 Jul 2025 at 08:48, Linus Torvalds
wrote:
>
> Background for others: current -git ends up having odd hangs when
> Xwayland starts for me (not at boot, but when I log in). It seems to
> be very timing-dependent, so presumably I'm just unlucky with my
> hardware.
Update for this thread as
Hi
Am 11.07.25 um 17:48 schrieb Linus Torvalds:
On Fri, 11 Jul 2025 at 02:40, Thomas Zimmermann wrote:
Reverting the whole thing is the only sensible action here.
I'm assuming this is against some current drm tree, not mine, because
it doesn't apply here.
Yes, it's against drm-misc-fixes, w
On Fri, 11 Jul 2025 at 02:40, Thomas Zimmermann wrote:
>
> Reverting the whole thing is the only sensible action here.
I'm assuming this is against some current drm tree, not mine, because
it doesn't apply here.
I'll try the smaller set of reverts that Simona suggested for my
testing, and will g
On Fri, Jul 11, 2025 at 12:32:02PM +0200, Christian König wrote:
> On 11.07.25 11:35, Thomas Zimmermann wrote:
> > Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
> > in the affected places. Also revert any fixes on top. Separates references
> > to imported and exported DMA
On 11.07.25 11:35, Thomas Zimmermann wrote:
> Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
> in the affected places. Also revert any fixes on top. Separates references
> to imported and exported DMA bufs within a GEM object; as before.
>
> Using the dma_buf as the one au
Revert the use of drm_gem_object.dma_buf back to .import_attach->dmabuf
in the affected places. Also revert any fixes on top. Separates references
to imported and exported DMA bufs within a GEM object; as before.
Using the dma_buf as the one authoritative field for the DMA buf turns
out to be frag
11 matches
Mail list logo
