Re: SSLHonorCipherOrder for OpenBSD's httpd
On Mon, Jul 08, 2013 at 07:06:43AM +0200, Otto Moerbeek wrote: > I think you missed the renogiate case. Anyway, I posted almost the > same diff some time ago. You're right -- renegotiate case was missed. Your patch from April looks fine to me. It would be beneficial to have it committed. Thanks
Re: SSLHonorCipherOrder for OpenBSD's httpd
On Sun, Jul 07, 2013 at 08:18:18PM -0700, Aaron Stellman wrote:
> As you may or may not know, SSLHonorCipherOrder is supported since
> apache 2.1.
>
> This diff ports this feature to OpenBSD's httpd. Its effects can be
> tested @ https://www.ssllabs.com/ssltest/analyze.html?d=example.com by
> playing with SSLHonorCipherOrder/SSLCipherSuite directives.
>
> SSLHonorCipherOrder directive is useful for prioritizing certain crypto
> parameters over others. I use to to prioritize GCM over RC4, and RC4
> over CBC based ciphers to reduce chance of BEAST attack.
>
> It's documented @
> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder
>
> This diff is adapted from r103832 @
> http://svn.apache.org/repos/asf/httpd (subversion)
>
> Thanks
I think you missed the renogiate case. Anyway, I posted almost the
same diff some time ago.
-Otto
> Index: usr.sbin/httpd//src/modules/ssl/mod_ssl.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/mod_ssl.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 mod_ssl.c
> --- usr.sbin/httpd//src/modules/ssl/mod_ssl.c 14 Oct 2007 15:12:59 -
> 1.10
> +++ usr.sbin/httpd//src/modules/ssl/mod_ssl.c 8 Jul 2013 03:08:27 -
> @@ -158,6 +158,8 @@ static command_rec ssl_config_cmds[] = {
> AP_SRV_CMD(Protocol, RAW_ARGS,
> "Enable or disable various SSL protocols"
> "(`[+-][SSLv2|SSLv3|TLSv1] ...' - see manual)")
> +AP_SRV_CMD(HonorCipherOrder, FLAG,
> +"Use the server's cipher ordering preference")
>
> #ifdef SSL_EXPERIMENTAL_PROXY
> /*
> Index: usr.sbin/httpd//src/modules/ssl/mod_ssl.h
> ===
> RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/mod_ssl.h,v
> retrieving revision 1.21
> diff -u -p -r1.21 mod_ssl.h
> --- usr.sbin/httpd//src/modules/ssl/mod_ssl.h 4 Apr 2006 08:51:28 -
> 1.21
> +++ usr.sbin/httpd//src/modules/ssl/mod_ssl.h 8 Jul 2013 03:08:27 -
> @@ -514,6 +514,7 @@ typedef struct {
> char*szCACertificateFile;
> char*szLogFile;
> char*szCipherSuite;
> +BOOL cipher_server_pref;
> FILE*fileLogFile;
> int nLogLevel;
> int nVerifyDepth;
> @@ -597,6 +598,7 @@ const char *ssl_cmd_SSLCACertificatePat
> const char *ssl_cmd_SSLCACertificateFile(cmd_parms *, SSLDirConfigRec *,
> char *);
> const char *ssl_cmd_SSLCARevocationPath(cmd_parms *, SSLDirConfigRec *,
> char *);
> const char *ssl_cmd_SSLCARevocationFile(cmd_parms *, SSLDirConfigRec *,
> char *);
> +const char *ssl_cmd_SSLHonorCipherOrder(cmd_parms *cmd, void *dcfg, int
> flag);
> const char *ssl_cmd_SSLVerifyClient(cmd_parms *, SSLDirConfigRec *, char *);
> const char *ssl_cmd_SSLVerifyDepth(cmd_parms *, SSLDirConfigRec *, char *);
> const char *ssl_cmd_SSLSessionCache(cmd_parms *, char *, char *);
> Index: usr.sbin/httpd//src/modules/ssl/ssl_engine_config.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/ssl_engine_config.c,v
> retrieving revision 1.19
> diff -u -p -r1.19 ssl_engine_config.c
> --- usr.sbin/httpd//src/modules/ssl/ssl_engine_config.c 27 May 2008
> 10:17:24 - 1.19
> +++ usr.sbin/httpd//src/modules/ssl/ssl_engine_config.c 8 Jul 2013
> 03:08:27 -
> @@ -208,6 +208,7 @@ void *ssl_config_server_create(pool *p,
> sc->szCARevocationPath = NULL;
> sc->szCARevocationFile = NULL;
> sc->pRevocationStore = NULL;
> +sc->cipher_server_pref = UNSET;
>
> #ifdef SSL_EXPERIMENTAL_PROXY
> sc->nProxyVerifyDepth = UNSET;
> @@ -264,6 +265,7 @@ void *ssl_config_server_merge(pool *p, v
> cfgMerge(szCARevocationPath, NULL);
> cfgMerge(szCARevocationFile, NULL);
> cfgMerge(pRevocationStore, NULL);
> +cfgMergeBool(cipher_server_pref);
>
> for (i = 0; i < SSL_AIDX_MAX; i++) {
> cfgMergeString(szPublicCertFile[i]);
> @@ -540,6 +542,17 @@ const char *ssl_cmd_SSLCipherSuite(
> else
> dc->szCipherSuite = arg;
> return NULL;
> +}
> +
> +const char *ssl_cmd_SSLHonorCipherOrder(cmd_parms *cmd, void *dcfg, int flag)
> +{
> +#ifdef SSL_OP_CIPHER_SERVER_PREFERENCE
> +SSLSrvConfigRec *sc = mySrvConfig(cmd->server);
> +sc->cipher_server_pref = flag?TRUE:FALSE;
> +return NULL;
> +#else
> +return "SSLHonorCiperOrder unsupported; not implemented by the SSL
> library";
> +#endif
> }
>
> const char *ssl_cmd_SSLCertificateFile(
> Index: usr.sbin/httpd//src/modules/ssl/ssl_engine_init.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/ssl_engine_init.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 ssl_engine_init.c
> --- usr.sbin/httpd//src/modules/ssl/ssl_engine_init.c 7 Jul 2012 17:08:17
>
Re: SSLHonorCipherOrder for OpenBSD's httpd
On Sun, Jul 07, 2013 at 08:40:52PM -0700, Aaron Stellman wrote: > On Mon, Jul 08, 2013 at 05:30:22AM +0200, J??r??mie Courr??ges-Anglas wrote: > > Otto Moerbeek had already done work about this, but no one commented on > > the mailing-list: http://marc.info/?l=openbsd-tech&m=136670100711787&w=2 > > I am sorry I've missed his earlier email. > > > > This diff is adapted from r103832 @ > > > http://svn.apache.org/repos/asf/httpd (subversion) > > > > Does that mean that the code is constrained by the Apache 2.0 licence? > > I believe so -- I apologize if that's not acceptable for OpenBSD src. I believe there's very little copyrightable in this. It's basically switching on an openssl option. -Otto
Re: base apache and HonorCipherOrder
On Sun, 7 Jul 2013, Aaron Stellman wrote: > On Tue, Apr 23, 2013 at 09:08:19AM +0200, Otto Moerbeek wrote: > > If there is any interest, I might add the manual stuff, get ok's and > > commit it. > > I find it useful to have SSLHonorCipherOrder in OpenBSD's apache. More than that, AFAIK it is necessary to mitigate some of the TLS crypto attacks. IMO it is well worth having. It would also be good if someone could make a patch to enable ECDHE cipher suites in Apache-1.x. This nginx patch is a good reference to what needs to be done: http://hg.nginx.org/nginx/rev/0832a6997227 -d
Re: base apache and HonorCipherOrder
On Tue, Apr 23, 2013 at 09:08:19AM +0200, Otto Moerbeek wrote: > If there is any interest, I might add the manual stuff, get ok's and > commit it. I find it useful to have SSLHonorCipherOrder in OpenBSD's apache.
Re: SSLHonorCipherOrder for OpenBSD's httpd
On Mon, Jul 08, 2013 at 05:30:22AM +0200, J??r??mie Courr??ges-Anglas wrote: > Otto Moerbeek had already done work about this, but no one commented on > the mailing-list: http://marc.info/?l=openbsd-tech&m=136670100711787&w=2 I am sorry I've missed his earlier email. > > This diff is adapted from r103832 @ > > http://svn.apache.org/repos/asf/httpd (subversion) > > Does that mean that the code is constrained by the Apache 2.0 licence? I believe so -- I apologize if that's not acceptable for OpenBSD src.
Re: SSLHonorCipherOrder for OpenBSD's httpd
Aaron Stellman writes: > As you may or may not know, SSLHonorCipherOrder is supported since > apache 2.1. > > This diff ports this feature to OpenBSD's httpd. Its effects can be > tested @ https://www.ssllabs.com/ssltest/analyze.html?d=example.com by > playing with SSLHonorCipherOrder/SSLCipherSuite directives. Otto Moerbeek had already done work about this, but no one commented on the mailing-list: http://marc.info/?l=openbsd-tech&m=136670100711787&w=2 > SSLHonorCipherOrder directive is useful for prioritizing certain crypto > parameters over others. I use to to prioritize GCM over RC4, and RC4 > over CBC based ciphers to reduce chance of BEAST attack. > > It's documented @ > http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder > > This diff is adapted from r103832 @ > http://svn.apache.org/repos/asf/httpd (subversion) Does that mean that the code is constrained by the Apache 2.0 licence? -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
SSLHonorCipherOrder for OpenBSD's httpd
As you may or may not know, SSLHonorCipherOrder is supported since
apache 2.1.
This diff ports this feature to OpenBSD's httpd. Its effects can be
tested @ https://www.ssllabs.com/ssltest/analyze.html?d=example.com by
playing with SSLHonorCipherOrder/SSLCipherSuite directives.
SSLHonorCipherOrder directive is useful for prioritizing certain crypto
parameters over others. I use to to prioritize GCM over RC4, and RC4
over CBC based ciphers to reduce chance of BEAST attack.
It's documented @
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder
This diff is adapted from r103832 @
http://svn.apache.org/repos/asf/httpd (subversion)
Thanks
Index: usr.sbin/httpd//src/modules/ssl/mod_ssl.c
===
RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/mod_ssl.c,v
retrieving revision 1.10
diff -u -p -r1.10 mod_ssl.c
--- usr.sbin/httpd//src/modules/ssl/mod_ssl.c 14 Oct 2007 15:12:59 - 1.10
+++ usr.sbin/httpd//src/modules/ssl/mod_ssl.c 8 Jul 2013 03:08:27 -
@@ -158,6 +158,8 @@ static command_rec ssl_config_cmds[] = {
AP_SRV_CMD(Protocol, RAW_ARGS,
"Enable or disable various SSL protocols"
"(`[+-][SSLv2|SSLv3|TLSv1] ...' - see manual)")
+AP_SRV_CMD(HonorCipherOrder, FLAG,
+"Use the server's cipher ordering preference")
#ifdef SSL_EXPERIMENTAL_PROXY
/*
Index: usr.sbin/httpd//src/modules/ssl/mod_ssl.h
===
RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/mod_ssl.h,v
retrieving revision 1.21
diff -u -p -r1.21 mod_ssl.h
--- usr.sbin/httpd//src/modules/ssl/mod_ssl.h 4 Apr 2006 08:51:28 - 1.21
+++ usr.sbin/httpd//src/modules/ssl/mod_ssl.h 8 Jul 2013 03:08:27 -
@@ -514,6 +514,7 @@ typedef struct {
char*szCACertificateFile;
char*szLogFile;
char*szCipherSuite;
+BOOL cipher_server_pref;
FILE*fileLogFile;
int nLogLevel;
int nVerifyDepth;
@@ -597,6 +598,7 @@ const char *ssl_cmd_SSLCACertificatePat
const char *ssl_cmd_SSLCACertificateFile(cmd_parms *, SSLDirConfigRec *, char *);
const char *ssl_cmd_SSLCARevocationPath(cmd_parms *, SSLDirConfigRec *, char *);
const char *ssl_cmd_SSLCARevocationFile(cmd_parms *, SSLDirConfigRec *, char *);
+const char *ssl_cmd_SSLHonorCipherOrder(cmd_parms *cmd, void *dcfg, int flag);
const char *ssl_cmd_SSLVerifyClient(cmd_parms *, SSLDirConfigRec *, char *);
const char *ssl_cmd_SSLVerifyDepth(cmd_parms *, SSLDirConfigRec *, char *);
const char *ssl_cmd_SSLSessionCache(cmd_parms *, char *, char *);
Index: usr.sbin/httpd//src/modules/ssl/ssl_engine_config.c
===
RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/ssl_engine_config.c,v
retrieving revision 1.19
diff -u -p -r1.19 ssl_engine_config.c
--- usr.sbin/httpd//src/modules/ssl/ssl_engine_config.c 27 May 2008 10:17:24 - 1.19
+++ usr.sbin/httpd//src/modules/ssl/ssl_engine_config.c 8 Jul 2013 03:08:27 -
@@ -208,6 +208,7 @@ void *ssl_config_server_create(pool *p,
sc->szCARevocationPath = NULL;
sc->szCARevocationFile = NULL;
sc->pRevocationStore = NULL;
+sc->cipher_server_pref = UNSET;
#ifdef SSL_EXPERIMENTAL_PROXY
sc->nProxyVerifyDepth = UNSET;
@@ -264,6 +265,7 @@ void *ssl_config_server_merge(pool *p, v
cfgMerge(szCARevocationPath, NULL);
cfgMerge(szCARevocationFile, NULL);
cfgMerge(pRevocationStore, NULL);
+cfgMergeBool(cipher_server_pref);
for (i = 0; i < SSL_AIDX_MAX; i++) {
cfgMergeString(szPublicCertFile[i]);
@@ -540,6 +542,17 @@ const char *ssl_cmd_SSLCipherSuite(
else
dc->szCipherSuite = arg;
return NULL;
+}
+
+const char *ssl_cmd_SSLHonorCipherOrder(cmd_parms *cmd, void *dcfg, int flag)
+{
+#ifdef SSL_OP_CIPHER_SERVER_PREFERENCE
+SSLSrvConfigRec *sc = mySrvConfig(cmd->server);
+sc->cipher_server_pref = flag?TRUE:FALSE;
+return NULL;
+#else
+return "SSLHonorCiperOrder unsupported; not implemented by the SSL library";
+#endif
}
const char *ssl_cmd_SSLCertificateFile(
Index: usr.sbin/httpd//src/modules/ssl/ssl_engine_init.c
===
RCS file: /cvs/src/usr.sbin/httpd/src/modules/ssl/ssl_engine_init.c,v
retrieving revision 1.28
diff -u -p -r1.28 ssl_engine_init.c
--- usr.sbin/httpd//src/modules/ssl/ssl_engine_init.c 7 Jul 2012 17:08:17 - 1.28
+++ usr.sbin/httpd//src/modules/ssl/ssl_engine_init.c 8 Jul 2013 03:08:27 -
@@ -589,6 +589,16 @@ void ssl_init_ConfigureServer(server_rec
SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3);
if (!(sc->nProtocol & SSL_PROTOCOL_TLSV1))
SSL_CTX_set_options(ctx, SSL_OP_NO_TLSv1);
+
+#ifdef SSL_OP_CIPHER_SERVER_PREFERENCE
+{
+SSLSrvConfigRec *sc = mySrvConfig(s);
+if (sc->cipher_server_pref ==
remove obsolete variables NKMEMPAGES_MIN/ NKMEMPAGES_MAX
Index: regress/usr.bin/diff/t8.2
===
RCS file: /cvs/src/regress/usr.bin/diff/t8.2,v
retrieving revision 1.1
diff -u -p -r1.1 t8.2
--- regress/usr.bin/diff/t8.2 17 Jul 2003 21:04:04 - 1.1
+++ regress/usr.bin/diff/t8.2 7 Jul 2013 21:54:34 -
@@ -58,18 +58,6 @@ struct vm_map *kmem_map = NULL;
#endif
intnkmempages = NKMEMPAGES;
-/*
- * Defaults for lower- and upper-bounds for the kmem_map page count.
- * Can be overridden by kernel config options.
- */
-#ifndefNKMEMPAGES_MIN
-#defineNKMEMPAGES_MIN NKMEMPAGES_MIN_DEFAULT
-#endif
-
-#ifndef NKMEMPAGES_MAX
-#defineNKMEMPAGES_MAX NKMEMPAGES_MAX_DEFAULT
-#endif
-
struct kmembuckets bucket[MINBUCKET + 16];
struct kmemstats kmemstats[M_LAST];
struct kmemusage *kmemusage;
@@ -434,8 +422,6 @@ free(addr, type)
void
kmeminit_nkmempages()
{
- int npages;
-
if (nkmempages != 0) {
/*
* It's already been set (by us being here before, or
@@ -446,22 +432,13 @@ kmeminit_nkmempages()
/*
* We use the following (simple) formula:
-*
* - Starting point is physical memory / 4.
-*
-* - Clamp it down to NKMEMPAGES_MAX.
-*
-* - Round it up to NKMEMPAGES_MIN.
+* - If that is excessive, limit it to NKMEMPAGES_MAX_DEFAULT.
*/
- npages = physmem / 4;
-
- if (npages > NKMEMPAGES_MAX)
- npages = NKMEMPAGES_MAX;
-
- if (npages < NKMEMPAGES_MIN)
- npages = NKMEMPAGES_MIN;
+ nkmempages = physmem / 4;
- nkmempages = npages;
+ if (nkmempages > NKMEMPAGES_MAX_DEFAULT)
+ nkmempages = NKMEMPAGES_MAX_DEFAULT;
}
/*
Index: sys/kern/kern_malloc.c
===
RCS file: /cvs/src/sys/kern/kern_malloc.c,v
retrieving revision 1.102
diff -u -p -r1.102 kern_malloc.c
--- sys/kern/kern_malloc.c 4 Jul 2013 17:35:52 - 1.102
+++ sys/kern/kern_malloc.c 7 Jul 2013 21:54:37 -
@@ -85,8 +85,8 @@ struct vm_map *kmem_map = NULL;
#endif
/*
- * Default number of pages in kmem_map. We attempt to calculate this
- * at run-time, but allow it to be either patched or set in the kernel
+ * Default number of pages in kmem_map. We calculate this at
+ * compile-time, but also allow it to be either patched or set in the kernel
* config file.
*/
#ifndef NKMEMPAGES
@@ -94,20 +94,6 @@ struct vm_map *kmem_map = NULL;
#endif
u_int nkmempages = NKMEMPAGES;
-/*
- * Defaults for lower- and upper-bounds for the kmem_map page count.
- * Can be overridden by kernel config options.
- */
-#ifndefNKMEMPAGES_MIN
-#defineNKMEMPAGES_MIN 0
-#endif
-u_int nkmempages_min = 0;
-
-#ifndef NKMEMPAGES_MAX
-#defineNKMEMPAGES_MAX NKMEMPAGES_MAX_DEFAULT
-#endif
-u_int nkmempages_max = 0;
-
struct kmembuckets bucket[MINBUCKET + 16];
#ifdef KMEMSTATS
struct kmemstats kmemstats[M_LAST];
@@ -475,8 +461,6 @@ free(void *addr, int type)
void
kmeminit_nkmempages(void)
{
- u_int npages;
-
if (nkmempages != 0) {
/*
* It's already been set (by us being here before, or
@@ -490,30 +474,14 @@ kmeminit_nkmempages(void)
* the page size may not be known (on sparc GENERIC kernels, for
* example). But we still want the MD code to be able to provide
* better values.
-*/
- if (nkmempages_min == 0)
- nkmempages_min = NKMEMPAGES_MIN;
- if (nkmempages_max == 0)
- nkmempages_max = NKMEMPAGES_MAX;
-
- /*
* We use the following (simple) formula:
-*
* - Starting point is physical memory / 4.
-*
-* - Clamp it down to nkmempages_max.
-*
-* - Round it up to nkmempages_min.
+* - If that is excessive, limit it to NKMEMPAGES_MAX_DEFAULT.
*/
- npages = physmem / 4;
-
- if (npages > nkmempages_max)
- npages = nkmempages_max;
-
- if (npages < nkmempages_min)
- npages = nkmempages_min;
+ nkmempages = physmem / 4;
- nkmempages = npages;
+ if (nkmempages > NKMEMPAGES_MAX_DEFAULT)
+ nkmempages = NKMEMPAGES_MAX_DEFAULT;
}
/*
Re: Stairstep mouse motion
On Sun, Jul 7, 2013 at 12:22 PM, 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.
That is a very cool effect (referring to your image). Having not seen
this issue, I tried drawing a few diagonal lines; this was using the
synaptics touchpad. The lines were pretty smooth looking. Then I
connected a USB mouse and reattempted drawing the diagonal lines.
That's when I see the stair-step effect; still not as wave-like as
yours are.
Just adding a data-point.
--patrick
> 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
>
> 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 7 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;
> case WSCONS_EVENT_MOUSE_DELTA_Y:
> - dy = -event->value;
> + dy -= event->value;
> DBG(4, ErrorF("Relative Y %d\n", event->value));
> break;
> case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
> @@ -548,14 +549,18 @@ wsReadInput(InputInfoPtr pInfo)
> }
> ++event;
>
> - if (dx || dy) {
> - if (wsWheelEmuFilterMotion(pInfo, dx, dy))
> + if ((dx || dy) && event->type != WSCONS_EVENT_MOUSE_DELTA_X &&
> + event->type != WSCONS_EVENT_MOUSE_DELTA_Y) {
> + int tmpx = dx, tmpy = dy;
> + dx = dy = 0;
> +
> + 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 (d
Stairstep mouse motion
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
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 7 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;
case WSCONS_EVENT_MOUSE_DELTA_Y:
- dy = -event->value;
+ dy -= event->value;
DBG(4, ErrorF("Relative Y %d\n", event->value));
break;
case WSCONS_EVENT_MOUSE_ABSOLUTE_X:
@@ -548,14 +549,18 @@ wsReadInput(InputInfoPtr pInfo)
}
++event;
- if (dx || dy) {
- if (wsWheelEmuFilterMotion(pInfo, dx, dy))
+ if ((dx || dy) && event->type != WSCONS_EVENT_MOUSE_DELTA_X &&
+ event->type != WSCONS_EVENT_MOUSE_DELTA_Y) {
+ int tmpx = dx, tmpy = dy;
+ dx = dy = 0;
+
+ 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 +588,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 +598,24 @@ wsReadInp
Re: sendbug(1) & online bug tracking system
On Sun, Jul 07, 2013 at 07:43:53PM +0200, Alexis de BRUYN wrote: > Hi tech@, > > Since the OpenBSD bug tracking system has been shut down, the 4th > paragraph of the sendbug(1) DESCRIPTION is in my opinion not really > relevant as it. > > Could it be adjusted by something like: > > "The status of bug reports can be followed by checking the > b...@openbsd.org mail list archive." as mentionned in > http://www.openbsd.org/query-pr.html ? > > -- > Alexis de BRUYN > fixed, thanks! jmc Index: sendbug.1 === RCS file: /cvs/src/usr.bin/sendbug/sendbug.1,v retrieving revision 1.21 diff -u -r1.21 sendbug.1 --- sendbug.1 12 Aug 2012 17:01:36 - 1.21 +++ sendbug.1 7 Jul 2013 18:16:29 - @@ -53,11 +53,10 @@ Any follow up mail to the PR should keep the same mail subject. .Pp -The bugs database can be queried using the online bug tracking system -available at +The status of bug reports can be followed by checking the +.Mt b...@openbsd.org +mailing list archive available at .Lk http://www.openbsd.org/query-pr.html . -This allows users to search for PRs based on either PR number -or content. .Pp The options are as follows: .Bl -tag -width Ds
sendbug(1) & online bug tracking system
Hi tech@, Since the OpenBSD bug tracking system has been shut down, the 4th paragraph of the sendbug(1) DESCRIPTION is in my opinion not really relevant as it. Could it be adjusted by something like: "The status of bug reports can be followed by checking the b...@openbsd.org mail list archive." as mentionned in http://www.openbsd.org/query-pr.html ? -- Alexis de BRUYN
