Re: [PATCH v2 1/3] sur40: properly report a single frame rate of 60 FPS

[Florian Echtler <floe@butterbrot.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1920 bytes --]

On 06.07.2016 10:40, Hans Verkuil wrote:
> On 07/05/16 09:06, Hans Verkuil wrote:
>> On 07/05/2016 08:56 AM, Florian Echtler wrote:
>>> On 05.07.2016 08:41, Hans Verkuil wrote:
>>>>
>>>> Why is s_parm added when you can't change the framerate?
>>>
>>> Oh, I thought it's mandatory to always have s_parm if you have g_parm
>>> (even if it always returns the same values).
>>>
>>>> Same questions for the
>>>> enum_frameintervals function: it doesn't hurt to have it, but if there is only
>>>> one unchangeable framerate, then it doesn't make much sense.
>>>
>>> If you don't have enum_frameintervals, how would you find out about the
>>> framerate otherwise? Is g_parm itself enough already for all userspace
>>> tools?
>>
>> It should be. The enum_frameintervals function is much newer than g_parm.
>>
>> Frankly, I have the same problem with enum_framesizes: it reports only one
>> size. These two enum ioctls are normally only implemented if there are at
>> least two choices. If there is no choice, then G_FMT will return the size
>> and G_PARM the framerate and there is no need to enumerate anything.
>>
>> The problem is that the spec is ambiguous as to the requirements if there
>> is only one choice for size and interval. Are the enum ioctls allowed in
>> that case? Personally I think there is nothing against that. But should
>> S_PARM also be allowed even though it can't actually change the frameperiod?
>>
>> Don't bother making changes yet, let me think about this for a bit.
> 
> OK, I came to the conclusion that if enum_frameintervals returns one or
> more intervals, then s_parm should be present, even if there is only one
> possible interval.
> 
> I have updated the compliance utility to check for this.

AFAICT, the original patch does meet the requirements, then? Or do you
have any change requests?

Best, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]