Bug#578406: embedded checks and fallback: apparently wrong solution

2010-04-20 Thread Michel Dänzer
On Mon, 2010-04-19 at 20:27 +0400, Michael Tokarev wrote: 
> 
>  2.  There's a limitation of max texture size in most radeon cards,
>which is 2048.  Which means that in case a (virtual) resolution of
>the screen is >2048 (which is not uncommon), new compiz will refuse
>to start.  Previously compiz-manager has a feature to SKIP_CHECKS
>and run compiz anyway.  Now that feature does not exist anymore.
>Just today we were discussed this problem on irc with some ubuntu
>user, -- the prob was nautilus trying to display background picture.
>The solution for that user was to recompile compiz without the
>above-mentioned patch and specify SKIP_CHECKS.  (It is because
>almost all radeon cards actually works just fine with larger
>texture sizes).

Compiz doesn't check these limits just for fun. If everything works
properly by simply disabling a check, that means either:

  * Compiz checks the wrong limit (e.g. texture size instead of
viewport size) somewhere and needs to be fixed to check the
right limit. 
  * The value checked doesn't accurately reflect the hardware
capabilities, and the Mesa driver needs to be fixed.


-- 
Earthling Michel Dänzer   |http://www.vmware.com
Libre software enthusiast |  Debian, X and DRI developer



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#578406: embedded checks and fallback: apparently wrong solution

2010-04-19 Thread Michael Tokarev
Package: compiz
Version: 0.8.4-3
Severity: normal

0.8.4-1 (debian version) dropped compiz-manager script and implemented
everything in compiz binary.  I mean the patch taken from ubuntu,
debian/patches/060_move_checks_to_compiz.patch .

Now, there are 2 problems with this approach:

 1.  It is not possible to specify the fallback window manager.  The
   guesswork done in launchFallbackWM() is childish, there should be
   some option to actually specify what to run, if at all.  Maybe for
   some default it's remotely acceptable, but not for a ultimate
   solution.  For example, I'm running LXDE, and it is opening me
   xterm, and there's no way to specify what to run instead (and
   no, I don't want to run metacity or kwin).

 2.  There's a limitation of max texture size in most radeon cards,
   which is 2048.  Which means that in case a (virtual) resolution of
   the screen is >2048 (which is not uncommon), new compiz will refuse
   to start.  Previously compiz-manager has a feature to SKIP_CHECKS
   and run compiz anyway.  Now that feature does not exist anymore.
   Just today we were discussed this problem on irc with some ubuntu
   user, -- the prob was nautilus trying to display background picture.
   The solution for that user was to recompile compiz without the
   above-mentioned patch and specify SKIP_CHECKS.  (It is because
   almost all radeon cards actually works just fine with larger
   texture sizes).

For the case "1" above, I'm not sure that running a fallback WM is any
good idea at all, at least from the compiz binary itself (I'm not 
talking about the case "2" here).  How about just exiting with some
known exit code, and have a small wrapper script that does all the
guesswork (if needed) and can be modified and is at least transparent 
for the users?  Note that it took me quite some energy (and several new
non-friends in #compiz) to figure out that the problem is actually in
debian changes and not in original compiz...

Some background on all this:  I run diskless workstations (X terminals) 
here off a single image, and they're run compiz if available, so there 
should be a way to fall back to a _specified_ WM in case compiz does not
see enough hardware support.  Also, when logging in remotely compiz 
refuses to start and i'm getting WM-less environment as the result, and 
I'm logging in remotely to my home machine quite often -- from a 
notebook which I use just as an X terminal, because all my files and my
other environment is on my main PC and it is multi-user machine.
So in both this scenarios, I need reliable fallback.  Which does not
exist in debian version but is quite easy to get in official compiz.

Thanks!

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (990, 'stable'), (60, 'testing'), (50, 'unstable'), (1, 
'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.33-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages compiz depends on:
ii  compiz-core   0.8.4-3OpenGL window and compositing mana
ii  compiz-gnome  0.8.4-3OpenGL window and compositing mana
ii  compiz-gtk0.8.4-3OpenGL window and compositing mana
ii  compiz-plugins0.8.4-3OpenGL window and compositing mana

compiz recommends no packages.

Versions of packages compiz suggests:
ii  compizconfig-settings-manager 0.8.4-2Compizconfig Settings Manager

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org