1. 21 May, 2012 1 commit
  2. 17 May, 2012 6 commits
  3. 16 May, 2012 10 commits
  4. 14 May, 2012 14 commits
  5. 10 May, 2012 1 commit
  6. 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>
      afc153a5
  7. 04 May, 2012 4 commits
  8. 03 May, 2012 3 commits
    • 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>
      c91d00e0
    • Daniel Kurtz's avatar
      os/log: only write timestamp if a message is actually written to logfile · 6ce0eac4
      Daniel Kurtz authored and Peter Hutterer's avatar Peter Hutterer committed
      
      
      The current code will write a timestamps into the logFile whenever
      the last message ended with a '\n' - even if the verb for that timestamp
      is at too high a level.  This timestamp will sit there with no matching
      message until the next call to LogVWrite with a valid verb.
      
      In other words, in some cases, timestamps in the X.org.log are for some
      completely unrelated message that was previously ignored due to
      insufficient verbosity, and not for the message that appears next to it
      in the log file.
      
      We keep the current policy which appears to be to only apply timestamps if
      a message is actually written to a log file.  That is, no timestamps on
      stderr, or in the mem buffer.  Therefore, the timestamp stringification
      is moved to the conditional where it is used.
      
      Since logging uses a fixed length buffer, this patch also forces a '\n'
      whenever a buffer is terminated due to a too-long write request.  This
      allows the newline detection to work even on overflow, and also cleans up
      the log a bit in the overflow case.
      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>
      6ce0eac4
    • Daniel Kurtz's avatar
      os/xprintf: add Xvscnprintf and Xscnprintf · 5c2e2a16
      Daniel Kurtz authored and Peter Hutterer's avatar Peter Hutterer committed
      
      
      Normal snprintf() usually returns the number of bytes that would have been
      written into a buffer had the buffer been long enough.
      
      The scnprintf() variants return the actual number of bytes written,
      excluding the trailing '\0'.
      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>
      5c2e2a16