[Bug 1942616] Re: Settings Power says high hardware temperature
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 is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1942616 Title: Settings Power says high hardware temperature To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/power-profiles-daemon/+bug/1942616/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1942616] Re: Settings Power says high hardware temperature
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 control panel sets the Energy Performance Preference (EPP) of the CPU to high performance. While maybe not very useful, it's still possible technically to have Turbo Boost off and EPP set to high performance, and I don't see why it shouldn't be possible through Gnome. I suspect Gnome checks the "no turbo" flag as a thermal trip indicator, which it is not. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1942616 Title: Settings Power says high hardware temperature To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/power-profiles-daemon/+bug/1942616/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] Re: Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
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 anything
else than the refreshing rate that's on the preferred (i.e. first
mentioned on EDID) DTD.
However, it seems to me the first DTD usually has the highest refresh
rate, which makes your problem strange. Could that mean the 60 Hz DTD is
the preferred one on your laptop's panel, despite it being able to go up
to 135 Hz ?
Also, are you sure you're using true Xorg, not Xorg on Wayland ? Bcos on
any readings on the latter would be mostly irrelevant as they don't
necessary reflect the reality (Xorg on Wayland being only a
compatibility layer). From what I've seen, when asking for a reduced
refresh rate, even if it fails, Wayland seems to try to near the target
refresh rate by syncing frames to a factor of the effective refresh
rate. That's why on a previous post, when trying to get 60Hz on my
144Hz-capable monitor, I was getting 72 fps with glxgears... But in your
case of trying to get 135 from an effective 60, Wayland surely can't do
this trick.
Anyway, you can get the EDID from sysfs easily. On my current config,
mine is in /sys/class/drm/card0-eDP-1/edid. You should have something
similar. To quicky decode the EDID, you can use edid-decode (from the
edid-decode package), most basically like this :
edid-decode /sys/class/drm/card0-eDP-1/edid
Then you can create a modified, hex-edited EDID file, with the two DTDs
swapped, put it somewhere under the /lib/firmware directory and add the
following in a file inside /etc/modprobe.d :
options drm edid_firmware=eDP-1:mydir/myedid.bin
eDP-1 is your connector name, for me it's eDP-1 but for you it can be
something else. You can also omit "eDP-1:", in which case the EDID will
apply to all connectors. While I didn't check myself, I suppose it will
be a problem if you plug your laptop on an external monitor.
Also, if the module is loaded while the system is still on the initramfs, it
won't work since your modified EDID won't be there, hence you will have to add
it with an initramfs hook in /etc/initramfs-tools/hooks. The file should look
like this :
--- File starts after this line -
#!/bin/sh
PREREQ=""
prereqs () {
echo "$PREREQ"
}
case "$1" in
prereqs)
prereqs
exit 0
;;
esac
. /usr/share/initramfs-tools/hook-functions
copy_file edid /lib/firmware/mydir/myedid.bin
- File ends before this line -
Make the file belong to root:root and mode 555 (readable/executable by
all). You should then update your initramfs with update-initramfs -u (to
update the initramfs for the current running kernel) or update-initramfs
-u -k all (to update for all installed kernels, or you can specify a
kernel). And reboot...
Hope this helps !
--
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:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896250] Re: SDL support is missing while virglrenderer has problems with GTK
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. Additionally, SDL has the advantage of completely grabbing the keyboard, as I remember having the problem that a Ctrl-Alt-Del wasn't caught using GTK (but maybe I don't remember correctly, because that sounds odd), while it clearly works fine with SDL. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896250 Title: SDL support is missing while virglrenderer has problems with GTK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1896250/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1628707] Re: Highlighting a region in emacs is invisible because region color equals window color
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 => Customize Emacs => Top-level Customization Group, and from there going to the following subgroups : Faces => Basic Faces. Scroll down to the region face, and choose the background of your choice. Then, go back up in the buffer, click Apply and save and you're done. You could also choose another theme instead : Options => Customize Emacs => Custom Themes. Choose your theme and click Save Theme Settings. ** 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/1628707 Title: Highlighting a region in emacs is invisible because region color equals window color To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1628707/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1628707] Re: Highlighting a region in emacs is invisible because region color equals window color
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 appropriate bg color and seems to default to this almost invisible light grey. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1628707 Title: Highlighting a region in emacs is invisible because region color equals window color To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1628707/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 364874] Re: Copy/Paste Can't Handle Nonprinting Characters
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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/364874 Title: Copy/Paste Can't Handle Nonprinting Characters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ghex/+bug/364874/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] Re: Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
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 "1920x1080": 60 342060 1920 1968 2000 2080 1080 1090 1095 2740 0x40 0xa [ +0,30] i915 :00:02.0: [drm:intel_dump_pipe_config [i915]] adjusted mode: [ +0,81] [drm:drm_mode_debug_printmodeline [drm]] Modeline "1920x1080": 144 342060 1920 1968 2000 2080 1080 1090 1095 1142 0x48 0xa As a side note, on Wayland sessions, it seems it tries to behave like it did switch to 60Hz, with glxgears vsyncing at around 70Hz. Strange... I suppose I should go upstream for this bug, since it doesn't seem it will be addressed any time soon here. I didn't mod my EDID yet, but the workaround likely still works. I will come back if it doesn't. -- 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: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] Re: Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
** 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: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1396379] Re: installer uses first EFI system partition found even when directed otherwise
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. https://bugs.launchpad.net/bugs/1396379 Title: installer uses first EFI system partition found even when directed otherwise To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1396379] Re: installer uses first EFI system partition found even when directed otherwise
** 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913672] Re: gnome-shell 3.38.2-1ubuntu1~20.10.1 is crashing with assertion failures in st_bin_get_preferred_width
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. https://bugs.launchpad.net/bugs/1913672 Title: gnome-shell 3.38.2-1ubuntu1~20.10.1 is crashing with assertion failures in st_bin_get_preferred_width To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1913672/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913672] Re: gnome-shell 3.38.2-1ubuntu1~20.10.1 is crashing with assertion failures in st_bin_get_preferred_width
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 here : https://people.canonical.com/~ubuntu-archive/phased- updates.html Considering all those first go through proposed, the phasing system is an ultimate security system in case something slipped through, which should happen rarely. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913672 Title: gnome-shell 3.38.2-1ubuntu1~20.10.1 is crashing with assertion failures in st_bin_get_preferred_width To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1913672/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1913672] Re: gnome-shell 3.38.2-1ubuntu1~20.10.1 is crashing with assertion failures in st_bin_get_preferred_width
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 seems to me it should at least collect some data before phasing out, so maybe the bug is somewhere else or it has been blocked manually... The qemu package looks affected too, maybe it's not a coincidence that it has been published only a few days before : https://launchpad.net/ubuntu/groovy/amd64/qemu -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1913672 Title: gnome-shell 3.38.2-1ubuntu1~20.10.1 is crashing with assertion failures in st_bin_get_preferred_width To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1913672/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1897765] Re: gnome-shell crashed with signal 5 in g_log("Error in freeze/thaw accounting") from meta_window_actor_thaw() from WindowManager::_sizeChangedWindow
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
anything wrong with this fix ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1897765
Title:
gnome-shell crashed with signal 5 in g_log("Error in freeze/thaw
accounting") from meta_window_actor_thaw() from
WindowManager::_sizeChangedWindow
To manage notifications about this bug go to:
https://bugs.launchpad.net/mutter/+bug/1897765/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896250] Re: SDL support is missing while virglrenderer has problems with GTK
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 crash, but it's an Android crash. Not sure to what extent it could be used for diagnosis though... And honestly, I don't think trying Qemu 5.1 will change anything ! You're right, I will have to report this to the mailing list (along with that other bug I'm patching, which I did on their IRC channel, but no one was responding). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896250 Title: SDL support is missing while virglrenderer has problems with GTK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1896250/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] Re: Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
** 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: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896250] Re: SDL support is missing while virglrenderer has problems with GTK
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 problem, using a dedicated Unix socket to exchange device- related data, but never managed to even have it correctly set up, maybe I should try again... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896250 Title: SDL support is missing while virglrenderer has problems with GTK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1896250/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896250] Re: SDL support is missing while virglrenderer has problems with GTK
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 comes from virglrenderer... but we'll see ! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896250 Title: SDL support is missing while virglrenderer has problems with GTK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1896250/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896250] Re: SDL support is missing while virglrenderer has problems with GTK
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 seems indeed that Fosshub has a hosting problem with the Android-x86 images, I'll have to report this to the project maintainer. You seem to experience the same crash as I do. Bootloader OK, the GUI is responsive at the beginning, and it crashes after a variable amount of time. You're right, the bug #1898490 looks like it could be related, I don't see the virgl=on option, but I suppose it's on by default. I normally have those messages on my Qemu instance : gl_version 45 - core profile enabled GLSL feature level 430 virtio_input_hid_handle_status: unknown type 20 virtio_input_hid_handle_status: unknown type 20 The virtio_input_hid messages don't seem to be a problem, and certainly unrelated to the Android 9.0 crashing problem since at the time I tried with other, non-virtio input devices, I didn't have that message but it was still crashing the same way. It happens that I have that "stale GL error" from time to time, that almost always corresponds to an app not displaying properly in Android. Generally, quitting and restarting the app solves the problem, but not always, there are cases and Android apps that never worked correctly with virglrenderer, such as Armello. So, virglrenderer seems less stable with Android (or is it virtio-vga ?). In particular, switching from the surfaceflinger OpenGL display to a VGA, non-OpenGL console display (Alt+F1) never worked correctly (Alt+F7 to go back to the surfaceflinger display). However, as I said before, it seems to me it shouldn't behave differently depending on which display, GTK or SDL, is used. Concerning other frontends, I'm not familiar with those since my setup isn't headless : I'm not a server guy, I run the emulator on my laptop, so apart from GTK and SDL, it's not clear to me if I could run something else that would give me 3D acceleration. Moreover, my hardware is more than 6 years old now, and lacks some virtualisation capabilities that could serve as an alternative to virglrenderer. Anyway virglrenderer is still pre 1.0 so I guess it's the prime suspect after all. I will upgrade to Groovy next month, I'll keep you informed on that (I may even try Qemu 5.0 before upgrading). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896250 Title: SDL support is missing while virglrenderer has problems with GTK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1896250/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896250] Re: SDL support is missing while virglrenderer has problems with GTK
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 : https://www.android-x86.org/ You can choose Download from there, and you will be presented with two options, download from Fosshub, or download from OSDN. I gave the Fosshub link. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896250 Title: SDL support is missing while virglrenderer has problems with GTK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1896250/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896250] Re: SDL support is missing while virglrenderer has problems with GTK
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) : https://www.fosshub.com/Android-x86.html?dwl=android-x86_64-9.0-r2.iso Then boot the image in Qemu : qemu-system-x86_64 -machine q35,vmport=off -cpu host -accel kvm -smp 2 -m 4G -audiodev pa,id=pasound,timer-period=5000 -device ES1370,audiodev=pasound -device virtio-vga,virgl=on -device virtio-mouse -device virtio-keyboard -drive file=android-x86_64-9.0-r2.iso,if=virtio,media=cdrom,format=raw,readonly=on -display gtk,gl=on -usb -nodefaults -monitor vc -nic user,hostfwd=tcp:127.0.0.1:-: It shouldn't take long before the screen freezes. Here's the associated log entry : - LOG START - 10-05 01:00:18.548 1147 1259 F libc: Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xe8 in tid 1259 (frame-worker), pid 1147 (surfaceflinger) 10-05 01:00:18.565 4406 4406 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 10-05 01:00:18.565 4406 4406 F DEBUG : Build fingerprint: 'Android-x86/android_x86_64/x86_64:9/PI/lh03251128:userdebug/test-keys' 10-05 01:00:18.565 4406 4406 F DEBUG : Revision: '0' 10-05 01:00:18.565 4406 4406 F DEBUG : ABI: 'x86_64' 10-05 01:00:18.565 4406 4406 F DEBUG : pid: 1147, tid: 1259, name: frame-worker >>> /system/bin/surfaceflinger <<< 10-05 01:00:18.565 4406 4406 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xe8 10-05 01:00:18.565 4406 4406 F DEBUG : Cause: null pointer dereference 10-05 01:00:18.565 4406 4406 F DEBUG : rax rbx 7eb0cc0585b0 rcx rdx 7eb0d2a9cc08 10-05 01:00:18.565 4406 4406 F DEBUG : r8 r9 r10 r11 0246 10-05 01:00:18.565 4406 4406 F DEBUG : r12 0001 r13 7eb0d30d7050 r14 001e r15 7eb0d30d7100 10-05 01:00:18.565 4406 4406 F DEBUG : rdi rsi fff0 10-05 01:00:18.565 4406 4406 F DEBUG : rbp 7eb0ccf01400 rsp 7eb0ccf01310 rip 7eb0cd2892ac 10-05 01:00:18.566 4406 4406 F DEBUG : 10-05 01:00:18.566 4406 4406 F DEBUG : backtrace: 10-05 01:00:18.566 4406 4406 F DEBUG : #00 pc 000202ac /system/vendor/lib64/hw/hwcomposer.drm.so (android::DrmDisplayCompositor::CommitFrame(android::DrmDisplayComposition*, bool)+668) 10-05 01:00:18.566 4406 4406 F DEBUG : #01 pc 0001e72b /system/vendor/lib64/hw/hwcomposer.drm.so (android::DrmDisplayCompositor::ApplyFrame(std::__1::unique_ptr>, int)+27) 10-05 01:00:18.566 4406 4406 F DEBUG : #02 pc 0001e68e /system/vendor/lib64/hw/hwcomposer.drm.so (android::DrmDisplayCompositor::FrameWorker::Routine()+318) 10-05 01:00:18.566 4406 4406 F DEBUG : #03 pc 000372e8 /system/vendor/lib64/hw/hwcomposer.drm.so (android::Worker::InternalRoutine()+72) 10-05 01:00:18.566 4406 4406 F DEBUG : #04 pc 00037466 /system/vendor/lib64/hw/hwcomposer.drm.so (_ZNSt3__114__thread_proxyINS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_MN7android6WorkerEFvvEPS8_EPvSD_+54) 10-05 01:00:18.566 4406 4406 F DEBUG : #05 pc 00092bfb /system/lib64/libc.so (__pthread_start(void*)+27) 10-05 01:00:18.566 4406 4406 F DEBUG : #06 pc 0002af0d /system/lib64/libc.so (__start_thread+61) - LOG END - It seems the problem doesn't happen when using the Android 8.1-r3 image, or I didn't try long enough. As I said, using SDL "solves" the problem. One could argue the problem is with Android itself, but then why would it react differently depending on which frontend, GTK or SDL, is used ? Shouldn't it be transparent to the emulated system ? I saw other people reporting the problem on a russian forum (don't remember which one), not anywhere else (I searched only for Android problems with virglrenderer). I had to translate since I'm not russian myself (I'm french). Interestingly, shortly after reporting the bug here, I was contacted by a Russian who confirmed he had the same problem. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896250 Title: SDL support is missing while virglrenderer has problems with GTK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1896250/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] Re: Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
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 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: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] Re: Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
** 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 to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1896250] [NEW] SDL support is missing while virglrenderer has problems with GTK
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 Qemu's GTK frontend and virglrenderer were interacting badly. That may very well be a problem with virglrenderer, not Qemu, but still, using SDL is a good way around it. Currently it doesn't change anything for me as I have to rebuild to insert a personal patch anyway, but I thought it may be worth mentioning, since people may experience problems with virglrenderer they don't know how to solve. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: qemu-system-x86 1:4.2-3ubuntu6.6 ProcVersionSignature: Ubuntu 5.4.0-47.51-generic 5.4.55 Uname: Linux 5.4.0-47-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.8 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri Sep 18 15:30:22 2020 InstallationDate: Installed on 2019-09-22 (361 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) KvmCmdLine: COMMAND STAT EUID RUID PIDPPID %CPU COMMAND MachineType: Notebook P17SM-A ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-47-generic root=UUID=788f8a5e-9667-4cfb-abf4-bc76ebcb86bb ro quiet splash mtrr_spare_reg_nr=0 vt.handoff=7 SourcePackage: qemu UpgradeStatus: Upgraded to focal on 2020-05-16 (124 days ago) dmi.bios.date: 03/27/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.5 dmi.board.asset.tag: Tag 12345 dmi.board.name: P17SM-A dmi.board.vendor: Notebook dmi.board.version: Not Applicable dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd03/27/2014:svnNotebook:pnP17SM-A:pvrNotApplicable:rvnNotebook:rnP17SM-A:rvrNotApplicable:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: Not Applicable dmi.product.name: P17SM-A dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: Notebook ** Affects: qemu (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896250 Title: SDL support is missing while virglrenderer has problems with GTK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1896250/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1851123] Re: Ubuntu 19.10 and focal live cloned create and mount casper-rw partition
@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 things : 1. Create a partition that occupies the remaining space on the USB stick, hence preventing the live image from creating (and writing to) one without my consent 2. Create a custom Grub config file on the EFI partition on the stick, specifying my own parameters The first solution is the most straightforward, has the advantage the stick can be used for additional purposes, but the inconvenient that it's hardware-dependent (not all sticks have the same size). To have the integrity check work, I would have to rehash after modifying, and maintain different hashes, one hash per stick. The second solution requires more changes, but would work for all sticks. It probably won't work if I boot the stick on a non-EFI BIOS though. For integrity-checking purposes I would have to rehash too, but would only require one hash for all sticks. Concerning your change proposal, adding an additional entry to Grub solves indeed the problem of risking a typo compared to having to type "nopersistent" and/or "toram" at every boot, to avoid undesired writes. However, it still requires to never forget interrupting the boot process. @mwhudson : Imho, the current situation of the 19.10 live image can be considered a bug, since it changes a default that has been there for more than a decade, and that's in many minds, that a live OS image is volatile. That's not due to a coding error, like most bugs are, but rather in comparison to usually expected behaviour, or "untold specification". Moreover, your reasons for wanting it to become a default are unclear, especially considering that the ones who want persistence could achieve that by passing a one-time option at boot, and being OK for subsequent boots, which obviously people who don't want persistence can't do, precisely because they don't want persistence. For these reasons it can be worth clarifying, outside of a bug process why not. I just started a thread : https://ubuntuforums.org/showthread.php?t=2431843 -- 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 partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1851123/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1851123] Re: Ubuntu 19.10 and focal live cloned create and mount casper-rw partition
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 partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1851123/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1851123] Re: Ubuntu 19.10 and focal live cloned create and mount casper-rw partition
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 consequences in the long term. May a bug arise, there is an increased probability that it would behave destructively, especially considering that we're facing scripted automatic partitioning, which isn't quite the least potentially destructive operation. On one hand, I understand there are use cases when people want to have installer logs handy on their stick, and having to pass "persistent" each and every time on the command line can be a problem. But On the other hand, there are people who don't want their USB stick written to for several reasons, one being to perform an integrity check before booting (such an unattended write operation would make subsequent integrity checks fail). The only option for these users is to remember adding "nopersistent" each and every time, and with no typing mistake of course, and not forgetting to interrupt the boot process, otherwise there's a write, and it's too late. It seems to me there should be a solution to make both worlds happy, such as requiring people who want log persistence to pass "persistent" or why not "persistent-log" once on the command line. The system would then create the partition the way it's currently done by default, and during further boots with the default parameters, the system would check if a "casper-rw" volume exists on the live support, and if yes, mount it rw. Additionnally, to address @cscameron's remark, it could be indeed useful to be able to limit the space automatically allotted to casper-rw on the live medium, such as defining an additional parameter to specify its size, either absolute or relative (as a percentage), but another solution that's already working is to create and format the volume manually (don't forget to label "casper-rw") and specify its size, which is a one time operation, hence should not be too much of a burden. -- 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 partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1851123/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1852368] [NEW] 19.10 live image has persistence enabled by default
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 /var/crash and /var/log. Passing the "nopersistent" parameter prevents that behaviour. I tried on a specially crafted disk image on qemu comprising the unmodified live image, followed by 1 GiB of zeroes, to simulate a USB stick with some remaining space. I didn't have that problem with the 19.04 live image, on the exact same hardware. Could it be that the system now interprets my USB stick as non-removable media, hence assuming persistence as the default, or is everyone else affected ? Defaulting to persistence poses problems : - integrity checks on the USB stick fail, since it the partition table has been modified - Despite passing the "toram" parameter, the USB stick can't be ejected without performing additional operations ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: casper (not installed) ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1 Uname: Linux 5.3.0-19-generic x86_64 ApportVersion: 2.20.11-0ubuntu8.2 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Nov 13 03:38:19 2019 InstallationDate: Installed on 2019-09-22 (51 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) SourcePackage: casper UpgradeStatus: Upgraded to eoan on 2019-11-01 (11 days ago) ** Affects: casper (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug eoan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1852368 Title: 19.10 live image has persistence enabled by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1852368/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845801] Re: [nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login.
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 gnome-session-binary fixes it, or just not using automatic login. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1845801/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845801] Re: [nvidia] Automatic login fails and then all subsequent logins fail. Killing gnome-session-binary fixes it, or just not using automatic login.
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 need for fancy graphics before that, and I'm sure even people encrypting their root fs could be happy with an "ugly" password prompt. I mean, fancy graphics are nice, but that's worth nothing if the system is unbootable, and playing with the early boot process shouldn't be done lightly. I too had problems with my system being unbootable after upgrade (related to the Nvidia driver too), and among other things I removed everything that was setting the FRAMEBUFFER initramfs option, because that's what brings the Nvidia driver in the initramfs. I wasn't sure that solved my problem though, but now that I read that removing the splash option from the kernel command line solves a similar problem, I'm thinking about it again... On my laptop, two files were setting the FRAMEBUFFER option : /etc /initramfs-tools/conf.d/splash that was created upon installing the MATE desktop environment, and a configuration hook script that was installed by the crypsetup-initramfs package. I removed the first file and purged the crypsetup-initramfs package, and got no more Nvidia GPU driver in the 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 gnome-session-binary fixes it, or just not using automatic login. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1845801/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] Re: Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
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 from dmesg (ISO date format) : 2019-11-04T16:39:13,088276+01:00 [drm:intel_dump_pipe_config [i915]] requested mode: 2019-11-04T16:39:13,088290+01:00 [drm:drm_mode_debug_printmodeline [drm]] Modeline "": 0 92450 1920 1968 2000 2080 1080 1083 1088 0x0 0x9 2019-11-04T16:39:13,088323+01:00 [drm:intel_dump_pipe_config [i915]] adjusted mode: 2019-11-04T16:39:13,088336+01:00 [drm:drm_mode_debug_printmodeline [drm]] Modeline "1920x1080": 60 140490 1920 1972 2007 2094 1080 1083 1089 1118 0x48 0x9 So it's the current 19.10 kernel (5.3.0-19-generic). I'm considering trying v5.4-rc5. I will report back once (and if) it's done. -- 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: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] Re: Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
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 40Hz are "adjusted" back to 60Hz To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1848746] [NEW] Refresh rate change requests to 40Hz are "adjusted" back to 60Hz
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 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"" 0 92450 1920 1968 2000 2080 1080 1083 1088 0x0 0x9 oct. 18 16:27:24 NovHak-P2 kernel: [drm:intel_dump_pipe_config [i915]] adjusted mode: oct. 18 16:27:24 NovHak-P2 kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1920x1080" 60 140490 1920 1972 2007 2094 1080 1083 1089 1118 0x48 0x9 I managed to have 40Hz through EDID modification, swapping the two DTDs it contains, one being 60Hz, the other 40Hz, hence placing the 40Hz DTD first, but then it remains sticked to 40Hz and unable to switch to a 60Hz mode. I suppose the bug is i915-related rather than Xorg-related, since the modelines seem correctly sent for KMS. I can provide additional information if needed. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: linux-image-generic 5.0.0.32.33 ProcVersionSignature: Ubuntu 5.0.0-32.34-generic 5.0.21 Uname: Linux 5.0.0-32-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC2: olivier 12097 F pulseaudio /dev/snd/controlC0: olivier 12097 F pulseaudio /dev/snd/controlC1: olivier 12097 F pulseaudio CurrentDesktop: ubuntu:GNOME Date: Fri Oct 18 16:43:01 2019 InstallationDate: Installed on 2019-09-22 (26 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) MachineType: Notebook P17SM-A ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=fr_FR.UTF-8 SHELL=/bin/bash ProcFB: 0 inteldrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.0.0-32-generic root=UUID=788f8a5e-9667-4cfb-abf4-bc76ebcb86bb ro quiet splash mtrr_spare_reg_nr=0 vt.handoff=1 RelatedPackageVersions: linux-restricted-modules-5.0.0-32-generic N/A linux-backports-modules-5.0.0-32-generic N/A linux-firmware1.178.3 SourcePackage: linux UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/27/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.5 dmi.board.asset.tag: Tag 12345 dmi.board.name: P17SM-A dmi.board.vendor: Notebook dmi.board.version: Not Applicable dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: To Be Filled By O.E.M. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd03/27/2014:svnNotebook:pnP17SM-A:pvrNotApplicable:rvnNotebook:rnP17SM-A:rvrNotApplicable:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.: dmi.product.family: Not Applicable dmi.product.name: P17SM-A dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: Notebook ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug disco ** Attachment added: "Modified EDID" https://bugs.launchpad.net/bugs/1848746/+attachment/5298241/+files/EDID-modded.bin -- 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: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1848746/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 873929] Re: X freezes after login on iMac8.1 after upgrade to oneiric
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 drivers and the system should fall back to nouveau. IMHO nouveau is the best you can get if you don't have a proprietary driver supporting your GPU. If you're a perfectionist, you can even purge the remnants of the nvidia drivers, get a list with : dpkg -l 'nvidia*' You will notice some packages have the status flags rc which means they're removed/scheduled for removal (r), and configuration files remain (c). Then do an apt-get purge followed by the names of those nvidia rc packages separated by spaces... But don't remove nvidia- common ! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/873929 Title: X freezes after login on iMac8.1 after upgrade to oneiric To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/873929/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 873929] Re: X freezes after login on iMac8.1 after upgrade to oneiric
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 here, it freezes anyway after some time waiting at the login screen. I have the same strange /proc/driver/nvidia/params too (I don't think the value 4294967295 is anything like normal where it appears). A few system BIOS/vBIOS flashes didn't change anything. If you dare breaking your distribution's packaging system, you could try an old version of the driver (but NOT the legacy 173 one) from nVidia's website. Eventually it used to work in the past, with older drivers, it started freezing with last summer's drivers if I remember correctly... but those older drivers had problems anyway, most notably with flash players. I have been suspecting a buggy BIOS, especially the ACPI DSDT, since I got ACPI-related error messages. You share at least one with me : [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored Booting with acpi=off doesn't solve it though, at least for me. Anyway, can't help thinking our problems are related. The 8800M GTS and 8800M GTX are similar, both G92M, and released the same day by nVidia... I will come back if I ever find a solution to this ! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/873929 Title: X freezes after login on iMac8.1 after upgrade to oneiric To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/873929/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 111939] Re: Not possible to alt-tab during a drag-and-drop operation
** 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 https://bugs.launchpad.net/bugs/111939 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
