Re: RFC: kern.video.record
On Fri, Sep 18, 2020 at 06:50:33AM -0600, Thomas Frohwein wrote: Hello Thomas, Thanks for your comments! > It might be worth considering combining kern.audio.record and > kern.video.record, as they serve the same purpose (just different > modalities). I doubt that granular controls with separate switches will be > very useful at this level; maybe rather leave this differentiation to the > application? > > An added benefit would be that there would be less largely duplicated code; > and probably better maintainability. I agree that it would simplify the code. The reason that I didn't merge them is because I know that sometimes people want to record audio but not video (I doubt that many people record video without audio). Now, admittedly, this isn't necessarily a super-common use case, so it might not be worth having two knobs for it, but it might be worth considering. Personally I'm completely comfortable with whatever the general consensus is for merging/not-merging! Laurie
Re: RFC: kern.video.record
On Sat, Sep 19, 2020 at 10:14:55AM +0100, Laurence Tratt wrote: > > I agree that it would simplify the code. The reason that I didn't merge them > is because I know that sometimes people want to record audio but not video (I > doubt that many people record video without audio). Now, admittedly, this > isn't necessarily a super-common use case, so it might not be worth having > two knobs for it, but it might be worth considering. Personally I'm > completely comfortable with whatever the general consensus is for > merging/not-merging! There are legal reasons for recording video only. Depends on local laws. I forget the exact details, but Texas laws regarding informing others if they are being recorded are more permissive than other states as far as needing to inform. I've only been following this thread lightly, but it seems relevant to at least throw that information in. Chris Bennett
Re: RFC: kern.video.record
> On Sep 19, 2020, at 10:39 AM, Chris Bennett > wrote: > > On Sat, Sep 19, 2020 at 10:14:55AM +0100, Laurence Tratt wrote: >> >> I agree that it would simplify the code. The reason that I didn't merge them >> is because I know that sometimes people want to record audio but not video (I >> doubt that many people record video without audio). Now, admittedly, this >> isn't necessarily a super-common use case, so it might not be worth having >> two knobs for it, but it might be worth considering. Personally I'm >> completely comfortable with whatever the general consensus is for >> merging/not-merging! > > There are legal reasons for recording video only. Depends on local laws. > I forget the exact details, but Texas laws regarding informing others if > they are being recorded are more permissive than other states as far as > needing to inform. I've only been following this thread lightly, but it > seems relevant to at least throw that information in. > > Chris Bennett > > Admittedly, I have not used audio or video recording on OpenBSD; however, the minimal code duplication is avoidable in other ways. Having two switches to control two separate modalities, as you described, provides more flexibility with respect to truly preventing an application (poorly designed, malicious, etc) from “snooping” on your audio or video. Again, I’m not a user of the recording functionality, so this is me throwing my two cents out there. -Brian
[PATCH] faq13, Using a Webcam
Hello, After some discussions in the WIP thread, I decided to send a patch without the part in question. So here is the "Using a Webcam" chapter which does only mention that it's necessary to set permissions of /dev/video* to the user. I leaves out the details about how to do it best. If there are new developments, like a video group or a sysctl video.record knob, I'll send delta patches to describe the behavior. OK? Best Regards, Stefan Index: faq/faq13.html === RCS file: /cvs/www/faq/faq13.html,v retrieving revision 1.220 diff -u -p -u -p -r1.220 faq13.html --- faq/faq13.html 19 May 2020 02:01:48 - 1.220 +++ faq/faq13.html 19 Sep 2020 17:26:38 - @@ -66,6 +66,7 @@ FAQ - Multimedia Choosing the Default Audio Device Debugging Audio Problems Using MIDI Instruments + Using a Webcam
Re: [PATCH] Adding group "video" for /dev/video*
Stefan Hagen wrote: > This patch changes MAKEDEV to generate /dev/video0..n with permission > 660 and group "video". It also adds the group "video" with GID 46 to > /etc/groups. > > OK? *ping* I think this one got lost in the thread. Best Regards, Stefan
Re: RFC: kern.video.record
On Sun, 13 Sep 2020 09:23:36 +0100 Laurence Tratt : > Since I recently opened my big fat mouth and suggested that > "kern.video.record" (analogous to kern.audio.record) might be a good idea, I > decided to put together a quick prototype (heavily based on the > kern.audio.record code). This at least roughly works for me but raises some > questions such as: I vote for keeping both so we can enable audio only or video only and be sure about what is enabled and able to record our environment
Re: ksh "clear-screen" for vi mode
On Sat, Sep 19, 2020 at 03:50:52PM -0600, Todd C. Miller wrote: > The vi and emacs edit code are completely separate. Try the following > diff. I had to rename a few things to avoid clashing with ncurses.h. This works and appears to match bash's behavior in that it only works in normal mode. I would slightly prefer to also add the command to the nonstandard vi commands in the switch around line 650 to have it available from insert mode as well. This would match zsh's behavior. Either way, ok tb
Re: ksh "clear-screen" for vi mode
The vi and emacs edit code are completely separate. Try the following
diff. I had to rename a few things to avoid clashing with ncurses.h.
- todd
Index: bin/ksh/vi.c
===
RCS file: /cvs/src/bin/ksh/vi.c,v
retrieving revision 1.56
diff -u -p -u -r1.56 vi.c
--- bin/ksh/vi.c15 Mar 2018 16:51:29 - 1.56
+++ bin/ksh/vi.c19 Sep 2020 21:48:31 -
@@ -14,12 +14,14 @@
#include
#include
#include
+#ifndef SMALL
+# include
+# include
+#endif
#include "sh.h"
#include "edit.h"
-#define CTRL(c)(c & 0x1f)
-
struct edstate {
char*cbuf; /* main buffer to build the command line */
int cbufsize; /* number of bytes allocated for cbuf */
@@ -52,8 +54,9 @@ static intBackword(int);
static int Endword(int);
static int grabhist(int, int);
static int grabsearch(int, int, int, char *);
+static voiddo_clear_screen(void);
static voidredraw_line(int);
-static voidrefresh(int);
+static voidrefresh_line(int);
static int outofwin(void);
static voidrewindow(void);
static int newcol(int, int);
@@ -271,9 +274,9 @@ vi_hook(int ch)
case 0:
if (state == VLIT) {
es->cursor--;
- refresh(0);
+ refresh_line(0);
} else
- refresh(insert != 0);
+ refresh_line(insert != 0);
break;
case 1:
return 1;
@@ -298,7 +301,7 @@ vi_hook(int ch)
return -1;
} else if (putbuf("?", 1, 0) != 0)
return -1;
- refresh(0);
+ refresh_line(0);
}
}
}
@@ -310,7 +313,7 @@ vi_hook(int ch)
vi_error();
} else
es->cbuf[es->cursor++] = ch;
- refresh(1);
+ refresh_line(1);
state = VNORMAL;
break;
@@ -375,7 +378,7 @@ vi_hook(int ch)
if (!srchpat[0]) {
vi_error();
state = VNORMAL;
- refresh(0);
+ refresh_line(0);
return 0;
}
} else {
@@ -392,17 +395,17 @@ vi_hook(int ch)
} while (srchlen > 0 &&
isu8cont(locpat[srchlen]));
es->cursor = es->linelen;
- refresh(0);
+ refresh_line(0);
return 0;
}
restore_cbuf();
state = VNORMAL;
- refresh(0);
+ refresh_line(0);
} else if (ch == edchars.kill) {
srchlen = 0;
es->linelen = 1;
es->cursor = 1;
- refresh(0);
+ refresh_line(0);
return 0;
} else if (ch == edchars.werase) {
struct edstate new_es, *save_es;
@@ -421,7 +424,7 @@ vi_hook(int ch)
es->linelen -= char_len((unsigned
char)locpat[i]);
srchlen = n;
es->cursor = es->linelen;
- refresh(0);
+ refresh_line(0);
return 0;
} else {
if (srchlen == SRCHLEN - 1)
@@ -446,7 +449,7 @@ vi_hook(int ch)
es->cbuf[es->linelen++] = ch;
}
es->cursor = es->linelen;
- refresh(0);
+ refresh_line(0);
}
return 0;
}
@@ -459,15 +462,15 @@ vi_hook(int ch)
switch (vi_cmd(argc1, curcmd)) {
case -1:
vi_error();
- refresh(0);
+ refresh_line(0);
break;
case 0:
if (insert != 0)
inslen = 0;
- refresh(insert != 0);
+
