A post was split to a new topic: Error: extra database is inconsistent
symlink removed and octopi works. my operational fix definition: getting an update-broken app to run. I’ll call it “work around” next time.
In the past, SDDM seemed to remember which session I started, either the X11 or Wayland session.
Now, it appears to just go straight to Wayland on a new start, regardless of the previous selection. Is there a workaround for this bug?
Edit: I’ve also got pamac crashing on me, when trying to do updates 
If anything it should be the opposite as manjaro patched it to default to x11 (and then we had reports of people who had been using wayland being switched to x11 by default).
Interesting, I seem to lack that patch. Is it recent? Perhaps my mirror isnt updated yet?
Edit: I see in /etc/sddm.conf.d/ I have 00_manjaro_settings.conf and kde_settings.conf (and virtualkeyboard.conf). The manjaro file just sets the theme to breath, the kde file sets autologin to use the wayland session (Session=plasma).
i use X11 session (mostly), the recent update to plasma 6.0.5 made SDDM switch to wayland without me noticing, in the next loggin-in. no biggie, after logging out and loggin in with X11 session now SDDM defaults to X11 session.
4 Likes
I see spectre-meltdown-checker and manjaro-settings-manager-kcm being dropped from the repos 
The former is barely maintained upstream and has been causing more confusion that usefulness. It’s just a script designed to be used in user space anyway.
The latter is not compatible with KDE Plasma 6, so users would have noticed the MSM KCM no longer appeared, anyway. We just forgot to drop it sooner along with the update.
1 Like
FYI, to plasma users. SDDM default session did reset to wayland again in the update from 6.0.5-0 → 6.0.5-1
1 Like
I’ll just share my opinion regarding Plasma 6.1 Beta and NVIDIA 555 drivers, if you are interested. I’ve been testing this for two days and everything works really well, even surprising for beta version. There are no more problems with games in the Wayland session. Some users complain about the problems when using 2 high frequencies monitor, but there is nothing critical and I think this will be corrected to the release of a stable driver 555. There is a small problem with the frameskips, but this is easily solved by the addition of nvreg_enablegpufirmware = 0 in parameters when loading.
1 Like
I’ve tested 555 + 6.0.4 with explicit sync patches and I’ve had a weird problem with fullscreen videos in Firefox, fps drops to 30 and even lower which makes watching videos really bad. It almost feels like vrr kicks in somehow. Do you use vrr? Can you test if this happens in 6.1?
As I wrote earlier, no I don’t see any problems, make sure to add the following parameters: nvidia_drm.modeset=1 nvidia_drm.fbdev=1 nvidia.NVreg_EnableGpuFirmware=0 to GRUB_CMDLINE_LINUX_DEFAULT.
Perhaps this is some kind of problem specific to your equipment.
UPD: Perhaps this topic will be useful for you 555 release feedback & discussion - Linux - NVIDIA Developer Forums
You should have 6.0.5-1.0.
Has anyone else had bluetooth vanish off their system in the last few days? My Realtek RTL8822BE was working fine up until today, I believe, but was definitely working a week ago. Now KDE thinks Ive got no bluetooth adaptor installed.
I’ve had that problem for years with my Comet Lake HP Laptop. I gave up using Bluetooth in LInux.
If the BT driver works, then you have BT, otherwise buy a compatible dongle. I wasted a week of life trying to figure out a driver for my hardware. Please don’t follow my example.
It was working. I was using it daily, have been for months. Its interesting to see it disappear is all. Buying a dongle is not going to help, as there’s already a working chip in there.
Edit: or perhaps its died and gone to heaven? I hope not 
Perhaps I’ll need to look at a dongle…
# dmesg
[ 3322.123868] rtw_8822be 0000:07:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Receiver ID)
[ 3322.123874] rtw_8822be 0000:07:00.0: device [10ec:b822] error status/mask=00000080/00006000
[ 3322.123881] rtw_8822be 0000:07:00.0: [ 7] BadDLLP
That seems relevant.
Edit: and a good chunk of log spam along these lines:
[ 5.260993] usb 1-2: device descriptor read/64, error -71
[ 5.557459] usb 1-2: device descriptor read/64, error -71
[ 5.665265] usb usb1-port2: attempt power cycle
[ 6.133686] usb 1-2: new full-speed USB device number 4 using xhci_hcd
[ 6.160892] usb 1-2: Device not responding to setup address.
I’ve tried turning the bluetooth module off and on again, no dice. I guess I’ll give it a shot from a live USB.
Gnome (unstable)
Upgrade of GDM from version gdm-46.0-1 to gdm-46.2-1
complains:
Gdm: on_display_added: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed
Gdm: on_display_removed: assertion 'GDM_IS_REMOTE_DISPLAY (display)' failed
GDM_IS_REMOTE_DISPLAY (found by "Perplexity")
GDM_IS_REMOTE_DISPLAY is a macro or function defined in the GNOME Display Manager (GDM) codebase. It is used to check if a given display object represents a remote display. In the context of GDM, a remote display refers to a display that is not physically connected to the local machine, but rather accessed over a network or remote connection. This could include displays connected via protocols like VNC, RDP, or X11 forwarding. The GDM_IS_REMOTE_DISPLAY macro is likely used as a type check or assertion to ensure that certain operations or configurations are only applied to remote displays, and not local displays. For example, the code snippet from the GitHub repository shows the macro being used to conditionally set properties on a display object, but only if it is a remote display. The error messages from the Reddit posts suggest that the macro is also used in assertions or sanity checks within the GDM codebase. The error occurs when the assertion fails, indicating that an operation was attempted on a display object that was not a remote display, contrary to the expected condition. In summary, GDM_IS_REMOTE_DISPLAY is a utility macro or function provided by the GDM codebase to differentiate between local and remote displays, allowing for proper handling and configuration of remote display connections within the GNOME desktop environment.
Looks like a report that no external display is found by whatever (GDM).
Summary
Based on the provided search results, the error “GDM_IS_REMOTE_DISPLAY (display)’ failed” occurs when the GNOME Display Manager (GDM) attempts an operation on a display object that is not a remote display, contrary to its expectation.
Cause of the Error
The GDM_IS_REMOTE_DISPLAY macro or function is used within the GDM codebase to check if a given display object represents a remote display (e.g., accessed over a network or remote connection like VNC, RDP, or X11 forwarding) or a local display. This macro is likely used in assertions or sanity checks to ensure that certain operations or configurations are only applied to remote displays and not local displays. The error message suggests that the assertion ‘GDM_IS_REMOTE_DISPLAY (display)’ failed, indicating that an operation was attempted on a display object that was expected to be a remote display, but it was not.
Potential Scenarios
Some potential scenarios that could trigger this error include:
- Incorrect Display Object Type: The display object being operated on is not actually a remote display, but a local display object was passed to a function or code path that expected a remote display.
- Coding Error: There could be a bug or coding error in the GDM codebase itself, where the GDM_IS_REMOTE_DISPLAY macro or function is being used incorrectly or in an unexpected context.
- Environmental Issue: It’s possible that there could be an environmental issue or configuration problem that causes GDM to misidentify a remote display as a local display, or vice versa.
Without more context or access to the specific code paths and execution environment, it’s difficult to pinpoint the exact cause of the error. However, the search results clearly indicate that the error is related to an incorrect assumption or assertion about the type of display object being handled within the GDM codebase.
1 Like
Its June Now
1 Like