Hi Rodolfo, debian developers,
* Gregor Zattler <telegr...@gmx.net> [2013-07-27; 10:47]:
> * Gregor Zattler <telegr...@gmx.net> [12. Jul. 2013]:
>> * Rodolfo García Peñas <k...@kix.es> [12. Jul. 2013]:
>>> Probably the bug could be here:
>>>
>>> module new.c:
>>> 173 /* Work around stupid X11 bug: When switching immediately after the
>>> command
>>> 174 * is entered, the enter button may get stuck. */
>>> 175 if (getenv("DISPLAY") != NULL)
>>> 176 sleep(1);
>>>
>>> Probably the problem is not only related to the enter key.
>>>
>>> Can you reproduce the bug yet? Then, the best idea could be run
>>> vlock without the module "new". Then we can see if the bug is
>>> in that module and work on it. Because we are in X11, run vlock
>>> -sa is not possible and we need the "new" module.
>>>
>>> Perhaps, one idea is increase the sleep time, for testing, something like:
>>>
>>> 176 sleep(5);
[... 13 lines deleted ...]
> I used vlock -san since this last E-Mail with sleep (9): I
> realized only two hangs when the laptop was suspended and I woke
> it up. This is something I do often and it hanged only twice.
>
> Otherwise vlock functioned perfect -- with the exeption of having
> to wait for 9 secs. Which is still a security problem since I
> have to call vlock -san *after* the laptop wakes up from suspend
> (doesn't suspend while vlocked). Therefore the laptop is not
> protected for this waiting time after wakeup (by an attacker).
>
> Now I changed the sleeping time to 5 secs as you suggested and will
> proceede bisecting. I'll report back when I know how long the
> waiting time should be in order to function correctly.
It worked perfectly with 2 seconds sleep time. Since September
first I test it with 1.5 seconds sleep time and today it hanged
for the first time.
HTH, Gregor
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
