Re: [PATCH v4] Documentation: gpu: Mention the requirements for new properties

[Maxime Ripard <maxime@cerno.tech>]

[-- Attachment #1: Type: text/plain, Size: 4610 bytes --]

On Tue, Jul 06, 2021 at 12:37:23PM +0300, Pekka Paalanen wrote:
> > > > +- It must provide a generic helper in the core code to register that
> > > > +  property on the object it attaches to.
> > > > +
> > > > +- Its content must be decoded by the core and provided in the object's
> > > > +  associated state structure. That includes anything drivers might want to
> > > > +  precompute, like :c:type:`struct drm_clip_rect <drm_clip_rect>` for planes.
> > > > +
> > > > +- An IGT test must be submitted where reasonable.  
> > > 
> > > Would it be too much to replace "where reasonable" with "if it is at
> > > all possible to write a test."?
> > >   
> > > > +  
> > > 
> > > How about adding the following somewhere?
> > > 
> > > - The initial state of the property (set during driver initialization)
> > >   must match how the driver+hardware behaved before introducing this
> > >   property. It may be some fixed value or it may be inherited from e.g.
> > >   the firmware that booted the system. How the initial state is
> > >   determined must also be documented, that is, where does it come from.
> > > 
> > > The initial state must not be called "default", because I want to
> > > reserve the term default for something else if possible: the phrase
> > > "reset everything to defaults", which is a whole another discussion.  
> > 
> > I've taken into account your previous comments, thanks
> > 
> > > How about also saying that fbcon/fbdev must set this property when
> > > taking over? That sounds to be like a common omission leading to funky
> > > KMS state in fbcon. The value fbdev sets it to only needs to make
> > > sense to fbdev, and it does not need to be ~~the initial value~~ nor the
> > > default value. Or are we hoping to kill fbcon in favor of a userspace
> > > kmscon soon? ;-)
> > > 
> > > Ooh, maybe the KMS property documentation should also say what value
> > > fbdev will set the property to. That's kind of UABI, because userspace
> > > probably implicitly relies on it in many cases. ...which means fbdev
> > > should set the property to its initial value, otherwise userspace will
> > > break.  
> > 
> > I'm not sure about this one: fbdev and fbcon are still optional features
> > of the kernel and can be disabled at the user discretion. Having any
> > part of the user-space rely on the fbdev behavior seems a bit broken,
> > especially when we have a mechanism to retrieve the state when the
> > application starts.
> 
> yes, exactly that is why fbdev/fbcon should reset the properties to
> their initial values. You would not want userspace inheriting a
> different KMS state with vs. without fbcon when it starts.

I'm not sure I'm following you when fbdev/fbcon should reset these
properties. When a master takes over?

If we consider fbdev as any KMS client, isn't it a fundamental change
with how it's currently done? I haven't seen anywhere that a compositor
(or any client for that matter) should put the KMS device in the same
state that it started it with. In case of a crash it would be fairly
difficult to achieve.

> Retrieving the current KMS state is useless if the current KMS state is
> somehow wonky and the application does not understand that specific KMS
> property that is wonky. It cannot set the property to any value other
> than it already had without user intervention.

Yeah, that's true. But the same could be said if you switch from one
client to the other for example, at the moment there's no guarantee that
the first one didn't change a property to a value you don't expect in
the second. Unless we manage to tie that somehow to a first open of the
device?

> I'd say fbcon causing all KMS state to be reset is a quality of life
> thing. It's possible to live without by rebooting, but it would
> certainly make at least developers' and testers' life easier until we
> get the real "reset KMS" knob (which fbcon could then use too).
> 
> Besides, even if it is broken for userspace to rely on the KMS state
> set by fbcon/fbdev, userspace is already doing that and not on purpose
> because new KMS properties get added in the kernel. I would bet that
> there is not a single userspace program that would actually set all KMS
> properties that drivers might expose. So they are depending on
> inherited KMS state, which could be left by driver initialization, by
> fbdev/fbcon, or by any other userspace.
> 
> But yeah, this idea is something new, so don't let this discussion
> delay landing the docs.

Ack, I've sent a new version

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]