Any new news on support for this?

I guess not. The developers don't seem to consider this an important feature, which is probably why they didn't implement it in the first place.

And people wonder why the "year of the ****X Desktop" never comes. A mystery why KDE, LXQt and the upcoming Budgie rewrite choose SDDM as their new display manager. Hope someone keeps KDM alive, as at least that is feature complete. All in all a morbidly unprofessional and sad turn of events.

As none of the maintainers has even looked at or even considered replying to this thread - its time to close it and give up on SDDM. Not professional enough. Hopefully the KDE and other Qt desktop teams can wake up and switch to something more viable than this.

XDMCP is not secure and will likely not be supported by SDDM.

True, but then it is standard practice to wrap XDMCP in SSH.
XDMCP is however the only tried and true mechanism to date to allow for multi-user graphical terminal services in GNU/Linux environments. It is preposterous to be forced into SDDM by the major distributions when it is clear that SDDM is more about making things look pretty rather than being feature complete.

Rather than just saying 'its insecure therefore we won't support it' - how about supporting it until an alternative is available, or figuring out some mandatory SSH or TLS mechanism to secure it instead? Everyone knows Telnet, XDMCP and many others are insecure - which is why they get wrapped. Nobody would blame the SDDM team for the inherent security flaws in XDMCP.

But its not going to happen for a combination of reasons such as 'rather not support anything that might make the project look bad even if there aren't any viable alternatives for the foreseeable future' + 'prettiness outweighs functionality' type reasoning. And it took more than a month for someone to even consider replying to the request. I wouldn't be complaining if SDDM was optional - but it isn't thanks to the KDE, LXQt and other Qt desktop teams. Ridiculous. The FOSS community should be working on feature completeness, not regression.

Let's hope either someone on the SDDM team wakes up and sees the value of functionality over aesthetics - Or - that a better project comes along then.

I work on open source for free, unfortunately I'm not employed by any of the companies that ship SDDM in their Linux distros, therefore I will not spend my spare time writing code for features I'm not interested in. Figuring out some mandatory SSH or TLS mechanism would ad extra days of work to the analysis, develop and test phases, that makes it even worse. Since nobody has ever implemented this feature, not even people employed by open source companies, this likely means that XDMCP will not be supported for the foreseeable future.
For the same reason I respond to tickets when I can (best effort).

FWIW I stumbled on this tidbit from 2008:

https://www.phoronix.com/forums/forum/software/general-linux-open-source/46194-sddm-is-the-recommended-display-manager-of-kde-plasma-5?p=586734#post586734

@gocpp you can always try to implement it and send a PR 😃

@plfiorini - I can understand the stance you take on the matter; although I do not agree or share it. I too write and develop a lot of open source software for free - and a big part of it is writing code for sake of compatibility and interoperability purposes with platforms I truly despise at every level (which I won't name beyond referencing eaten fruit or panes of glass). I couldn't care or be interested less in creating interoperability between POSIX and those platforms on a personal level - but that's not the way it is. It has to be done to bridge the gaps. So I do it, regardless of personal preference - for sake of compatibility and the hope of expanding the amount of open source followers and steal them away from the worship of rotten fruit or stained panes of glass. Its not about preference - its about real world usage scenarios.

That said I must admit I thought there was some communication between the KDE (and other) teams and the SDDM teams. I stand corrected. I shall then direct my frustration to said teams and confront them with the question of why on earth they thought dropping multi-user graphical terminal service-support by adopting a seemingly (and now in this thread declared - perpetually incomplete) display server was a good idea.

So apologies to you - I didn't realise this project was about personal preference and mistakenly assumed this was a collaborative effort to ditch KDM due to its dependency on XDM and head for a pure (and feature complete) display server in C++ & Qt. I shall therefore direct my attention to the KDE and LXQt teams instead and petition them to drop SDDM.

@bew - not in a million years will I contribute to a project that prefers personal preferences over functionality. I'd rather write a new display server from scratch. Which is what I'll do if I'm ever finished writing the functional code I don't personally care for but see the need for.

@dtzWill - Exactly. And because of that every Qt based Desktop project is recommending it as well. Guess none of them have ever looked at Enterprise posix deployments. What a disaster.

Edit: In case you meant the section that quotes:

In a wayland world, how are we going to do thin clients? Honestly, I don't know. I doubt it will be XDMCP in it's current form, and realistically we're not going to write a lot of code knowing it will be pretty soon redundant.

Well, that was said in 2014. This is 2018. Wayland still hasn't become the defacto standard in Enterprise deployments and likely won't until the issue is properly tackled. Thin Clients / Graphical Terminal Services are often vital in Enterprise deployments.

Thus until something else comes along - the world needs XDMCP. Not because its perfect, but because it works (for now).

@gocpp - you can save your time and i can answer right here - we (LXQt) recommend SDDM and will do in future. Please notice that it is a recommendation - so we don't depend on SDDM. In other words - the user has the choice. And if you would have a slightly deeper look into LXQt you would notice that nearly every component can be changed at users whish.

PS: Can't figure out who is 'us'

@agaida - obviously none of the aforementioned Desktop environments depend on the display manager and obviously an alternative can be installed - this was clearly referenced to in the original post. But with KDE adopting SDDM over KDM for example all development on KDM has - or soon will - cease except for maybe some security updates - thus the dependency will occur over time due to lack of alternatives; Lightdm is also being abandoned, leaving only GDM to support XDMCP for the foreseeable future, making for muddied and 'unclean' installations among other issues.

Recommendation by a major popular desktop environment will influence time and energy spent on related projects - thus shape the future of those projects and therefore (in the long run) the features that are available to users.

No need to discuss it further - I get it; no efforts will be made by the Qt-based desktop communities to honour backwards compatibility, offer graphical terminal services etc - until someone else makes a drop in replacement for the aforementioned in such a way as to be Wayland friendly and with modern security in mind and preferably in such a way that it requires no effort whatsoever by said Qt-based desktop teams. Thus it will be either a clean but outdated GTK based deployment for enterprise environments, or a muddied and non-cohesive mixed GTK & Qt based mess - until someone has the time to reinvent all that which has been already stated. Thank you for your efforts, taking the time to truly read that which has been said in the thread, dwelling on the implications in the long term etc. Much appreciated.

Ok, still can't figure out who us is - have a happy life.

@agaida - it is irrelevant who us is for now. To you I say: have a happy life skimming text rather than reading, and contributing to fragmentation rather than integration.

@gocpp XDMCP is not relevant to most users and it's unsecure, all reasons to downvote it from the list of features with higher priority that should be supported with my very limited spare time. But since SDDM is open source and community based, feel free to act as integral part of this community and submit a PR.

Maybe stick with us and become a core developer yourself over time so we'll all enjoy adding every feature missing together.

This discussion made me realize that it's time to actively promote the Bountysource page where users can influence priorities by putting money where their mouth is.

Feel free to check it out: https://www.bountysource.com/teams/sddm

@plfiorini - it may seem less relevant as the default environment in Enterprise deployments (Red Hat, SUSE Enterprise and Ubuntu) tends to be GNOME based (which does support XDMCP) instead of KDE or other Qt based options. Therefore the vote is most likely coming from single-user desktop minded folk.

And yes it is insecure but it is also all we have on posix environments for the moment - that was already established earlier on in this thread. Having users wrap it in SSH or implementing a mandatory wrap in SSH or TLS would mitigate said insecurity.

But its already made clear that there is no intention in this community to implement it - I get it, so the discussion is closed.

I wasn't aware of the Bountysource SDDM page - that should indeed be more actively promoted. A good way to increase funding.

We shall see if the resources can be committed to implement it ourselves - with the very real risk of having the PR rejected and resources wasted as this community doesn't deem XDMCP relevant. A high risk indeed. Let's see.

tl;dr
Security reasons to abandon XDMCP are weak reasons: we are usually able to manage security (SSH, iptables, awareness) and we are requested to be responsible.
It is simply a useful feature to manage my small laptop with my large desktop screen when I'm at home. LightDM is the solution.

SO Sad to see this thread - lots of people wanting to use XDMCP. SSDM not implementing it is a real problem for me too.

David