Re: [PATCH 2/6] xf86drmMode: separate drmModeAtomicCommit() and drmModeAtomicCleanup()

[Pekka Paalanen <ppaalanen@gmail.com>]

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

On Fri, 21 Aug 2015 16:18:59 +0900
Hyungwon Hwang <human.hwang@samsung.com> wrote:

> Hi Pekka,
> 
> On Fri, 21 Aug 2015 09:42:26 +0300
> Pekka Paalanen <ppaalanen@gmail.com> wrote:
> 
> > On Fri, 21 Aug 2015 13:54:49 +0900
> > Hyungwon Hwang <human.hwang@samsung.com> wrote:
> > 
> > > Hi Emil,
> > > 
> > > On Thu, 20 Aug 2015 17:17:27 +0100
> > > Emil Velikov <emil.l.velikov@gmail.com> wrote:
> > > 
> > > > Hi Hyungwon,
> > > > 
> > > > On 19 August 2015 at 01:58, Hyungwon Hwang
> > > > <human.hwang@samsung.com> wrote:
> > > > > This patch seprates the code, which sorts proprty sets and
> > > > > eliminates duplicate properties, from drmModeAtomicCommit(). Now
> > > > > drmModeAtomicCleanup() has to do the job before calling
> > > > > drmModeAtomicCommit(), and drmModeAtomicCommit() just converts
> > > > > the cleaned request to IOCTL argument.
> > > > >
> > > > Afaict the commit message should say why we want this, rather than
> > > > rewording what the patch does.
> > > > 
> > > > I'm not sure about the atomic status for wayland and others but
> > > > this commit might cause issues there. Additionally, with this
> > > > patch we'll send a lot of useless information to the kernel if
> > > > one omits drmModeAtomicCleanup(). The kernel will likely discard
> > > > it but still this doesn't seem like a good idea imho.
> > > 
> > > Yes. I agree that this change burdens the userspace application to
> > > use API correctly. In my case, for modetest, the function of
> > > cleaning up the request is needed, so I thought that this
> > > separation would be needed. Overall, I agree with you. So I will
> > > drop this patch, and find another way which is specific for
> > > modetest.
> > 
> > Hi,
> > 
> > why do you need that, exactly?
> 
> To make the buffer for plane, I needed to figure out the width and the
> height which the user set which are in the request, but not applied to
> the kernel yet. To get the value from the request, I thought cleaning
> the request before I try to getting the value from the request was
> needed because the user could set the different values for the same
> property.

Hi,

I would say that that is completely out of the scope of the libdrm API.
The caller of that API set those values, so it knows them - why should
libdrm offer an API to query back the values you just put in the req?

The caller is storing those values somewhere else too in any case,
exactly because it wants to allocate buffers of the same size. So very
likely those values were already stored *before* the atomic request was
even created.

IMHO, it is the responsibility of the application to track what it
itself is doing. If you have to write some data structures to do that,
then that's what you should do. Libdrm is not a replacement for that.


Thanks,
pq

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

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel