From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D2EEC5661 for ; Thu, 25 Dec 2025 22:53:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.184 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766703217; cv=none; b=K5KVR6EwnkJMd71t+AJbkfjU670J6WmvYGeUSTqFFKH/1FoKw65OUQzPsYjwl6PepUX/Wm345zhsSbpTGt7mTHe/QbGvr733tzpz7g2HYslk3C48IwHXU/CDt3aPRG1VcDVQB8rQSsz9hnJj80IgKNqEnueU7lEOTN1QyZyIpas= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766703217; c=relaxed/simple; bh=8Bl87sjOeJEeTTZcr4AU4MZuxMspVdlgihJDib5ly6k=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bgQdCHgC3XH9GqVabhRR0KchANUUqGxSCXw0kERCSp94MyFOuKsxyFcd/6ulrknl7mcEHHnwqCSscgEByXodyJ/nSfBCSRJgBAnDKO4YXjt8huKl1+zPiCVG+ZCpF84lyyLI+Qd1xOv6Dww9J0lYwNI4w6U/7AKCRUYyNF1Yyms= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool; spf=pass smtp.mailfrom=packett.cool; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b=SparbaWU; arc=none smtp.client-ip=91.218.175.184 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=packett.cool Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=packett.cool Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=packett.cool header.i=@packett.cool header.b="SparbaWU" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packett.cool; s=key1; t=1766703213; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UTq5gCCegajzQ2uBoKipxKxU+gvWEXz5erxNVvC4+Ng=; b=SparbaWUMVuyS44P0MyDh26WSZ+4Jq6khpXTArWlLEC0wEngbSMGFJ9ajp5TgHBQrnX1/e p6itN0+cXOnsL9QLmdTGDO4gmGSa4nCpXam2/vpyiCEojoZ2PAy5AqB3coAdtRl2qy/nxV jt6i7Pd22LhBf7p6EIVkNKhbeVhYWRzvRw4Fj5ZEdSsxdHyxVlWbG7UD0mwkgJ4GVoYpyn JK/yAhhicHt3rw7fj7e/MqQZv53jlSPhUUYCYbDoCiiQKxHrJ0+TDFabiXtjeH0bpuTzEr LXbUWchwSDOI2XQXYXT3AVJ90orOxmYav3obSlMURt5CO7RsoRkDouKlBlUMMw== Date: Thu, 25 Dec 2025 19:53:26 -0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] media: iris: set default size when S_FMT is called with zero size To: Bryan O'Donoghue , Vikash Garodia , Dikshita Agarwal , Abhinav Kumar , Mauro Carvalho Chehab , Hans Verkuil , Stefan Schmidt , Vedang Nagar Cc: linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org References: <20251012235330.20897-1-val@packett.cool> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Val Packett In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 10/28/25 10:19 AM, Bryan O'Donoghue wrote: > On 13/10/2025 00:50, Val Packett wrote: >> drivers/media/platform/qcom/iris/iris_vdec.c | 5 +++++ >>   1 file changed, 5 insertions(+) >> >> diff --git a/drivers/media/platform/qcom/iris/iris_vdec.c >> b/drivers/media/platform/qcom/iris/iris_vdec.c >> index ae13c3e1b426..6be09d82e24d 100644 >> --- a/drivers/media/platform/qcom/iris/iris_vdec.c >> +++ b/drivers/media/platform/qcom/iris/iris_vdec.c >> @@ -196,6 +196,11 @@ int iris_vdec_s_fmt(struct iris_inst *inst, >> struct v4l2_format *f) >>       if (vb2_is_busy(q)) >>           return -EBUSY; >> >> +    if (f->fmt.pix_mp.width == 0 && f->fmt.pix_mp.height == 0) { >> +        f->fmt.pix_mp.width = DEFAULT_WIDTH; >> +        f->fmt.pix_mp.height = DEFAULT_HEIGHT; >> +    } >> + >>       iris_vdec_try_fmt(inst, f); >> >>       switch (f->type) { >> -- > > Doesn't venus do > > orig_pixmap = *pixmap; > > try_fmt(); > > format.fmt.pix_mp.width = orig_pixmp.width; > format.fmt.pix_mp.height = orig_pixmp.height; > > should you fall back to DEFAULT_WIDTH/HEIGHT or to > orig_pixmp.width/height ? Hi– sorry for the late reply and happy holidays :) The patch does the fallback *before* try_fmt(). I have just retested everything, even with yesterday's new "misc fixes" patchset (https://lore.kernel.org/all/20251224-iris-fixes-v1-0-5f79861700ec@oss.qualcomm.com/). The issue is still present, the 0x0 size is what iris_vdec_s_fmt gets before try_fmt(). What the rpi-ffmpeg developer said (https://github.com/jc-kynesim/rpi-ffmpeg/issues/103) is: - V4L2 very clearly says that you should be able to pass anything into S_FMT and it should set the returned values to something valid - S_FMT should not only not complain, it should return valid values in the structure passed to it which will then be used in the REQBUFS - the buffers being allocated are for the coded bitstream (remember in V4L2 speak OUTPUT=source, CAPTURE=destination); width/height doesn't really mean a lot here but buffer size does - https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-decoder.html 4.5.1.5 states "width, height: coded resolution of the stream; required only if it cannot be parsed from the stream for the given coded format; otherwise the decoder will use this resolution as a placeholder resolution that will likely change as soon as it can parse the actual coded resolution from the stream" So since this is a deliberate zero request, and V4L2 requires returning a valid placeholder resolution, it should be DEFAULT indeed. I'll resend with a comment as requested by Dikshita. ~val