enable mpip(4) in GENERIC?
ok? Index: GENERIC === RCS file: /cvs/src/sys/conf/GENERIC,v retrieving revision 1.257 diff -u -p -r1.257 GENERIC --- GENERIC 20 Dec 2018 23:00:55 - 1.257 +++ GENERIC 18 Mar 2019 03:22:03 - @@ -94,6 +94,7 @@ pseudo-device mobileip# MobileIP encaps pseudo-device loop# network loopback pseudo-device mpe # MPLS PE interface pseudo-device mpw # MPLS pseudowire support +pseudo-device mpip# MPLS IP Layer2 pseudowire support pseudo-device bpe # Provider Backbone Bridge edge interface pseudo-device pair# Virtual Ethernet interface pair pseudo-device ppp # PPP
Re: wscons: precision scrolling
On Sun, 17 Mar 2019 at 19:35:17 +0100, Ulf Brosziewski wrote: > Hi Joshua, > > could you make a test with the updated diff below and check whether > the scroll speed is normal? (There are no changes in ws, it's just > the kernel part). Hi, this version scrolls much better.
Re: [patch] improve strptime(3) %z timezone parsing
On Sun, Mar 17, 2019 at 03:10:04PM -0400, Ted Unangst wrote: > Hiltjo Posthuma wrote: > > Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD > > strptime(3) man page (%z) describes military/nautical zones are supported. > > > > - NetBSD supports it (correctly since only a few months ago and it is not in > > stable or backported). > > - FreeBSD and DragonFlyBSD do not support them (strptime returns NULL). > > - Linux glibc does not support them (strptime returns NULL). > > - Linux musl libc does not support %z. > > This sounds like we should just drop support as well. I think that's better > than supporting something that's clearly unreliable. By that reckoning, you would never implement anything new... :(
Re: [patch] improve strptime(3) %z timezone parsing
Hiltjo Posthuma wrote: > Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD > strptime(3) man page (%z) describes military/nautical zones are supported. > > - NetBSD supports it (correctly since only a few months ago and it is not in > stable or backported). > - FreeBSD and DragonFlyBSD do not support them (strptime returns NULL). > - Linux glibc does not support them (strptime returns NULL). > - Linux musl libc does not support %z. This sounds like we should just drop support as well. I think that's better than supporting something that's clearly unreliable.
Re: wscons: precision scrolling
Hi Joshua,
could you make a test with the updated diff below and check whether
the scroll speed is normal? (There are no changes in ws, it's just
the kernel part).
On 3/16/19 4:16 PM, joshua stein wrote:
> On Thu, 14 Mar 2019 at 00:48:33 +0100, Ulf Brosziewski wrote:
>> Much too fast? I'm a bit surprised. In my tests, the new method was
>> generally somewhat slower than the old one (and I haven't changed the
>> "scroll units"). How did you test it? Which hardware and which applications
>> did you use?
>
> This is with an imt touchpad:
>
>ihidev0 at iic1 addr 0x15 irq 109 (polling), vendor 0x4f3 product
> 0x3056, ELAN2201
>ihidev0: 93 report ids
>imt0 at ihidev0: clickpad, 5 contacts
>wsmouse0 at imt0 mux 0
>
> I tested with two-finger scrolling in Firefox and Chrome with a new
> user and fresh browser profiles. I loaded the same webpages with
> the old wstpad code and the new, and the two-finger scrolling with
> the new setup scrolls much too fast for even small finger movements
> (~0.5").
>
> A movement with the previous code that would trigger the
> mousewheel-style scrolling of just a handful of lines causes the new
> code to scroll nearly an entire screen-height of the page.
>
>
Index: dev/wscons/wsconsio.h
===
RCS file: /cvs/src/sys/dev/wscons/wsconsio.h,v
retrieving revision 1.90
diff -u -p -r1.90 wsconsio.h
--- dev/wscons/wsconsio.h 10 Nov 2018 14:27:51 - 1.90
+++ dev/wscons/wsconsio.h 17 Mar 2019 18:23:14 -
@@ -112,6 +112,12 @@ struct wscons_event {
#defineWSCONS_EVENT_TOUCH_RESET25 /* (no value) */
/*
+ * Precision Scrolling
+ */
+#define WSCONS_EVENT_HSCROLL 26 /* dx * 4096 / scroll_unit */
+#define WSCONS_EVENT_VSCROLL 27 /* dy * 4096 / scroll_unit */
+
+/*
* Keyboard ioctls (0 - 31)
*/
Index: dev/wscons/wsmouse.c
===
RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
retrieving revision 1.51
diff -u -p -r1.51 wsmouse.c
--- dev/wscons/wsmouse.c19 Feb 2019 07:01:02 - 1.51
+++ dev/wscons/wsmouse.c17 Mar 2019 18:23:14 -
@@ -1034,10 +1034,18 @@ wsmouse_motion_sync(struct wsmouseinput
wsmouse_evq_put(evq, DELTA_X_EV(input), dx);
if (dy)
wsmouse_evq_put(evq, DELTA_Y_EV(input), dy);
- if (motion->dz)
- wsmouse_evq_put(evq, DELTA_Z_EV, motion->dz);
- if (motion->dw)
- wsmouse_evq_put(evq, DELTA_W_EV, motion->dw);
+ if (motion->dz) {
+ if (IS_TOUCHPAD(input))
+ wsmouse_evq_put(evq, VSCROLL_EV, motion->dz);
+ else
+ wsmouse_evq_put(evq, DELTA_Z_EV, motion->dz);
+ }
+ if (motion->dw) {
+ if (IS_TOUCHPAD(input))
+ wsmouse_evq_put(evq, HSCROLL_EV, motion->dw);
+ else
+ wsmouse_evq_put(evq, DELTA_W_EV, motion->dw);
+ }
}
if (motion->sync & SYNC_POSITION) {
if (motion->sync & SYNC_X) {
Index: dev/wscons/wsmouseinput.h
===
RCS file: /cvs/src/sys/dev/wscons/wsmouseinput.h,v
retrieving revision 1.12
diff -u -p -r1.12 wsmouseinput.h
--- dev/wscons/wsmouseinput.h 10 Nov 2018 14:27:51 - 1.12
+++ dev/wscons/wsmouseinput.h 17 Mar 2019 18:23:14 -
@@ -210,6 +210,8 @@ int wstpad_set_param(struct wsmouseinput
WSCONS_EVENT_MOUSE_ABSOLUTE_X : WSCONS_EVENT_MOUSE_ABSOLUTE_Y)
#define DELTA_Z_EV WSCONS_EVENT_MOUSE_DELTA_Z
#define DELTA_W_EV WSCONS_EVENT_MOUSE_DELTA_W
+#define VSCROLL_EV WSCONS_EVENT_VSCROLL
+#define HSCROLL_EV WSCONS_EVENT_HSCROLL
#define ABS_Z_EV WSCONS_EVENT_TOUCH_PRESSURE
#define ABS_W_EV WSCONS_EVENT_TOUCH_CONTACTS
#define BTN_DOWN_EVWSCONS_EVENT_MOUSE_DOWN
Index: dev/wscons/wstpad.c
===
RCS file: /cvs/src/sys/dev/wscons/wstpad.c,v
retrieving revision 1.22
diff -u -p -r1.22 wstpad.c
--- dev/wscons/wstpad.c 29 Dec 2018 21:03:58 - 1.22
+++ dev/wscons/wstpad.c 17 Mar 2019 18:23:14 -
@@ -167,8 +167,6 @@ struct wstpad {
u_int mtcycle;
u_int ignore;
- int dx;
- int dy;
int contacts;
int prev_contacts;
u_int btns;
@@ -223,12 +221,11 @@ struct wstpad {
} tap;
struct {
- int acc_dx;
- int acc_dy;
int dz;
int dw;
int hdist;
int vdist;
+ int mag;
} scroll;
};
@@ -435,8 +432,8 @@ set_freeze_ts(struct wstpad *tp, int sec
/* Return
Re: switch Xorg protos to xorgproto 2018.4
On Sun, Feb 24, 2019 at 12:56:53PM +0100, Matthieu Herrb wrote: > On Thu, Feb 14, 2019 at 09:38:33AM +0100, Matthieu Herrb wrote: > > On Mon, Feb 11, 2019 at 07:34:46AM +0100, Matthieu Herrb wrote: > > > Hi, > > > > > > I've recently imported xorgproto 2018.4 in xenocara. This is a package > > > the unifies all the previous *proto packages from X.Org (except > > > xcb-proto which is special), and enabled it yesterday. > > > > > > I had to revert that last commit since it is suspected to be the cause > > > for this regression mentionned on misc: > > > https://marc.info/?l=openbsd-misc=154983711329128=2 > > > > > > So please test the following diff for other possible regressions, > > > while we're looking at the compton issue. > > > > The compton issue has been found and a patch got committed to ports. > > > > So any ok for this ? > > ping ? Running this on my x250 and x201. No problems so far.
Re: update xserver to version 1.19.7
On Sun, Mar 03, 2019 at 01:48:18PM +0100, Matthieu Herrb wrote: > Hi, > > the patch below updates the X server to version 1.19.7. It's a bug-fix > release. You'll find the change log at the begining of the patch. > > To test, apply the patch with patch -p0 -E in /usr/xenocara/xserver, > and then re build xenocara as documented in release(8). > > The patch is also available at https://herrb.eu/xserver-1.19.7.diff > > Test reports and/or Oks welcome, > Running this on x250 and x201, and it seems fine.
Re: [patch] improve strptime(3) %z timezone parsing
On Sun, Mar 10, 2019 at 04:16:37PM -0400, Ted Unangst wrote: > Hiltjo Posthuma wrote: > > 2. The military/nautical UTC offsets are also reversed. This was also > > actually > > a bug in RFC822: > > > > RFC5322 (referenced in strptime(3) man page): > > https://tools.ietf.org/html/rfc5322 > > Section 4.3, page 34 says: > > " > >The 1 character military time zones were defined in a non-standard > >way in [RFC0822] and are therefore unpredictable in their meaning. > >The original definitions of the military zones "A" through "I" are > >equivalent to "+0100" through "+0900", respectively; "K", "L", and > >"M" are equivalent to "+1000", "+1100", and "+1200", respectively; > >"N" through "Y" are equivalent to "-0100" through "-1200". > >respectively; and "Z" is equivalent to "+". However, because of > >the error in [RFC0822], they SHOULD all be considered equivalent to > >"-" unless there is out-of-band information confirming their > >meaning. > > " > > > > While comparing the other BSD and Linux code-bases I noticed NetBSD has > > fixed > > this on 2017-08-24. It is not in NetBSD 8 stable yet, but in NetBSD-current: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/time/strptime.c > > So the fix doesn't follow either RFC? Does anyone implement the 5322 suggested > behavior of all zero offsets? Afaik no implementation uses zero offsets for military zones, but most implementations do return NULL when parsing a military zone with strptime(3) %z. Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD strptime(3) man page (%z) describes military/nautical zones are supported. - NetBSD supports it (correctly since only a few months ago and it is not in stable or backported). - FreeBSD and DragonFlyBSD do not support them (strptime returns NULL). - Linux glibc does not support them (strptime returns NULL). - Linux musl libc does not support %z. Any comments/OKs for the other points (1, 3, 4) ? Thanks for the review, -- Kind regards, Hiltjo
bgpd, change peer config handling
Move the struct peer into bgpd_config and switch it to a TAILQ instead of
the hand-rolled list. This changes the way peers are reloaded since now
both parent and session engine are now merging the lists.
If you are using neighbor templates you should really test this diff since
it may fix problems when switching from a templated peer to a fully
confiured one. All other users are also invited to test this :)
--
:wq Claudio
Index: bgpd.c
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.c,v
retrieving revision 1.213
diff -u -p -r1.213 bgpd.c
--- bgpd.c 7 Mar 2019 07:42:36 - 1.213
+++ bgpd.c 14 Mar 2019 11:11:57 -
@@ -43,7 +43,7 @@ __dead void usage(void);
intmain(int, char *[]);
pid_t start_child(enum bgpd_process, char *, int, int, int);
intsend_filterset(struct imsgbuf *, struct filter_set_head *);
-intreconfigure(char *, struct bgpd_config *, struct peer **);
+intreconfigure(char *, struct bgpd_config *);
intdispatch_imsg(struct imsgbuf *, int, struct bgpd_config *);
intcontrol_setup(struct bgpd_config *);
intimsg_send_sockets(struct imsgbuf *, struct imsgbuf *);
@@ -100,7 +100,6 @@ int
main(int argc, char *argv[])
{
struct bgpd_config *conf;
- struct peer *peer_l, *p;
struct rde_rib *rr;
struct pollfdpfd[POLL_MAX];
time_t timeout;
@@ -125,8 +124,6 @@ main(int argc, char *argv[])
if (saved_argv0 == NULL)
saved_argv0 = "bgpd";
- peer_l = NULL;
-
while ((ch = getopt(argc, argv, "cdD:f:nRSv")) != -1) {
switch (ch) {
case 'c':
@@ -169,20 +166,14 @@ main(int argc, char *argv[])
usage();
if (cmd_opts & BGPD_OPT_NOACTION) {
- conf = new_config();
- if (parse_config(conffile, conf, _l))
+ if ((conf = parse_config(conffile, NULL)) == NULL)
exit(1);
if (cmd_opts & BGPD_OPT_VERBOSE)
- print_config(conf, , >networks, peer_l,
- conf->filters, conf->mrt, >l3vpns);
+ print_config(conf, );
else
fprintf(stderr, "configuration OK\n");
- while ((p = peer_l) != NULL) {
- peer_l = p->next;
- free(p);
- }
while ((rr = SIMPLEQ_FIRST()) != NULL) {
SIMPLEQ_REMOVE_HEAD(, entry);
free(rr);
@@ -261,7 +252,7 @@ BROKEN if (pledge("stdio rpath wpath cpa
if (imsg_send_sockets(ibuf_se, ibuf_rde))
fatal("could not establish imsg links");
conf = new_config();
- quit = reconfigure(conffile, conf, _l);
+ quit = reconfigure(conffile, conf);
if (pftable_clear_all() != 0)
quit = 1;
@@ -317,7 +308,7 @@ BROKEN if (pledge("stdio rpath wpath cpa
u_int error;
reconfig = 0;
- switch (reconfigure(conffile, conf, _l)) {
+ switch (reconfigure(conffile, conf)) {
case -1:/* fatal error */
quit = 1;
break;
@@ -358,10 +349,6 @@ BROKEN if (pledge("stdio rpath wpath cpa
ibuf_rde = NULL;
}
- while ((p = peer_l) != NULL) {
- peer_l = p->next;
- free(p);
- }
while ((rr = SIMPLEQ_FIRST()) != NULL) {
SIMPLEQ_REMOVE_HEAD(, entry);
free(rr);
@@ -451,8 +438,9 @@ send_filterset(struct imsgbuf *i, struct
}
int
-reconfigure(char *conffile, struct bgpd_config *conf, struct peer **peer_l)
+reconfigure(char *conffile, struct bgpd_config *conf)
{
+ struct bgpd_config *new_conf;
struct peer *p;
struct filter_rule *r;
struct listen_addr *la;
@@ -469,12 +457,13 @@ reconfigure(char *conffile, struct bgpd_
reconfpending = 2; /* one per child */
log_info("rereading config");
- if (parse_config(conffile, conf, peer_l)) {
+ if ((new_conf = parse_config(conffile, >peers)) == NULL) {
log_warnx("config file %s has errors, not reloading",
conffile);
reconfpending = 0;
return (1);
}
+ merge_config(conf, new_conf);
if (prepare_listeners(conf) == -1) {
reconfpending = 0;
@@ -524,7 +513,7 @@ reconfigure(char *conffile, struct bgpd_
}
/* send peer list to the SE */
- for (p = *peer_l; p != NULL; p = p->next) {
+ TAILQ_FOREACH(p, >peers, entry) {
if (imsg_compose(ibuf_se,
Re: vmd/vmctl: improve VM name checks/error handling
On Sun, Mar 17, 2019 at 01:07:23AM +0100, Klemens Nanni wrote: > On Sat, Mar 16, 2019 at 11:41:02PM +, Jason McIntyre wrote: > > i don;t understand why you special case "id" in a separate paragraph. > Specifying an ID is valid only if you want to start an existing VM. > You cannot create new VMs using a numerical name, that is an ID. This > limitation is the point I wanted to clarify in the first place. > > Without the separate paragraph, this information is lost and `id | name' > could just be `id' again. But as shown in one of my previous mails, > something like `vmctl start 60 ...' to create a new VM called "60" is > not possible and leads to non-obvious errors, hence my attempt to > differentiate between those cases. > > > just document "name" and "id" as normal arguments. > That's what I just did, no? > > > within the "start" command it would be consistent, but within the page > > less so. i think this should be fixed wholesale, in a separate diff. > Sure. > ah, i missed the distinction also. in that case i'm fine with the diff. i would suggest one tweak, but it's up to you to decide if it reads better. > +Start a new VM > +.Ar name > +with the specified parameters. > +An existing VM may be referenced by its > +.Ar id . i'd be tempted to phrase it: Start a new VM .Ar name with the specified parameters. An existing VM may be started by referencing its .Ar id . jmc
