Unable to load X11 session after Tumbleweed update:

older
Only economic print quality with...

-pj

7 May 2024 7 May '24

19:36

Hi, I decided to update an i386 Tumbleweed machine here to the latest 20240506 snapshot there were many many packages listed for update (1900+). I used snapper to create a snapshot manually prior to the update. The update appears to have completed fine without incident. I then powercycled the machine. Now when the SDDM desktop display manager is displayed, I am able to select X11 session type then enter my password and login. Once logged in, the desktop is for the most part unusable. Menu button is covered by workspaces, taskmanager is partially blank, (konsole is also unusable). I can then switch to TTY1 and enter my username and password. Passing 'inxi -Gxx' displays the following -> https://paste.opensuse.org/pastes/f42c153b3d71 It appears to me that Xwayland is being used ever though I have selected the X11 session type at SDDM login. Looking through /.config/kdeglobals (using TTY1) does not show -> [QtQuickRendererSettings] SceneGraphBackend=software I know this is probably not a software rendering issue. Previously I have forced software rendering by editing /etc/environment and adding -> QT_QUICK_BACKEND=software KWIN_COMPOSE=02ES Do you believe this may be an issue with a newer version of Mesa now? Can you tell me the best way to force X11 session to load? -Best Regards

Show replies by date

Felix Miata

12 May 12 May

17:07

-pj composed on 2024-05-07 12:36 (UTC-0500):

...

Hi, I decided to update an i386 Tumbleweed machine here to the latest 20240506 snapshot there were many many packages listed for update (1900+). I used snapper to create a snapshot manually prior to the update.

...

The update appears to have completed fine without incident. I then powercycled the machine. Now when the SDDM desktop display manager is displayed, I am able to select X11 session type then enter my password and login. Once logged in, the desktop is for the most part unusable. Menu button is covered by workspaces, taskmanager is partially blank, (konsole is also unusable).

...

I can then switch to TTY1 and enter my username and password. Passing 'inxi -Gxx' displays the following -> https://paste.opensuse.org/pastes/f42c153b3d71

...

It appears to me that Xwayland is being used ever though I have selected the X11 session type at SDDM login.

...

Looking through /.config/kdeglobals (using TTY1) does not show -> [QtQuickRendererSettings] SceneGraphBackend=software

...

I know this is probably not a software rendering issue. Previously I have forced software rendering by editing /etc/environment and adding -> QT_QUICK_BACKEND=software KWIN_COMPOSE=02ES

...

Do you believe this may be an issue with a newer version of Mesa now?

...

Can you tell me the best way to force X11 session to load?

Your inxi output shows xwayland is /available/, confusing information, as it also shows wayland is "inactive". Inxi does report your session is an X.org session. I suggest to run zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication to ensure you don't have v5 KDE or any other stale packages remaining installed. If your Plasma still isn't running properly after than processing, try removing those old special settings you employed for v5. V6 is a major upgrade. Those old settings could be interfering with v6. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

-pj

16 May 16 May

07:35

New subject: One quarter of screen displaying a white box in KDE V6. (WAS) Unable to load usable X11 session after Tumbleweed update:

On 05-12-2024 10:07AM, Felix Miata wrote:

...

-pj composed on 2024-05-07 12:36 (UTC-0500):

...
Hi, I decided to update an i386 Tumbleweed machine here to the latest 20240506 snapshot there were many many packages listed for update (1900+). I used snapper to create a snapshot manually prior to the update.

...
The update appears to have completed fine without incident. I then powercycled the machine. Now when the SDDM desktop display manager is displayed, I am able to select X11 session type then enter my password and login. Once logged in, the desktop is for the most part unusable. Menu button is covered by workspaces, taskmanager is partially blank, (konsole is also unusable).

...
I can then switch to TTY1 and enter my username and password. Passing 'inxi -Gxx' displays the following -> https://paste.opensuse.org/pastes/f42c153b3d71

...
It appears to me that Xwayland is being used ever though I have selected the X11 session type at SDDM login.

...
Looking through /.config/kdeglobals (using TTY1) does not show -> [QtQuickRendererSettings] SceneGraphBackend=software

...
I know this is probably not a software rendering issue. Previously I have forced software rendering by editing /etc/environment and adding -> QT_QUICK_BACKEND=software KWIN_COMPOSE=02ES

...
Do you believe this may be an issue with a newer version of Mesa now?

...
Can you tell me the best way to force X11 session to load?

Your inxi output shows xwayland is /available/, confusing information, as it also shows wayland is "inactive". Inxi does report your session is an X.org session.

I am glad to hear back from you about this Felix Miata. I commented out the entries that I made in the /etc/environment file (SDDM window descriptors are partially blank now but I can login to KDE V6, (software rendering helped to fix the blank SDDM issue). I updated the machine to snapshot 20240514, powercycled. The V6 Plasma display is plagued by 1/4 of the screen displaying a white box (top right). This was also happening after the initial V6 Megaupdate. Having Software Rendering enabled started a Konsole box in a tiny window so it had to be expanded after the "V6 Megaupdate"). I had neglected to see this initially. See image here of one quarter of the screen displaying a white box. -> https://paste.opensuse.org/pastes/944b0bde86e1 :~> inxi -GSaz --vs --zl --hostname inxi 3.3.34-00 (2024-04-13) System: Host: localhost.localdomain Kernel: 6.8.9-1-pae arch: i686 bits: 32 compiler: gcc v: 13.2.1 clocksource: hpet avail: acpi_pm parameters: BOOT_IMAGE=/boot/vmlinuz-6.8.9-1-pae root=/dev/mapper/system-root resume=/dev/system/swap mitigations=auto quiet security=apparmor Desktop: KDE Plasma v: 6.0.4 tk: Qt v: N/A info: frameworks v: 6.2.0 wm: kwin_x11 tools: avail: xscreensaver vt: 2 dm: SDDM Distro: openSUSE Tumbleweed 20240514 Graphics: Device-1: Intel Mobile 945GM/GMS 943/940GML Express Integrated Graphics vendor: Hewlett-Packard driver: i915 v: kernel arch: Gen-3.5 process: Intel 90nm built: 2005-06 ports: active: LVDS-1 empty: DVI-D-1,SVIDEO-1,VGA-1 bus-ID: 00:02.0 chip-ID: 8086:27a2 class-ID: 0300 Display: x11 server: X.Org v: 21.1.12 with: Xwayland v: 23.2.6 compositor: kwin_x11 driver: X: loaded: intel unloaded: fbdev,modesetting,vesa dri: i915 gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 1280x800 s-dpi: 96 s-size: 338x211mm (13.31x8.31") s-diag: 398mm (15.69") Monitor-1: LVDS-1 mapped: LVDS1 model: LG Philips 0x8d00 built: 2005 res: 1280x800 dpi: 108 gamma: 1.2 size: 300x190mm (11.81x7.48") diag: 358mm (14.1") ratio: 16:10 modes: 1280x800 API: EGL v: 1.5 hw: drv: intel i915 platforms: device: 0 egl: 1.4 drv: i915 device: 1 drv: swrast surfaceless: egl: 1.4 drv: i915 x11: egl: 1.4 drv: i915 inactive: gbm,wayland API: OpenGL v: 4.5 compat-v: 2.1 vendor: mesa v: 24.0.5 glx-v: 1.4 direct-render: yes renderer: i915 (: 945GM) device-ID: 8086:27a2 memory: 187.5 MiB unified: yes API: Vulkan Message: No Vulkan data available. Yes, I see "wm: kwin_x11" displayed.

...

I suggest to run

zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication

to ensure you don't have v5 KDE or any other stale packages remaining installed.

...

If your Plasma still isn't running properly after than processing, try removing those old special settings you employed for v5. V6 is a major upgrade. Those old settings could be interfering with v6.

What are your thoughts on this? I have updated the information on https://bugzilla.opensuse.org/show_bug.cgi?id=1224061 I see your response there also and have changed the topic a bit. -Regards

Felix Miata

08:26

New subject: One quarter of screen displaying a white box in KDE V6

-pj composed on 2024-05-16 00:35 (UTC-0500):

...

Felix Miata wrote: ...

...
I suggest to run

...

...
zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication

...

...
to ensure you don't have v5 KDE or any other stale packages remaining installed.

...

I do not see anything related to v5 KDE on the machine. How are the stale packages displayed?

*KF5* is one of KDE5's packaging strings. I would consider "stale" a pseudonym for "System Packages":

...

:~> sudo zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication

...

[sudo] password for root: i | boost-license1_84_0 | package | 1.84.0-2.1 | noarch | (System Packages) i+ | brscan-skey | package | 0.3.2-0 | i386 | (System Packages) i+ | brscan4 | package | 0.4.11-1 | i386 | (System Packages)

No one can avoid (System Packages) applied to Brother printer packages. Just pretend you didn't see them.

...

i+ | kernel-pae | package | 6.8.8-1.1 | i686 | (System Packages) i+ | kernel-pae | package | 6.7.7-1.1 | i686 | (System Packages) i+ | kernel-pae | package | 6.7.6-1.1 | i686 | (System Packages)

These are so marked because they are no longer available from standard or any other enabled repos.

...

i | libabsl2308_0_0 | package |20230802.1-3.1 | i586 | (System Packages)

I think this is the first to suggest your last zypper dup didn't finish.

...

i | libboost_filesystem1_84_0 i | libboost_iostreams1_84_0 i | libboost_locale1_84_0 i | libboost_thread1_84_0 i+ | libcamera-base0_1 i+ | libcamera0_1 i | libcbor0_10 i+ | libdvdcss2 i | libjxl0_9 i | libkerfuffle23 i | libKF5TextAddonsWidgets1 i | libKF5TextAutoCorrectionCore1 i | libKF5TextAutoCorrectionWidgets1 i | libKF5TextEditTextToSpeech1 i | libKF5TextEmoticonsCore1 i | libKF5TextEmoticonsWidgets1 i | libKF5TextGrammarCheck1 i | libKF5TextTranslator1 i | libkgapi i | libKPim5AkonadiAgentBase5 i | libKPim5AkonadiCore5 i | libKPim5AkonadiPrivate5 i | libKPim5AkonadiWidgets5 i | libKPim5AkonadiXml5 i | libKPim5GAPICalendar5 i | libKPim5GAPICore5 i | libKPim5GAPIPeople5 i | libKPim5GAPITasks5 i | libKPim5KontactInterface5 i | libKPim5Libkdepim5 i | libKPim5Mime5 i | libKPim5PkPass5 i | libKPim5TextEdit5 i | liblastlog2-1 i | libpoppler133 i | libpoppler134 i | libprotobuf-lite25_1_0 i | libprotobuf-lite25_2_0 i | libprotobuf25_1_0 i | libprotobuf25_2_0 i | libruby3_2-3_2 i | libSPIRV-Tools-2023_6_rc1 i | libvpx8 i+ | mfcj485dwcupswrapper i+ | mfcj485dwlpr ^ more Brother. i | ruby3.2 i | ruby3.2-rubygem-abstract_method i | ruby3.2-rubygem-cfa i | ruby3.2-rubygem-cfa_grub2 i | ruby3.2-rubygem-cheetah i | ruby3.2-rubygem-fast_gettext i | ruby3.2-rubygem-gem2rpm i | ruby3.2-rubygem-nokogiri i | ruby3.2-rubygem-ruby-augeas i | ruby3.2-rubygem-ruby-dbus i | ruby3.2-rubygem-simpleidn i | ruby3.2-rubygem-unf i | ruby3.2-rubygem-unf_ext | package | 1.84.0-2.1 | i586 | (System Packages) | package | 1.84.0-2.1 | i586 | (System Packages) | package | 1.84.0-2.1 | i586 | (System Packages) | package | 1.84.0-2.1 | i586 | (System Packages) | package | 0.1.0-1.2 | i586 | (System Packages) | package | 0.1.0-1.2 | i586 | (System Packages) | package | 0.10.2-1.4 | i586 | (System Packages) | package | 1.4.3+3-10.3| i586 | (System Packages) | package | 0.9.2-1.2 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 1.4.1-2.3 | i586 | (System Packages) | package | 1.4.1-2.3 | i586 | (System Packages) | package | 1.4.1-2.3 | i586 | (System Packages) | package | 1.4.1-2.3 | i586 | (System Packages) | package | 1.4.1-2.3 | i586 | (System Packages) | package | 1.4.1-2.3 | i586 | (System Packages) | package | 1.4.1-2.3 | i586 | (System Packages) | package | 1.4.1-2.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.4 | i586 | (System Packages) | package | 23.08.4-1.4 | i586 | (System Packages) | package | 23.08.4-1.4 | i586 | (System Packages) | package | 23.08.4-1.4 | i586 | (System Packages) | package | 23.08.4-1.4 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 23.08.4-1.3 | i586 | (System Packages) | package | 1.3.1-1.2 | i586 | (System Packages) | package | 23.12.0-1.3 | i586 | (System Packages) | package | 24.02.0-1.1 | i586 | (System Packages) | package | 25.1-9.7 | i586 | (System Packages) | package | 25.2-10.1 | i586 | (System Packages) | package | 25.1-9.7 | i586 | (System Packages) | package | 25.2-10.1 | i586 | (System Packages) | package | 3.2.2-4.3 | i586 | (System Packages) | package | 2023.6~rc1-1.4| i586 | (System Packages) | package | 1.13.1-1.4 | i586 | (System Packages) | package | 1.0.0-0 | i386 | (System Packages) | package | 1.0.0-0 | i386 | (System Packages) | package | 3.2.2-4.3 | i586 | (System Packages) | package | 1.2.1-2.8 | i586 | (System Packages) | package | 1.0.2-1.8 | i586 | (System Packages) | package | 2.0.0-1.8 | i586 | (System Packages) | package | 1.0.0-1.8 | i586 | (System Packages) | package | 2.3.0-1.3 | i586 | (System Packages) | package | 0.10.1-22.3 | i586 | (System Packages) | package | 1.15.5-1.8 | i586 | (System Packages) | package | 0.5.0-3.8 | i586 | (System Packages) | package | 0.23.1-2.3 | i586 | (System Packages) | package | 0.2.1-1.8 | i586 | (System Packages) | package | 0.1.4-1.8 | i586 | (System Packages) | package | 0.0.9.1-1.3 | i586 | (System Packages)

zypper dup should have removed the ruby3.2s by now, and probably all but the brothers in the list above. I don't believe there's any justification to continue having libKF5* or libKPim5* packages installed any more unless you purposely locked them so that they could not be upgraded or removed. Boost*1_84_0* has been upgraded to 1_85_0*. Highly likely incomplete zypper dup is the root cause of https://bugzilla.opensuse.org/show_bug.cgi?id=1224061.

...

pj@localhost:~>

...

...
If your Plasma still isn't running properly after than processing, try removing those old special settings you employed for v5. V6 is a major upgrade. Those old settings could be interfering with v6.

...

What are your thoughts on this?

First get fully upgraded to latest i586 TW, then see how things are working. I have an alternate theory that incomplete dup may not be the whole problem. That white box makes me think about the following: https://gitlab.freedesktop.org/drm/nouveau/-/issues/214 https://bugzilla.kernel.org/show_bug.cgi?id=217479 https://bugzilla.opensuse.org/show_bug.cgi?id=1211761 What these would boil down to is regressions creeping into old hardware setups due to developers working so hard on Wayland and trying to forget X11 exists. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

-pj

17 May 17 May

06:37

New subject: One quarter of screen displaying a white box in KDE V6

On 05-16-2024 01:26AM, Felix Miata wrote:

...

-pj composed on 2024-05-16 00:35 (UTC-0500):

...
Felix Miata wrote: ...

...
I suggest to run

...
...
zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication

...
...
to ensure you don't have v5 KDE or any other stale packages remaining installed.

...
I do not see anything related to v5 KDE on the machine. How are the stale packages displayed?

*KF5* is one of KDE5's packaging strings. I would consider "stale" a pseudonym for "System Packages":

...

...
:~> sudo zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication

...
[sudo] password for root: i | boost-license1_84_0 | package | 1.84.0-2.1 | noarch | (System Packages) i+ | brscan-skey | package | 0.3.2-0 | i386 | (System Packages) i+ | brscan4 | package | 0.4.11-1 | i386 | (System Packages)

No one can avoid (System Packages) applied to Brother printer packages. Just pretend you didn't see them.

Yes, I know of brscan-skey and brscan4 related to brother but boost-license1_84_0 provides -> Boost provides free peer-reviewed portable C++ source libraries.

...

...
i+ | kernel-pae | package | 6.8.8-1.1 | i686 | (System Packages) i+ | kernel-pae | package | 6.7.7-1.1 | i686 | (System Packages) i+ | kernel-pae | package | 6.7.6-1.1 | i686 | (System Packages)

These are so marked because they are no longer available from standard or any other enabled repos.

Yes, marked as installed by user request I think because I modified /etc/zypp/zypp.conf file to -> multiversion.kernels' (*entry*) = latest,latest-1,latest-2,latest-3,latest-4,latest-5,latest-6,latest-7,latest-8,latest-9,running

...

...
i | libabsl2308_0_0 | package |20230802.1-3.1 | i586 | (System Packages)

I think this is the first to suggest your last zypper dup didn't finish.

This is somewhat unexpected news to hear from you about this. I believe that I *did* wait for the "zypper dup" to finish completely. To be certain I powercycled and completed another "zypper dup" on the machine once again today. I would like to also add the following is currently also set in /etc/zypp/zypp.conf -> commit.downloadMode = DownloadAsNeeded

...

...
i | libboost_filesystem1_84_0 | package | 1.84.0-2.1 | i586 | (System Packages) i | libboost_iostreams1_84_0 | package | 1.84.0-2.1 | i586 | (System Packages) i | libboost_locale1_84_0 | package | 1.84.0-2.1 | i586 | (System Packages) i | libboost_thread1_84_0 | package | 1.84.0-2.1 | i586 | (System Packages) i+ | libcamera-base0_1 | package | 0.1.0-1.2 | i586 | (System Packages) i+ | libcamera0_1 | package | 0.1.0-1.2 | i586 | (System Packages) i | libcbor0_10 | package | 0.10.2-1.4 | i586 | (System Packages) i+ | libdvdcss2 | package | 1.4.3+3-10.3| i586 | (System Packages) i | libjxl0_9 | package | 0.9.2-1.2 | i586 | (System Packages) i | libkerfuffle23 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKF5TextAddonsWidgets1 | package | 1.4.1-2.3 | i586 | (System Packages) i | libKF5TextAutoCorrectionCore1 | package | 1.4.1-2.3 | i586 | (System Packages) i | libKF5TextAutoCorrectionWidgets1 | package | 1.4.1-2.3 | i586 | (System Packages) i | libKF5TextEditTextToSpeech1 | package | 1.4.1-2.3 | i586 | (System Packages) i | libKF5TextEmoticonsCore1 | package | 1.4.1-2.3 | i586 | (System Packages) i | libKF5TextEmoticonsWidgets1 | package | 1.4.1-2.3 | i586 | (System Packages) i | libKF5TextGrammarCheck1 | package | 1.4.1-2.3 | i586 | (System Packages) i | libKF5TextTranslator1 | package | 1.4.1-2.3 | i586 | (System Packages) i | libkgapi | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5AkonadiAgentBase5 | package | 23.08.4-1.4 | i586 | (System Packages) i | libKPim5AkonadiCore5 | package | 23.08.4-1.4 | i586 | (System Packages) i | libKPim5AkonadiPrivate5 | package | 23.08.4-1.4 | i586 | (System Packages) i | libKPim5AkonadiWidgets5 | package | 23.08.4-1.4 | i586 | (System Packages) i | libKPim5AkonadiXml5 | package | 23.08.4-1.4 | i586 | (System Packages) i | libKPim5GAPICalendar5 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5GAPICore5 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5GAPIPeople5 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5GAPITasks5 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5KontactInterface5 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5Libkdepim5 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5Mime5 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5PkPass5 | package | 23.08.4-1.3 | i586 | (System Packages) i | libKPim5TextEdit5 | package | 23.08.4-1.3 | i586 | (System Packages) i | liblastlog2-1 | package | 1.3.1-1.2 | i586 | (System Packages) i | libpoppler133 | package | 23.12.0-1.3 | i586 | (System Packages) i | libpoppler134 | package | 24.02.0-1.1 | i586 | (System Packages) i | libprotobuf-lite25_1_0 | package | 25.1-9.7 | i586 | (System Packages) i | libprotobuf-lite25_2_0 | package | 25.2-10.1 | i586 | (System Packages) i | libprotobuf25_1_0 | package | 25.1-9.7 | i586 | (System Packages) i | libprotobuf25_2_0 | package | 25.2-10.1 | i586 | (System Packages) i | libruby3_2-3_2 | package | 3.2.2-4.3 | i586 | (System Packages) i | libSPIRV-Tools-2023_6_rc1 | package | 2023.6~rc1-1.4| i586 | (System Packages) i | libvpx8 | package | 1.13.1-1.4 | i586 | (System Packages) i+ | mfcj485dwcupswrapper | package | 1.0.0-0 | i386 | (System Packages) i+ | mfcj485dwlpr | package | 1.0.0-0 | i386 | (System Packages) ^ more Brother. i | ruby3.2 | package | 3.2.2-4.3 | i586 | (System Packages) i | ruby3.2-rubygem-abstract_method | package | 1.2.1-2.8 | i586 | (System Packages) i | ruby3.2-rubygem-cfa | package | 1.0.2-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-cfa_grub2 | package | 2.0.0-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-cheetah | package | 1.0.0-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-fast_gettext | package | 2.3.0-1.3 | i586 | (System Packages) i | ruby3.2-rubygem-gem2rpm | package | 0.10.1-22.3 | i586 | (System Packages) i | ruby3.2-rubygem-nokogiri | package | 1.15.5-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-ruby-augeas | package | 0.5.0-3.8 | i586 | (System Packages) i | ruby3.2-rubygem-ruby-dbus | package | 0.23.1-2.3 | i586 | (System Packages) i | ruby3.2-rubygem-simpleidn | package | 0.2.1-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-unf | package | 0.1.4-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-unf_ext | package | 0.0.9.1-1.3 | i586 | (System Packages)

zypper dup should have removed the ruby3.2s by now,

...

in the list above. I don't believe there's any justification to continue having libKF5* or libKPim5* packages installed any more unless you purposely locked them so that they could not be upgraded or removed. Boost*1_84_0* has been upgraded to 1_85_0*. Highly likely incomplete zypper dup is the root cause of https://bugzilla.opensuse.org/show_bug.cgi?id=1224061.

I honestly do not think this is the case here (imcomplete zypper dup). What is the best way to check the "zypper dup" for completed status then? Passing zypper ve -> Dependencies of all installed packages are satisfied. Passing zypper ll -> no package locks are defined.

...

...
pj@localhost:~>

...
...
If your Plasma still isn't running properly after than processing, try removing those old special settings you employed for v5. V6 is a major upgrade. Those old settings could be interfering with v6.

There is a trade off on this situation with this machine in doing so now. Enabling software rendering allows me to navigate SDDM but creates a much less usable system tray/taskbar. Disabling software rendering (reverting to hardware rendering) now, nearly disables SDDM's display capability to select a different window manager or whatever else. It is much more difficult due to every option label displaying blank fields. I have been working a bit with the Enlightenment desktop on this machine directly after the 32 bit KDE Plasma P6 MEGARELEASE issues.

...

...
What are your thoughts on this?

First get fully upgraded to latest i586 TW, then see how things are working.

Please tell me how to verify that the Tumbleweed snapshot on the machine is fully upgraded. Currently hostnamectl reports 20240515 .

...

I have an alternate theory that incomplete dup may not be the whole problem. That white box makes me think about the following: https://gitlab.freedesktop.org/drm/nouveau/-/issues/214 https://bugzilla.kernel.org/show_bug.cgi?id=217479 https://bugzilla.opensuse.org/show_bug.cgi?id=1211761 What these would boil down to is regressions creeping into old hardware setups due to developers working so hard on Wayland and trying to forget X11 exists.

Thank you for sharing the reports above, some of what is discussed in there is a little confusing. To me, this appears to be a regression here also. Can you recommend anything like attempting nosimplefb=1 or the likes in /etc/default/grub perhaps? What are other suggestions you may have for me to look into on this? Should I continue using SDDM instead of GDM? It seems that using the KDE Plasma V6 MEGARELEASE on the machine in question may be out of the question for me🫥 and I will have to switch the Desktop Environment. I can use the hardware with X11 server and Enlightenment desktop with a learning curve it seems. Best Regards to you🫥

Felix Miata

08:45

New subject: One quarter of screen displaying a white box in KDE V6

-pj composed on 2024-05-16 23:37 (UTC-0500):

...

Felix Miata wrote:

...

and probably all but the brothers

...
in the list above. I don't believe there's any justification to continue having libKF5* or libKPim5* packages installed any more unless you purposely locked them so that they could not be upgraded or removed. Boost*1_84_0* has been upgraded to 1_85_0*. Highly likely incomplete zypper dup is the root cause of https://bugzilla.opensuse.org/show_bug.cgi?id=1224061.

...

I honestly do not think this is the case here (imcomplete zypper dup). What is the best way to check the "zypper dup" for completed status then? Passing zypper ve -> Dependencies of all installed packages are satisfied. Passing zypper ll -> no package locks are defined. ... There is a trade off on this situation with this machine in doing so now. Enabling software rendering allows me to navigate SDDM but creates a much less usable system tray/taskbar. Disabling software rendering (reverting to hardware rendering) now, nearly disables SDDM's display capability to select a different window manager or whatever else. It is much more difficult due to every option label displaying blank fields. I have been working a bit with the Enlightenment desktop on this machine directly after the 32 bit KDE Plasma P6 MEGARELEASE issues.

...

...
First get fully upgraded to latest i586 TW, then see how things are working.

...

Please tell me how to verify that the Tumbleweed snapshot on the machine is fully upgraded. Currently hostnamectl reports 20240515 .

Try just purging stuff you don't need and/or don't use: zypper pa --unneeded Then zealously remove.... ...

...

Should I continue using SDDM instead of GDM? It seems that using the KDE Plasma V6 MEGARELEASE on the machine in question may be out of the question for me🫥 and I will have to switch the Desktop Environment. I can use the hardware with X11 server and Enlightenment desktop with a learning curve it seems.

-pj

18 May 18 May

06:23

New subject: One quarter of screen displaying a white box in KDE V6

On 05-17-2024 01:45AM, Felix Miata wrote:

...

-pj composed on 2024-05-16 23:37 (UTC-0500):

...
Felix Miata wrote:

...
and probably all but the brothers

...
in the list above. I don't believe there's any justification to continue having libKF5* or libKPim5* packages installed any more unless you purposely locked them so that they could not be upgraded or removed. Boost*1_84_0* has been upgraded to 1_85_0*. Highly likely incomplete zypper dup is the root cause of https://bugzilla.opensuse.org/show_bug.cgi?id=1224061.

...
I honestly do not think this is the case here (imcomplete zypper dup). What is the best way to check the "zypper dup" for completed status then? Passing zypper ve -> Dependencies of all installed packages are satisfied. Passing zypper ll -> no package locks are defined. ... There is a trade off on this situation with this machine in doing so now. Enabling software rendering allows me to navigate SDDM but creates a much less usable system tray/taskbar. Disabling software rendering (reverting to hardware rendering) now, nearly disables SDDM's display capability to select a different window manager or whatever else. It is much more difficult due to every option label displaying blank fields. I have been working a bit with the Enlightenment desktop on this machine directly after the 32 bit KDE Plasma P6 MEGARELEASE issues.

...
...
First get fully upgraded to latest i586 TW, then see how things are working.

...
Please tell me how to verify that the Tumbleweed snapshot on the machine is fully upgraded. Currently hostnamectl reports 20240515 .

Try just purging stuff you don't need and/or don't use:

zypper pa --unneeded

Then zealously remove....

Is there a need to create a snapshot before doing this (removing)?

...

:~> sudo zypper pa --unneeded [sudo] password for root: Loading repository data... Reading installed packages... S | Repository | Name | Version | Arch --+-----------------------+------------------------------------+---------------------+------- i | Main Repository (OSS) | accountsservice-lang | 23.13.9-8.1 | noarch i | Main Repository (OSS) | akonadi-plugin-contacts | 24.02.2-1.1 | i586 i | Main Repository (OSS) | akonadi-plugin-mime | 24.02.2-1.1 | i586 i | Main Repository (OSS) | akonadi-search | 24.02.2-1.1 | i586 i | Main Repository (OSS) | baloo5-file | 5.115.0-1.2 | i586 i | Main Repository (OSS) | baloo5-imports | 5.115.0-1.2 | i586 i | Main Repository (OSS) | baloo5-kioslaves | 5.115.0-1.2 | i586 i | Main Repository (OSS) | baloo5-tools | 5.115.0-1.2 | i586 i | Main Repository (OSS) | bluez-qt-udev | 5.115.0-1.2 | i586 i | Main Repository (OSS) | filelight | 24.02.2-1.1 | i586 i | Main Repository (OSS) | frameworkintegration-plugin | 5.115.0-1.2 | i586 i | Main Repository (OSS) | grantlee5 | 5.3.1-2.5 | i586 i | Main Repository (OSS) | gsettings-desktop-schemas-lang | 46.0-2.1 | noarch i | Main Repository (OSS) | gtk2-immodule-amharic | 2.24.33-9.1 | i586 i | Main Repository (OSS) | gtk2-immodule-inuktitut | 2.24.33-9.1 | i586 i | Main Repository (OSS) | gtk2-immodule-thai | 2.24.33-9.1 | i586 i | Main Repository (OSS) | gtk2-immodule-tigrigna | 2.24.33-9.1 | i586 i | Main Repository (OSS) | gtk2-immodule-vietnamese | 2.24.33-9.1 | i586 i | Main Repository (OSS) | kactivities5-imports | 5.115.0-1.2 | i586 i | Main Repository (OSS) | kbd-legacy | 2.6.4-4.1 | noarch i | Main Repository (OSS) | kcmutils-imports | 5.115.0-1.2 | i586 i | Main Repository (OSS) | kdelibs4support | 5.115.0-1.2 | i586 i | Main Repository (OSS) | kio-extras5 | 24.02.2-1.1 | i586 i | Main Repository (OSS) | knewstuff-imports | 5.115.0-1.2 | i586 i | Main Repository (OSS) | kpeople5 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | kpipewire-imports | 5.27.11-1.2 | i586 i | Main Repository (OSS) | kquickcharts | 5.115.0-1.2 | i586 i | Main Repository (OSS) | kross | 5.115.0-1.2 | i586 i | Main Repository (OSS) | ktexteditor | 5.115.0-1.2 | i586 i | Main Repository (OSS) | kwallet-tools | 5.115.0-1.2 | i586 i | Main Repository (OSS) | kwrited5 | 5.27.11-1.2 | i586 i | Main Repository (OSS) | layer-shell-qt5 | 5.27.11-1.3 | i586 i | @System | libabsl2308_0_0 | 20230802.1-3.1 | i586 i | Main Repository (OSS) | libAppStreamQt5-3 | 1.0.3-1.1 | i586 i | @System | libboost_filesystem1_84_0 | 1.84.0-2.1 | i586 i | @System | libboost_iostreams1_84_0 | 1.84.0-2.1 | i586 i | @System | libboost_locale1_84_0 | 1.84.0-2.1 | i586 i | @System | libcbor0_10 | 0.10.2-1.4 | i586 i | Main Repository (OSS) | libchm0 | 0.40-25.4 | i586 i | Main Repository (OSS) | libetebase0 | 0.5.5-2.6 | i586 i | packman-essentials | libfaad2 | 2.10.1-1699.1.pm.15 | i586 i | Main Repository (OSS) | libibus-1_0-5 | 1.5.29-4.2 | i586 i | @System | libjxl0_9 | 0.9.2-1.2 | i586 i | Main Repository (OSS) | libkdecorations2-5 | 5.27.11-1.2 | i586 i | @System | libkerfuffle23 | 23.08.4-1.3 | i586 i | Main Repository (OSS) | libKF5Cddb5 | 24.02.2-1.1 | i586 i | Main Repository (OSS) | libKF5CompactDisc5 | 24.02.2-1.1 | i586 i | Main Repository (OSS) | libKF5DAV5 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | libKF5GlobalAccelPrivate5 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | libKF5Holidays5 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | libKF5KDcraw5 | 24.02.2-1.1 | i586 i | Main Repository (OSS) | libKF5KHtml5 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | libKF5ModemManagerQt6 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | libKF5NetworkManagerQt6 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | libKF5NewStuffWidgets5 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | libKF5Purpose5 | 5.115.0-2.2 | i586 i | Main Repository (OSS) | libKF5PurposeWidgets5 | 5.115.0-2.2 | i586 i | Main Repository (OSS) | libKF5Screen8 | 5.27.11-1.2 | i586 i | Main Repository (OSS) | libKF5Su5 | 5.115.0-1.2 | i586 i | @System | libKF5TextAutoCorrectionWidgets1 | 1.4.1-2.3 | i586 i | @System | libKF5TextGrammarCheck1 | 1.4.1-2.3 | i586 i | @System | libKF5TextTranslator1 | 1.4.1-2.3 | i586 i | Main Repository (OSS) | libKF5UnitConversion5 | 5.115.0-1.2 | i586 i | Main Repository (OSS) | libKGantt2 | 2.8.0-1.10 | i586 i | @System | libkgapi | 23.08.4-1.3 | i586 i | Main Repository (OSS) | libkImageAnnotator-Qt5-0 | 0.7.1-1.2 | i586 i | Main Repository (OSS) | libkolabxml1 | 1.1.6-14.6 | i586 i | Main Repository (OSS) | libkomparediff2-5 | 24.02.2-1.1 | i586 i | @System | libKPim5AkonadiAgentBase5 | 23.08.4-1.4 | i586 i | @System | libKPim5AkonadiXml5 | 23.08.4-1.4 | i586 i | @System | libKPim5GAPICalendar5 | 23.08.4-1.3 | i586 i | @System | libKPim5GAPIPeople5 | 23.08.4-1.3 | i586 i | @System | libKPim5GAPITasks5 | 23.08.4-1.3 | i586 i | @System | libKPim5KontactInterface5 | 23.08.4-1.3 | i586 i | @System | libKPim5Libkdepim5 | 23.08.4-1.3 | i586 i | @System | libKPim5Mime5 | 23.08.4-1.3 | i586 i | @System | libKPim5PkPass5 | 23.08.4-1.3 | i586 i | @System | libKPim5TextEdit5 | 23.08.4-1.3 | i586 i | Main Repository (OSS) | libKPim6Gravatar6 | 24.02.2-1.1 | i586 i | Main Repository (OSS) | libKPim6IdentityManagementWidgets6 | 24.02.2-1.1 | i586 i | Main Repository (OSS) | libKPim6MailImporterAkonadi6 | 24.02.2-1.1 | i586 i | Main Repository (OSS) | libKPim6Tnef6 | 24.02.2-1.1 | i586 i | Main Repository (OSS) | libKScreenLocker5 | 5.27.11-1.2 | i586 i | Main Repository (OSS) | libkwalletbackend5-5 | 5.115.0-1.2 | i586 i | @System | liblastlog2-1 | 1.3.1-1.2 | i586 i | Main Repository (OSS) | libLLVM17 | 17.0.6-4.1 | i586 i | Main Repository (OSS) | libmetis5 | 5.1.0-11.1 | i586 i | Main Repository (OSS) | libpackagekitqt5-1 | 1.1.1-1.6 | i586 i | Main Repository (OSS) | libphonenumber8 | 8.13.30-1.6 | i586 i | @System | libpoppler133 | 23.12.0-1.3 | i586 i | @System | libpoppler134 | 24.02.0-1.1 | i586 i | @System | libprotobuf-lite25_1_0 | 25.1-9.7 | i586 i | @System | libprotobuf-lite25_2_0 | 25.2-10.1 | i586 i | @System | libprotobuf25_1_0 | 25.1-9.7 | i586 i | @System | libprotobuf25_2_0 | 25.2-10.1 | i586 i | Main Repository (OSS) | libqaccessibilityclient-qt5-0 | 0.6.0-1.1 | i586 i | Main Repository (OSS) | libqca-qt5-2 | 2.3.8+git1-1.4 | i586 i | Main Repository (OSS) | libqgpgme15 | 1.23.2-4.2 | i586 i | Main Repository (OSS) | libqt5-qdbus | 5.15.13+kde4-1.2 | i586 i | Main Repository (OSS) | libqt5-qtpaths | 5.15.13+kde4-1.2 | i586 i | Main Repository (OSS) | libqt5-qtvirtualkeyboard | 5.15.13+kde0-1.2 | i586 i | Main Repository (OSS) | libqt5-qtwayland | 5.15.13+kde60-1.2 | i586 i | Main Repository (OSS) | libqt5keychain1 | 0.14.2-1.2 | i586 i | Main Repository (OSS) | libQt5Sensors5 | 5.15.13+kde0-1.2 | i586 i | Main Repository (OSS) | libQt5WebView5 | 5.15.13+kde0-1.2 | i586 i | Main Repository (OSS) | libSDL2_image-2_0-0 | 2.8.2-1.5 | i586 i | Main Repository (OSS) | libsolv-tools | 0.7.29-1.1 | i586 i | @System | libSPIRV-Tools-2023_6_rc1 | 2023.6~rc1-1.4 | i586 i | @System | libvpx8 | 1.13.1-1.4 | i586 i | Main Repository (OSS) | libXRes1 | 1.2.2-1.7 | i586 i | Main Repository (OSS) | openconnect-lang | 9.12-3.1 | noarch i | Main Repository (OSS) | oxygen5-sounds | 5.27.10-1.3 | noarch i | Main Repository (OSS) | perl-HTTP-CookieJar | 0.014-1.8 | noarch i | Main Repository (OSS) | python311-setuptools | 69.0.3-1.2 | noarch i | Main Repository (OSS) | qca-qt5 | 2.3.8+git1-1.4 | i586 i | @System | ruby3.2-rubygem-cfa_grub2 | 2.0.0-1.8 | i586 i | @System | ruby3.2-rubygem-cheetah | 1.0.0-1.8 | i586 i | @System | ruby3.2-rubygem-fast_gettext | 2.3.0-1.3 | i586 i | @System | ruby3.2-rubygem-nokogiri | 1.15.5-1.8 | i586 i | @System | ruby3.2-rubygem-ruby-dbus | 0.23.1-2.3 | i586 i | @System | ruby3.2-rubygem-simpleidn | 0.2.1-1.8 | i586 i | Main Repository (OSS) | systemd-doc | 255.5-1.1 | noarch paul@localhost:~>

So you are saying to use zypper to remove each of the packages displayed above I think? ...

...

...
Should I continue using SDDM instead of GDM? It seems that using the KDE Plasma V6 MEGARELEASE on the machine in question may be out of the question for me🫥 and I will have to switch the Desktop Environment. I can use the hardware with X11 server and Enlightenment desktop with a learning curve it seems.

I categorize SDDM as evil here. Its use hijacks vt1 & vt2. BAAAD. I have only about two instances remaining on openSUSE. Everything else (triple digits) uses KDM3, TDM, XDM, or in just a very select few cases, LightDM.

Do you have over 100 machines there? I have switched the machine in question here to use XDM now. I cannot see the ability of XDM to allow to select a different X session or Window manager. So I used # update-alternatives --config default-xsession.desktop then I selected option three -> /usr/share/xsessions/plasma6.desktop I have turned off software rendering. Should I have compositing on or off? The taskbar is stable...just that big white box issue.

...

Consider shooting for something like what I have here for 32bits: # inxi -SMC System: Host: gx28c Kernel: 6.7.7-1-default arch: i686 bits: 32 Console: pty pts/1 Distro: openSUSE Tumbleweed 20240515 Machine: Type: Desktop System: Dell product: OptiPlex GX280 v: N/A serial: 2R0QS71 Mobo: Dell model: 0H8164 serial: ..CN6986155A0396. BIOS: Dell v: A08 date: 03/03/2006 CPU: Info: single core model: Intel Pentium 4 bits: 32 type: MT cache: L2: 1024 KiB Speed (MHz): avg: 2793 min/max: N/A cores: 1: 2793 2: 2793 # df / /home /usr/local Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda17 4839833 3977936 616105 87% / /dev/sda8 2402073 226809 2052369 10% /home /dev/sda10 1016488 789456 174823 82% /usr/local

I do not see which type of graphics but I see your CPU is 2 core p4 32 bit. Which is similar to the T2400 here in ways.

...

# zypper lr ... # | Alias | Enabled | GPG Check | URI --+----------+---------+-----------+------------------------------------------------------------------------- 1 | KDE3 | Yes | (r ) Yes | http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ 2 | Non-OSS | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/non-oss 3 | OSS | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/oss 4 | PackmanE | Yes | (r ) Yes | http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_Tumbleweed/Essentials 5 | Update | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/update/tumbleweed/ 6 | openh264 | Yes | (r ) Yes | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/

If I change the repos on the machine here to what you have provided above will I be more on track then? Do you suggest KDE3 (as per repo shown above) and not KDE5? KDE5 seemed to be working fairly decent I thought on this machine in question here.

...

# zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication il | kernel-default | package | 6.7.7-1.1 | i586 | (System Packages) il | kernel-default | package | 6.6.11-1.1 | i586 | (System Packages) il | kernel-default | package | 6.5.9-3.1 | i586 | (System Packages) il | libtag1 | package | 1.13.1-1.3 | i586 | (System Packages) i | libvpx8 | package | 1.13.1-1.2 | i586 | (System Packages) il | xfsprogs | package | 6.1.1-1.1 | i586 | (System Packages)

Your list is not large at all. Why are you not using 6.8.9-1-pae ? Is it because of the matching with your report here -> https://bugzilla.opensuse.org/show_bug.cgi?id=1212696

...

# zypper --no-refresh se -si | egrep 'kde|plasma|sddm|gdm|lightdm|kdm' | grep -v block i+ | kde3-gwenview | package | 1.4.2-157.8 | i586 | KDE3 i+ | kde3-kcm_gtk | package | 0.7svn20070827-24.10 | i586 | KDE3 i | kde3-susetranslations | package | 12.1-24.4 | noarch | KDE3 i+ | kdeaddons3-kicker | package | 3.5.10-38.192 | i586 | KDE3 i+ | kdeadmin3 | package | 3.5.10-55.90 | i586 | KDE3 i+ | kdeartwork3 | package | 3.5.10-78.6 | i586 | KDE3 i | kdebase3 | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-apps | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-kdm | package | 3.5.10.1-380.9 | i586 | KDE3 i | kdebase3-ksysguardd | package | 3.5.10.1-380.9 | i586 | KDE3 i | kdebase3-runtime | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-session | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-SuSE | package | 11.3-106.5 | i586 | KDE3 i+ | kdebase3-SuSE-branding-openSUSE | package | 11.3-106.5 | i586 | KDE3 i+ | kdebase3-workspace | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdegraphics3 | package | 3.5.10-166.8 | i586 | KDE3 i+ | kdegraphics3-pdf | package | 3.5.10-166.8 | i586 | KDE3 i | kdelibs3 | package | 3.5.10-267.11 | i586 | KDE3 i | kdelibs3-default-style | package | 3.5.10-267.11 | i586 | KDE3 i+ | kdemultimedia3 | package | 3.5.10.1-85.8 | i586 | KDE3 i+ | kdemultimedia3-mixer | package | 3.5.10.1-85.8 | i586 | KDE3 i+ | kdenetwork3-IRC | package | 3.5.10-159.5 | i586 | KDE3 i+ | kdeutils3 | package | 3.5.10-123.9 | i586 | KDE3 i | libQt5Core5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5DBus5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Gui5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Network5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5OpenGL5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Svg5 | package | 5.15.13+kde6-1.2 | i586 | Non-OSS i | libQt5Test5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Widgets5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5X11Extras5 | package | 5.15.13+kde0-1.2 | i586 | Non-OSS i+ | systemsettings-kde3 | package | 0.2-11.113 | i586 | KDE3 #

No Plasma, no SDDM, no GDM, no QT6, no Wayland, no Gnome, no bling, no bloat. Lotsa stuff that's been working for decades.

I have a long list of files when I pass the command above. Perhaps I could start from scratch with the repos you have illuminated above?

...

... not done, but need sleep now....

Very good of you to type this information out on this you are very helpful. I will continue and respond to your second message now.

Felix Miata

07:58

New subject: One quarter of screen displaying a white box in KDE V6

-pj composed on 2024-05-17 23:23 (UTC-0500):

...

On 05-17-2024 01:45AM, Felix Miata wrote:

...

...
-pj composed on 2024-05-16 23:37 (UTC-0500): ...

...
Please tell me how to verify that the Tumbleweed snapshot on the machine is fully upgraded. Currently hostnamectl reports 20240515 .

...

...
Try just purging stuff you don't need and/or don't use:

...

...
zypper pa --unneeded

...

...
Then zealously remove....

...

Is there a need to create a snapshot before doing this (removing)?

You'll need to get someone familiar with snapshot usage to answer that. I'm still using EXTx everywhere except for one ancient laptop for which I was not the openSUSE installer. My brother gave it to me with Leap on BTRFS.

...

...
:~> sudo zypper pa --unneeded ... S | Repository | Name | Version | Arch --+-----------------------+------------------------------------+---------------------+------- i | Main Repository (OSS) | accountsservice-lang | 23.13.9-8.1 | noarch i | Main Repository (OSS) | akonadi-plugin-contacts | 24.02.2-1.1 | i586 i | Main Repository (OSS) | akonadi-plugin-mime | 24.02.2-1.1 | i586 ...>> i | Main Repository (OSS) | libLLVM17 | 17.0.6-4.1 | i586 ... i | @System | ruby3.2-rubygem-ruby-dbus | 0.23.1-2.3 | i586 i | @System | ruby3.2-rubygem-simpleidn | 0.2.1-1.8 | i586 i | Main Repository (OSS) | systemd-doc | 255.5-1.1 | noarch paul@localhost:~>

...

So you are saying to use zypper to remove each of the packages displayed above I think?

I'm saying zypper says removal of all would be a safe operation - nothing remaining would be "broken". None of the packages listed there are required to keep the system operational. Many are packages available in multiple versions, such as libLLVM1# and ruby3.#-rubygem-*. Most people who are not software developers have zero need for multiple versions of the same software installed at once. You may selectively remove only some, leaving behind any you believe you have use for. Installed size of libLLVM17 is 137,703,210, nothing to sneeze at with another almost like it also installed, libLLVM18.

...

...
I categorize SDDM as evil here. Its use hijacks vt1 & vt2. BAAAD. I have only about two instances remaining on openSUSE. Everything else (triple digits) uses KDM3, TDM, XDM, or in just a very select few cases, LightDM.

...

Do you have over 100 machines there?

40-something or other that remain known to be bootable, all multiboot except for the brother's BTRFS 2008 laptop. Median OS installation count per PC is probably in the mid-20s. Max is about 60. I'm typing from one with a mere five. My newest has 17.

...

I have switched the machine in question here to use XDM now. I cannot see the ability of XDM to allow to select a different X session or Window manager. So I used # update-alternatives --config default-xsession.desktop then I selected option three -> /usr/share/xsessions/plasma6.desktop I have turned off software rendering. Should I have compositing on or off? The taskbar is stable...just that big white box issue.

I don't think Plasma can be made to run anymore with compositing disabled at the X level (as was normal here until 2-3 years ago). If disabling it is desired, it must be done via systemsettings, or via kwinrc: [Compositing] Enabled=false

...

...
Consider shooting for something like what I have here for 32bits: # inxi -SMC System: Host: gx28c Kernel: 6.7.7-1-default arch: i686 bits: 32 Console: pty pts/1 Distro: openSUSE Tumbleweed 20240515 Machine: Type: Desktop System: Dell product: OptiPlex GX280 v: N/A serial: 2R0QS71 Mobo: Dell model: 0H8164 serial: ..CN6986155A0396. BIOS: Dell v: A08 date: 03/03/2006 CPU: Info: single core model: Intel Pentium 4 bits: 32 type: MT cache: L2: 1024 KiB Speed (MHz): avg: 2793 min/max: N/A cores: 1: 2793 2: 2793 # df / /home /usr/local Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda17 4839833 3977936 616105 87% / /dev/sda8 2402073 226809 2052369 10% /home /dev/sda10 1016488 789456 174823 82% /usr/local

...

I do not see which type of graphics but I see your CPU is 2 core p4 32 bit. Which is similar to the T2400 here in ways.

That PC is the first generation of i915 graphics, namesake of the Kernel's aging Intel GPU driver, roughly two years older than your 945, or mine, but my 945s all have either 64 bit operating systems, or a discrete (non-Intel) GPU card installed.

...

...
# zypper lr ... # | Alias | Enabled | GPG Check | URI --+----------+---------+-----------+------------------------------------------------------------------------- 1 | KDE3 | Yes | (r ) Yes | http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ 2 | Non-OSS | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/non-oss 3 | OSS | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/oss 4 | PackmanE | Yes | (r ) Yes | http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_Tumbleweed/Essentials 5 | Update | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/update/tumbleweed/ 6 | openh264 | Yes | (r ) Yes | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/

...

If I change the repos on the machine here to what you have provided above will I be more on track then?

Without knowing your own repo details, that's unanswerable. There's no need for KDE3 unless you intend to use KDM3 to replace SDDM, and/or add KDE3 as a DE selection on your laptop.

...

Do you suggest KDE3 (as per repo shown above) and not KDE5? KDE5 seemed to be working fairly decent I thought on this machine in question here.

KDE5 has been replaced by KDE6 in TW. KDE3 remained as an option when KDE4 was introduced, kept when KDE5 replaced KDE4, and continues alongside KDE6. It's not an official part of TW, but maintained by very welcome volunteers.

...

...
# zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication il | kernel-default | package | 6.7.7-1.1 | i586 | (System Packages) il | kernel-default | package | 6.6.11-1.1 | i586 | (System Packages) il | kernel-default | package | 6.5.9-3.1 | i586 | (System Packages) il | libtag1 | package | 1.13.1-1.3 | i586 | (System Packages) i | libvpx8 | package | 1.13.1-1.2 | i586 | (System Packages) il | xfsprogs | package | 6.1.1-1.1 | i586 | (System Packages)

...

Your list is not large at all. Why are you not using 6.8.9-1-pae ? Is it

No one has ever persuaded me there's any point to using PAE on systems with 2G or less installed RAM. The 32bit PCs I have with 2G of RAM are at max, can't have more.

...

because of the matching with your report here -> https://bugzilla.opensuse.org/show_bug.cgi?id=1212696

That report is about i965 graphics, which is part of a chipset for 64 bit CPUs.

...

...
# zypper --no-refresh se -si | egrep 'kde|plasma|sddm|gdm|lightdm|kdm' | grep -v block i+ | kde3-gwenview | package | 1.4.2-157.8 | i586 | KDE3 i+ | kde3-kcm_gtk | package | 0.7svn20070827-24.10 | i586 | KDE3 i | kde3-susetranslations | package | 12.1-24.4 | noarch | KDE3 i+ | kdeaddons3-kicker | package | 3.5.10-38.192 | i586 | KDE3 i+ | kdeadmin3 | package | 3.5.10-55.90 | i586 | KDE3 i+ | kdeartwork3 | package | 3.5.10-78.6 | i586 | KDE3 i | kdebase3 | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-apps | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-kdm | package | 3.5.10.1-380.9 | i586 | KDE3 i | kdebase3-ksysguardd | package | 3.5.10.1-380.9 | i586 | KDE3 i | kdebase3-runtime | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-session | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-SuSE | package | 11.3-106.5 | i586 | KDE3 i+ | kdebase3-SuSE-branding-openSUSE | package | 11.3-106.5 | i586 | KDE3 i+ | kdebase3-workspace | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdegraphics3 | package | 3.5.10-166.8 | i586 | KDE3 i+ | kdegraphics3-pdf | package | 3.5.10-166.8 | i586 | KDE3 i | kdelibs3 | package | 3.5.10-267.11 | i586 | KDE3 i | kdelibs3-default-style | package | 3.5.10-267.11 | i586 | KDE3 i+ | kdemultimedia3 | package | 3.5.10.1-85.8 | i586 | KDE3 i+ | kdemultimedia3-mixer | package | 3.5.10.1-85.8 | i586 | KDE3 i+ | kdenetwork3-IRC | package | 3.5.10-159.5 | i586 | KDE3 i+ | kdeutils3 | package | 3.5.10-123.9 | i586 | KDE3 i | libQt5Core5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5DBus5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Gui5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Network5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5OpenGL5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Svg5 | package | 5.15.13+kde6-1.2 | i586 | Non-OSS i | libQt5Test5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Widgets5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5X11Extras5 | package | 5.15.13+kde0-1.2 | i586 | Non-OSS i+ | systemsettings-kde3 | package | 0.2-11.113 | i586 | KDE3 #

...

...
No Plasma, no SDDM, no GDM, no QT6, no Wayland, no Gnome, no bling, no bloat. Lotsa stuff that's been working for decades.

...

I have a long list of files when I pass the command above.

I'll bet. :)

...

Perhaps I could start from scratch with the repos you have illuminated above?

It could be easy enough, but best to isolate source of white box with least amount of expended effort first. Does the white box only appear in Plasma? Is it still present if you open IceWM or openbox instead? Is it there if you boot only to multi-user target, then use startx? Is it there if you create a test/virgin user to open a Plasma session? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

-pj

19 May 19 May

21:12

New subject: One quarter of screen displaying a white box in KDE V6

On 05-18-2024 12:58AM, Felix Miata wrote:

...

-pj composed on 2024-05-17 23:23 (UTC-0500):

...
On 05-17-2024 01:45AM, Felix Miata wrote:

...
...
-pj composed on 2024-05-16 23:37 (UTC-0500): ...

...
Please tell me how to verify that the Tumbleweed snapshot on the machine is fully upgraded. Currently hostnamectl reports 20240515 .

...
...
Try just purging stuff you don't need and/or don't use:

...
...
zypper pa --unneeded

...
...
Then zealously remove....

...
Is there a need to create a snapshot before doing this (removing)?

You'll need to get someone familiar with snapshot usage to answer that. I'm still using EXTx everywhere except for one ancient laptop for which I was not the openSUSE installer. My brother gave it to me with Leap on BTRFS.

...

...
...
:~> sudo zypper pa --unneeded ... S | Repository | Name | Version | Arch --+-----------------------+------------------------------------+---------------------+------- i | Main Repository (OSS) | accountsservice-lang | 23.13.9-8.1 | noarch i | Main Repository (OSS) | akonadi-plugin-contacts | 24.02.2-1.1 | i586 i | Main Repository (OSS) | akonadi-plugin-mime | 24.02.2-1.1 | i586 ...>> i | Main Repository (OSS) | libLLVM17 | 17.0.6-4.1 | i586 ... i | @System | ruby3.2-rubygem-ruby-dbus | 0.23.1-2.3 | i586 i | @System | ruby3.2-rubygem-simpleidn | 0.2.1-1.8 | i586 i | Main Repository (OSS) | systemd-doc | 255.5-1.1 | noarch paul@localhost:~>

...
So you are saying to use zypper to remove each of the packages displayed above I think?

I'm saying zypper says removal of all would be a safe operation - nothing remaining would be "broken". None of the packages listed there are required to keep the system operational. Many are packages available in multiple versions, such as libLLVM1# and ruby3.#-rubygem-*. Most people who are not software developers have zero need for multiple versions of the same software installed at once. You may selectively remove only some, leaving behind any you believe you have use for. Installed size of libLLVM17 is 137,703,210, nothing to sneeze at with another almost like it also installed, libLLVM18.

Ok,

...

...
...
I categorize SDDM as evil here. Its use hijacks vt1 & vt2. BAAAD. I have only about two instances remaining on openSUSE. Everything else (triple digits) uses KDM3, TDM, XDM, or in just a very select few cases, LightDM.

...
Do you have over 100 machines there?

40-something or other that remain known to be bootable, all multiboot except for the brother's BTRFS 2008 laptop. Median OS installation count per PC is probably in the mid-20s. Max is about 60. I'm typing from one with a mere five. My newest has 17.

Ok, keep up the excellent work and testing.

...

...
I have switched the machine in question here to use XDM now. I cannot see the ability of XDM to allow to select a different X session or Window manager. So I used # update-alternatives --config default-xsession.desktop then I selected option three -> /usr/share/xsessions/plasma6.desktop I have turned off software rendering. Should I have compositing on or off? The taskbar is stable...just that big white box issue.

I don't think Plasma can be made to run anymore with compositing disabled at the X level (as was normal here until 2-3 years ago). If disabling it is desired, it must be done via systemsettings, or via kwinrc:

[Compositing] Enabled=false

Ok, I noted this. It appears this has been the problem. It did not seem to disable correctly in System Settings when tried previously.

...

...
...
Consider shooting for something like what I have here for 32bits: # inxi -SMC System: Host: gx28c Kernel: 6.7.7-1-default arch: i686 bits: 32 Console: pty pts/1 Distro: openSUSE Tumbleweed 20240515 Machine: Type: Desktop System: Dell product: OptiPlex GX280 v: N/A serial: 2R0QS71 Mobo: Dell model: 0H8164 serial: ..CN6986155A0396. BIOS: Dell v: A08 date: 03/03/2006 CPU: Info: single core model: Intel Pentium 4 bits: 32 type: MT cache: L2: 1024 KiB Speed (MHz): avg: 2793 min/max: N/A cores: 1: 2793 2: 2793 # df / /home /usr/local Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda17 4839833 3977936 616105 87% / /dev/sda8 2402073 226809 2052369 10% /home /dev/sda10 1016488 789456 174823 82% /usr/local

...
I do not see which type of graphics but I see your CPU is 2 core p4 32 bit. Which is similar to the T2400 here in ways.

That PC is the first generation of i915 graphics, namesake of the Kernel's aging Intel GPU driver, roughly two years older than your 945, or mine, but my 945s all have either 64 bit operating systems, or a discrete (non-Intel) GPU card installed.

I contemplated the possibility of installing a T7600 (nonG) CPU into the machine. Compatible CPU list as per the machines user and service guide: https://www.informaticanapoli.it/download/MANUALI/Hp/HP-Compaq-nc6400-Notebo... The following processors, varying by computer model: ❏ Intel Core Duo T7600 (2.33-GHz) processor ❏ Intel Core Duo T7400 (2.16-GHz) processor ❏ Intel Core Duo T7200 (2.00-GHz) processor ❏ Intel Core Duo T5600 (1.83-GHz) processor ❏ Intel Core Duo T5500 (1.66-GHz) processor ❏ Intel Core Duo T2300E (1.66-GHz) processor ❏ Intel Core Duo T2600 (2.17-GHz) processor ❏ Intel Core Duo T2500 (2.00-GHz) processor ❏ Intel Core Duo T2400 (1.83-GHz) processor ❏ Intel Core Duo T2300 (1.67-GHz) processor ❏ Intel Core Solo T1300 (1.66-GHz) processor ❏ Intel Celeron M 440 (1.80-GHz) processor ❏ Intel Celeron M 430 (1.73-GHz) processor Can you give any insight on this (T2400 currently installed)? That way I could run a 64 bit version of Tumbleweed. Perhaps eliminating the problem for now. It could potentially allow for many more current 64 bit packages to be usable on this machine then.

...

...
...
# zypper lr ... # | Alias | Enabled | GPG Check | URI --+----------+---------+-----------+------------------------------------------------------------------------- 1 | KDE3 | Yes | (r ) Yes | http://download.opensuse.org/repositories/KDE:/KDE3/openSUSE_Tumbleweed/ 2 | Non-OSS | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/non-oss 3 | OSS | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/oss 4 | PackmanE | Yes | (r ) Yes | http://ftp.gwdg.de/pub/linux/packman/suse/openSUSE_Tumbleweed/Essentials 5 | Update | Yes | (r ) Yes | http://download.opensuse.org/ports/i586/update/tumbleweed/ 6 | openh264 | Yes | (r ) Yes | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed/

...
If I change the repos on the machine here to what you have provided above will I be more on track then?

Without knowing your own repo details, that's unanswerable. There's no need for KDE3 unless you intend to use KDM3 to replace SDDM, and/or add KDE3 as a DE selection on your laptop.

I should have listed repos in last message. This is the current repos list. :~> zypper lr -ua Repository priorities in effect: (See 'zypper lr -P' for details) 70 (raised priority) : 1 repository 99 (default priority) : 4 repositories # | Alias | Name | Enabled | GPG Check | Refresh | URI --+----------------------------------+----------------------------+---------+-----------+---------+------------------------------------------------------------------------------- 1 | download.opensuse.org-non-oss | Main Repository (NON-OSS) | Yes | (r ) Yes | Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/non-oss/ 2 | download.opensuse.org-oss | Main Repository (OSS) | Yes | (r ) Yes | Yes | http://download.opensuse.org/ports/i586/tumbleweed/repo/oss/ 3 | download.opensuse.org-tumbleweed | Main Update Repository | Yes | (r ) Yes | Yes | http://download.opensuse.org/ports/i586/update/tumbleweed/ 4 | openSUSE-20240116-0 | openSUSE-20240116-0 | No | ---- | ---- | hd:/?device=/dev/disk/by-id/usb-__07032AFB8723F717-0:0-part2 5 | packman-essentials | packman-essentials | Yes | (r ) Yes | Yes | https://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/Essentia... 6 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | http://download.opensuse.org/ports/i586/debug/tumbleweed/repo/oss/ 7 | repo-openh264 | Open H.264 Codec (openSU-> | Yes | (r ) Yes | Yes | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed 8 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | ---- | http://download.opensuse.org/ports/i586/source/tumbleweed/repo/oss/ localhost:~> What I see between yours and the one here is yours has KDE3 otherwise they appear to be identical.

...

...
Do you suggest KDE3 (as per repo shown above) and not KDE5? KDE5 seemed to be working fairly decent I thought on this machine in question here.

KDE5 has been replaced by KDE6 in TW. KDE3 remained as an option when KDE4 was introduced, kept when KDE5 replaced KDE4, and continues alongside KDE6. It's not an official part of TW, but maintained by very welcome volunteers.

...

...
...
# zypper --no-refresh se -si | grep 'tem Pac' | grep -v plication il | kernel-default | package | 6.7.7-1.1 | i586 | (System Packages) il | kernel-default | package | 6.6.11-1.1 | i586 | (System Packages) il | kernel-default | package | 6.5.9-3.1 | i586 | (System Packages) il | libtag1 | package | 1.13.1-1.3 | i586 | (System Packages) i | libvpx8 | package | 1.13.1-1.2 | i586 | (System Packages) il | xfsprogs | package | 6.1.1-1.1 | i586 | (System Packages)

...
Your list is not large at all. Why are you not using 6.8.9-1-pae ? Is it

No one has ever persuaded me there's any point to using PAE on systems with 2G or less installed RAM. The 32bit PCs I have with 2G of RAM are at max, can't have more.

...

...
because of the matching with your report here -> https://bugzilla.opensuse.org/show_bug.cgi?id=1212696

That report is about i965 graphics, which is part of a chipset for 64 bit CPUs.

Ok, thank you for clearing my misunderstanding.

...

...
...
# zypper --no-refresh se -si | egrep 'kde|plasma|sddm|gdm|lightdm|kdm' | grep -v block i+ | kde3-gwenview | package | 1.4.2-157.8 | i586 | KDE3 i+ | kde3-kcm_gtk | package | 0.7svn20070827-24.10 | i586 | KDE3 i | kde3-susetranslations | package | 12.1-24.4 | noarch | KDE3 i+ | kdeaddons3-kicker | package | 3.5.10-38.192 | i586 | KDE3 i+ | kdeadmin3 | package | 3.5.10-55.90 | i586 | KDE3 i+ | kdeartwork3 | package | 3.5.10-78.6 | i586 | KDE3 i | kdebase3 | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-apps | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-kdm | package | 3.5.10.1-380.9 | i586 | KDE3 i | kdebase3-ksysguardd | package | 3.5.10.1-380.9 | i586 | KDE3 i | kdebase3-runtime | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-session | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdebase3-SuSE | package | 11.3-106.5 | i586 | KDE3 i+ | kdebase3-SuSE-branding-openSUSE | package | 11.3-106.5 | i586 | KDE3 i+ | kdebase3-workspace | package | 3.5.10.1-380.9 | i586 | KDE3 i+ | kdegraphics3 | package | 3.5.10-166.8 | i586 | KDE3 i+ | kdegraphics3-pdf | package | 3.5.10-166.8 | i586 | KDE3 i | kdelibs3 | package | 3.5.10-267.11 | i586 | KDE3 i | kdelibs3-default-style | package | 3.5.10-267.11 | i586 | KDE3 i+ | kdemultimedia3 | package | 3.5.10.1-85.8 | i586 | KDE3 i+ | kdemultimedia3-mixer | package | 3.5.10.1-85.8 | i586 | KDE3 i+ | kdenetwork3-IRC | package | 3.5.10-159.5 | i586 | KDE3 i+ | kdeutils3 | package | 3.5.10-123.9 | i586 | KDE3 i | libQt5Core5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5DBus5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Gui5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Network5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5OpenGL5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Svg5 | package | 5.15.13+kde6-1.2 | i586 | Non-OSS i | libQt5Test5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5Widgets5 | package | 5.15.13+kde138-1.2 | i586 | Non-OSS i | libQt5X11Extras5 | package | 5.15.13+kde0-1.2 | i586 | Non-OSS i+ | systemsettings-kde3 | package | 0.2-11.113 | i586 | KDE3 #

...
...
No Plasma, no SDDM, no GDM, no QT6, no Wayland, no Gnome, no bling, no bloat. Lotsa stuff that's been working for decades.

...
I have a long list of files when I pass the command above.

I'll bet. :)

...
Perhaps I could start from scratch with the repos you have illuminated above?

It could be easy enough, but best to isolate source of white box with least amount of expended effort first. Does the white box only appear in Plasma? Is it still present if you open IceWM or openbox instead? Is it there if you boot only to multi-user target, then use startx? Is it there if you create a test/virgin user to open a Plasma session?

I have added user test and experience the same white box. Using XDM to login to X11 session. Seem to have lost taskbar altogether in the second testing. Switched to TTY3 logged in as test, passed startx result > blank screen with mouse cursor. Switched to TTY1 logged in as test, passed startx result > White box remains with usable desktop otherwise. IceWM and Enlightenment have no white box. It does seem to be Plasma KDE6 specific on this machine. Good news to report🫥. I changed /etc/xdg/kwinrc to include and contain the following: [Desktops] Number=2 [Compositing] Enabled=false AnimationSpeed=2 ------------------- I powercycled the machine. The white box is *not* there. ------------------------------- Passing 'xdpyinfo | grep Composite' displays Composite. Is this the way to check which compositor is used when enabled in kwinrc? I do not know why sudo -E kate /etc/environment no longer loads 'kate' Would this have something to do with compositing being disabled? man sudo > -E --preserve-env Indicates to the security policy that the user wishes to preserve their existing environmental variables..... I have noticed that when logging out of the session, the window descriptors are blank. I have attached a screenshot of this > https://paste.opensuse.org/pastes/7d376bc11a7b That is something that is not major from what I can see right now. Your thoughts are most welcome. I will report on 2nd message soon. -Greatest Hopes🫥

Felix Miata

20 May 20 May

01:59

New subject: One quarter of screen displaying a white box in KDE V6

-pj composed on 2024-05-19 14:12 (UTC-0500):

...

I contemplated the possibility of installing a T7600 (nonG) CPU into the machine.

...

Compatible CPU list as per the machines user and service guide: https://www.informaticanapoli.it/download/MANUALI/Hp/HP-Compaq-nc6400-Notebo...

...

The following processors, varying by computer model: ❏ Intel Core Duo T7600 (2.33-GHz) processor # 64 bits ... ❏ Intel Core Duo T2400 (1.83-GHz) processor # 32 bits

...

Can you give any insight on this (T2400 currently installed)? That way I could run a 64 bit version of Tumbleweed. Perhaps eliminating the problem for now. It could potentially allow for many more current 64 bit packages to be usable on this machine then.

$20 on eBay for T7600? Cheap enough if you want to keep that laptop relevant a while longer. I've done lots of CPU upgrades, but never a laptop. I have no idea if there are possible gotchas here, but what's $20 any more? I suppose if you're poor enough, it might be worth first reading https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/mobi... and your laptop documentation. Old: https://www.intel.com/content/www/us/en/products/sku/27235/intel-core-duo-pr... Proposed: https://www.intel.com/content/www/us/en/products/sku/27257/intel-core2-duo-p...

...

I have added user test and experience the same white box. Using XDM to login to X11 session. Seem to have lost taskbar altogether in the second testing. Switched to TTY3 logged in as test, passed startx result > blank screen with mouse cursor. Switched to TTY1 logged in as test, passed startx result > White box remains with usable desktop otherwise.

...

IceWM and Enlightenment have no white box. It does seem to be Plasma KDE6 specific on this machine.

...

Good news to report🫥. I changed /etc/xdg/kwinrc to include and contain the following:

...

[Desktops] Number=2

...

[Compositing] Enabled=false AnimationSpeed=2

...

------------------- I powercycled the machine. The white box is *not* there. -------------------------------

Sounds like the thread's stated purpose has been solved.

...

Passing 'xdpyinfo | grep Composite' displays Composite. Is this the way to check which compositor is used when enabled in kwinrc?

I don't remember if I ever knew how to check if enabled. Whenever I had it disabled via /etc/X11/xorg.conf.d/ or in systemsettings' display configuration compositing enable at startup, I just assumed it to be the state. I don't think grepping Composite from xdpyinfo is helpful: # xdpyinfo | grep -A11 -B11 posit depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x1b00008, revert to PointerRoot number of extensions: 28 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 DRI3 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM Present RANDR # Looks to me like it's simply listed as available, whether or not systemsettings has it enabled on startup. I think if it was globally disabled any more, Plasma would simply refuse to start.

...

I do not know why sudo -E kate /etc/environment no longer loads 'kate' Would this have something to do with compositing being disabled? man sudo > -E --preserve-env Indicates to the security policy that the user wishes to preserve their existing environmental variables.....

No idea. I don't use Kate.

...

I have noticed that when logging out of the session, the window descriptors are blank. I have attached a screenshot of this > https://paste.opensuse.org/pastes/7d376bc11a7b

I suppose that's a theme failure of some kind. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

Carlos E. R.

18 May 18 May

14:28

New subject: One quarter of screen displaying a white box in KDE V6

On 2024-05-18 06:23, -pj wrote:

...

On 05-17-2024 01:45AM, Felix Miata wrote:

...
-pj composed on 2024-05-16 23:37 (UTC-0500):

...
Felix Miata wrote:

...

...
Try just purging stuff you don't need and/or don't use:

zypper pa --unneeded

Then zealously remove....

Is there a need to create a snapshot before doing this (removing)?

Need, no. But it is recommended to take a snapshot before big changes, or changes that you do not know whether they will work or not or make things worse. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

Felix Miata

17 May 17 May

21:17

New subject: One quarter of screen displaying a white box in KDE V6

-pj composed on 2024-05-16 23:37 (UTC-0500): ...

...

i | ruby3.2 | package | 3.2.2-4.3 | i586 | (System Packages) i | ruby3.2-rubygem-abstract_method | package | 1.2.1-2.8 | i586 | (System Packages) i | ruby3.2-rubygem-cfa | package | 1.0.2-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-cfa_grub2 | package | 2.0.0-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-cheetah | package | 1.0.0-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-fast_gettext | package | 2.3.0-1.3 | i586 | (System Packages) i | ruby3.2-rubygem-gem2rpm | package | 0.10.1-22.3 | i586 | (System Packages) i | ruby3.2-rubygem-nokogiri | package | 1.15.5-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-ruby-augeas | package | 0.5.0-3.8 | i586 | (System Packages) i | ruby3.2-rubygem-ruby-dbus | package | 0.23.1-2.3 | i586 | (System Packages) i | ruby3.2-rubygem-simpleidn | package | 0.2.1-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-unf | package | 0.1.4-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-unf_ext | package | 0.0.9.1-1.3 | i586 | (System Packages)

...

It seems as if nothing has changed after trying to ensure that "zypper dup" has completed fully.

I purged ruby3.2* on several installations manually after they were upgraded to ruby3.3* and left behind. Why zypper dup purged them itself on some and why on others not I never tried to determine.

...

and probably all but the brothers

...
in the list above. I don't believe there's any justification to continue having libKF5* or libKPim5* packages installed any more unless you purposely locked them so that they could not be upgraded or removed. Boost*1_84_0* has been upgraded to 1_85_0*. Highly likely incomplete zypper dup is the root cause of https://bugzilla.opensuse.org/show_bug.cgi?id=1224061.

...

I honestly do not think this is the case here (imcomplete zypper dup). What is the best way to check the "zypper dup" for completed status then? Passing zypper ve -> Dependencies of all installed packages are satisfied. Passing zypper ll -> no package locks are defined.

Zypper ve can only do so much. I use zypper pa --unneeded to find out what remains stuck in the cobwebs and needs admin purging. Apt-get can do this automatically on Debian, but zypper apparently hasn't yet been taught how. Until every instance of "(System Packages)" can be satisfactorily justified, I consider a dup incomplete.

...

Enabling software rendering allows me to navigate SDDM but creates a much less usable system tray/taskbar. Disabling software rendering (reverting to hardware rendering) now, nearly disables SDDM's display capability to select a different window manager or whatever else. It is much more difficult due to every option label displaying blank fields. I have been working a bit with the Enlightenment desktop on this machine directly after the 32 bit KDE Plasma P6 MEGARELEASE issues.

Your old laptop with 945GM graphics appears may be on the edge of a support maintenance cliff. Cf. https://bugzilla.opensuse.org/show_bug.cgi?id=1212696 (i965-only problem) Many moons ago, a new display driver technology was introduced as default, called device independent X, or DIX. It wasn't intended to support antiques, as there was too little of it still working in the hands of driver developers and maintainers at that point in time. The dividing line between supported or not for Intel GPUs was somewhere between 945 (not supported; yours) and 965 (supported). Until then, display drivers were all device dependent, or DDX. Thus, oldies like yours need support need the DDX adequately maintained, in an environment where the newer favorite child "modesetting DIX" gets most of the developer attention. For the 945, that's the xf86-video-intel rpm. It hasn't had an official "release" in somewhere around a decade. The current version in TW is 2.99.917.916yadayada. :p AFAIK, none of the DMs I am happy to use (not GDM; not SDDM) care in any way about graphics rendering configuration. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

-pj

18 May 18 May

06:47

New subject: One quarter of screen displaying a white box in KDE V6

On 05-17-2024 02:17PM, Felix Miata wrote:

...

-pj composed on 2024-05-16 23:37 (UTC-0500): ...

...
i | ruby3.2 | package | 3.2.2-4.3 | i586 | (System Packages) i | ruby3.2-rubygem-abstract_method | package | 1.2.1-2.8 | i586 | (System Packages) i | ruby3.2-rubygem-cfa | package | 1.0.2-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-cfa_grub2 | package | 2.0.0-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-cheetah | package | 1.0.0-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-fast_gettext | package | 2.3.0-1.3 | i586 | (System Packages) i | ruby3.2-rubygem-gem2rpm | package | 0.10.1-22.3 | i586 | (System Packages) i | ruby3.2-rubygem-nokogiri | package | 1.15.5-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-ruby-augeas | package | 0.5.0-3.8 | i586 | (System Packages) i | ruby3.2-rubygem-ruby-dbus | package | 0.23.1-2.3 | i586 | (System Packages) i | ruby3.2-rubygem-simpleidn | package | 0.2.1-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-unf | package | 0.1.4-1.8 | i586 | (System Packages) i | ruby3.2-rubygem-unf_ext | package | 0.0.9.1-1.3 | i586 | (System Packages)

...
It seems as if nothing has changed after trying to ensure that "zypper dup" has completed fully.

I purged ruby3.2* on several installations manually after they were upgraded to ruby3.3* and left behind. Why zypper dup purged them itself on some and why on others not I never tried to determine.

Ok well then I will do so. Since zypper is not dpkg --purge one would pass -> # zypper rm ruby3.2 .........and so on right?

...

...
and probably all but the brothers

...
in the list above. I don't believe there's any justification to continue having libKF5* or libKPim5* packages installed any more unless you purposely locked them so that they could not be upgraded or removed. Boost*1_84_0* has been upgraded to 1_85_0*. Highly likely incomplete zypper dup is the root cause of https://bugzilla.opensuse.org/show_bug.cgi?id=1224061.

...
I honestly do not think this is the case here (imcomplete zypper dup). What is the best way to check the "zypper dup" for completed status then? Passing zypper ve -> Dependencies of all installed packages are satisfied. Passing zypper ll -> no package locks are defined.

Zypper ve can only do so much. I use zypper pa --unneeded to find out what remains stuck in the cobwebs and needs admin purging. Apt-get can do this automatically on Debian, but zypper apparently hasn't yet been taught how.

...

Until every instance of "(System Packages)" can be satisfactorily justified, I consider a dup incomplete.

...
Enabling software rendering allows me to navigate SDDM but creates a much less usable system tray/taskbar. Disabling software rendering (reverting to hardware rendering) now, nearly disables SDDM's display capability to select a different window manager or whatever else. It is much more difficult due to every option label displaying blank fields. I have been working a bit with the Enlightenment desktop on this machine directly after the 32 bit KDE Plasma P6 MEGARELEASE issues.

Your old laptop with 945GM graphics appears may be on the edge of a support maintenance cliff. Cf. https://bugzilla.opensuse.org/show_bug.cgi?id=1212696 (i965-only problem)

Thank you for bringing this into a more clear light so to say.

...

Many moons ago, a new display driver technology was introduced as default, called device independent X, or DIX. It wasn't intended to support antiques, as there was too little of it still working in the hands of driver developers and maintainers at that point in time. The dividing line between supported or not for Intel GPUs was somewhere between 945 (not supported; yours) and 965 (supported). Until then, display drivers were all device dependent, or DDX. Thus, oldies like yours need support need the DDX adequately maintained, in an environment where the newer favorite child "modesetting DIX" gets most of the developer attention. For the 945, that's the xf86-video-intel rpm. It hasn't had an official "release" in somewhere around a decade. The current version in TW is 2.99.917.916yadayada. :p

🫥Thanks for sharing this.

...

AFAIK, none of the DMs I am happy to use (not GDM; not SDDM) care in any way about graphics rendering configuration.

This is something that I did not realize before. I had tried XDM and then proceeded to go back to SDDM and learned of software render on GitLab after a month. So some say VTTY and some TTY. As for SDDM, its use hijacks vt1 & vt2 . I'll take your word for it right now. Is there something you can suggest I perhaps read on a bit about it? Obviously I am not an advanced user here. Please do feel free to add onto this and respond -Greatest Hopes

Felix Miata

08:33

New subject: One quarter of screen displaying a white box in KDE V6

-pj composed on 2024-05-17 23:47 (UTC-0500):

...

Felix Miata wrote: ...

...
I purged ruby3.2* on several installations manually after they were upgraded to ruby3.3* and left behind. Why zypper dup purged them itself on some and why on others not I never tried to determine.

...

Ok well then I will do so. Since zypper is not dpkg --purge one would pass -> # zypper rm ruby3.2 .........and so on right?

More or less. Zypper accepts wildcards to some degree. Bash completion helps minimize required typing, but it is frustrating to know Debian users have the autoremove advantage. ...

...

...
AFAIK, none of the DMs I am happy to use (not GDM; not SDDM) care in any way about graphics rendering configuration.

...

This is something that I did not realize before. I had tried XDM and then proceeded to go back to SDDM and learned of software render on GitLab after a month. So some say VTTY and some TTY. As for SDDM, its use hijacks vt1 & vt2 . I'll take your word for it right now. Is there something you can suggest I perhaps read on a bit about it? Obviously I am not an advanced user here.

The tradition amongst most distros for decades was to keep tty[1-6] available for text login sessions, and start the GUI DM on tty7, with any additional X sessions going to tty8, next tty9. The Gnome/GDM/systemd people several years ago decided this was no longer necessary, and moved GDM to tty1 (or tty2, I'm not sure which, as I never again installed GDM after the first time). The KDE devs played monkey see, monkey do on this. Neither group considered there to be any relevant disruption possible by this break in tradition. I have regular uses for tty1, tty2 & tty3, so no room for their intrusion into my workspaces. Ignoring my own uses, that tradition meant that when someone in a help forum was having X trouble, it was pretty much an unconditional given they could be told to Ctrl-Alt-F1 to reach a login prompt from which to attempt repairs and/or collect logs. That doesn't work at all when the greeter has usurped tty1. That made a lot of Google hits obsolete, or worse. TDM, KDM3 and XDM so far have remained on tty7. I think LightDM has too, but I'm not sure. It gets little use here. The same concept works in general, as it always has, because any of tty3-6 at least are normally free & equally capable when the DM has conscripted 1 and/or 2. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

Andreas Croci

09:11

New subject: One quarter of screen displaying a white box in KDE V6

...

The tradition amongst most distros for decades was to keep tty[1-6] available for text login sessions, and start the GUI DM on tty7, with any additional X sessions going to tty8, next tty9. The Gnome/GDM/systemd people several years ago decided this was no longer necessary, and moved GDM to tty1 (or tty2, I'm not sure which, as I never again installed GDM after the first time). The KDE devs played monkey see, monkey do on this. Neither group considered there to be any relevant disruption possible by this break in tradition. I have regular uses for tty1, tty2 & tty3, so no room for their intrusion into my workspaces. Just FWIW: on my freshly installed (three or four days ago) OpenSUSE LEAP 15.5 with default settings (Plasma 5), tty1-tty6 are free and whatever graphical stuff is running takes on tty7, like the good old

On 18/05/24 08:33, Felix Miata wrote tradition 😉.

Carlos E. R.

14:36

New subject: One quarter of screen displaying a white box in KDE V6

On 2024-05-18 09:11, Andreas Croci wrote:

...

On 18/05/24 08:33, Felix Miata wrote

...

...
The tradition amongst most distros for decades was to keep tty[1-6] available for text login sessions, and start the GUI DM on tty7, with any additional X sessions going to tty8, next tty9. The Gnome/GDM/systemd people several years ago decided this was no longer necessary, and moved GDM to tty1 (or tty2, I'm not sure which, as I never again installed GDM after the first time). The KDE devs played monkey see, monkey do on this. Neither group considered there to be any relevant disruption possible by this break in tradition. I have regular uses for tty1, tty2 & tty3, so no room for their intrusion into my workspaces.

...

Just FWIW: on my freshly installed (three or four days ago) OpenSUSE LEAP 15.5 with default settings (Plasma 5), tty1-tty6 are free and whatever graphical stuff is running takes on tty7, like the good old tradition 😉.

I don't expect Leap 15.x to be affected yet. Tumbleweed, might. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

Felix Miata

18:14

New subject: SDDM VT location (was: One quarter of screen displaying a white box...)

Andreas Croci composed on 2024-05-18 09:11 (UTC+0200):

...

Felix Miata wrote

...

...
The tradition amongst most distros for decades was to keep tty[1-6] available for text login sessions, and start the GUI DM on tty7, with any additional X sessions going to tty8, next tty9. The Gnome/GDM/systemd people several years ago decided this was no longer necessary, and moved GDM to tty1 (or tty2, I'm not sure which, as I never again installed GDM after the first time). The KDE devs played monkey see, monkey do on this. Neither group considered there to be any relevant disruption possible by this break in tradition. I have regular uses for tty1, tty2 & tty3, so no room for their intrusion into my workspaces.

...

Just FWIW: on my freshly installed (three or four days ago) OpenSUSE LEAP 15.5 with default settings (Plasma 5), tty1-tty6 are free and whatever graphical stuff is running takes on tty7, like the good old tradition 😉.

Another tradition - openSUSE does not always blindly accept upstream blunders. e.g. it shielded its users from https://bugzilla.gnome.org/show_bug.cgi?id=757142. I'm not directly aware of any other distro that did that, but I suspect Slackware may have, and possibly others. I tried Neon last year in order to see how KDE6 was shaping up. I could not find a way to get SDDM off VT1, or use a different DM. The only other distros where I've had Plasma installed are Mageia and Fedora. They switched to VT1 in due course. IIRC, some TW & Leap installations here stayed with tradition, while others didn't. Which did which I've not tried to track. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

Andreas Croci

18:40

New subject: SDDM VT location

On 18/05/2024 18:14, Felix Miata wrote:

...

Andreas Croci composed on 2024-05-18 09:11 (UTC+0200):

...
...
The tradition amongst most distros for decades was to keep tty[1-6] available for text login sessions, and start the GUI DM on tty7, with any additional X sessions going to tty8, next tty9. The Gnome/GDM/systemd people several years ago decided this was no longer necessary, and moved GDM to tty1 (or tty2, I'm not sure which, as I never again installed GDM after the first time). The KDE devs played monkey see, monkey do on this. Neither group considered there to be any relevant disruption possible by this break in tradition. I have regular uses for tty1, tty2 & tty3, so no room for their intrusion into my workspaces. Just FWIW: on my freshly installed (three or four days ago) OpenSUSE LEAP 15.5 with default settings (Plasma 5), tty1-tty6 are free and whatever graphical stuff is running takes on tty7, like the good old

Felix Miata wrote tradition 😉. Another tradition - openSUSE does not always blindly accept upstream blunders. e.g. it shielded its users from https://bugzilla.gnome.org/show_bug.cgi?id=757142. I'm not directly aware of any other distro that did that, but I suspect Slackware may have, and possibly others.

I tried Neon last year in order to see how KDE6 was shaping up. I could not find a way to get SDDM off VT1, or use a different DM.

The only other distros where I've had Plasma installed are Mageia and Fedora. They switched to VT1 in due course. IIRC, some TW & Leap installations here stayed with tradition, while others didn't. Which did which I've not tried to track.

Nice that you say that: it brings me to experimenting a bit and find out new (to me) things. I just tried in my Tumbleweed with Plasma 6 and the graphics stuff (don't know if it's SDDM, but I would guess it is) is on tty2. The others work as ttys. What I just found out, that I didn't know before: if I switch to tty1, the music I have playing in KDE "disappears", as is to be expected. As soon as I login to tty1, the music starts playing again even without graphics. Amazing.

Carlos E. R.

14:33

New subject: One quarter of screen displaying a white box in KDE V6

On 2024-05-18 08:33, Felix Miata wrote:

...

-pj composed on 2024-05-17 23:47 (UTC-0500):

...
Felix Miata wrote: ...

...
I purged ruby3.2* on several installations manually after they were upgraded to ruby3.3* and left behind. Why zypper dup purged them itself on some and why on others not I never tried to determine.

...
Ok well then I will do so. Since zypper is not dpkg --purge one would pass -> # zypper rm ruby3.2 .........and so on right?

More or less. Zypper accepts wildcards to some degree. Bash completion helps minimize required typing, but it is frustrating to know Debian users have the autoremove advantage. ...

...
...
AFAIK, none of the DMs I am happy to use (not GDM; not SDDM) care in any way about graphics rendering configuration.

...
This is something that I did not realize before. I had tried XDM and then proceeded to go back to SDDM and learned of software render on GitLab after a month. So some say VTTY and some TTY. As for SDDM, its use hijacks vt1 & vt2 . I'll take your word for it right now. Is there something you can suggest I perhaps read on a bit about it? Obviously I am not an advanced user here.

The tradition amongst most distros for decades was to keep tty[1-6] available for text login sessions, and start the GUI DM on tty7, with any additional X sessions going to tty8, next tty9. The Gnome/GDM/systemd people several years ago decided this was no longer necessary, and moved GDM to tty1 (or tty2, I'm not sure which, as I never again installed GDM after the first time). The KDE devs played monkey see, monkey do on this. Neither group considered there to be any relevant disruption possible by this break in tradition. I have regular uses for tty1, tty2 & tty3, so no room for their intrusion into my workspaces.

I got that surprise in some machine somewhere. I can't remember where exactly, was over a year ago.

...

Ignoring my own uses, that tradition meant that when someone in a help forum was having X trouble, it was pretty much an unconditional given they could be told to Ctrl-Alt-F1 to reach a login prompt from which to attempt repairs and/or collect logs. That doesn't work at all when the greeter has usurped tty1. That made a lot of Google hits obsolete, or worse. TDM, KDM3 and XDM so far have remained on tty7. I think LightDM has too, but I'm not sure. It gets little use here.

The same concept works in general, as it always has, because any of tty3-6 at least are normally free & equally capable when the DM has conscripted 1 and/or 2.

-- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)

-pj

20 May 20 May

04:04

New subject: Working with display managers and selecting session types: (Was) One quarter of screen displaying a white box in KDE V6

On 05-18-2024 01:33AM, Felix Miata wrote:

...

-pj composed on 2024-05-17 23:47 (UTC-0500):

...
Felix Miata wrote: ...

...
I purged ruby3.2* on several installations manually after they were upgraded to ruby3.3* and left behind. Why zypper dup purged them itself on some and why on others not I never tried to determine.

...
Ok well then I will do so. Since zypper is not dpkg --purge one would pass -> # zypper rm ruby3.2 .........and so on right?

More or less. Zypper accepts wildcards to some degree. Bash completion helps minimize required typing, but it is frustrating to know Debian users have the autoremove advantage.

Have completed removing all the packages that 'zypper pa --unneeded' displayed. Powercycled and no packages are finally found by the command.

...

...

...
...
AFAIK, none of the DMs I am happy to use (not GDM; not SDDM) care in any way about graphics rendering configuration.

...

...
This is something that I did not realize before. I had tried XDM and then proceeded to go back to SDDM and learned of software render on GitLab after a month. So some say VTTY and some TTY. As for SDDM, its use hijacks vt1 & vt2 . I'll take your word for it right now. Is there something you can suggest I perhaps read on a bit about it? Obviously I am not an advanced user here.

The tradition amongst most distros for decades was to keep tty[1-6] available for text login sessions, and start the GUI DM on tty7, with any additional X sessions going to tty8, next tty9. The Gnome/GDM/systemd people several years ago decided this was no longer necessary, and moved GDM to tty1 (or tty2, I'm not sure which, as I never again installed GDM after the first time). The KDE devs played monkey see, monkey do on this. Neither group considered there to be any relevant disruption possible by this break in tradition. I have regular uses for tty1, tty2 & tty3, so no room for their intrusion into my workspaces.

Thanks for writing about that.

...

Ignoring my own uses, that tradition meant that when someone in a help forum was having X trouble, it was pretty much an unconditional given they could be told to Ctrl-Alt-F1 to reach a login prompt from which to attempt repairs and/or collect logs. That doesn't work at all when the greeter has usurped tty1. That made a lot of Google hits obsolete, or worse. TDM, KDM3 and XDM so far have remained on tty7. I think LightDM has too, but I'm not sure. It gets little use here.

LightDM is on tty7 also. It has capability to select which session type is to be loaded after input login information provided. I did not see that with XDM and I believe that XDM has to be manually configured for which type of session to start.

...

The same concept works in general, as it always has, because any of tty3-6 at least are normally free & equally capable when the DM has conscripted 1 and/or 2.

Curiously selecting > Plasma , Wayland for the session type. The white box returns only this time in the bottom right corner.

Felix Miata

04:47

New subject: Working with display managers and selecting session types: (Was) One quarter of screen displaying a white box in KDE V6

-pj composed on 2024-05-19 21:04 (UTC-0500):

...

Curiously selecting > Plasma , Wayland for the session type. The white box returns only this time in the bottom right corner.

https://bugzilla.opensuse.org/show_bug.cgi?id=1224061 needs an update with your observations since reporting. If this is a reproducible bug it would be nice to know how so a fix can be found. Screenshots should be attachments bug reports, not susepastes, which may expire before their usefulness. That white box looks like it may be an X terminal with its titlebar above the top of the screen. If you can reproduce it in any way, try clicking in it to locate focus there, then hold down the <ENTER> key for a while to see if shell prompts appear. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

-pj

06:27

New subject: Working with display managers and selecting session types: (Was) One quarter of screen displaying a white box in KDE V6

On 05-19-2024 09:47PM, Felix Miata wrote:

...

-pj composed on 2024-05-19 21:04 (UTC-0500):

...
Curiously selecting > Plasma , Wayland for the session type. The white box returns only this time in the bottom right corner.

https://bugzilla.opensuse.org/show_bug.cgi?id=1224061 needs an update with your observations since reporting. If this is a reproducible bug it would be nice to know how so a fix can be found. Screenshots should be attachments bug reports, not susepastes, which may expire before their usefulness.

I have added attachments *not* susepaste to the Bug Report now. Thank you for reminder of this.

...

That white box looks like it may be an X terminal with its titlebar above the top of the screen.

To me the white box seems to somehow act like it is 'alive'. When Dolphin is opened it is set for Konsole to be displayed at the bottom portion (see bug report attachment). When enter/CR is tapped Konsole attempts to rightfully take back the screen. If left for a minute the white box takes it's desired bottom right 1/4 of the screen back. This is now when a Plasma6 (Wayland) session is loaded. Obviously since Plasma (X11) is usable now it's not a horrible problem like before. If you can reproduce it in any way, try clicking in it to locate

...

focus there, then hold down the <ENTER> key for a while to see if shell prompts appear.

Nothing seems to be able to appear in the white box when it is clicked or clicked on. I have updated the bug report to include my findings. https://bugzilla.opensuse.org/show_bug.cgi?id=1224061 -Best Hopes🫥

Age (days ago)

Last active (days ago)

List overview

Download

21 comments

4 participants

participants (4)

-pj
Andreas Croci
Carlos E. R.
Felix Miata

Unable to load X11 session after Tumbleweed update:

tags

participants (4)