Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sddm doesn't work with old PC, with graphic card who supports only openGL 1.3 ( black screen at startup ), #575

Open
Potomac opened this issue Dec 17, 2015 · 15 comments

Comments

@Potomac
Copy link

commented Dec 17, 2015

I tried to use sddm on an old laptop ( pentium 2.4 Ghz, radeon 9000 AGP, driver : radeon open source ), archlinux 32 bits, sddm version : 0.13.0,

at startup sddm shows only a black screen, and the keyboard doesn't work, it seems like a "freeze", I don't see mouse cursor, and it's impossible to switch to a virtual console ( alt-f2 ) because the keyboard seems frozen,

I want to know the minimal hardware requirements in order to use sddm ?

is it possible to use sddm on a very old PC ? ( from 2003, a PC with a graphic card who supports only openGL 1.3 for example )

the other display managers ( kdm, slim ) work without problems with my old PC, so there is something wrong in sddm, something who prevents old graphic cards to work

@tpgxyz

This comment has been minimized.

Copy link

commented Dec 18, 2015

It's not SDDM fault as it's Qt5Gui which needs OpenGL 2+ features.
Imho good solution would be if SDDM before starting sddm-greeter checked for OpenGL 2+ and if this is not met then export QT_XCB_FORCE_SOFTWARE_OPENGL=1 to use software rendering.

@plfiorini

This comment has been minimized.

Copy link
Member

commented Jan 28, 2016

Or distros should do it. Some like Fedora already does [1], likely other QtQuick applications won't work either without the env var so this has to be addressed everywhere.

[1] https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140127/1181404.html

@KOLANICH

This comment has been minimized.

Copy link

commented Jul 2, 2017

then export QT_XCB_FORCE_SOFTWARE_OPENGL=1 to use software rendering.

It doesn't work (even with LIBGL_ALWAYS_SOFTWARE). Also I don't think it's a good idea to use software rendering.

@tachometer

This comment has been minimized.

Copy link

commented Jan 2, 2018

To temporarily work around this, you can add QT_QUICK_BACKEND=software to /etc/security/pam_env.conf . I verified it on my Raspberry PI 3 and no CPU load from the greeter anymore.

@Serverhamster

This comment has been minimized.

Copy link

commented May 6, 2019

Fedora 29 here. The screen is not blank, but sddm does not accept any input unless QT_XCB_FORCE_SOFTWARE_OPENGL=1 or QT_QUICK_BACKEND=software is set.

@kkofler

This comment has been minimized.

Copy link

commented May 6, 2019

The issue in Fedora appears to be that the Fedora workaround runs from xinitrc.d which is not getting run for SDDM's own session, only for the sessions it spawns.

@plfiorini

This comment has been minimized.

Copy link
Member

commented May 6, 2019

@kkofler So would it be sufficient if we create a wrapper that source /etc/X11/xinit/xinitrc and then run the greeter? The same goes for the Xorg server perhaps?

@kkofler

This comment has been minimized.

Copy link

commented May 6, 2019

On Fedora, that would probably work. If the distro does not ship anything like our https://src.fedoraproject.org/rpms/qt5-qtbase/blob/master/f/10-qt5-check-opengl2.sh , then of course it won't help.

@kkofler

This comment has been minimized.

Copy link

commented May 6, 2019

What you could do in the wrapper is to not source anything, but just do the check directly. (You can just copy&paste the code from Fedora. I wrote it and I don't think it even qualifies for copyright protection, as trivial as it is.)

@plfiorini

This comment has been minimized.

Copy link
Member

commented May 6, 2019

Or we can copy 10-qt5-check-opengl2.sh to SDDM and just do that, so we don't even mess how Xorg and greeter are launched.

@plfiorini

This comment has been minimized.

Copy link
Member

commented May 6, 2019

We had the same idea :)

@plfiorini plfiorini added this to the 0.19 milestone May 6, 2019

@KOLANICH

This comment has been minimized.

Copy link

commented May 6, 2019

If I remember right, no QtQuick apps were working on pre-SSE2 computers because Qt libs for QtQuick were built using SSE2. Some apps (more precisely KDevelop) have worked it around with some degradation by disabling the features requiring QtQuick. I have worked that around by using LightDM, though IMHO the stuff should be fixed in order to work on ancient PCs.

@kkofler

This comment has been minimized.

Copy link

commented May 6, 2019

Qt Quick can be built without SSE2 ever since they switched from V8 to Qt's V4, at least with some patching (see https://src.fedoraproject.org/rpms/qt5-qtdeclarative/tree/f28 ). The V4 JavaScript engine will be in pure software mode, without JIT, but it will build without -msse2 and run on non-SSE2 x86 without triggering SIGILL. (That said, some distros, such as Fedora ≥ 29, do not support non-SSE2 x86 anymore, so rebuilding Qt Quick alone will not help you on such a distro.)

@kkofler

This comment has been minimized.

Copy link

commented May 6, 2019

(What we did for Fedora ≤ 28 was that we actually built qt5-qtdeclarative twice on 32-bit x86, once without SSE2 and JIT, and once with SSE2 and JIT enabled, and installed the latter to `/usr/lib/sse2'. So only people on ancient non-SSE2 machines got the performance hit from the disabled JIT.)

@KOLANICH

This comment has been minimized.

Copy link

commented May 6, 2019

I know that it may be possible (in practice I guess it is not, even building simple apps requires tremendous amounts of RAM nowadays, for example today I have built not a very large machine learning library (it is not large, the -O3 binary is several MiB), while building almost none of RAM was free, the good thing was I was building on Windows, if I was building this on Linux, I would have to hit reset button thanks to 12309) to build everything myself and even use Gentoo. So IMHO it is a distro issue (I use Lubuntu on ancient computers). Though I don't expect this be fixed - most of distros, including Lubuntu, are phasing out i686.

What we did for Fedora ≤ 28 was that we actually built qt5-qtdeclarative twice

Thank you for the info. I wonder if they can be transplanted to lubuntu.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.