Static variables

2013-07-08 Thread Maxime Villard
Hi,
is it normal that in some functions like

tc_ticktock(void)
{
static int count;

if (++count  tc_tick)
return;
count = 0;
tc_windup();
}

the static variables are not initialized?

- kern_tc.c l.547
- kern_resource.c l.499
- kern_sched.c l.106
- subr_extent.c l.130
- ...



Re: Static variables

2013-07-08 Thread Franco Fichtner
Hi Maxime,

On Jul 8, 2013, at 10:40 AM, Maxime Villard rusty...@gmx.fr wrote:

 the static variables are not initialized?

Static variables are always zeroed when not specified otherwise.


Regards,
Franco



Re: Static variables

2013-07-08 Thread Maxime Villard
Le 08/07/2013 11:00, Franco Fichtner a écrit :
 Hi Maxime,
 
 On Jul 8, 2013, at 10:40 AM, Maxime Villard rusty...@gmx.fr wrote:
 
 the static variables are not initialized?
 
 Static variables are always zeroed when not specified otherwise.
 
 
 Regards,
 Franco
 
 

Ah, yes. I didn't know.



Re: Stairstep mouse motion

2013-07-08 Thread Henri Kemppainen
 The issue that input drivers devices need high refresh frequency to be
 able to achieve high-precision freehand drawing is quite well known¹.

Yes.  But the bug here isn't about that.  I think I'll have to elaborate
a little.

When you move the mouse, it will report its motion in an event with a
two-component vector.  Naturally both components must always be present,
otherwise information is lost.  When wsmouse(4) gets such an event,
it will break that event into two separate events, one for the X delta
and another for Y.  This is because the current event structure cannot
contain the deltas for both axes.

Now ws(4) takes these two events and naturally considers them independent
(as there is no metadata to couple them together), and fills in the blanks
by setting one or the other delta to zero.  The result is two orthogonal
vectors which represent a motion your mouse never reported.  Their sum is
the original vector, but the motion they describe is still wrong.

So the problem here is not refresh frequency, precision or anything like
that.  It's just that our data gets effectively mangled and corrupted 
between the two layers.  My diff attempts to reconstruct the original
vector by summing consecutive delta events, but as you noted below, this
can also result in data loss.  The lossless method would involve extending
the ws event structure or adding some metadata (in the form of new events),
or perhaps stuffing both deltas into the value field we have now (this is
lossless only if they fit in 16 bits)..  Interpolation is something I
definitely wouldn't apply here :-)

 I re-did a few experiments with and without your patch on my laptop
 (with the Lenovo track point wihch is a relative device). I could not
 reproduce the waves you're getting in Gimp, but without your patch
 diagonals show indeed larger staircases effects. Under xfig(1) or
 bitmap(1) the difference is much less noticeable. Clearly the
 strategy used by applications to trac mouse motion for freehand
 drawing are not the same.

 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.



Re: Stairstep mouse motion

2013-07-08 Thread Henri Kemppainen
  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.

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.c  8 Jul 2012 14:22:03 -   
1.57
+++ xenocara/driver/xf86-input-ws/src/ws.c  8 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 (wsWheelEmuFilterMotion(pInfo, 0, dy))
+   if (wsWheelEmuFilterMotion(pInfo, 0, ydelta))
continue;
 
/* absolute position event */
DBG(3, 

Re: Static variables

2013-07-08 Thread Matthew Dempsky
On Mon, Jul 8, 2013 at 2:06 AM, Maxime Villard rusty...@gmx.fr wrote:
 Ah, yes. I didn't know.

For what it's worth, this is specified in C99 §6.7.8 (Initializaton)
paragraph 10:

If an object that has static storage duration is not initialized
explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned) zero;
— if it is an aggregate, every member is initialized (recursively)
according to these rules;
— if it is a union, the first named member is initialized (recursively)
according to these rules.

On OpenBSD (and most, if not all, ELF platforms), this is implemented
by assigning these objects into the .bss section, which is initialized
to all zero bytes at program startup, taking advantage of the fact
that all of our platforms represent null pointers and zero values as
sequences of zero bytes.