1. 21 Sep, 2011 1 commit
  2. 15 Jul, 2011 1 commit
    • Daniel Stone's avatar
      XKB: Work around broken interps from old xkbcomp · 82f5521a
      Daniel Stone authored
      Bugfix for broken xkbcomp: if we encounter an XFree86Private action with
      Any+AnyOfOrNone(All), then we skip the interp as broken.  Versions of
      xkbcomp below 1.2.2 had a bug where they would interpret a symbol that
      couldn't be found in an interpret as Any.  So, an
      XF86LogWindowTree+AnyOfOrNone(All) interp that triggered the PrWins
      action would make every key without an action trigger PrWins if libX11
      didn't yet know about the XF86LogWindowTree keysym.  None too useful.
      
      We only do this for XFree86 actions, as the current XKB dataset relies
      on Any+AnyOfOrNone(All) -> SetMods for Ctrl in particular.
      
      See xkbcomp commits 2a473b906943ffd807ad81960c47530ee7ae9a60 and
      3caab5aa37decb7b5dc1642a0452efc3e1f5100e for more details.
      Signed-off-by: default avatarDaniel Stone <daniel@fooishbar.org>
      Acked-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      82f5521a
  3. 06 May, 2011 4 commits
  4. 17 Mar, 2011 2 commits
  5. 16 Mar, 2011 1 commit
  6. 22 Feb, 2011 3 commits
  7. 15 Feb, 2011 1 commit
  8. 13 Feb, 2011 2 commits
    • Ander Conselvan de Oliveira's avatar
      ProcXkbGetXkbByName: fix use of uninitialised bytes valgrind error. · 85f90173
      Ander Conselvan de Oliveira authored
      ==9999== Syscall param writev(vector[...]) points to uninitialised byte(s)
      ==9999==    at 0x4AB5154: writev (writev.c:51)
      ==9999==    by 0x7C7C3: _XSERVTransWritev (Xtrans.c:912)
      ==9999==    by 0x61C8B: FlushClient (io.c:924)
      ==9999==    by 0x62423: WriteToClient (io.c:846)
      ==9999==    by 0xCE39B: XkbSendMap (xkb.c:1408)
      ==9999==    by 0xD247B: ProcXkbGetKbdByName (xkb.c:5814)
      ==9999==    by 0x4AB53: Dispatch (dispatch.c:432)
      ==9999==    by 0x205BF: main (main.c:291)
      ==9999==  Address 0x557eb68 is 40 bytes inside a block of size 4,096 alloc'd
      ==9999==    at 0x48334A4: calloc (vg_replace_malloc.c:467)
      ==9999==    by 0x62567: WriteToClient (io.c:1065)
      ==9999==    by 0x452EB: ProcEstablishConnection (dispatch.c:3685)
      ==9999==    by 0x4AB53: Dispatch (dispatch.c:432)
      ==9999==    by 0x205BF: main (main.c:291)
      ==9999==  Uninitialised value was created by a stack allocation
      ==9999==    at 0xD1910: ProcXkbGetKbdByName (xkb.c:5559)
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarOliver McFadden <oliver.mcfadden@nokia.com>
      Signed-off-by: default avatarAnder Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
      85f90173
    • Ander Conselvan de Oliveira's avatar
      XkbSendNames: fix use of uninitialised bytes valgrind error. · 8a34d7a8
      Ander Conselvan de Oliveira authored
      ==537== Syscall param writev(vector[...]) points to uninitialised byte(s)
      ==537==    at 0x4AB7154: writev (writev.c:51)
      ==537==    by 0x8935B: _XSERVTransWritev (Xtrans.c:912)
      ==537==    by 0x6C55F: FlushClient (io.c:924)
      ==537==    by 0x6CCF3: WriteToClient (io.c:846)
      ==537==    by 0xD51D3: XkbSendNames (xkb.c:3765)
      ==537==    by 0xD8183: ProcXkbGetKbdByName (xkb.c:5825)
      ==537==    by 0x27B7B: Dispatch (dispatch.c:432)
      ==537==    by 0x205B7: main (main.c:291)
      ==537==  Address 0x55899f2 is 154 bytes inside a block of size 1,896 alloc'd
      ==537==    at 0x4834C48: malloc (vg_replace_malloc.c:236)
      ==537==    by 0xD47AF: XkbSendNames (xkb.c:3642)
      ==537==    by 0xD8183: ProcXkbGetKbdByName (xkb.c:5825)
      ==537==    by 0x27B7B: Dispatch (dispatch.c:432)
      ==537==    by 0x205B7: main (main.c:291)
      ==537==  Uninitialised value was created by a heap allocation
      ==537==    at 0x4834C48: malloc (vg_replace_malloc.c:236)
      ==537==    by 0xD47AF: XkbSendNames (xkb.c:3642)
      ==537==    by 0xD8183: ProcXkbGetKbdByName (xkb.c:5825)
      ==537==    by 0x27B7B: Dispatch (dispatch.c:432)
      ==537==    by 0x205B7: main (main.c:291)
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarOliver McFadden <oliver.mcfadden@nokia.com>
      Signed-off-by: default avatarAnder Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
      8a34d7a8
  9. 27 Jan, 2011 1 commit
  10. 19 Oct, 2010 2 commits
  11. 01 Sep, 2010 2 commits
  12. 20 Jul, 2010 1 commit
  13. 11 Jun, 2010 1 commit
  14. 07 Jun, 2010 1 commit
  15. 06 Jun, 2010 2 commits
  16. 14 May, 2010 1 commit
  17. 12 May, 2010 1 commit
  18. 02 Feb, 2010 1 commit
  19. 24 Jan, 2010 1 commit
  20. 19 Dec, 2009 3 commits
  21. 11 Dec, 2009 2 commits
  22. 14 Oct, 2009 1 commit
  23. 21 Sep, 2009 1 commit
  24. 04 Sep, 2009 1 commit
  25. 15 Jul, 2009 1 commit
  26. 14 Jul, 2009 1 commit
  27. 22 May, 2009 1 commit
    • Peter Hutterer's avatar
      Input: rename DeviceIntRec->isMaster to ->type. · b12d302d
      Peter Hutterer authored
      isMaster is not enough as long as we differ between master pointers and
      keyboard. With flexible device classes, the usual checks for whether a
      master device is a pointer (currently check for ->button, ->valuators or
      ->key) do not work as an SD may post an event through a master and mess this
      check up.
      
      Example, a device with valuators but no buttons would remove the button
      class from the VCP and thus result in the
      IsPointerDevice(inputInfo.pointer) == FALSE.
      
      This will become worse in the future when new device classes are introduced
      that aren't provided in the current system (e.g. a switch class).
      
      This patch replaces isMaster with "type", one of SLAVE, MASTER_POINTER and
      MASTER_KEYBOARD. All checks for dev->isMaster are replaced with an
      IsMaster(dev).
      b12d302d