From: "Zebediah Figura (she/her)" <zfigura@codeweavers.com>
Subject: Re: [PATCH] qcap:fix the bug which camera device can't be released correctly.
Message-Id: <601ce32d-4fb3-30b9-c622-66aa5aaa2cf0@codeweavers.com>
Date: Sat, 5 Jun 2021 12:44:09 -0500
In-Reply-To: <1696ed8c.3eb5.179dbc957f2.Coremail.luoriyuhui21@163.com>
References: <20210603042532.65022-1-luoriyuhui21@163.com> <96c44211-8fba-cc70-06a5-b5eefd180158@codeweavers.com> <1696ed8c.3eb5.179dbc957f2.Coremail.luoriyuhui21@163.com>

Hello Keming,

It isn't clear from the log, but it looks like the application may be 
trying to create a second filter on the same device without fully 
releasing the first one.

Although I haven't tested very fully, I think Windows is more lenient 
about opening multiple capture filters than we currently allow for. It 
may be that there's a leak somewhere that we're to blame for; it's 
probably worth checking carefully to make sure that isn't the case.

But we may need to find ways to avoid holding a file descriptor open 
when not streaming. When doing that you will need to account for the 
fact that most APIs remain usable even after a stream is stopped. You 
may want to defer VIDIOC_S_FMT until streaming starts, and find a way to 
release ownership of the device when streaming stops (I don't know 
offhand if v4l2 provides this; you may need to close and reopen the 
descriptor.)

Tests replicating the application behaviour would also be useful.

ἔρρωσο,
Zebediah