sddm
sddm copied to clipboard
sddm
Improve SDDM's multiuser system performance
Hello, as part of a university linux project we (a team of 2 students) want to contribute to SDDM.
One of our goals is to improve the multiuser system capabilities of SDDM.
As of now, SDDM generates a list of users which then can be selected in a "scroll bar" in some themes such as the default/fallback theme. This is nice and looks great, but with a multiuser system as the one here in our university, this list is of little use since nobody wants to scroll through thousands of entries.. Sure, one can use a different theme, but SDDM is always generating the userlist. And iterating over well over 10 000 users for its creation just generates unnecessary load on the LDAP-server.
To solve this we have 2 approaches:
-
Add a config entry to disable the generation of the UserModel-object. This would probably be the easiest way of doing it, but there's one problem: The default theme relies on the UserModel-object. So if one would enable the "multiuser-system-mode", the default theme would become useless as it wouldn't allow anybody to log in..
-
Another approach would be to add some "requirements" for the themes. This is probably more "configuration-friendly", as it would not require any new config entry. Instead a metadata entry in each theme not relying on this user list specifying the need for the UserModel-object could disable the generation of this list.
Maybe you have a better idea.
Thomas and Milan
P.S.: Of course we will develop this feature in the open on GitHub and give updates here.
What about instantiate UserModel from QML only when needed instead of a context object that is always created?
I like the idea of letting the theme decide but keep in mind this would break backward compatibility with older themes and would conflict with the separation of code and theme. Our approach in modifying the metadata would only affect new themes explicitly having a setting "IgnoreUsermodel=true" to disable querying passwd-entries.
Best regards Milan and Thomas
It's good that you're thinking of the compatibility, but this is also available with the version number in the metadata.
The theme metadata contains two version-numbers, "Version" and "Theme-API". Theme-API describes the components-version to draw elements, so we obviously can't use it for our purpose. Version is not used yet - is it planned to store the theme's version or the "greeter's featureset version"?
Of course we could implement a third version-number but we think the best way to implement such changes is by using feature-flags that can be set in the metadata to tell the greeter which features are supported by the theme.
This way we can:
- extend functionality without breaking backward-compatibility
- keep the code clean (too many version checks would lead to confusing code, feature checks are nicer to maintain)
- separate code and theme
- enable themes to use a certain subset of the possible features, depending on the flags set in its metadata
Version is not used yet
It is, just not by SDDM. It's so if you are distributing a theme via store.kde.org or whatever you can see if there's a new version of the theme out. You're right we can't use it here.
Theme-API describes the components-version to draw elements, so we obviously can't use it for our purpose.
That's not quite right. The Theme-API version does not control what component version is used.
The "import SddmComponents N.M" line in the QML does.
There's no reason for the metadata to care what import is used, and there are some themes outside SDDM that set Theme-API but don't use SDDM's components at all.
The CMake for the included themes just lazily uses the same variable, because they're both 2.0. That could easily change.
There is a huge advantage for doing what Pier suggested which hasn't been mentioned.
If we did that I could write a theme that had a text prompt initially and dynamically switched to using the user switcher or switched using a theme config.
In fact, Plasma's theme does that.
If we only construct the UserModel when instantiated we can do that better. Using the .desktop file limits your theme to only doing one or the other.
Another suggestion is to have a configuration file with "MaximumUid=-1", and change the user scanning code to not scan if Max < Min.
Additional users ("last", "root", whatever), could be forced visible via a new "ShowUsers=..." configuration entry, as suggested by https://github.com/sddm/sddm/issues/559
Is this still relevant after https://github.com/sddm/sddm/commit/316bfb54c5f362d31757d3431ef9f8353cc6c870?
Why not load solely the currently observed entries of the list rather than iterate through all of them, and provide a search-bar if the name is known already? Those should more dynamically remediate the problem than arbitrary limitation of how many users to iterate.
