The workaround for me was to disable vt_handoff in /etc/grub.d/10_linux*
(i.e. set vt_handoff=0 in both places near the top of the file).
That resolved the issue completely.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-session i
This is still happening in Ubuntu 19.10, and I'm all but certain it will
continue to happen with 20.04 when I upgrade to it. I'll verify next
weekend when I finally have time for the upgrade.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed t
This bug needs to be fixed for those of us that don't use unity and only
rely on gnome-shell. The problem seems to have been diagnosed to compiz,
and thus the fix should be focused there so that it's not unnecessarily
tied to unrelated packages (i.e. unity, as was the fix mentioned above).
--
You
The problem has been narrowed down to when the headset is actually
charging - either through to the computer's USB ports or via a wall-
socket charger (any micro-USB charger with 0.5A output will suffice).
When the headset is unplugged (i.e. fully wireless), everything works
fine. But when the hea
Still seeing this with gnome-online-accounts-3.8.3-2 on Saucy.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to evolution-data-server in Ubuntu.
https://bugs.launchpad.net/bugs/1175122
Title:
Doesn't work with Google 2-Factor Authentica
Nevermind my last comment. It appears that "someone else" had replaced
the original packages with the ones from the gnome3-team/gnome3 ppa, and
those did need the mentioned workaround.
The VPN indicator also seems to have been fixed by rolling back the
packages and the workaround.
--
You receive
I can confirm that on Ubuntu Saucy with gnome-control-
center-3.8.5-0ubuntu1~saucy the problem persists. A workaround was to
hard-link the files to the correct location (/usr/lib/x86_64-linux-
gnu/NetworkManager/) from the installation location from the plugin
packages (/usr/lib/NetworkManager/).
Ok...your latest suggestion (pulseaudio analog-input.conf.common
modifications) had no effect. The defect is still present.
Let me know if you'd like me to test something else.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to alsa-driver
The simplest definition of the bug is that after bootup, the actual
state of the emu20k2 hardware is not accurately reflected in the
software (alsamixer, alsactl store). The easiest observable effect (in
my case) is the PCM Capture switch - it shows off even though it's
functioning as if it were o
No effect for the default volume levels setting, the same behavior
continues (tested repeatedly).
No idea how to test the other thing you mention, since there's no
mention of "PCM Capture" anywhere in those pulseaudio files. Can you
offer up a concrete example of what you'd like me to add, and to
You lost me - what's the o'clock capture switch? How do I set it? What
are the permissible values? It's not documented in the alsactl man page
either.
If you give me an example I'll be more than happy to test and relay the
results.
--
You received this bug notification because you are a member o
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1133065
Title:
Default mixer settings for EMU20K2 enable PCM Input on boot while
showing it as disabled
Status in “alsa-driver” pa
As expected, login-logout had no effect. Therefore, it's safe to assume
the bug only manifests on a fresh boot. This reinforces the idea that
it's either "something" changing the card's state behind ALSA'S back, or
ALSA not properly restoring state to the card. The fact that alsactl
restore fail
Yes, precisely.
Take this sequence:
Start up the machine
Boot to Ubuntu
Log in
Open sound input settings (gnome-control-center sound, input tab)
Play some music
The input indicator moves with the music clearly denoting that the PCM
capture is enabled. However, alsactl store
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1133065
Title:
Default mixer settings for EMU20K2 enable PCM Input on boot while
showing it as disabled
Status in “alsa-driver” pa
There would be a simple workaround if any of the command-line utilities
for alsa would allow me to change specific mixer settings. A script
could easily be devised to simply turn PCM Input on, then off, and that
would be that. Sadly, to my knowledge no such utility exists.
--
You received this
Public bug reported:
Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it
shows as disabled (muted) in alsamixer. One has to enable it and
disable it in alsamixer in order to ensure sound does not "leak" out.
This is unaffected by alsactl store/restore - even if the asound.sta
Yes, it still occurs with nVidia drivers at 295.49, even 295.53.
Videos are also choppy in standalone totem. gst123 works fine, so it
would appear that the problem is within totem itself and not the
gstreamer libraries. mplayer-based players work fine (except mplayer2).
--
You received this bug
** Attachment added: "VID_20120429_171350.mp4"
https://bugs.launchpad.net/bugs/994864/+attachment/3130829/+files/VID_20120429_171350.mp4
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to totem in Ubuntu.
https://bugs.launchpad.net/bugs/
Public bug reported:
When trying to play MP4 videos captured from my Galaxy Nexus and copied
to the local hard drive, video playback in Totem is choppy. VLC has no
problem.
Videos used to work fine in Totem in Natty and Oneiric. It appears that
Totem is maxing out the core upon which it's runni
Ditto for Facebook:
http://developers.facebook.com/docs/reference/api/user/
I'm almost positive all the others contain this information as well.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gwibber in Ubuntu.
https://bugs.launchpad.ne
To-whit, I found this:
https://dev.twitter.com/docs/api/1/get/account/settings
The JSON object contains timezone information which can be used to
determine which timezone the account is configured to. Thus, it can be
used to calculate the UTC time that the message came in under. That's
Twitter d
I get it - the problem is the message source (Twitter, in this
particular case), not Gwibber. Fair enough.
So is there an API from the actual service(s) to attempt to get the
timezone configured for the account? What I'm thinking is that Gwibber
*should* (ideally) store all timestamps relative t
Public bug reported:
While researching to build a script that would automatically purge
messages older than X amount of time from the SQLite database, I found
that the "from the epoch" timestamps being stored in messages.time
aren't really "from the epoch".
As per all definitions, "the epoch" sta
24 matches
Mail list logo
