add --osd-custom-message #32
Conversation
|
Oh... I know this is the way it was implemented in, eg, msposd... Or we can merge your implementation as is but keeping in mind that it is a temporary hack. On Linux I think more standard way is to create a UNIX socket for such things... At least the way it was popular smth like 15 years ago (nowdays people add HTTP APIs). Do you think we can change it to be based on UNIX datagram socket? Example: https://medium.com/swlh/getting-started-with-unix-domain-sockets-4472c0db4eb1 The upside of the UNIX socket would be that it can't be accidentally overriden and that filesystem is not involved. And it has a potential of growing to a real API. What do you think? |
|
I have mixed feelings about that. Using Unix-domain sockets isn't easy to interface with, and not many people are familiar with them. For instance, in a shell, you would need socat to write to it. We would also need another thread to handle connections, and at that point, it might be simpler to include a basic HTTP server library to handle everything for us. This would give us an HTTP interface, which is more versatile, easier to interface with, and familiar to more people. Edit: maybe mongoose ? Using fileinput is straightforward to implement and easy to interface with. We are not reading and writing to a physical file—/run is tmpfs, served by the kernel in memory—so I expect it to remain available as long as the kernel is running. I wouldn’t worry too much about file access here. Concerning overwrites: In theory, this is possible, but I expect it to be rare in practice. What’s the worst that could happen? Receiving garbage data? We should sanitize any data we read in any case. Getting half a message or two messages at once? That doesn’t sound like the end of the world to me. None of this information should be mission-critical anyway. |
|
Ok, I guess we can merge it like this for now even though I'm not reall happy about that. With intention to implement a real HTTP API later. (With this feature, we would already have 2 APIs: one is to toggle DVR with SIGUSR and 2nd is to show custom OSD msg). |
|
I think as a temporary feature it's fine, but it should stay beta until a proper API is thought out. |
|
Shall i rename the switch to |
|
Maybe just add a note to the |
src/osd.c
Outdated
| if (msg_length > 0 && custom_msg[msg_length - 1] == '\n') { | ||
| custom_msg[msg_length - 1] = '\0'; | ||
| msg_length--; // Adjust length after removing newline | ||
| } |
There was a problem hiding this comment.
should this be a while loop instead? Smth like
while (msg_length > 0 && custom_msg[msg_length - 1] == '\n') {
custom_msg[msg_length - 1] = '\0';
msg_length--; // Adjust length after removing newline
}
There was a problem hiding this comment.
Plan was to ensure that the read message is null terminated at position 80.
We only read sizeof(custom_msg) so either custom_msg[80] (and maybe before) is aleardy null terminted or the read input is exactly 80 bytes long. In that case we should always null termintare at 80.
Will change this to always null termiate at 80.
There was a problem hiding this comment.
@henkwiedig I rather meant that it could be that the file contains
my msg\n
\n
\n
Wuite unlikely, but since we already decide to strip newlines at the end of the line we read, might make sense to ensure all the newlines are stripped. But up to you. Just a tip.
|
This feature is great, I can display current channel when doing a channel scan, and can also show waring message when system is overheat from shell. But I think /run/pixelpilot.msg should a FIFO file and created when pp start. The ideal behavior is clearing the file after reading the content instead of deleting the file every time finish reading it. UNIX socket is not so easy using in shell, So I prefer FIFO. @henkwiedig |
This MR will add the feature of a custom message displayed on screen.
pixelpilot will read from
/run/pixelpilot.msgand display whatever is in there up to 79 chars.After reading the input file will be deleted to make it ready for a new read.
Message will be displayed 4 osd refresh loops.
This makes it easy to quickly integrate other software.
As an example i currently use this to display the current channel when my channel switcher script is triggered via gpio.