Re: Update elf(5)
Might be nice to mention that 5.4 'was' the first release that used ELF on all platforms? On Mon, Jul 8, 2013 at 11:16 PM, Simon Kuhnle wrote: > With VAX being an ELF platform, this is no longer true, is it? > > Regards > Simon > > Index: elf.5 > === > RCS file: /cvs/src/share/man/man5/elf.5,v > retrieving revision 1.20 > diff -u -r1.20 elf.5 > --- elf.5 17 Jan 2013 21:54:18 - 1.20 > +++ elf.5 9 Jul 2013 06:14:54 - > @@ -1355,9 +1355,7 @@ > .Sh HISTORY > .Ox > ELF support first appeared in > -.Ox 1.2 , > -although not all supported platforms use it as the native > -binary file format. > +.Ox 1.2 . > ELF in itself first appeared in > .At V . > The ELF format is an adopted standard. >
Update elf(5)
With VAX being an ELF platform, this is no longer true, is it? Regards Simon Index: elf.5 === RCS file: /cvs/src/share/man/man5/elf.5,v retrieving revision 1.20 diff -u -r1.20 elf.5 --- elf.5 17 Jan 2013 21:54:18 - 1.20 +++ elf.5 9 Jul 2013 06:14:54 - @@ -1355,9 +1355,7 @@ .Sh HISTORY .Ox ELF support first appeared in -.Ox 1.2 , -although not all supported platforms use it as the native -binary file format. +.Ox 1.2 . ELF in itself first appeared in .At V . The ELF format is an adopted standard.
Re: Static variables
On Mon, Jul 8, 2013 at 2:06 AM, Maxime Villard 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.
Re: Stairstep mouse motion
> > 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 */
Re: Stairstep mouse motion
> 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
On Sun, Jul 07, 2013 at 10:22:23PM +0300, Henri Kemppainen wrote:
> So I needed to see my thoughts on paper but my desk was so full of stuff
> I couldn't make room for pen and paper. Instead I fired up Gimp, and
> drawing with the mouse worked fine until I realized it's next to impossible
> to draw diagonal lines that look like lines.
>
> Instead of straight lines, I got waves. The faster I draw the mouse, the
> deeper the waves. It looked like diagonal mouse motion generated a pair
> of pointer motion events, one for the X axis and another for Y. And Gimp
> smoothed that stairstep motion, resulting in waves. Xev(1) confirmed my
> hypothesis.
>
> It turns out wsmouse(4) is breaking the mouse input into multiple events.
> This isn't necessarily a bug, since it allows for a very small and simple
> event structure which works without modification as new properties (such
> as button states, axes, etc.) are added.
>
> Now wsmouse generates all the events it can in a loop before waking up
> the process that waits for these events. So on the receiving side (i.e.
> in the xenocara ws(4) driver) we can sum all the consecutive X and Y
> deltas from a single read() before issuing a pointer motion event. This
> eliminates the stairsteps as long as the events generated by wsmouse fit
> in the buffers involved.
>
> Other approaches would be either extending the event structure, or perhaps
> adding a new event type that somehow communicates the intended grouping
> for events that follow/precede (but ugh...). I felt the ws(4) fix was
> the least intrusive, and it appears to work just fine here. What do you
> think?
>
> This image (drawn in Gimp) illustrates the problem. The last two lines
> were drawn with my diff applied.
>
> http://guu.fi/mousebug.png
Thanks for the report and patch.
The issue that input drivers devices need high refresh frequency to be
able to achieve high-precision freehand drawing is quite well known¹.
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.
OTOH, I've always considered that sending many small steps events to
the application, and letting it merge them would generally be better,
even if they come with a too high latency. Having associated
kernel timestamps would help estimating the speed and get better
dynamic interpolation, but the X input driver model doesn't really
make that possible.
So I'd like to see a few more reports of whether that patch helps or
not.
-
¹) For years X has tried to solve this issue by using asynchrous IO (ie a
signal handler for SIGIO) to handle input events as soon as
possible. Unfortunatly even though it sort-of worked, it let way too
much code run in the signal handler itself, and without major
architectural rework, it just can't work 100% reliably, so we ended up
disabling that code by default.
An approach using a separate thread for input was also tried, but the
overhead and complexity of proper locking between display drivers and
input drivers killed that idea too.
>
> 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.c7 Jul 2013 18:33:57 -
> @@ -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 dz = 0, dw = 0, ax = 0, ay = 0;
> int zbutton = 0, wbutton = 0;
>
> switch (event->type) {
> @@ -506,11 +507,11 @@ wsReadInput(InputInfoPtr pInfo)
> buttons));
> break;
> case WSCONS_EVENT_MOUSE_DELTA_X:
> - dx = event->value;
> + dx += event->value;
> DBG(4, ErrorF("Relative X %d\n", event->value));
> break;
Re: Static variables
Le 08/07/2013 11:00, Franco Fichtner a écrit : > Hi Maxime, > > On Jul 8, 2013, at 10:40 AM, Maxime Villard 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: Static variables
Hi Maxime, On Jul 8, 2013, at 10:40 AM, Maxime Villard wrote: > the static variables are not initialized? Static variables are always zeroed when not specified otherwise. Regards, Franco
Static variables
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
- ...
