Hi Gregor er all,
On 08/18/2009 03:32 PM, Gregor Jasny wrote:
Hi Hans,
I just received the following bug report. As far as I understand the
code, this shared memory is for remembering configuration values.
Control values such as the setting for the gamma software correction. Yes.
this is to remember them between runs, but also so that a control panel
application like v4l2ucp can realtime influence the libv4l software effects
running in another streaming application.
So everybody who has write permission on the video device can change the
underlaying values. So this would justify the same permissions on the
shm segment as on the video device.
Yes it would, but often the process creating the segment does not have
the permissions necessary to create such segments, so I think your solution
below is the best we can do.
> But I assume then libv4l needs some
locking code.
No, no locking is needed, all accesses done to the shared memory
are 32 bit words reads / writes. Without any inter dependencies
between different reads / writes. So assuming that an aligned
32 bit word read / write is atomic at the hardware level, there is
no need for locking.
Would adding a uid to the shm segment be a solution?
Yes, this is not perfect as libv4l fake / software controls are now
per user, whereas hardware controls are per device, but this is the best
we can do imho. Even better (prettier) would be to use the username.
Patches welcome, please let let me know if you do not plan on working on
this then I'll do a patch myself.
Regards,
Hans
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
