-
Notifications
You must be signed in to change notification settings - Fork 246
chore: disable sleep mode when detecting video format #887
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
Conversation
Implemented a new feature to enable or disable HDMI sleep mode, allowing users to reduce power consumption when the device is not in use. Added state management for the power saving setting and integrated it with the existing settings page.
V4L2 buffers were not explicitly freed before closing the device, causing VIDIOC_S_FMT to fail with EBUSY on restart. Added VIDIOC_REQBUFS(count=0) call in cleanup to free buffer queue synchronously before close(). This ensures subsequent opens can set format immediately without EBUSY errors, eliminating 100ms+ retry delays.
Co-authored-by: Adam Shiervani <adam.shiervani@gmail.com> Co-authored-by: Adam Shiervani <adamshiervani@fastmail.com>
Co-authored-by: Adam Shiervani <adam.shiervani@gmail.com> Co-authored-by: Adam Shiervani <adamshiervani@fastmail.com>
IDisposable
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this already merged, but I had a couple questions/comments
| // it's used to ensure that only one change is made to the video stream at a time. | ||
| // as the change usually requires to restart video streaming | ||
| // TODO: check video streaming status instead of using a hardcoded timeout | ||
| func (n *Native) useExtraLock(fn func() error) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this queuing-up be better handled by pushing the change into a channel to be handled inside a go-routine that serves up the changes in-order?
|
|
||
| uint32_t detected_width, detected_height; | ||
| bool detected_signal = false, streaming_flag = false; | ||
| bool detected_signal = false, streaming_flag = false, streaming_stopped = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we declare streaming_stopped as volatile so the compiler knows that another thread might be mucking with them? (streaming_flag is protected by mutex, so should be fine, but wouldn't hurt to declare it volatile as well?)
No description provided.