[WIP] minimal libptz implementation

[puuu]

This is a minimal implementation of libptz. It only implements the currently used functionality. It is reverse engineered from Ver24520191030 using strace and overloaded system calls.

It should help provide ptz functionality on newer firmware versions.

I am currently testing this version and compare it with the original libptz version.

[puuu]

@roleoroleo this implementation works fine for me.

But I have some issues with the ptz tool that I also can reproduce with original libhardware.so or libptz.so.

For set_preset, the check of MAX_[XY] and MIN_[XY] are done before setting the x and y variables, so the checks never apply. Sometimes the ptz driver reports negative values and they make the preset invalid.

Furthermore, my model (GK-200MP2-B) can drive to look complete upwards (the most compact position), in this case y is about 1800, but ptz.h defines MAX_Y as 900. I am afraid that changing MAX_Y will change the behavior of the internal presets.

Is there some reason for this?

[roleoroleo]

For set_preset, the check of MAX_[XY] and MIN_[XY] are done before setting the x and y variables, so the checks never apply. Sometimes the ptz driver reports negative values and they make the preset invalid.

You are right, this is a bug.

Furthermore, my model (GK-200MP2-B) can drive to look complete upwards (the most compact position), in this case y is about 1800, but ptz.h defines MAX_Y as 900. I am afraid that changing MAX_Y will change the behavior of the internal presets.

You are right again. I need to check it.

EDIT

Ok, now I remember. It's not simple to know the right coordinates of the motor. If you move the cam to the upper limit and run a ptz -a up the cam cannot go up because it can't go behind the limit but the y coordinate increases. The same if you go down, right or left. This way you lose the reference. You should be able to move around the area without going beyond the limits. Somewhere I found 3500 and 900 so I set them in the code but I'm not sure if they are the real limits of the cam. I accept suggestions :)

[WildRat]

You should be able to move around the area without going beyond the limits. Somewhere I found 3500 and 900 so I set them in the code but I'm not sure if they are the real limits of the cam. I accept suggestions :)

I think that the required values need to be measured once, and then "embed" into the source code. Since this project is intended for one specific device hardware model.

[roleoroleo]

For my cam the vertical limit is about 1350.

[puuu]

For my cam the vertical limit is about 1350.

I can confirm this. The 1800 was only a guess. 1350 is almost the best. For the horizontal limit my camera can go up to 3800 and drive reproducible back to the same position.

Somewhere I found 3500 and 900 so I set them in the code but I'm not sure if they are the real limits of the cam.

I guess from the parameter of ptz_drv.ko. The same command with same parameter can also be find in the firmware.

I have no idea what these parameters mean. The camera seems to drive to half of these parameters after loading the kernel module, but I didn't find any other changes in behavior.

How about using: MAX_X 3500 and MAX_Y 1350?

[roleoroleo]

How about using: MAX_X 3500 and MAX_Y 1350?

Ok. I will merge this pr and change the define in the code.