linux-kernel - Re: [PATCH 1/2] drm: introduce page_flip

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <15d1d986-e9cf-48fb-be4e-b2c33974dffc@mailbox.org>
Date: Wed, 28 Jan 2026 15:25:49 +0100
From: Michel Dänzer <michel.daenzer@...lbox.org>
To: Christian König <christian.koenig@....com>,
 Timur Kristóf <timur.kristof@...il.com>,
 Hamza Mahfooz <someguy@...ective-light.com>, dri-devel@...ts.freedesktop.org
Cc: Alex Deucher <alexander.deucher@....com>, David Airlie
 <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
 Harry Wentland <harry.wentland@....com>, Leo Li <sunpeng.li@....com>,
 Rodrigo Siqueira <siqueira@...lia.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 Sunil Khatri <sunil.khatri@....com>, Ce Sun <cesun102@....com>,
 Lijo Lazar <lijo.lazar@....com>, Kenneth Feng <kenneth.feng@....com>,
 Ivan Lipski <ivan.lipski@....com>, Alex Hung <alex.hung@....com>,
 Tom Chung <chiahsuan.chung@....com>, Melissa Wen <mwen@...lia.com>,
 Fangzhi Zuo <Jerry.Zuo@....com>, amd-gfx@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, Mario Limonciello <mario.limonciello@....com>
Subject: Re: [PATCH 1/2] drm: introduce page_flip_timeout()

On 1/28/26 12:25, Christian König wrote:
> On 1/28/26 10:19, Timur Kristóf wrote:
>> On 2026. január 26., hétfő 14:00:59 közép-európai téli idő Christian König 
>> wrote:
>>> On 1/26/26 11:27, Michel Dänzer wrote:
>>>> On 1/26/26 11:14, Christian König wrote:
>>>>>
>>>>> But looking at the slide Harry actually pointed out what immediately came
>>>>> to my mind as well, e.g. that the Compositor needs to issue a full
>>>>> modeset to re-program the CRTC.> 
>>>> In principle, the kernel driver has all the information it needs to
>>>> reprogram the HW by itself. Not sure why the compositor would need to be
>>>> actively involved.
>>>
>>> [...]
>>>
>>> Then second even if the kernel can do it I'm not sure if it should do it.
>>>
>>> [...]
>>
>> I agree with Michel here. It's a kernel bug, it should be solved by the 
>> kernel. I don't like the tendency of pushing userspace to handle kernel bugs, 
>> especially if this is just needed for one vendor's buggy driver. (No offence.)
> 
> Well I strongly disagree. The kernel is not here to serve userspace, [...]

Can't say I agree with that statement.

Anyway, user space certainly isn't here to kick the kernel back into gear after it hit a bug, or to tell it things it already knows.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast