Created attachment 647434 [details]
lack of refresh?

This may be not only a problem in kdm. I attach a screen-shot of what happens with the milestone when you upsize a firefox-page to fullscreen.

Flickers and often does not build correctly. This may be correlated to the login behavior or not, but as also the login screen flickers weiredly.... This is not the case with tumbleweed where both problems where not present with the very same machine.

(In reply to Stakanov Schufter from comment #0)
> When you input the password (correct one) in kdm login screen (provided that
> with plasma5 it is still called such, you end up with the same screen as if
> the password would be wrong (only without statement wrong password). 
> That is black dots in the field and input mask.
> Only when you click on the unlock button beside the password field with the
> mouse, the system opens correctly (but the mask flickers wildly before
> vanishing). 

First, is this a default installation?
You are using SDDM then, not KDM.

Second, do you really mean the *login* screen? (that one has no unlock button)
Or rather the screenlocker? (which is totally unrelated to either KDM or SDDM)

> A password if correct should give unlock of the screen when you press enter. 
> The current situation could induce the user to believe the password written
> might be wrong. 

So this is actually about the screen locker it seems. Changing the summary accordingly.

Do I understand you correctly, that unlocking works if you click on the unlock button, just the Enter key is not accepted?

I can only say that this works fine on my 13.2 system here, and also on Tumbleweed when I tested it.

> I put this under "workspace" but maybe bugs to kdm should be filed under
> application?

Well, the display manager rather belongs to the "workspace", just like the screen locker.

(In reply to Stakanov Schufter from comment #1)
> This may be not only a problem in kdm. I attach a screen-shot of what
> happens with the milestone when you upsize a firefox-page to fullscreen.
> 
> Flickers and often does not build correctly. This may be correlated to the
> login behavior or not, but as also the login screen flickers weiredly....
> This is not the case with tumbleweed where both problems where not present
> with the very same machine.

Would rather look/sound like a graphics driver problem to me.
Can you reproduce in "recovery mode"?

Hi,

This problem is still present in Leap 42.1 RC1, and I don't consider it "minor": I cannot unlock the screen, neither clicking on "Unlock" ("Entsperren") nor pressing the <ENTER> key unlocks the screen, despite the password being 100% correct.

(In reply to Thomas Schmid from comment #3)
> This problem is still present in Leap 42.1 RC1, and I don't consider it
> "minor": I cannot unlock the screen, neither clicking on "Unlock"
> ("Entsperren") nor pressing the <ENTER> key unlocks the screen, despite the
> password being 100% correct.

This sounds like a completely different problem though as the one reported here.

Is this a fresh installation, or an upgrade?
Your problem might actually be Bug#931296.

I have this problem on one station where I upgraded from openSuSE 13.2 to Leap 42.1 RC1.

On another station, where I had done a fresh install of Leap 42.1 M2, then upgraded to Beta1 and now RC1, unlocking the lock screen does work.

Side note: On 3 stations I have installed Leap 42.1 RC1, I have 3 different start and lock screens, without having consciously change any of these settings..

>Is this a fresh installation, or an upgrade?
Upgrade from 13.2

>Your problem might actually be Bug#931296.
Yes, it is: I used the "+s"-workaround in Bug#931296#c1 for kcheckpass, and now unlocking works.
I do not understand to what conclusion the team came in the end of Bug#931296.

(In reply to Thomas Schmid from comment #6)
> >Is this a fresh installation, or an upgrade?
> Upgrade from 13.2

And before that you probably upgraded from earlier versions too...
openSUSE uses pam_unix.so as default since 12.3 already.

> >Your problem might actually be Bug#931296.
> Yes, it is: I used the "+s"-workaround in Bug#931296#c1 for kcheckpass, and
> now unlocking works.

Be aware that you should add a line for this to /etc/permissions.local though, or it will be overwritten on updates.

I think the better "fix" is to adapt the PAM config though.
You should have some .rpmnew files in /etc/pam.d/, just move/copy them over the corresponding common-xxx-pc files.
Or running this *should* fix it too:
pam-config -d --unix2
pam-config -a --unix

> I do not understand to what conclusion the team came in the end of
> Bug#931296.

Me neither.
Especially since kcheckpass had the suid bit set for years in KDE4 already.

(In reply to Wolfgang Bauer from comment #7)
> > I do not understand to what conclusion the team came in the end of
> > Bug#931296.
> 
> Me neither.
> Especially since kcheckpass had the suid bit set for years in KDE4 already.

PS, just to be clear here:
The team came to no conclusion at all in the end of Bug#931296.
The last comment just means that the request for changing the kcheckpass permissions will likely be declined again by the security team, as it already has been once (Bug#926267).

Lets just collect all the same bugs under one :)

*** This bug has been marked as a duplicate of bug 931296 ***