xserver: Branch 'server-1.7-nominations' - 2 commits

[Peter Hutterer]

 dix/devices.c |    8 --------
 dix/events.c  |    5 -----
 2 files changed, 13 deletions(-)

New commits:
commit d35e08b6db911c404d7baf680dab30e8a6831bc4
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Thu Feb 18 16:00:15 2010 +1000

    dix: remove now-erroneous comment about frozen slave devices.
    
    A direct grab on a slave device through XI2 detaches it, regardless of
    whether the grab is sync or async. So this comment doesn't apply to XI2
    anyway.
    
    For XI1, aside from your life being miserable already, it doesn't matter as
    XI1 does not have a concept of attachment. You can freeze a device and if
    you don't freeze _all_ other devices at the same time, the master device can
    still happily send events to the client.
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
    Acked-by: Adam Jackson <ajax at redhat.com>
    (cherry picked from commit c0d941913199ed251fceab62fcf65437f6f9bd31)
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>

diff --git a/dix/events.c b/dix/events.c
index 4423c16..02079be 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -1414,11 +1414,6 @@ CheckGrabForSyncs(DeviceIntPtr thisDev, Bool thisMode, Bool otherMode)
 	    thisDev->deviceGrab.sync.other = NullGrab;
     }
 
-    /*
-        XXX: Direct slave grab won't freeze the paired master device.
-        The correct thing to do would be to freeze all SDs attached to the
-        paired master device.
-     */
     if (IsMaster(thisDev))
     {
         dev = GetPairedDevice(thisDev);
commit 11c27f261efc5b7a8594ad2de7bed4339f2a62ce
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date:   Mon Feb 15 16:32:16 2010 +1000

    dix: try to ring the bell even if the current device doesn't have one. (#24503)
    
    Evdev devices do not have the bell proc set, but XTEST devices do. By
    exiting early, the bell only rings if the last keyboard used was the XTEST
    keyboard and hence the bell proc is still set on the master but not if an
    evdev keyboard was used last.
    
    The better approach here is to try to ring the bell on all devices attached
    to this master device in case one or more actually do produce an audible
    sound. That's also XKB's behaviour if XkbUseCoreKbd is specified as device
    identifier.
    
    X.Org Bug 24503 <http://bugs.freedesktop.org/show_bug.cgi?id=24503>
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
    Reviewed-by: Adam Jackson <ajax at redhat.com>
    (cherry picked from commit 758f6971750ed507e64eee817d720a77181439f2)
    
    Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>

diff --git a/dix/devices.c b/dix/devices.c
index ef199b7..87b6dc7 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -2019,14 +2019,6 @@ ProcBell(ClientPtr client)
 	return BadValue;
     }
 
-    /* Seems like no keyboard actually has the BellProc set. Returning
-     * BadDevice (previous code) will make apps crash badly. The man pages
-     * doesn't say anything about a BadDevice being returned either.
-     * So just quietly do nothing and pretend everything has worked.
-     */
-    if (!keybd->kbdfeed->BellProc)
-        return Success;
-
     newpercent = (base * stuff->percent) / 100;
     if (stuff->percent < 0)
         newpercent = base + newpercent;