1. 03 Jun, 2016 1 commit
    • Olivier Fourdan's avatar
      xkb: add hook to allow/deny AccessX key repeat · fda5675f
      Olivier Fourdan authored
      The xserver generates the key repeat by itself.
      
      But when used with another server processing inputs first (e.g. a
      Wayland compositor), the other server may be busy dealing with some
      other things and not queue up key release events in time.
      
      Add a vfunc in XkbSrvInfo to possibly add a check before re-emitting a
      keypress event in the AccessX timer handler, so that the key repeat has
      a chance to be denied if the server processing the input is not ready.
      Signed-off-by: 's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      fda5675f
  2. 15 Apr, 2016 1 commit
  3. 24 Nov, 2015 1 commit
  4. 12 Nov, 2014 1 commit
  5. 03 Apr, 2014 1 commit
  6. 12 Jan, 2014 1 commit
  7. 05 Dec, 2012 2 commits
  8. 29 Nov, 2012 1 commit
    • Peter Hutterer's avatar
      xkb: fill in keycode and event type for slow keys enablement · 2c4388a0
      Peter Hutterer authored
      eventType is set for the type that triggered a XkbControlsNotify event.
      Technically, SlowKeys is triggered by a timer which doesn't have a matching
      core event type. So we used to use 0 here.
      
      Practically, the timer is triggered by a key press + hold and cancelled when
      the key is released before the timeout expires. So we might as well set
      KeyPress (keycode) in the ControlsNotify to give clients a chance to differ
      between timer-triggered SlowKeys and client-triggered ones.
      
      This is a chance in behaviour, though I suspect with little impact.
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Acked-by: 's avatarDaniel Stone <daniel@fooishbar.org>
      2c4388a0
  9. 29 Oct, 2012 1 commit
    • Peter Hutterer's avatar
      xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP · 2decff63
      Peter Hutterer authored
      For button release events, the current code picks the VCK. Because that has
      a XKB struct, it thinks this is a PointerKeys event and proceeds to send the
      release event through the XTest pointer. That has no effect in normal
      operation as the button is never down and an attempt is silently discarded
      (normal event processing continues with the VCP).
      
      On server shutdown, the XTest device is already removed, leading to a
      null-pointer derefernce when the device is checked for whether buttons are
      down (XkbFakeDeviceButton → button_is_down(xtest pointer)).
      
      The current state has only worked by accident, the right approach here is to
      handle the VCP's event as such and not switch to the keyboard.
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
      2decff63
  10. 04 Jul, 2012 1 commit
  11. 06 Jun, 2012 1 commit
  12. 14 May, 2012 1 commit
  13. 21 Mar, 2012 1 commit
    • Keith Packard's avatar
      Introduce a consistent coding style · 9838b703
      Keith Packard authored
      This is strictly the application of the script 'x-indent-all.sh'
      from util/modular. Compared to the patch that Daniel posted in
      January, I've added a few indent flags:
      
      	-bap
      	-psl
      	-T PrivatePtr
      	-T pmWait
      	-T _XFUNCPROTOBEGIN
      	-T _XFUNCPROTOEND
      	-T _X_EXPORT
      
      The typedefs were needed to make the output of sdksyms.sh match the
      previous output, otherwise, the code is formatted badly enough that
      sdksyms.sh generates incorrect output.
      
      The generated code was compared with the previous version and found to
      be essentially identical -- "assert" line numbers and BUILD_TIME were
      the only differences found.
      
      The comparison was done with this script:
      
      dir1=$1
      dir2=$2
      
      for dir in $dir1 $dir2; do
      	(cd $dir && find . -name '*.o' | while read file; do
      		dir=`dirname $file`
      		base=`basename $file .o`
      		dump=$dir/$base.dump
      		objdump -d $file > $dump
      	done)
      done
      
      find $dir1 -name '*.dump' | while read dump; do
      	otherdump=`echo $dump | sed "s;$dir1;$dir2;"`
      	diff -u $dump $otherdump
      done
      Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>
      Acked-by: 's avatarDaniel Stone <daniel@fooishbar.org>
      Acked-by: 's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      9838b703
  14. 02 Oct, 2011 1 commit
  15. 22 Aug, 2011 1 commit
  16. 22 Feb, 2011 1 commit
  17. 02 Jul, 2010 1 commit
  18. 01 Jul, 2010 3 commits
    • Peter Hutterer's avatar
      xkb: release XTEST pointer buttons on physical releases. (#28808) · 14327858
      Peter Hutterer authored
      If a button release event is posted for the MD pointer, post a release event
      through the matching XTEST device. This way, a client who posts a button
      press through the XTEST extension cannot inadvertedly lock the button.
      
      This behaviour is required for historical reasons, until server 1.7 the core
      pointer would release a button press on physical events, regardless of the
      XTEST state. Clients seem to rely on this behaviour, causing seemingly stuck
      grabs.
      
      The merged behaviour is kept for multiple keyboard PointerKey events, if two
      physical keyboards hold the button down as a result of PointerKey actions,
      the button is not released until the last keyboard releases the button.
      
      X.Org Bug 28808 <http://bugs.freedesktop.org/show_bug.cgi?id=28808>
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      14327858
    • Peter Hutterer's avatar
      xkb: merge lockedPtrButtons state from all attached SDs. · 69ac9098
      Peter Hutterer authored
      Problem:
      lockedPtrButtons keeps the state of the buttons locked by a PointerKeys button
      press. Unconditionally clearing the bits may cause stuck buttons in this
      sequence of events:
      
      1. type Shift + NumLock to enable PointerKeys
      2. type 0/Ins on keypad to emulate Button 1 press
              → button1 press event to client
      3. press and release button 1 on physical mouse
              → button1 release event to client
      
      Button 1 on the MD is now stuck and cannot be released.
      
      Cause:
      XKB PointerKeys button events are posted through the XTEST pointer device.
      Once a press is generated, the XTEST device's button is down. The DIX merges
      the button state of all attached SDs, hence the MD will have a button down
      while the XTEST device has a button down.
      
      PointerKey button events are only generated on the master device to avoid
      duplicate events (see XkbFakeDeviceButton()). If the MD has the
      lockedPtrButtons bit cleared by a release event on a physical device, no
      such event is generated when a keyboard device triggers the PointerKey
      ButtonRelease trigger. Since the event - if generated - is posted through
      the XTEST pointer device, lack of a generated ButtonRelease event on the
      XTEST pointer device means the button is never released, resulting in the
      stuck button observed above.
      
      Solution:
      This patch merges the MD's lockedPtrButtons with the one of all attached
      slave devices on release events. Thus, as long as one attached keyboard has
      a lockedPtrButtons bit set, this bit is kept in the MD. Once a PointerKey
      button is released on all keyboards, the matching release event is emulated
      from the MD through the XTEST pointer device, thus also releasing the button
      in the DIX.
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      69ac9098
    • Peter Hutterer's avatar
      xkb: remove now obsolete comment. · dbf249ec
      Peter Hutterer authored
      Looks like nothing broke from removing the hardcoded CoreProcessPointerEvent
      call. Whoop. Di. Doo.
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      dbf249ec
  19. 30 Jun, 2010 1 commit
    • Keith Packard's avatar
      xkb: merge lockedPtrButtons state from all attached SDs. · 60527106
      Keith Packard authored
      Problem:
      lockedPtrButtons keeps the state of the buttons locked by a PointerKeys button
      press. Unconditionally clearing the bits may cause stuck buttons in this
      sequence of events:
      
      1. type Shift + NumLock to enable PointerKeys
      2. type 0/Ins on keypad to emulate Button 1 press
              → button1 press event to client
      3. press and release button 1 on physical mouse
              → button1 release event to client
      
      Button 1 on the MD is now stuck and cannot be released.
      
      Cause:
      XKB PointerKeys button events are posted through the XTEST pointer device.
      Once a press is generated, the XTEST device's button is down. The DIX merges
      the button state of all attached SDs, hence the MD will have a button down
      while the XTEST device has a button down.
      
      PointerKey button events are only generated on the master device to avoid
      duplicate events (see XkbFakeDeviceButton()). If the MD has the
      lockedPtrButtons bit cleared by a release event on a physical device, no
      such event is generated when a keyboard device triggers the PointerKey
      ButtonRelease trigger. Since the event - if generated - is posted through
      the XTEST pointer device, lack of a generated ButtonRelease event on the
      XTEST pointer device means the button is never released, resulting in the
      stuck button observed above.
      
      Solution:
      This patch merges the MD's lockedPtrButtons with the one of all attached
      slave devices on release events. Thus, as long as one attached keyboard has
      a lockedPtrButtons bit set, this bit is kept in the MD. Once a PointerKey
      button is released on all keyboards, the matching release event is emulated
      from the MD through the XTEST pointer device, thus also releasing the button
      in the DIX.
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
      Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>
      60527106
  20. 10 Jun, 2010 1 commit
  21. 02 Feb, 2010 1 commit
  22. 02 Dec, 2009 1 commit
  23. 22 Sep, 2009 1 commit
  24. 14 Sep, 2009 1 commit
  25. 04 Sep, 2009 1 commit
  26. 29 Jul, 2009 1 commit
  27. 02 Jun, 2009 1 commit
  28. 22 May, 2009 1 commit
  29. 03 Mar, 2009 1 commit
  30. 23 Feb, 2009 3 commits
  31. 22 Jan, 2009 3 commits
  32. 20 Jan, 2009 1 commit
  33. 12 Dec, 2008 1 commit
    • Peter Hutterer's avatar
      Remove #define NEED_EVENTS and NEED_REPLIES · cb95642d
      Peter Hutterer authored
      A grep on xorg/* revealed there's no consumer of this define.
      
      Quote Alan Coopersmith:
      "The consumer was in past versions of the headers now located
      in proto/x11proto - for instance, in X11R6.0's xc/include/Xproto.h,
      all the event definitions were only available if NEED_EVENTS were
      defined, and all the reply definitions required NEED_REPLIES.
      
      Looks like Xproto.h dropped them by X11R6.3, which didn't have
      the #ifdef's anymore, so these are truly ancient now."
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@redhat.com>
      Signed-off-by: 's avatarAdam Jackson <ajax@redhat.com>
      cb95642d