I installed latest tumbleweed. after installing i saw that the resolution in X/KDE5 is set to 640x480 and i can not incrase the resolution in Controllcenter. I found out, that i have to install the openchrome driver for my graphiccard. Now i get a blinking courser after restarting. If i start X manual, using startx i get a screen with higher resolutions available.
i set kernel parameters to disable vesafb and nomodeset.
If i start normal i do not get a X.org-log.
Hello and welcome here.
As you are talking about your graphics card, may we please now what graphics card you use?
lspci tells me the graphic card is Via P4M890 [S3 UniChrome Pro] (rev 02)
Its a little bit frustrating. No i tried a GeForce 7600GS. Also failed. See https://forums.opensuse.org/showthread.php/530865-Installtion-of-NVIDIA-Linux-x86_64-304-137-run-failed?p=2863854#post2863854 .
Thanks for your help!
Is there a logfile of systemd, sddm which is created if it is started through systemd? Please help me…
Now i uninstalled sddm 0.17 and installed 0.14 from latest Leap. After that i reenabled ( systemctl enable sddm.service ) sddm. After that i blocked updating sddm. Works now for me. Hope there will be a fixed version of sddm in the future.
Good that it works for you now, but remember that you break the integrity of the system.
I know. But i do not know whats excatly my problem is. I read that version 0.16 has a problem with the order of starts by systemd. Some graphic parts are started too late or something like that.
If you have a i solution idea, feel free to tell me.
That should be irrelevant in openSUSE, as sddm is normally started via a generic display-manager.service specific to our distribution.
sddm 0.17.0 is definitely not broken in general, it is of course tested by openQA, and it works fine here on all my 42.3 systems.
Maybe you could provide the /var/log/Xorg.0.log from a failed start?
And/or the output from “sudo systemctl status display-manager.service”.
Thanks for your reply. I also do not think sddm is broken. But i searched alot and read on different websites that many users have problems with sddm 0.16 and up.
If it helps i will post /var/log/Xorg.0.log and the status of displaymanager with sddm 0.17 later.
Here you find the files of a failed start.
http://files.fm/u/zyug7rc8
Hope you see something i did not see. Thanks for your Help!
That may have various reasons though.
In particular, you are using the same display-manager.service (which is actually part of the xdm package) with sddm 0.14, so it’s unlikely the reason for your problem.
Unless you enabled sddm.service manually.
If it helps i will post /var/log/Xorg.0.log and the status of displaymanager with sddm 0.17 later.
If you want possible further help trying to get 0.17 to work, please do.
If you’re fine with using sddm 0.14, it doesn’t matter much I’d say… 
Well, I suppose yes.
First of all, you did enable the sddm.service apparently.
Try to run “sudo systemctl enable display-manager.service”.
Then, you are using the CHROME driver, which probably doesn’t have proper OpenGL support (and SDDM needs OpenGL support because of its usage of QML).
What output do you get if you install Mesa-demo-X and run “xglinfo | grep render”?
Although, that shouldn’t make a difference between sddm 0.14 and 0.17…
It might even be necessary to run “sudo systemctl disable sddm.service” first.
Please run “systemctl status display-manager.service” to check which one is really used.
It will tell quite at the beginning:
● display-manager.service - X Display Manager
Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; vendor preset: enabled)
In the things you provided, it says:
● sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: disabled)
I uploaded now the logfiles with 0.14 (all files with _0.14) and with 0.17 (without mark). I also did diffs and uploaded screenshots of them. There are interesting diffs i think, but do not know if it helps.
Here you find the files. https://files.fm/u/nz5tbwqg
Thanks for your help!
linux-aqyn:~> systemctl status display-manager.service
**●** sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: disable
Active: **active (running)** since Wed 2018-05-02 20:22:25 CEST; 33min ago
Docs: man:sddm(1)
man:sddm.conf(5)
Process: 1534 ExecStartPre=/usr/bin/plymouth quit --retain-splash **(code=exited, status**
Main PID: 1535 (sddm)
Tasks: 6 (limit: 2296)
CGroup: /system.slice/sddm.service
├─1535 /usr/bin/sddm
└─1539 /usr/bin/X -nolisten tcp -auth /run/sddm/{8b3cd4fc-f9d3-4cb0-bfa8-5a93
linux-aqyn:~> systemctl status sddm.service
**●** sddm.service - Simple Desktop Display Manager
Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: disable
Active: **active (running)** since Wed 2018-05-02 20:22:25 CEST; 36min ago
Docs: man:sddm(1)
man:sddm.conf(5)
Process: 1534 ExecStartPre=/usr/bin/plymouth quit --retain-splash **(code=exited, status**
Main PID: 1535 (sddm)
Tasks: 6 (limit: 2296)
CGroup: /system.slice/sddm.service
├─1535 /usr/bin/sddm
└─1539 /usr/bin/X -nolisten tcp -auth /run/sddm/{8b3cd4fc-f9d3-4cb0-bfa8-5a93
What output do you get if you install Mesa-demo-X and run “xglinfo | grep render”?
Although, that shouldn’t make a difference between sddm 0.14 and 0.17…
For all reading here, the package is named Mesa-demo-**x . **Looks like i misunderstood something?
[CODE]linux-aqyn:/ # zypper install Mesa-demo-x
Repository-Daten werden geladen…
Installierte Pakete werden gelesen…
Paketabhängigkeiten werden aufgelöst…
Das folgende NEUE Paket wird installiert:
Mesa-demo-x
1 neues Paket zu installieren.
Gesamtgröße des Downloads: 37,8 KiB. Bereits im Cache gespeichert: 0 B. Nach der
Operation werden zusätzlich 95,8 KiB belegt.
**Fortfahren? [j/n/…? zeigt alle Optionen] (j): **j
Paket Mesa-demo-x-8.4.0-1.1.x86_64 abrufen (1/1), 37,8 KiB ( 95,8 KiB entpackt)
Abrufen: Mesa-demo-x-8.4.0-1.1.x86_64.rpm …[fertig]
Überprüfung auf Dateikonflikte läuft: …[fertig]
(1/1) Installieren: Mesa-demo-x-8.4.0-1.1.x86_64 …[fertig]
linux-aqyn:/ # xglinfo | grep render
xglinfo: command not found
linux-aqyn:/ # which xglinfo
which: no xglinfo in (/sbin:/bin:/usr/sbin:/usr/bin)
Now i try to disable sddm and enable displaymanager with 0.17. Will report.Yes, sorry.
It should have been “glxinfo”, not “xglinfo”
Now i try to disable sddm and enable displaymanager with 0.17. Will report.
As you suggested yourself that it might be an upstream problem with sddm.service, that probably will help IMHO.
Btw, to post the diffs was a good idea in principle, but you could also just post them in text form, may be easier for everybody involved…
linux-aqyn:~/Downloads # glxinfo|grep render
direct rendering: Yes
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: llvmpipe (LLVM 6.0, 128 bits)
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_NV_conditional_render, GL_NV_depth_clamp, GL_NV_packed_depth_stencil,
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_NV_blend_square, GL_NV_conditional_render, GL_NV_depth_clamp,
GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
I am sorry to say, but did not help 
Here are the logfiles: https://files.fm/u/xphwujjw
Yes i know. first i tried with “diff” but because of the timestamps in every line i got to many differences. so i used kdiff3. it was easier and faster to get a useful output.
Ok, that confirms that you are using Mesa’s software OpenGL renderer, and matches the Xorg log:
3311.849] DRM memory allocation failed -6
3311.849] (II) CHROME(0): Using default xfree86 memcpy for video.
3311.849] (WW) CHROME(0): [XvMC] Cannot use XvMC without DRI!
3311.849] (II) CHROME(0): - Done
3311.857] (II) AIGLX: Screen 0 is not DRI2 capable
3311.857] (EE) AIGLX: reverting to software rendering
3313.192] (II) IGLX: enabled GLX_MESA_copy_sub_buffer
3313.194] (II) IGLX: Loaded and initialized swrast
3313.194] (II) GLX: Initialized DRISWRAST GL provider for screen 0
That’s slower of course, but should not cause a problem in principle.
(the log doesn’t actually mention the fglrx/ati drivers btw)
I am sorry to say, but did not help
Hm, then it’s rather not a problem with the systemd service file…
And actually I see nothing wrong in the systemctl output, that would rather indicate that sddm works fine and is running. :
Maybe some bug in the graphics driver or Mesa’s software renderer? (that only affects the newer version for some reason)
Unfortunately, I have no idea what to do then though. (I have no experience with the openchrome driver either)
Maybe it would help to use a different theme?
Try to put one of the following into /etc/sddm.conf:
[Theme]
Current=
[Theme]
Current=circles
[Theme]
Current=elarun
[Theme]
Current=maldives
[Theme]
Current=maya
Another thing you could try is to delete /var/lib/sddm/.cache/, maybe the newer version doesn’t like the cache files from the old version on your system…
Does sddm work if you run it inside a graphical session?
sddm-greeter --test-mode --theme /usr/share/sddm/themes/breeze-openSUSE
As the login screen doesn’t work, you’d need to switch to another one first of course, you can choose which one to use from the installed ones via:
sudo update-alternatives --config default-displaymanager
If that doesn’t work either, the terminal output may provide some clue.
You could also try to make sddm’s greeter suid root, maybe it’s some permission problem.
sudo chmod +s /usr/bin/Xorg
That’s all more or less guessing though.
Of course you can also use any other login manager if you like, lightdm e.g.
Just install it and set it with “update-alternatives” (as written above).
There’s nothing special in sddm that would be “required” by Plasma.
First of all thanks for your help. The problem does not hurt me much, but i want to find out the problem.
If i start X and start the command inside a terminal-window it shows up.
setuid for /usr/bin/Xorg is/was not set. Checked with
find /usr/bin/Xorg -user root -perm -4000 -exec ls -ldb {} \;
I will now restart and see/report what happens.