this bug still affects me in wine 1.3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/632206
Title:
Wine ( Crossover) cannot activate Securom modules after upgrading to
Maverick
To manage
1.4 even
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/632206
Title:
Wine ( Crossover) cannot activate Securom modules after upgrading to
Maverick
To manage notifications about this bug go to:
@Ricardo Pérez López
Did you enable the workaround in ccsm (compizconfig-settings-manager)? That
needs to be done manually.
--
Screen refresh problems with nvidia on intrepid
https://bugs.launchpad.net/bugs/269904
You received this bug notification because you are a member of Ubuntu
Bugs, which
@Karl Frisk:
Sure, but I only have it for amd64... It's attached, anyway.
(It's labeled ~andersk1 since he made the original patch, I just applied
it as is, without any modification)
** Attachment added: compiz-fusion-plugins-main with glXWaitX() workaround
patch for Intrepid (amd64)
@Anders:
I made my own intrepid package with your patch and haven't experienced
any (or only very minor) issues with the patch enabled (using original
/usr/bin/compiz, I.E. _with_ --loose-bindings and _without_ --indirect-
rendering).
I'm using the 180.37-0ubuntu1 nvidia driver from jaunty, and
@ Christoph Korn:
That is just the kind of display errors I get, albeit not that often...
@ All:
Installing 180.11 drivers makes the situation better for a while, but I did
experience some errors when compiz had been running for a long time (and only
on my external screen (my computer is a
I had very little problems using the 173.xx version in intrepid, and
after installing the 180.11 driver from jaunty (still running intrepid),
the situation seems to be even better =)
To do this (ONLY do this if you are sure about what you are doing, since jaunty
is still in heavy development and
I have this problem since 8.10 rc(-ish), didn't happen while I ran hardy
or in intrepid beta (upgraded on Oct 5). However, it also occurs when I
DON'T use uswsusp.
--
keyboard locked after 2nd hibernate
https://bugs.launchpad.net/bugs/106579
You received this bug notification because you are a
Oh, forgot to mention it doesn't happen every time, only about 20% of
the time or so (still very annoying). I have yet to find a common
cause...
--
keyboard locked after 2nd hibernate
https://bugs.launchpad.net/bugs/106579
You received this bug notification because you are a member of Ubuntu
An update to my last comment:
My brightness keys still work fine, and don't break X. However, my other
Fn-keys (Suspend and battery state) are still broken (only triggers
press events). Strange thing is, the battery state button definitely
worked at least once when I wrote my last comment... I
I think I've found the solution for this problem (I've successfully fixed it on
my laptop anyway).
Because of bug 207473 (or another one of the similar ones), I added blacklist
video to a file in my /etc/modprobe.d/. I accidentally(?) removed it the other
day and suddenly both showkey and X was
I was having this problem in Intrepid beta (amd64) with latest updates.
imwheel crashed every time I log in when it was set to start
automatically in /etc/X11/imwheel/startup.conf. Starting it manually
after it crashed worked just fine.
However, adding imwheel to my gnome session instead of
@kiomava: aplattner's patched compiz made it into the main repositories
(see
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/269904/comments/109).
fimbulvetr's version does contain the patches. The only differences
between ...ubuntu4 and ...ubuntu4~ppa1 should be the build date if I'm
not
showkeys(1) run in console doesn't see Fn+* key releases either (not
even when run with -s, as far as I can see).
--
X never sees brightness key release events
https://bugs.launchpad.net/bugs/261721
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Not to be pessimistic, but has anyone tried the patched compiz on an ATI
card?
--
Screen refresh problems with nvidia on intrepid
https://bugs.launchpad.net/bugs/269904
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
I think I spoke too soon. I experienced some quite bad corruption with a
maximised gnome-terminal running VIM (over SSH on a Debian machine, with
syntax highlighting editing a PHP file).
However, again reverting to -173 but still using the fixed compiz, I
only experienced very minor corruption,
I can confirm it on my Dell XPS M1330. The keys worked fine out of the
box in Hardy but in Intrepid all my Fn+* keys are repeating.
The keyboard lockup problem only occurs for me when gnome-power-manager
is running, and the problem can be removed by reverting the patch from
bug 280646 (I.E. by
Aarons packages seems to solve the problem better than -173 for me. With
-173 I had some corruption when switching context manager tabs in Amarok
(KDE based). I fail to reproduce those problems now.
--
Screen refresh problems with nvidia on intrepid
https://bugs.launchpad.net/bugs/269904
You
Just a heads up to anyone else experiencing this:
An upgrade does indeed fix the problem, however, the mirror I'm using
(se.archive.ubuntu.com) has yet to sync down the package causing the
problem (linux-firmware).
If you can't wait for your mirror to sync properly, the package is
available at
As a sidenote, some more investigation (by my friend) has come to the
conclusion that the faulty pointer doesn't mean :TIME **, it means **
EMIT:...
The full string is ** EMIT: charge-low (only the first 8 bytes are
used as a 64-bit 'pointer').
--
gnome-power-manager crashed with SIGSEGV in
I can confirm that James' patch fixes the problem.
--
gnome-power-manager crashes on low battery
https://bugs.launchpad.net/bugs/269083
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Downgrading to 173 isn't a solution either. I get no noticeable
differences at all between 173 and 177 on my 8400GS.
--
Screen refresh problems with nvidia on intrepid
https://bugs.launchpad.net/bugs/269904
You received this bug notification because you are a member of Ubuntu
Bugs, which is
$ lspci -n | grep 300
01:00.0 0300: 10de:0427 (rev a1)
$ lspci | grep VGA
01:00.0 VGA compatible controller: nVidia Corporation GeForce 8400M GS (rev a1)
--
Screen refresh problems with nvidia on intrepid
https://bugs.launchpad.net/bugs/269904
You received this bug notification because you are a
I decided to try -173 once again and, strange enough, it seems to work
all of a sudden... (Yes, I did reboot after my previous failures.)
Although, this time, I did an 'apt-get remove --purge compiz-core
compiz-wrapper' and also noticed that the USE_EMERALD variable had moved
(?) to
With an Nvidia mobile 8400GS (on a Dell XPS M1330 running Intrepid
64-bit), it happens for me with both the 177 and 173 drivers.
I have almost a 100% reproducibility rate in CompizConfig Settings
Manager (clicking a plugin to show its settings), but the worst thing is
Firefox, since I use it more
I can confirm that running without --loose-bindings fixes the problem.
(A web site I'm working on with lots of mouse-over/hover actions seems
to have 100% reproducibility of this problem.)
I disabled --loose-bindings by commenting out lines 340-344 in
/usr/bin/compiz (which really is a shell
A more simpler fix in /usr/bin/compiz is to change line 80 from
INDIRECT=no
to
INDIRECT=yes
(This change also disables --loose-bindings but at the same time enables
--indirect-rendering)
For me, this seems to give the same performance as the change in my last
comment.
--
Screen refresh
I don't think gstreamer is to blame. I don't get that error, and g-p-m
still segfaults for me when I disable use sound...
Also as said before, somewhere, the engine pointer sent to
gpm_cell_array_charge_low_cb (where the segfault occurs). Strange thing
is athat the pointer Mike's valgrind log
Yesterday, I found out using live CD's that the problem only seems to
exists when using amd64 architecture.
Some thorough investigation by me and a friend (with better C knowledge)
has led us to the macro _G_TYPE_CIT, defined at row 1479 in
gobject/gtype.h of the glib headers. The segfault seems
After some more hours of debugging we have pinpointed the problem to a
(most probable) memory corruption, memory seemingly owned by glib...
(Queue enthusiastic wahoo's.)
As to why or where this is happening, we haven't got a clue (yet?).
More detailed explanation:
The GpmEngine pointer (mostly
I get the same behaviour in version 2.24.0-0ubuntu3.
Also, when I run g-p-m in terminal with --no-daemon --verbose, I get the
following, quite suspicious output:
- ** EMIT: charge-low
** (gnome-power-manager:19145): CRITICAL **:
gpm_cell_array_charge_low_cb: assertion `engine != NULL' failed
*** This bug is a duplicate of bug 269083 ***
https://bugs.launchpad.net/bugs/269083
** Visibility changed to: Public
--
gnome-power-manager crashed with SIGSEGV in gpm_cell_array_charge_low_cb()
https://bugs.launchpad.net/bugs/279285
You received this bug notification because you are a
Some GDB backtracing tells me that the crash seems to happen on line 799
in gpm-engine.c (that is AFTER the ubuntu patches are applied). I fail
to fix it with my limited C knowledge, though...
--
gnome-power-manager crashed with SIGSEGV in g_closure_invoke()
Actually, as far as I can tell, the problem exists (and on the same line
of code, too) even without the ubuntu/debian patches. I couldn't get the
thing to run without having the package installed (whined about gconf
schemas), so my investigations may not be correct. If they are is
correct, though,
Jo,
Well make it a week or two. Running the computer with the electrical
cord in place does not count (although it does add data about how the
battery charges). You can check the progress by right clicking g-p-m in
the system tray, selecting power history and then in that box (near
the bottom),
5of0,
My bet is that use time doesn't help, because gnome-power-manager is
coded to work just like this (I've read the code).
Like I've said in a previous comment
(https://bugs.launchpad.net/ubuntu/+source/gnome-power-
manager/+bug/135548/comments/88), gnome-power-manager WILL NOT DO
ANYTHING
As far as I could tell from the code, Anoop P B has the correct solution
(which I can see from the output of my g-p-m).
If the battery profile of the (primary) battery isn't good enough
(accuracy less than 40%), no action will be taken, and no warnings will
be shown. This is true even if
As I said in my last comment, I would submit my patch when I was done
with it, and here it is.
Cited from the changelog of my patched package:
* Added 11_policy_actions_fallback.patch which makes policy actions
fall back to per-percent policy if the battery profile is not good
enough
If you add yourself to the 'disk' group (run 'sudo adduser yourusername
disk' in a terminal, then log out and back in again), it should work.
** Changed in: eject (Ubuntu)
Sourcepackagename: None = eject
Status: New = Invalid
--
cannot eject USB device (iPod) as non-root
39 matches
Mail list logo
