1. 19 May, 2012 1 commit
  2. 18 May, 2012 2 commits
  3. 17 May, 2012 6 commits
  4. 16 May, 2012 10 commits
  5. 14 May, 2012 14 commits
  6. 10 May, 2012 1 commit
  7. 08 May, 2012 1 commit
    • James Cloos's avatar
      Fix RANDR’s gamma_to_ramp(). · afc153a5
      James Cloos authored
      In order to generate a 256-entry ramp in [0,65535] which covers the full
      range, one must mupliply eight-bit values not by 256 but rather by 257.
      Many years back – well before the RANDR extension was written, and
      before xorg@fdo – a similar bug fix was made to the DIX for converting
      client-supplied eight-bit color values into sixteen-bit values.
      Noticed by: Elle Stone and Graeme Gill.
      Signed-off-by: James Cloos's avatarJames Cloos <cloos@jhcloos.com>
  8. 04 May, 2012 4 commits
  9. 03 May, 2012 1 commit
    • Daniel Kurtz's avatar
      os/log: refactor logging · c91d00e0
      Daniel Kurtz authored and Peter Hutterer's avatar Peter Hutterer committed
      It is not safe to ever use an arbitrary (possibly user supplied) string as
      part of the format for a *sprintf() call.
      For example:
        1. Name a Bluetooth keyboard "%n%n%n%n%n%n%n%n"
        2. Pair it with a computer running X and try to use it
        3. X is not happy when trying to do the following in xf86-input-evdev:
           xf86IDrvMsg(pInfo, X_CONFIG, "Device: \"%s\"\n", device);
           because LogVHdrMessageVerb() has put the %n from the device name
           into a format string of the form:
              "evdev: %n%n%n%n%n%n%n%n: Device: \"%s\"\n"
      Instead, build up a log message in place by appending successive formatted
      strings by sncprintf'ing to the end of the previous.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>