Re: IR remote control autorepeat / evdev

2011-05-13 Thread Mauro Carvalho Chehab 
Em 12-05-2011 08:05, Peter Hutterer escreveu:
> On Thu, May 12, 2011 at 03:36:47AM +0200, Mauro Carvalho Chehab wrote:
>> Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu:
>>> Em 12-05-2011 02:37, Anssi Hannula escreveu:
>>
 I don't see any other places:
 $ git grep 'REP_PERIOD' .
 dvb/dvb-usb/dvb-usb-remote.c:   input_dev->rep[REP_PERIOD] =
 d->props.rc.legacy.rc_interval;
>>>
>>> Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we
>>> should change it to something like 125ms, for example, as 33ms is too 
>>> short, as it takes up to 114ms for a repeat event to arrive.
>>>
>> IMO, the enclosed patch should do a better job with repeat events, without
>> needing to change rc-core/input/event logic.
>>
>> -
>>
>> Subject: Use a more consistent value for RC repeat period
>> From: Mauro Carvalho Chehab 
>>
>> The default REP_PERIOD is 33 ms. This doesn't make sense for IR's,
>> as, in general, an IR repeat scancode is provided at every 110/115ms,
>> depending on the RC protocol. So, increase its default, to do a
>> better job avoiding ghost repeat events.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>>
>> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
>> index f53f9c6..ee67169 100644
>> --- a/drivers/media/rc/rc-main.c
>> +++ b/drivers/media/rc/rc-main.c
>> @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev)
>>   */
>>  dev->input_dev->rep[REP_DELAY] = 500;
>>  
>> +/*
>> + * As a repeat event on protocols like RC-5 and NEC take as long as
>> + * 110/114ms, using 33ms as a repeat period is not the right thing
>> + * to do.
>> + */
>> +dev->input_dev->rep[REP_PERIOD] = 125;
>> +
>>  path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
>>  printk(KERN_INFO "%s: %s as %s\n",
>>  dev_name(&dev->dev),
> 
> so if I get this right, a XkbSetControls(.. XkbRepeatKeysMask ...) by a
> client to set the repeat rate would provide the same solution - for those
> clients/devices affected. 

Yes, if we preserve the same logic. The above will probably still generate
ghost repeats if the user keeps the IR pressed for a long time, as we're using
a separate timer at the rc-core logic than the one used inside evdev.

> The interesting question is how clients would identify the devices that are
> affected by this (other than trial and error).

That is easy. I've added a logic that detects it on Xorg evdev on some RFC 
patches
I've prepared in the past to allow using a keycode with more than 247 for IR's.
I'll work on a new version for it and submit again when I have some time.
Anyway, I'm enclosing a patch with the old version. 

Basically, GetRCInputs.c file adds a logic that returns a list of input devices
that are Remote Controllers, using rc-core.

This logic inside evdev gets the RC devices and adds a flag identifying them
as such:

+/* Check if the device is a remote controller */
+pRCDevList = GetRCInputDevices(&NumDevices);
+for (i = 0; i < NumDevices; i++) {
+if (!strcmp(device, pRCDevList[i].InputName)) {
+ pEvdev->flags |= EVDEV_RC_EVENTS;
+ break;
+}
+}

Thanks,
Mauro

-

diff --git a/src/GetRCInputs.c b/src/GetRCInputs.c
new file mode 100644
index 000..0e03e3a
--- /dev/null
+++ b/src/GetRCInputs.c
@@ -0,0 +1,358 @@
+/*
+ * Copyright © 2011 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without
+ * fee, provided that the above copyright notice appear in all copies
+ * and that both that copyright notice and this permission notice
+ * appear in supporting documentation, and that the name of Red Hat
+ * not be used in advertising or publicity pertaining to distribution
+ * of the software without specific, written prior permission.  Red
+ * Hat makes no representations about the suitability of this software
+ * for any purpose.  It is provided "as is" without express or implied
+ * warranty.
+ *
+ * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
+ * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
+ * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
+ * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ * Author:
+ * Mauro Carvalho Chehab 
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "evdev.h"
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct UEvents {
+char   *key;
+char   *value;
+struct UEvents *next;
+};
+
+struct SysfsNames  {
+char  *name;
+struct

Re: [PATCH] Delete *-config.h.in entries that are never defined now.

2011-05-13 Thread Daniel Stone 
Hi,

On Thu, May 12, 2011 at 03:21:53PM -0700, Jamey Sharp wrote:
> Various #ifdefs remain that are conditional on _POSIX_SOURCE or
> _XOPEN_SOURCE, and I'm skeptical that any of those are correct, but
> that's a subject for another day.

Most of this is to work around historical libc damage, sadly.

> -/* BSD-compliant source */
> -#undef _BSD_SOURCE
> -
> -/* POSIX-compliant source */
> -#undef _POSIX_SOURCE
> -
> -/* X/Open-compliant source */
> -#undef _XOPEN_SOURCE

And these three.

Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libX11] XCB: Add more friendly error messages for common asserts

2011-05-13 Thread Daniel Stone 
This patch adds more friendly error messages for three common classes of
assertion:
- missed sequence numbers due to being griefed by another thread
- unknown requests in queue due to being griefed by another thread
- extensions dequeuing too much or too little reply data

It adds error messages offering advice (e.g. call XInitThreads() first)
on stderr, but still generates actual assertions.  Hopefully this means
it's a little more Googleable and a little less frightening.

Signed-off-by: Daniel Stone 
---
 src/xcb_io.c |  105 +-
 1 files changed, 89 insertions(+), 16 deletions(-)

diff --git a/src/xcb_io.c b/src/xcb_io.c
index 8930736..4dadc88 100644
--- a/src/xcb_io.c
+++ b/src/xcb_io.c
@@ -15,6 +15,7 @@
 #ifdef HAVE_INTTYPES_H
 #include 
 #endif
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +23,16 @@
 #include 
 #endif
 
+#define throw_thread_fail_assert(_message, _var) { \
+unsigned int _var = 1; \
+fprintf(stderr, "[xcb] " _message "\n"); \
+fprintf(stderr, \
+"Most likely this is a multi-threaded client and XInitThreads " \
+"has not been called\n"); \
+fprintf(stderr, "Aborting, sorry about that.\n"); \
+assert(!_var); \
+}
+
 static void return_socket(void *closure)
 {
Display *dpy = closure;
@@ -51,9 +62,14 @@ static void require_socket(Display *dpy)
 * happens while Xlib does not own the socket.  A
 * complete fix would be to make XCB's public API use
 * 64-bit sequence numbers. */
-   assert(!(sizeof(unsigned long) > sizeof(unsigned int)
-&& dpy->xcb->event_owner == XlibOwnsEventQueue
-&& (sent - dpy->last_request_read >= (UINT64_C(1) << 
32;
+   if ((sizeof(unsigned long) > sizeof(unsigned int) &&
+ dpy->xcb->event_owner == XlibOwnsEventQueue &&
+ (sent - dpy->last_request_read >= (UINT64_C(1) << 32 {
+throw_thread_fail_assert("Sequence number wrapped beyond "
+ "32 bits while Xlib did not own "
+ "the socket",
+ xcb_xlib_seq_number_wrapped);
+}
dpy->xcb->last_flushed = dpy->request = sent;
dpy->bufmax = dpy->xcb->real_bufmax;
}
@@ -125,9 +141,19 @@ static PendingRequest *append_pending_request(Display 
*dpy, unsigned long sequen
node->reply_waiter = 0;
if(dpy->xcb->pending_requests_tail)
{
-   
assert(XLIB_SEQUENCE_COMPARE(dpy->xcb->pending_requests_tail->sequence, <, 
node->sequence));
-   assert(dpy->xcb->pending_requests_tail->next == NULL);
-   dpy->xcb->pending_requests_tail->next = node;
+if 
(XLIB_SEQUENCE_COMPARE(dpy->xcb->pending_requests_tail->sequence,
+  >=, node->sequence))
+{
+throw_thread_fail_assert("Unknown sequence number while "
+ "appending request",
+ xcb_xlib_seq_number_wrapped);
+}
+if (dpy->xcb->pending_requests_tail->next != NULL) {
+throw_thread_fail_assert("Unknown request in queue while "
+ "appending request",
+ xcb_xlib_seq_number_wrapped);
+}
+   dpy->xcb->pending_requests_tail->next = node;
}
else
dpy->xcb->pending_requests = node;
@@ -137,15 +163,30 @@ static PendingRequest *append_pending_request(Display 
*dpy, unsigned long sequen
 
 static void dequeue_pending_request(Display *dpy, PendingRequest *req)
 {
-   assert(req == dpy->xcb->pending_requests);
+   if (req != dpy->xcb->pending_requests)
+{
+throw_thread_fail_assert("Unknown request in queue while "
+ "dequeuing",
+ xcb_xlib_seq_number_wrapped);
+}
dpy->xcb->pending_requests = req->next;
if(!dpy->xcb->pending_requests)
{
-   assert(req == dpy->xcb->pending_requests_tail);
+if (req != dpy->xcb->pending_requests_tail)
+{
+throw_thread_fail_assert("Unknown request in queue while "
+ "dequeuing",
+ xcb_xlib_seq_number_wrapped);
+}
dpy->xcb->pending_requests_tail = NULL;
}
-   else
-   assert(XLIB_SEQUENCE_COMPARE(req->sequence, <, 
dpy->xcb->pending_requests->sequence));
+   else if (XLIB_SEQUENCE_COMPARE(req->sequence, >=,
+   dpy->xcb->pending_requests->seq

[PATCH] bsd: Add support for -novtswitch.

2011-05-13 Thread Cyril Brulebois 
VT switching back to the initial VT is possible in the following case:
  #if defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT)

Make it possible to prevent that from happening if -novtswitch was
passed, which should make the life of display manager developers easier,
especially when it comes to handling multiple users.

X.Org Bug 37174 

Signed-off-by: Cyril Brulebois 
---
 hw/xfree86/os-support/bsd/bsd_init.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

Patch tested on a GNU/kFreeBSD VM, on top of 1.10.2rc1. Applies on top
of master too, but not tested against it.

diff --git a/hw/xfree86/os-support/bsd/bsd_init.c 
b/hw/xfree86/os-support/bsd/bsd_init.c
index 123eb17..77667bb 100644
--- a/hw/xfree86/os-support/bsd/bsd_init.c
+++ b/hw/xfree86/os-support/bsd/bsd_init.c
@@ -41,6 +41,7 @@
 #include 
 
 static Bool KeepTty = FALSE;
+static Bool VTSwitch = TRUE;
 static int devConsoleFd = -1;
 #if defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT)
 static int VTnum = -1;
@@ -680,7 +681,7 @@ xf86CloseConsole()
   strerror(errno));
 }
 #endif
-   if (initialVT != -1)
+   if ((initialVT != -1) && VTSwitch)
ioctl(xf86Info.consoleFd, VT_ACTIVATE, initialVT);
 break;
 #endif /* SYSCONS_SUPPORT || PCVT_SUPPORT */
@@ -723,6 +724,11 @@ xf86ProcessArgument(int argc, char *argv[], int i)
return 1;
}
 #if defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT)
+   if (!strcmp(argv[i], "-novtswitch"))
+   {
+   VTSwitch = FALSE;
+   return 1;
+   }
if (!strcmp(argv[i], "-sharevts"))
{   
ShareVTs = TRUE;
-- 
1.7.5.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 1/6] make byte swapping macros less opaque to the optimizer

2011-05-13 Thread Keith Packard 
On Fri, 29 Apr 2011 14:46:23 +0300, Siarhei Siamashka 
 wrote:

> And of course, if none of the swapl/swaps/cpswapl/cpswaps are supposed
> to deal with unaligned pointers, then this is not an issue at all.

All of the protocol structures are aligned on 'natural' boundaries;
swaps within those should never be unaligned.

-- 
keith.pack...@intel.com


pgp88TNAahF5q.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PULL: xserver master] misc minor fixes

2011-05-13 Thread Keith Packard 
On Mon, 02 May 2011 20:46:06 -0700, Alan Coopersmith 
 wrote:

> Alan Coopersmith (4):
>   Move Xinput server API documentation from libXi to doc/xml
>   Make xorg.conf.example rule compatible with Solaris make
>   Only free pContext once when AddResource fails in 
> ProcRecordCreateContext
>   Clean up memory better when GetVisualInfo fails in ProcDbeGetVisualInfo

Merged.
   5cb31cd..043c175  master -> master

-- 
keith.pack...@intel.com


pgpEpYPh8vyLz.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PULL xserver] Composite ClipNotify fix and expose event elimination

2011-05-13 Thread Keith Packard 
On Wed, 4 May 2011 19:15:57 +0300, Ville Syrjälä  
wrote:

>   composite: Call ValidateGC after ChangeGC
>   composite: Initialize borderClip with current values
>   composite: Get rid of the internal UnmapWindow+MapWindow cycle
>   composite: Copy the window contents back from the pixmap
>   composite: Fix pWin->redirectDraw when changing between manual and 
> automatic redirection
>   composite: Recompute clipping when changing between manual and 
> automatic redirection

Merged.
   043c175..4d02c53  master -> master

-- 
keith.pack...@intel.com


pgptDOrhqLIiR.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PULL updated] XQuartz misc-foo

2011-05-13 Thread Keith Packard 
On Thu, 12 May 2011 19:02:52 -0700, Jeremy Huddleston  
wrote:

> Jeremy Huddleston (10):
>   XQuartz: Use a rwlock instead of a mutex to protect window_hash in the 
> pthread case
>   XQuartz: Fix incorrect typedefs with XPLUGIN_VERSION < 4
>   XQuartz: Ensure that {CF,NS}_RETURNS{,_NOT}_RETAINED are defined
>   XQuartz: prefs_copy_url and prefs_get_copy return retained objects
>   XQuartz: Make a copy of args for our crash reporter vsnprintf
>   XQuartz: Don't call into CoreFoundation after fork() and before exec()
>   configure.ac: XQuartz: Fix support for the deprecated 
> --with-launchd-id-prefix
>   Fix a typo: laucnd instead of launchd
>   XQuartz: stub: Log directly to ASL rather than stdout/stderr
>   XQuartz: Add a LOGGING section to our man page

Merged.
   4d02c53..6347a0b  master -> master

-- 
keith.pack...@intel.com


pgpJ8sq5TrjIE.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PULL updated again] input fixes

2011-05-13 Thread Keith Packard 
On Fri, 13 May 2011 12:57:01 +1000, Peter Hutterer  
wrote:

> Alan Coopersmith (1):
>   Move event filter initializer out of the structure itself
> 
> Chase Douglas (1):
>   Input: Pass co-ordinates by reference to transformAbsolute
> 
> Daniel Stone (10):
>   Input: Add DeepestSpriteWin function
>   Input: Fix event size confusion in CheckPassiveGrabsOnWindow
>   Input: Make CheckPassiveGrabsOnWindow take InternalEvent
>   Input: Simplify CheckPassiveGrabsOnWindow loop
>   XKB: Don't send unnecessary NewKeyboardNotifies
>   XKB: Simplify a loop in ProcXkbGetKbdByName
>   XKB: Remove duplicate keymap-copying loop
>   XKB: Send NewKeyboardNotify for dev before its master/slaves
>   XKB: Send XKB events for all devices to all clients
>   XKB: Fix sense inversion for core MapNotify events
> 
> Jamey Sharp (1):
>   dix: split implicit grab activation into a separate function.
> 
> Peter Hutterer (15):
>   input: Only release SD buttons for explicit floating/reattachment 
> (#36146)
>   input: change CHECKEVENT macro to verify_internal_event function
>   xfree86: print the device ID to the log when adding a device.
>   input: Provide Queue{Button|Keyboard|Proximity}Event helpers
>   input: replace EventListPtr with InternalEvent array
>   input: remove DDX event list handling
>   dix: replace unneded goto with break.
>   dix: split out window owner event delivery from DeliverEventsToWindow
>   dix: split out client delivery from DeliverEventsToWindow
>   dix: move the grab activation condition into a if block.
>   dix: return deliveries from DeliverGrabbedEvent
>   Xi: split DeviceStateNotify delivery into a separate function
>   dix: use a tmp variable instead of multiple rClient(other).
>   include: add version_compare helper function
>   dix: replace CORE_EVENT and XI2_EVENT macros with inline functions.

Merged.
   6347a0b..ba55402  master -> master

-- 
keith.pack...@intel.com


pgpB9Z2A9JNYg.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dri2: Don't send so many needless invalidate events

2011-05-13 Thread Keith Packard 
On Fri,  6 May 2011 18:18:15 +0300, ville.syrj...@nokia.com wrote:
> From: Ville Syrjälä 
> 
> Only send invalidate events for drawables if some client has requested
> some buffers.

Merged.
   ba55402..5318694  master -> master

-- 
keith.pack...@intel.com


pgpoFPF4wWdMC.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 7/9] doc: add external doc references support to Xserver-DTrace

2011-05-13 Thread Keith Packard 
On Thu, 28 Apr 2011 21:16:14 -0400, Gaetan Nadon  wrote:
> This makefile is used to build the 60+ docbooks in xorg.
> Dtrace is a user document and should be located under doc subdir.
> 
> This user document can now refer to external user/specs docs
> or can be referred to by such documnets.

This one doesn't apply anymore.

-- 
keith.pack...@intel.com


pgpqrUPayuqvL.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 6/9] man: relocate manual pages in the man subdir outside doc

2011-05-13 Thread Keith Packard 
On Thu, 28 Apr 2011 21:16:13 -0400, Gaetan Nadon  wrote:
> The convention is to have the manual pages in a man subdir
> which is not under a doc dir. The doc dir contains users docs.
> This will move man pages out of the way for upcoming DocBook patches.
> 
> Reviewed-by Jeremy Huddleston 
> Signed-off-by: Gaetan Nadon 

I've applied patches 1-6.
   5318694..221507e  master -> master

-- 
keith.pack...@intel.com


pgptlXTKkcmzB.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 1/6] make byte swapping macros less opaque to the optimizer

2011-05-13 Thread Matt Turner 
On Fri, May 13, 2011 at 4:43 PM, Keith Packard  wrote:
> On Fri, 29 Apr 2011 14:46:23 +0300, Siarhei Siamashka 
>  wrote:
>
>> And of course, if none of the swapl/swaps/cpswapl/cpswaps are supposed
>> to deal with unaligned pointers, then this is not an issue at all.
>
> All of the protocol structures are aligned on 'natural' boundaries;
> swaps within those should never be unaligned.

Thanks for clearing that up.

So, after fixing the couple of unaligned accesses that Siarhei's trick
uncovered, the patch should be OK as-is.

I'll see about fixing those.

Matt
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] bsd: Add support for -novtswitch.

2011-05-13 Thread Alan Coopersmith 
On 05/13/11 07:57 AM, Cyril Brulebois wrote:
> VT switching back to the initial VT is possible in the following case:
>   #if defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT)
> 
> Make it possible to prevent that from happening if -novtswitch was
> passed, which should make the life of display manager developers easier,
> especially when it comes to handling multiple users.

Our gdm maintainer has been poking me about -novtswitch as well, so maybe
we should consider moving it up to the xfree86 ddx common layer, instead
of replicating for each OS.

-- 
-Alan Coopersmith-alan.coopersm...@oracle.com
 Oracle Solaris Platform Engineering: X Window System

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 2/2] Xephyr: Delete Linux evdev support.

2011-05-13 Thread Alan Coopersmith 
On 05/12/11 03:21 PM, Jamey Sharp wrote:
> This only makes sense if Xfbdev is deleted first, and perhaps there's
> somebody who really cares about using system devices in nested windows?

Multiseat.   Though that really should be done using Xinput now instead
of reaching around behind the underlying X server to pull events out of
the raw device (and would be more portable than maintaining evdev
specific code in Xephyr, and let you get the benefit of the improvements
Peter makes to the Xorg evdev driver).

-- 
-Alan Coopersmith-alan.coopersm...@oracle.com
 Oracle Solaris Platform Engineering: X Window System

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: IR remote control autorepeat / evdev

2011-05-13 Thread Mauro Carvalho Chehab 
Em 13-05-2011 01:48, Anssi Hannula escreveu:
> On 12.05.2011 04:36, Mauro Carvalho Chehab wrote:
>> Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu:
>>> Em 12-05-2011 02:37, Anssi Hannula escreveu:
>>
 I don't see any other places:
 $ git grep 'REP_PERIOD' .
 dvb/dvb-usb/dvb-usb-remote.c:   input_dev->rep[REP_PERIOD] =
 d->props.rc.legacy.rc_interval;
>>>
>>> Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we
>>> should change it to something like 125ms, for example, as 33ms is too 
>>> short, as it takes up to 114ms for a repeat event to arrive.
>>>
>> IMO, the enclosed patch should do a better job with repeat events, without
>> needing to change rc-core/input/event logic.
> 
> It will indeed reduce the amount of ghost events so it brings us in the
> right direction.
> 
> I'd still like to get rid of the ghost repeats entirely, or at least
> some way for users to do it if we don't do it by default.

> Maybe we could replace the kernel softrepeat with native repeats (for
> those protocols/drivers that have them), while making sure that repeat
> events before REP_DELAY are ignored and repeat events less than
> REP_PERIOD since the previous event are ignored, so the users can still
> configure them as they like? 
> 

This doesn't seem to be the right thing to do. If the kernel will
accept 33 ms as the value or REP_PERIOD, but it will internally 
set the maximum repeat rate is 115 ms (no matter what logic it would
use for that), Kernel (or X) shouldn't allow the user to set a smaller value. 

The thing is that writing a logic to block a small value is not easy, since 
the max value is protocol-dependent (worse than that, on some cases, it is 
device-specific). It seems better to add a warning at the userspace tools 
that delays lower than 115 ms can produce ghost events on IR's.

> Or maybe just a module option that causes rc-core to use native repeat
> events, for those of us that want accurate repeat events without ghosting?

If the user already knows about the possibility to generate ghost effects,
with low delays, he can simply not pass a bad value to the kernel, instead 
of forcing a modprobe parameter that will limit the minimal value.

Mauro. 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH 1/6] make byte swapping macros less opaque to the optimizer

2011-05-13 Thread Keith Packard 
On Fri, 13 May 2011 17:24:29 -0400, Matt Turner  wrote:

> I'll see about fixing those.

Thanks!

-- 
keith.pack...@intel.com


pgpWq645rZYRy.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: IR remote control autorepeat / evdev

2011-05-13 Thread Anssi Hannula 
On 14.05.2011 01:39, Mauro Carvalho Chehab wrote:
> Em 13-05-2011 01:48, Anssi Hannula escreveu:
>> On 12.05.2011 04:36, Mauro Carvalho Chehab wrote:
>>> Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu:
 Em 12-05-2011 02:37, Anssi Hannula escreveu:
>>>
> I don't see any other places:
> $ git grep 'REP_PERIOD' .
> dvb/dvb-usb/dvb-usb-remote.c:   input_dev->rep[REP_PERIOD] =
> d->props.rc.legacy.rc_interval;

 Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we
 should change it to something like 125ms, for example, as 33ms is too 
 short, as it takes up to 114ms for a repeat event to arrive.

>>> IMO, the enclosed patch should do a better job with repeat events, without
>>> needing to change rc-core/input/event logic.
>>
>> It will indeed reduce the amount of ghost events so it brings us in the
>> right direction.
>>
>> I'd still like to get rid of the ghost repeats entirely, or at least
>> some way for users to do it if we don't do it by default.
> 
>> Maybe we could replace the kernel softrepeat with native repeats (for
>> those protocols/drivers that have them), while making sure that repeat
>> events before REP_DELAY are ignored and repeat events less than
>> REP_PERIOD since the previous event are ignored, so the users can still
>> configure them as they like? 
>>
> 
> This doesn't seem to be the right thing to do. If the kernel will
> accept 33 ms as the value or REP_PERIOD, but it will internally 
> set the maximum repeat rate is 115 ms (no matter what logic it would
> use for that), Kernel (or X) shouldn't allow the user to set a smaller value. 
> 
> The thing is that writing a logic to block a small value is not easy, since 
> the max value is protocol-dependent (worse than that, on some cases, it is 
> device-specific). It seems better to add a warning at the userspace tools 
> that delays lower than 115 ms can produce ghost events on IR's.

>From what I see, even periods longer than 115 ms can produce ghost events.

For example with your patch softrepeat period is 125ms, release timeout
250ms, and a native rate of 110ms:

There are 4 native events transmitted at
000 ms
110 ms
220 ms
330 ms
(user stops between 330ms and 440ms)

This causes these events in the evdev interface:
000: 1
125: 2
250: 2
375: 2
500: 2
550: 0

So we got 1-2 ghost repeat events.

>> Or maybe just a module option that causes rc-core to use native repeat
>> events, for those of us that want accurate repeat events without ghosting?
> 
> If the user already knows about the possibility to generate ghost effects,
> with low delays, he can simply not pass a bad value to the kernel, instead 
> of forcing a modprobe parameter that will limit the minimal value.

There is no "good value" for REP_PERIOD (as in ghost repeats guaranteed
gone like with native repeats). Sufficiently large values will make
ghost repeats increasingly rare, but the period becomes so long the
autorepeat becomes frustratingly slow to use.

-- 
Anssi Hannula
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel