[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Fingerprint management module and kgreeter plugin
From:       Jaroslav Barton <djaara () djaara ! net>
Date:       2009-09-25 18:20:42
Message-ID: 1253902842.9273.21.camel () localhost
[Download RAW message or body]

Aaron J. Seigo píše v Pá 25. 09. 2009 v 10:31 -0600:
> On September 25, 2009, Jaroslav Barton wrote:
> > This problem is nowadays corrected (since revision 1026101 by Oswald
> > Buddenhagen - thanks a lot) in KDM, krunner/lock is still affected with
> > this issue.
> 
> can you explain what the issue is in more detail and point to where in the 
> code the problem is being experienced (either in kfingermanager or in 
> krunner/lock?). i don't have a finger print scanner so can't check for myself.


Problems were in kdebase/workspace/kdm/kfrontend/(kgreeter.cpp|
kgverify.cpp|kgverify.h). Function handleVerify() was runned in graphics
interface context. It is not problem for password auth, because username
and password are send to backend at the same time and backend response
is mostly very quick. But it is problem for fingerprint auth.

Frontend send username to backend, backend asks for swipe/place finger
on sensor, frontend should display this question in some way (animation,
text information), after user swipe/place finger backend sends
verification result. This result should be negative (finger not
centered, swipe too short, etc.) or positive.

Because handleVerify() waits for verification result in graphics
interface context (thread), it is blocked while verification is in
progress. So there was not chance display animation, ask user for finger
swipe/place on sensor. That was changed since revision 1026101 for KDM.


For krunner (kdebase/workspace/krunner/lock/lockdlg.cc) is nearly same
issue with function called handleVerify() - surprise!

> > I would be nice have this fully functional since kde4.4 :-). I will be
> > happy if someone wants finis this work.
> 
> what we need is a maintainer to step up and maintain it in svn. while this is 
> a great feature, without someone who can take care of bug reports, etc it will 
> become abandoned code that sits and rots in svn. that is not good.
> 
> so unless someone is willing to maintain this feature actively, it really 
> shouldn't go into main KDE releases. maintenance does not take a lot of time, 
> it just takes a consistent amount of effort applied over time.

I understand. I haven't much time for active development, but I could
try maintain it.

> 
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
-- 
Jaroslav Bartoň

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]