Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Device locking #23

Open
laurivosandi opened this issue Apr 6, 2014 · 3 comments
Open

Device locking #23

laurivosandi opened this issue Apr 6, 2014 · 3 comments

Comments

@laurivosandi
Copy link

Hello,

currently it seems when two video player instances access the VDPAU interface then this causes a lot of trouble. In some cases I get garbage on the screen, segfault or even crash of the whole system. VDPAU device locking might sound good idea if the hardware does not allow two or more player instances. Let me know how I could help out.

Oh and a tarball release would be nice aswell to settle the versioning of your software package :)

@jemk
Copy link
Member

jemk commented Apr 6, 2014

That's a known issue, the kernel driver doesn't provide any sort of locking. We have direct register access, so if two instances are running they always overwrite each other.
To fix this the kernel driver needs to be extended with some locking.

There are IOCTL_ENGINE_REQ and IOCTL_ENGINE_REL, but all they do is changing a reference counter that doesn't get checked anywhere... There is also an #ifdef block with some task management code, but nobody ever tried to understand or even test this.
https://github.com/linux-sunxi/linux-sunxi/blob/stage/sunxi-3.4/drivers/media/video/sunxi/sunxi_cedar.c#L507

Another problem is, we have one big memory block. Userspace is responsible to allocate the needed pieces, but userspace can't know which parts of memory are already used by another instance.

To conclude, the current driver makes it hard or even impossible to have two instances. It also will never make it to mainline kernel, it has many security problems (direct memory access to whole memory). I'm currently trying to write a new driver, based on v4l2, but there are other problems, and it will need much more time.

@ssvb
Copy link

ssvb commented Apr 7, 2014

We can try to ensure that /dev/cedar_dev can be only opened by a single user. All the extra instances have to fail. And also try to track the userland MMIO and memory buffer mappings to clearly know when the userspace process has no access to the cedar hardware anymore.

@mittorn
Copy link

mittorn commented Jan 26, 2015

Is it possible to make it work with different buffers at single time?
For example, while one process is using cedar_dev, when another process trying to use cdxalloc, we should allocate new buffer in different memory region and lock all registers while first process id decoding frame, after that we should save its state (if any) and decode one frame from second process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants