Re: route rmx_expire time_t
On Fri, Jul 19, 2013 at 07:41:41PM +0200, Alexander Bluhm wrote: > Hi, > > For 64 bit time_t the routing message rmx_expire field has to be > changed from u_int to int64_t. I will do that after ABI unlock. > > I would like to prepare the /sbin/route source for this change. > > ok? I was thinking of making rmx_expire a relative time on the socket instead of an absolute timestamp (against a non monotonic time source). -- :wq Claudio
Re: Allwinner wip
On 20/07/13(Sat) 14:10, Artturi Alm wrote: > Hi, > > work-in-progress-quality 'port' to add support for Allwinner A10, tested > on cubieboard only. Nice work. For what I've seen this port is really similar to the beagle one. Do you think it's possible to merge your work into this port or is there any technical issue? M.
Re: Allwinner wip
Am 20.07.2013 um 14:20 schrieb Martin Pieuchot : > On 20/07/13(Sat) 14:10, Artturi Alm wrote: >> Hi, >> >> work-in-progress-quality 'port' to add support for Allwinner A10, tested >> on cubieboard only. > > Nice work. For what I've seen this port is really similar to the beagle > one. Do you think it's possible to merge your work into this port or is > there any technical issue? > > M. > I guess the biggest "issue" would be the load address, which currently is statically set in the kernel config. Sure, we could add a new config file for that SoC, but I'd rather not put multiple SoCs into the beagle/omap SoC port. I'm working on a generic arm(v7) arch, but that'll still take some time.
Re: Stairstep mouse motion
On Mon, Jul 08, 2013 at 08:26:56PM +0300, Henri Kemppainen wrote:
> > > I do fear that with some devices your patch will collapse too many
> > > events and make it harder to follow small radius curves.
> >
> > Right, I did not consider this case. If this is a problem, perhaps
> > the code could be changed to only collapse a pair of DELTA_X and
> > DELTA_Y events, but never more than that. This way it might still
> > incorrectly merge two independent motions along the axes into one
> > diagonal motion, but I would expect that to be rare, and the deltas
> > to be so small that it has very little impact on anything.
>
> Here's a diff that does just that. If ws receives more than one
> delta along an axis, it will not sum these; each will go in a separate
> event. But if it gets an X delta followed by an Y delta (or vice versa),
> these will be combined into a single event.
I've committed this patch. Thanks again for the contribution.
>
> Index: xenocara/driver/xf86-input-ws/src/ws.c
> ===
> RCS file: /cvs/xenocara/driver/xf86-input-ws/src/ws.c,v
> retrieving revision 1.57
> diff -u -p -r1.57 ws.c
> --- xenocara/driver/xf86-input-ws/src/ws.c8 Jul 2012 14:22:03 -
> 1.57
> +++ xenocara/driver/xf86-input-ws/src/ws.c8 Jul 2013 17:12:27 -
> @@ -474,7 +474,7 @@ wsReadInput(InputInfoPtr pInfo)
> {
> WSDevicePtr priv = (WSDevicePtr)pInfo->private;
> static struct wscons_event eventList[NUMEVENTS];
> - int n, c;
> + int n, c, dx, dy;
> struct wscons_event *event = eventList;
> unsigned char *pBuf;
>
> @@ -488,10 +488,11 @@ wsReadInput(InputInfoPtr pInfo)
> if (n == 0)
> return;
>
> + dx = dy = 0;
> n /= sizeof(struct wscons_event);
> while (n--) {
> int buttons = priv->lastButtons;
> - int dx = 0, dy = 0, dz = 0, dw = 0, ax = 0, ay = 0;
> + int newdx = 0, newdy = 0, dz = 0, dw = 0, ax = 0, ay = 0;
> int zbutton = 0, wbutton = 0;
>
> switch (event->type) {
> @@ -506,11 +507,17 @@ wsReadInput(InputInfoPtr pInfo)
> buttons));
> break;
> case WSCONS_EVENT_MOUSE_DELTA_X:
> - dx = event->value;
> + if (!dx)
> + dx = event->value;
> + else
> + newdx = event->value;
> DBG(4, ErrorF("Relative X %d\n", event->value));
> break;
> case WSCONS_EVENT_MOUSE_DELTA_Y:
> - dy = -event->value;
> + if (!dy)
> + dy = -event->value;
> + else
> + newdy = -event->value;
> DBG(4, ErrorF("Relative Y %d\n", event->value));
> break;
> case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
> @@ -548,14 +555,20 @@ wsReadInput(InputInfoPtr pInfo)
> }
> ++event;
>
> - if (dx || dy) {
> - if (wsWheelEmuFilterMotion(pInfo, dx, dy))
> + if ((newdx || newdy) || ((dx || dy) &&
> + event->type != WSCONS_EVENT_MOUSE_DELTA_X &&
> + event->type != WSCONS_EVENT_MOUSE_DELTA_Y)) {
> + int tmpx = dx, tmpy = dy;
> + dx = newdx;
> + dy = newdy;
> +
> + if (wsWheelEmuFilterMotion(pInfo, tmpx, tmpy))
> continue;
>
> /* relative motion event */
> DBG(3, ErrorF("postMotionEvent dX %d dY %d\n",
> - dx, dy));
> - xf86PostMotionEvent(pInfo->dev, 0, 0, 2, dx, dy);
> + tmpx, tmpy));
> + xf86PostMotionEvent(pInfo->dev, 0, 0, 2, tmpx, tmpy);
> }
> if (dz && priv->Z.negative != WS_NOMAP
> && priv->Z.positive != WS_NOMAP) {
> @@ -583,9 +596,9 @@ wsReadInput(InputInfoPtr pInfo)
> ay = tmp;
> }
> if (ax) {
> - dx = ax - priv->old_ax;
> + int xdelta = ax - priv->old_ax;
> priv->old_ax = ax;
> - if (wsWheelEmuFilterMotion(pInfo, dx, 0))
> + if (wsWheelEmuFilterMotion(pInfo, xdelta, 0))
> continue;
>
> /* absolute position event */
> @@ -593,15 +606,24 @@ wsReadInput(InputInfoPtr pInfo)
> xf86PostMotionEvent(pInfo->dev, 1, 0, 1, ax);
> }
> if (ay) {
> - dy = ay - priv->old_ay;
> + int ydelta = ay - priv->old_ay;
> priv->old_ay = ay;
> - if (wsWheel
Re: Allwinner wip
On 07/20/13 15:20, Martin Pieuchot wrote: On 20/07/13(Sat) 14:10, Artturi Alm wrote: Hi, work-in-progress-quality 'port' to add support for Allwinner A10, tested on cubieboard only. Nice work. For what I've seen this port is really similar to the beagle one. Do you think it's possible to merge your work into this port or is there any technical issue? M. That was my initial suggestion to Patrick, but I agree with him that having separate configs is not the way to go. This might also be beneficial if support for Allwinner A20 is added, going MP in allwinner-arch alone without possibly having so many Cortex-A9(pandaboard es) vs Cortex-A7(cubieboard2 w/A20 chip) issues to solve, this is purely speculation thought, i have not looked up on what kind of differences there is, nor if they would be at '/arch/arm-level' anyway. Inspired by Patrick's question about timer frequency, i found what was missing from awtimer.c, and with USELOWSPEEDOSC + related changes, times are finally reported correctly :) I was also given a possible direction to go with uart problems, so the horrible comdiff can be dropped i think, this is nr1 on my todo. i think i need to rework all the diffs outside arch/allwinner(including those that i did not send as they are not useful for anything as is) too, as i realized i had not rebuilt /usr/cross/allwinner as often as i updated /usr/src and it seems not to build the cross-env for me anymore, will sort this out with clean install or something after uart is working and the code is backed up somewhere before even trying native compilation. if anyone is really going to give it a try soonish, ask for current copy off list, as anything i could send now is most likely old by tomorrow morning. -Artturi
SSH_ASKPASS manpage clarification
This is an attempt to make the ssh-* man pages more exact regarding SSH_ASKPASS, when used for ssh-agent key confirmation. The point I'm making is that the relevant SSH_ASKPASS environment variable is not that of ssh-add(1) (apart from when ssh-add is actually asking for a passphrase). On a sidenote, I think I'd prefer a 'SSH_CONFIRM' variable or somesuch (falling back to SSH_ASKPASS), but maybe we don't want to pollute the environment any further. /Alexander Index: ssh-add.1 === RCS file: /cvs/src/usr.bin/ssh/ssh-add.1,v retrieving revision 1.58 diff -u -p -r1.58 ssh-add.1 --- ssh-add.1 3 Dec 2012 08:33:02 - 1.58 +++ ssh-add.1 21 Jul 2013 01:09:49 - @@ -84,14 +84,10 @@ to work. The options are as follows: .Bl -tag -width Ds .It Fl c -Indicates that added identities should be subject to confirmation before +Indicates that +.Xr ssh-agent 1 +should ask for confirmation before added identities are being used for authentication. -Confirmation is performed by the -.Ev SSH_ASKPASS -program mentioned below. -Successful confirmation is signaled by a zero exit status from the -.Ev SSH_ASKPASS -program, rather than text entered into the requester. .It Fl D Deletes all identities from the agent. .It Fl d Index: ssh-agent.1 === RCS file: /cvs/src/usr.bin/ssh/ssh-agent.1,v retrieving revision 1.53 diff -u -p -r1.53 ssh-agent.1 --- ssh-agent.1 21 Nov 2010 01:01:13 - 1.53 +++ ssh-agent.1 21 Jul 2013 01:09:49 - @@ -161,6 +161,18 @@ Later .Xr ssh 1 looks at these variables and uses them to establish a connection to the agent. .Pp +If confirmation before using a key is requested by +.Xr ssh-add 1 , +it is performed by the program specified in the +.Ev SSH_ASKPASS +environment variable, or +.Xr ssh-askpass 1 +if +.Ev SSH_ASKPASS +is not set. +Successful confirmation is signaled by a zero exit status, and that the +first line of the program's output is empty or the string "yes". +.Pp The agent will never send a private key over its request channel. Instead, operations that require a private key will be performed by the agent, and the result will be returned to the requester. Index: ssh_config.5 === RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.166 diff -u -p -r1.166 ssh_config.5 --- ssh_config.527 Jun 2013 14:05:37 - 1.166 +++ ssh_config.521 Jul 2013 01:09:49 - @@ -286,7 +286,7 @@ will cause ssh to listen for control connections, but require confirmation using the .Ev SSH_ASKPASS program before they are accepted (see -.Xr ssh-add 1 +.Xr ssh-agent 1 for details). If the .Cm ControlPath
Re: SSH_ASKPASS manpage clarification
Hi, Couple of comments inline. On Sun, Jul 21, 2013 at 03:16:28AM +0200, Alexander Hall wrote: > This is an attempt to make the ssh-* man pages more exact regarding > SSH_ASKPASS, when used for ssh-agent key confirmation. > > The point I'm making is that the relevant SSH_ASKPASS environment > variable is not that of ssh-add(1) (apart from when ssh-add is actually > asking for a passphrase). > > On a sidenote, I think I'd prefer a 'SSH_CONFIRM' variable or somesuch > (falling back to SSH_ASKPASS), but maybe we don't want to pollute the > environment any further. > > /Alexander > > > Index: ssh-add.1 > === > RCS file: /cvs/src/usr.bin/ssh/ssh-add.1,v > retrieving revision 1.58 > diff -u -p -r1.58 ssh-add.1 > --- ssh-add.1 3 Dec 2012 08:33:02 - 1.58 > +++ ssh-add.1 21 Jul 2013 01:09:49 - > @@ -84,14 +84,10 @@ to work. > The options are as follows: > .Bl -tag -width Ds > .It Fl c > -Indicates that added identities should be subject to confirmation before > +Indicates that > +.Xr ssh-agent 1 > +should ask for confirmation before added identities are > being used for authentication. ^ Zap "being" from above. > -Confirmation is performed by the > -.Ev SSH_ASKPASS > -program mentioned below. > -Successful confirmation is signaled by a zero exit status from the > -.Ev SSH_ASKPASS > -program, rather than text entered into the requester. > .It Fl D > Deletes all identities from the agent. > .It Fl d > Index: ssh-agent.1 > === > RCS file: /cvs/src/usr.bin/ssh/ssh-agent.1,v > retrieving revision 1.53 > diff -u -p -r1.53 ssh-agent.1 > --- ssh-agent.1 21 Nov 2010 01:01:13 - 1.53 > +++ ssh-agent.1 21 Jul 2013 01:09:49 - > @@ -161,6 +161,18 @@ Later > .Xr ssh 1 > looks at these variables and uses them to establish a connection to the > agent. > .Pp > +If confirmation before using a key is requested by > +.Xr ssh-add 1 , > +it is performed by the program specified in the > +.Ev SSH_ASKPASS > +environment variable, or > +.Xr ssh-askpass 1 > +if > +.Ev SSH_ASKPASS > +is not set. > +Successful confirmation is signaled by a zero exit status, and that the Maybe drop the "that" from above. > +first line of the program's output is empty or the string "yes". > +.Pp However, the sentence still reads awkwardly. Are you trying to say the requirement is: if (an_exit_status == 0 && (output_string == "" || output_string == "yes")) If so, maybe a better wording would be: Successful confirmation is signaled by a zero exit status, and the first line of the program's output SHOULD be either empty or the string "yes." --patrick > The agent will never send a private key over its request channel. > Instead, operations that require a private key will be performed > by the agent, and the result will be returned to the requester. > Index: ssh_config.5 > === > RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v > retrieving revision 1.166 > diff -u -p -r1.166 ssh_config.5 > --- ssh_config.5 27 Jun 2013 14:05:37 - 1.166 > +++ ssh_config.5 21 Jul 2013 01:09:49 - > @@ -286,7 +286,7 @@ will cause ssh > to listen for control connections, but require confirmation using the > .Ev SSH_ASKPASS > program before they are accepted (see > -.Xr ssh-add 1 > +.Xr ssh-agent 1 > for details). > If the > .Cm ControlPath >
