← Back to team overview

desktop-packages team mailing list archive

[Bug 1091103] Re: Default blacklist string shouldn't contain double escape

 

marking as closed (0.9.8 series is obsolete)

** Changed in: compiz/0.9.8
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to compiz in Ubuntu.
https://bugs.launchpad.net/bugs/1091103

Title:
  Default blacklist string shouldn't contain double escape

Status in Compiz:
  Fix Released
Status in Compiz 0.9.8 series:
  Fix Released
Status in Compiz Core:
  Fix Committed
Status in “compiz” package in Ubuntu:
  Fix Released
Status in “compiz” source package in Precise:
  Fix Released

Bug description:
  Note: similar to bug #1089246, this SRU only affects precise since on
  quantal/raring it wouldn't have an effect.

  [Impact]

  Incorrect default setting doesn't have the wanted effect of functional
  blacklist on precise, because of character escaping problems.

  [Test Case]

  The test case relies on a bug/feature of Intel driver that on modern
  Intel hardware like sandy bridge / ivy bridge, tear-free video
  playback is not possible without compositing if the video player
  doesn't use vsync itself. Thus tearing can be seen as an indication if
  unredirection is in effect or not.

  0. Have intel hardware on Ubuntu 12.04 LTS, with which this is easiest to test
  1. In CCSM, set Composite -> unredirect_match to '(any)', ie. remove everything that comes after that, that would normally prevent unredirection in common video players.
  2. Open http://www.youtube.com/watch?v=ZCPkOpMHB7g in Firefox and play it full screen
  3. Expected result: no tearing, because blacklist is in effect and prevents unredirection on Intel (and nouveau) regardless of the match setting

  Note: radeon always has tearfree Xv output, so you can't use a similar
  test and changing the blacklist string to include 'AMD' without
  forcing non-Xv X11 output

  [Regression Potential]

  Very low. Theoretically too excessive blacklisting could restore
  current precise behavior.

  ---

  The blacklist default option in a true precise environment - the only
  environment it's supposed to have an effect with its default setting -
  is not working. It seems that the default unredirect_driver_blacklist
  in the XML contains the same double escape as the test code. So the
  tests succeed, but in reality there is extra '\' in the default
  setting, preventing the regexp from working.

  This one, the current default doesn't work:
  (nouveau|Intel).*Mesa 8\\.0

  Either one of these works instead:
  (nouveau|Intel).*Mesa 8\.0
  (nouveau|Intel).*Mesa 8.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/compiz/+bug/1091103/+subscriptions