UAPI Re: [PATCH 1/3] drm: Add DRM_MODE_TV_MODE_MONOCHROME

[Daniel Vetter]

On Thu, May 23, 2024 at 04:51:25PM +0200, Maxime Ripard wrote:
> Hi,
> 
> Reviving this thread because I'm not sure what the outcome was.
> 
> On Thu, Feb 29, 2024 at 11:52:12AM GMT, Daniel Vetter wrote:
> > > The only thing I'm saying is that this breaks the usual DRM requirements.
> > > If, as a maintainer, you're fine with breaking the rules and have a good
> > > motivation to do so, that's fine by me. Rules are meant to be broken from
> > > time to time depending on the situation. But please don't pretend that
> > > modetest/xrandr is valid user-space to pass the rules.
> > 
> > I think it bends it pretty badly, because people running native Xorg are
> > slowly going away, and the modetest hack does not clear the bar for "is it
> > a joke/test/demo hack" for me.
> > 
> > I think some weston (or whatever compositor you like) config file support
> > to set a bunch of "really only way to configure is by hand" output
> > properties would clear the bar here for me. Because that is a feature I
> > already mentioned that xrandr _does_ have, and which modetest hackery very
> > much does not.
> 
> The expectation (and general usage) for that property was that it was
> set by the kernel command line and then was forgotten about. Old TVs
> require one mode and that's it, so it doesn't make much sense to change
> it while the system is live, you just want the default to work.
>
> So it's not really a matter of "the user-space code should be open"
> here, there's no user-space code, and there will likely never be given
> that it's mostly used to deal with decades-old systems at this point.

Yeah if this is being used just with the kernel cmdline, then I guess
that's somewhat ok-ish. And TVs are horrible, so "massage your kernel
cmdline" is comparitively not a horrible interface :-P

Anyway, I guess this makes this an ack.
-Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch