lkml.org 
[lkml]   [2022]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] drm/atomic: do not branch based on the value of current->comm[0]
Am 2022-11-05 23:20, schrieb Jason A. Donenfeld:
> This reverts 26b1d3b527e7 ("drm/atomic: Take the atomic toys away from
> X")

I'm in favor of reverting this commit. I've tried to get allowing to
enable atomic in Xorg again in there in the past:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/533

I've no illusions of getting this through though, after all mostly the
same people control what's merged into Xorg, what drm stuff gets into
the kernel and who disabled it in the kernel in the first place. And
there doesn't seem much interest in dealing with anything Xorg either,
in the merge request I linked, someone even called Xorg "abandonware".
This is also why I didn't respond here until now.

I do see value in enabling this. When I looked at this 2 years ago,
there were situations where enabling atomic brought clear improvements,
and I would expect that it can still improve performance on some special
systems. I think the users should have the option to use it if they want
or need to.

There is also the concern that this may cause a regression, but I would
argue, that there never was a regression to be fixed here in the first
place. There may have been that one broken application in the past, but
it was just that, a broken application, not something broken by the
kernel. I do not think the kernel should modify it's behavior just to
work around bugs in a specific program, which have always existed, and
didn't come from a changer in behavior of the kernel APIs. If a program
was written wrongly, the program should be fixed, and in case of Xorg, I
think it is fixed already.

This probably won't mean much coming from me, but:
Acked-by: Daniel Abrecht <public@danielabrecht.ch>

\
 
 \ /
  Last update: 2022-11-16 10:07    [W:0.827 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site