That's obviously a bug, since it makes the interface inconsistent.
However, it would be interesting to know if setting performance on the
interface actually changes anything, i.e. sets EPP to high performance.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
I confirm the problem on Impish (21.10), and didn't have it on 21.04.
While I have indeed Turbo Boost turned off, it shouldn't behave like
that for two reasons :
- The message is false, there is no temperature problem.
- On CPUs with hardware-driven P-states (HWP) on, the performance mode of the
Hi Cameron,
I didn't go upstream yet. I suppose upstream bugs should be filed to the
Intel Open Source Technology Center (https://01.org/), but I'm not sure.
Or maybe to the Linux kernel since it's an in-tree module after all...
From what I understand, the Intel module fails to switch to
Nice, thanks !
I've got a new laptop in the meantime, where I will likely use Intel's
GVT-g GPU virtualisation feature (my old hardware couldn't), hence no
need for virglrenderer, but of course that's only me. Moreover,
virglrenderer still has the advantage of being hardware-independent.
This problem has been around for a long time now...
It's probably compiled-in, and comes from the region face setup. By
default, the region face background is set to gtk_selection_bg_color,
which must correspond to light grey.
It's possible to change this from the X interface in Options =>
Some more information.
It seems the problem comes from the fact that the concept of a
background color has been deprecated in recent versions of GTK, and no
replacement has been made in the Emacs code :
https://lists.gnu.org/archive/html/bug-gnu-emacs/2017-09/msg01099.html
Emacs fails to load an
That logic is beyond me... One one hand the XConq package is removed,
but on the other hand, this remains untouched during more than ten
years. Considering how largely unusable it is, it should have been
removed ages ago.
--
You received this bug notification because you are a member of Ubuntu
Got a new laptop w/144Hz and 60Hz display frequencies available,
installed Hirsute.
Same problem, this time when trying to switch to 60Hz :
[ +0,82] i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] requested
mode:
[ +0,80] [drm:drm_mode_debug_printmodeline [drm]] Modeline
** Tags added: hirsute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848746
Title:
Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
To manage notifications about this bug go to:
k8s blah blah blah, but such a critical thing has been around for more
than six years. I can imagine how it can undermine the credibility of
Linux for newcomers...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags added: groovy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
To manage notifications about this
Thanks for the info, that's good to know. And btw, is there a place to
report or discuss about the phased-updater, like there is for Ubuntu
packages ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Maybe old bug reports are incorrectly attached to newer packages.
Focal, Bionic and others also have "zombie updates" : update-notifier on
Focal, gnome-calculator and nautilus on Bionic. Those last two have been
zombified more than one year ago (moreover at the same time it seems).
Have a look
I wonder if it could be a bug related to the crash reporting software
instead. What looks strange (but maybe I'm not reading it correctly) is
that the publishing history indicates it was brought back to 0% even
before it was put at 10% : https://launchpad.net/ubuntu/groovy/amd64
/gnome-shell
It
Command line apt users may not notice, but the fix has been phased out
the day it was released on updates, and the percentile has been
remaining at 0% since then.
As a consequence, update-manager users won't get the update. Is it
wanted behaviour (i.e. a manual, explicit phase-out), or is there
While it seems to be a "virtual hardware" problem, I'm not sure the
problem comes from Qemu. Right now the problem doesn't change much for
me, as I have to patch Qemu for another bug that's not yet addressed, so
adding SDL in the process doesn't change anything timewise.
In fact we do have a
** Tags added: groovy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848746
Title:
Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
To manage notifications about this bug go to:
Hi Christian ! I just upgraded to Groovy and it still crashes on my
side.
As before, recompiling w/SDL and using it instead solves the problem.
I remember I tried to use some of those vhost devices (check "qemu-
system-x86_64 -device help | grep vhost") in the hope it would work
around the
I guess the next step would be to confirm that upgrading to Qemu 5.0
solves the problem. I'll try that either by directly compiling 5.0, or
I'll wait until november when I will upgrade to Groovy.
However, I doubt it will really solve the problem, now I tend to stick
to the idea that the problem
Hello Christian,
I should have pointed that the log is from the Android system, not Qemu
or my host system !
I got the failure message running the following command in an Android
shell :
logcat '*:F'
(which means display log entries from all facilities (*), with the Fatal
(F) severity)
It
Hi Paride,
Sorry about that, they probably block direct linking.
Try that link instead : https://www.fosshub.com/Android-x86.html
Then, choose the "Android-x86 64-bit ISO file", version "9.0-r2". If it
still doesn't work, you could try the Android-x86 project web site :
Hi Christian,
Fairly easy to reproduce. I just tried with current qemu (version 4.2.1
(Debian 1:4.2-3ubuntu6.6)).
You need to download the Android 9.0r2 ISO image from the Android-x86
project. Here's a link for the 64-bit image (I chose the non k49 one) :
I switched to Focal in May and the bug is still there. The EDID
workaround still works.
I must be the only one switching to 40Hz sometimes, or it only affects
my GPU, which I doubt (Intel HD Graphics 4600, CPU Core i7-4710MQ).
--
You received this bug notification because you are a member of
** Tags added: eoan focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848746
Title:
Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
To manage notifications about this bug go
Public bug reported:
Disabling SDL support may have its reasons, but I guess that means I may
be the only one using the virglrenderer library, because it has problems
running with the GTK frontend.
I've been emulating an Android 9.0 device since Eoan, and it took me
some time to understand
@nio-wiklund, @mwhudson : Thanks for your replies.
@nio-wiklund : Your solution would probably do the trick, but has the
inconvenient of indiscriminately replacing a string with another in the
whole image, hence possibly in places where it's not desired.
I think I will rather do one of those two
I can raise my concern through another bug for sure, if necessary.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851123
Title:
Ubuntu 19.10 and focal live cloned create and mount casper-rw
Imho, the default behaviour should be overall read-only, as it's more in
line with the general perception of a live system as an "I'm just
looking" thing. Straying away from this concept could make more than a
few people uncomfortable.
Moreover, having a default write behaviour can have adverse
Public bug reported:
I'm not sure it's the correct place to report this...
When I boot from the 19.10 live image on a USB stick (at least my USB
stick, on my computer), the live system creates and formats an
additional partition on my stick, labeled "casper-rw" that's mounted
read-write on
s/crypsetup-initramfs/cryptsetup-initramfs
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1845801
Title:
[nvidia] Automatic login fails and then all subsequent logins fail.
Killing
Interesting. Just my two (Euro) cents, could that be related to the
Nvidia drivers being loaded early in the boot process, and being in the
initramfs ?
Imho, the only things that should reside in the initramfs are the tools
needed for the kernel to get access to the root filesystem, period. No
I made the switch to 19.10 and the problem is the same in the logs.
There is a slight difference however, the screen doesn't flicker any
more upon the change request. I suppose it now detects the adjusted
modeline is the same as the current one, hence nothing to do.
Here's some output extracted
I'll switch to Eoan Ermine in the beginning of November and report back.
Hopefully it will be enough !
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1848746
Title:
Refresh rate change requests to
Public bug reported:
Dear Launchpad readers,
Changes to a 40Hz-based mode are adjusted back to a 60Hz display mode by
KMS, as can be seen in the logs with the drm.debug=4 option :
oct. 18 16:27:24 NovHak-P2 kernel: [drm:intel_dump_pipe_config [i915]]
requested mode:
oct. 18 16:27:24 NovHak-P2
If you're using Oneiric, the only thing you need to do is remove the
nvidia_173 or nvidia_173_updates driver.
The command jockey-text -l will give you what supplementary drivers are
installed, which you can remove with e.g. :
jockey-text -d xorg:nvidia_173
Remove all activated, xorg-prefixed
nvidia-173 is a special legacy driver, which doesn't cover your 8800M
GTS card. Hence don't expect performance... Better try nouveau instead !
I have Oneiric x86_64 too and experience similar problems with my 8800M
GTX, i.e. systematic X freeze shortly after startup. Logging in doesn't
matter
** Bug watch added: Xfce Bugzilla #5578
http://bugzilla.xfce.org/show_bug.cgi?id=5578
** Also affects: xfwm4 via
http://bugzilla.xfce.org/show_bug.cgi?id=5578
Importance: Unknown
Status: Unknown
--
Not possible to alt-tab during a drag-and-drop operation
37 matches
Mail list logo
