Tails

#1 Updated by BitingBird 2015-03-04 14:55:27

• Priority changed from Normal to Elevated
• Target version set to Tails_1.3.2

It’s a regression, so I mark it as elevated.

#2 Updated by intrigeri 2015-03-05 12:29:08

• Assignee set to emmapeel
• QA Check changed from Dev Needed to Info Needed

BitingBird wrote:
> It’s a regression

I see nothing in this bug report that says so. emmapeel, can you reproduce that in Tails 1.2.3?

#3 Updated by emmapeel 2015-03-10 09:28:37

• Assignee deleted (emmapeel)
• QA Check changed from Info Needed to Dev Needed

intrigeri wrote:
> BitingBird wrote:
> > It’s a regression
>
> I see nothing in this bug report that says so. emmapeel, can you reproduce that in Tails 1.2.3?

I confirm it is a regression. Florence Virtual Keyboard works well from Tails 1.2.3

#4 Updated by BitingBird 2015-03-15 13:41:13

• QA Check deleted (Dev Needed)

#5 Updated by intrigeri 2015-03-19 10:08:08

• Assignee set to emmapeel
• QA Check set to Info Needed

Can you reproduce this bug after disabling the “disable while typing” touchpad setting? (and possibly restarting Florence)

Also, can you reproduce with Tails/Jessie? (http://nightly.tails.boum.org/build_Tails_ISO_feature-jessie/)

#7 Updated by emmapeel 2015-03-20 10:36:37

• Assignee changed from emmapeel to intrigeri
• QA Check changed from Info Needed to Dev Needed

intrigeri wrote:

> Also, can you reproduce with Tails/Jessie? (http://nightly.tails.boum.org/build_Tails_ISO_feature-jessie/)

This bug has dissapeared in Tails/Jessie. I don’t need to disable the setting, just works out of the box as in Tails 1.2.3

If target version is 1.3.1 then Dev is needed, but if we just wait I can say QA pass. Not sure what to do about that, so I pass you the ball, intrigueri!

#8 Updated by intrigeri 2015-03-20 22:06:06

• related to Feature #7779: Revisit default touchpad settings added

#9 Updated by intrigeri 2015-03-20 22:11:22

• Assignee changed from intrigeri to anonym

> This bug has dissapeared in Tails/Jessie.

Thanks!

So I think we have a few options (in increasing order of work needed):

• give up for Tails/Wheezy, document that problem in known issues, and focus on making Tails/Jessie happen ASAP
• disable the “Disable while typing” setting, keep the rest unchanged
  • pros: repairs the Florence + touchpad use-case
  • cons: I suspect that it’ll make many touchpads basically unusable with tap-to-click; maybe it’s not that bad, though; it would be useful to have a bunch of people try that on various hardware and report back
• disable the “Disable while typing” and “tap-to-click” settings
  • pros: repairs the Florence + touchpad use-case
  • cons: important usability regression compared to 1.3 for many users, e.g. those who don’t have physical buttons on their touchpad, and those who come from another OS that enables tap-to-click by default
• try to debug and find the root cause, and then fix it; a few ideas:
  • look at logs to try to understand what happens
  • try to reproduce with florence 0.6.2-2 (testing) or 0.6.3-1 (sid), backported for Wheezy

So it seems that we’ve no easy and very satisfying solution :(

Reassigning to the current RM, who has time allocated to deal with regressions. anonym, what do you think?

#10 Updated by anonym 2015-03-24 09:53:24

• Assignee changed from anonym to intrigeri
• QA Check changed from Dev Needed to Info Needed

I managed to reproduce this, but with even worse results. For me whatever whatever key I press in florence gets stuck, i.e. the touchpad is disabled while in the key is in the ‘down’ state, so the character gets spammed. The Fn key workaround didn’t work for me, but mashing Ctrl+Alt while moving the touchpad does, eventually. Another workaround is to have a mouse connected — moving it immediately fixes the situation, quite as expected (since it will reset the timer for the keyboard disabling).

intrigeri wrote:
> * try to debug and find the root cause, and then fix it; a few ideas:
> look at logs to try to understand what happens

Here’s the log from florence --debug, but it’s not very interesting:

Key 0x9ce32b8 (type 0): Event 0 received : Switching from state 1 to 1 (fsm 0)
sending press event
CONF:sounds=<false>
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 1 to 0 (fsm 0)
keyboard layout found: <English (US)>
keyboard layout symbol name=<pc+us+inet(evdev)+group(shifts_toggle)+group(alt_shift_toggle)>
new xkb symbol found: <us>
XKB state notify event received
CONF:activated=<'#FF0000'>
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 2 received : Switching from state 0 to 0 (fsm 0)
Key 0x9ce32b8 (type 0): Event 1 received : Switching from state 0 to 0 (fsm 0)
sending release event
Key 0x9ce32b8 (type 0): Event 3 received : Switching from state 0 to 1 (fsm 0)
CONF:ramble-button=<true>

The sending release event (and probably the Event 1 just before) appears exactly when I move the mouse I had connected, per my above mentioned workaround.

I couldn’t find anything interesting in dmesg, syslog, xsession-errors or similar. Did you have any other logs in mind?

> try to reproduce with florence 0.6.2-2 (testing) or 0.6.3-1 (sid), backported for Wheezy

I rebuilt florence 0.6.3-1 for wheezy-backports and tested it, but the bug is still there.

#11 Updated by intrigeri 2015-03-24 12:03:54

• Assignee changed from intrigeri to anonym
• QA Check deleted (Info Needed)

anonym wrote:
> Did you have any other logs in mind?

No, sorry.

#13 Updated by anonym 2015-03-24 13:11:17

• Assignee changed from anonym to emmapeel
• QA Check set to Info Needed

emmapeel wrote:
> intrigeri wrote:
> > Also, can you reproduce with Tails/Jessie? (http://nightly.tails.boum.org/build_Tails_ISO_feature-jessie/)
>
> This bug has dissapeared in Tails/Jessie. I don’t need to disable the setting, just works out of the box as in Tails 1.2.3

I just tested this in Tails/Jessie and, indeed, the bug is not there. However the reason for that seems to be that “Disable while typing” is not working. Emma, can you please retry this, and make sure to check whether that option seems to be working for you? FTR, the build I’m using is tails-i386-feature_jessie-1.4-20150323T1244Z-32a50d7.iso.

#14 Updated by anonym 2015-03-24 13:38:32

• Status changed from Confirmed to In Progress
• Assignee changed from emmapeel to anonym
• QA Check changed from Info Needed to Dev Needed

anonym wrote:
> However the reason for that seems to be that “Disable while typing” is not working.

Nevermind Emma! It turns out GNOME in Jessie just starts syndaemon differently, so different parts of the touchpad are disabled vs Wheezy, and this was what confused me to think that it was broken. Details:

• Wheezy: syndaemon -i 1.0 -K -R

• Jessie: syndaemon -i 1.0 -t -K -R

From the man page:

       -t     Only disable tapping and  scrolling,  not  mouse  movements,  in
              response to keyboard activity.

If I manually start syndaemon -i 1.0 -t -K -R in Wheezy, and that fixes the issue with florence \o/.

I will create a fix shortly via a wrapper since the arguments GNOME sets for syndaemon are hardcoded.

#16 Updated by anonym 2015-03-24 14:46:07

• % Done changed from 0 to 40
• Feature Branch set to bugfix/9011-fix-syndaemon-vs-florence

#17 Updated by anonym 2015-03-24 17:02:02

• Assignee deleted (anonym)
• % Done changed from 40 to 50
• QA Check changed from Dev Needed to Ready for QA

My fix works according to my tests.

#19 Updated by bertagaz 2015-03-27 11:44:58

• Assignee set to bertagaz

#20 Updated by bertagaz 2015-03-27 14:04:58

• Assignee changed from bertagaz to anonym

I confirm the fix works, congrats.

Still I have two remarks:

• the resulting syndaemon wrapper is not set -eu. Any reasons?
• I’m wondering why the -t option is added with this lines:

if ! echo "\${@}" | grep -qw -- "-t"; then
    set -- "\${@}" -t
fi

rather than just doing a one-liner

exec /usr/bin/sydaemon.distrib "-t ${@}"

or something like that. Why testing if the “-t” option is set, when we expect it to be during the Wheezy cycle?
Maybe I’m missing a shell trick needed to pass this “-t” option?

I’m not firmly opposed to merge this though, given we have limited time and it works.

#21 Updated by anonym 2015-03-27 15:01:21

• Assignee changed from anonym to bertagaz

bertagaz wrote:
> I confirm the fix works, congrats.

Cheers! Did you also reproduce the error (e.g. with Tails 1.3.1) on the same hardware?

> Still I have two remarks:
>
> * the resulting syndaemon wrapper is not set -eu. Any reasons?

• set -e isn’t needed since no command can fail in any meaningful (vs. set -e) way. If echo (with set -o pipefail so the error propagates) or grep fails in some unexpected way (ENOMEM or a bit flip or buffer-overflow bug or whatever) I don’t know how we can distinguish that from the expected grep failure (i.e. “-t” is not present) since it’s used in the conditional. Well, there are very convoluted ways to do it but we’re not preparing for such arcane errors in other shell scripts.

• set -u is irrelevant since the only variable used is ${}@, which isn’t checked.

> * I’m wondering why the -t option is added with this lines:
>
> […]
>
> rather than just doing a one-liner
> […]
>
> or something like that. Why testing if the “-t” option is set, when we expect it to be during the Wheezy cycle?
> Maybe I’m missing a shell trick needed to pass this “-t” option?

You’re not. I’m just trying to avoid some issues I’ve seen before when writing shell wrappers. For instance, I’ve seen applications do unexpected things when a flag is provided twice, e.g. a second instance cancels the first, and also think of -v -v... for increased verbosity. It’s conceivable that some Tails user would invoke syndaemon -t herself (perhaps by discovering this fix herself :)). I haven’t checked if double -t does something bad for syndaemon, and I doubt it does, but I’m just careful.

Using set -- ... is most elegant way I know to modify a wrappers parameters while also keep ${}'s special quoting rules for a *single* exec@ call at the end. The alternative would be to repeat the exec call, e.g. something like this:

if echo "${@}" | grep -qw -- "-t"; then
    exec /usr/bin/sydaemon.distrib "${@}" 
else
    exec /usr/bin/sydaemon.distrib "-t ${@}"
fi

which is less elegant due to the repetition.

So, yeah, I’m just following my own “shell wrapper best practices” which perhaps is overkill for this very simple one.

#22 Updated by bertagaz 2015-03-27 15:23:37

• Status changed from In Progress to Fix committed
• Assignee changed from bertagaz to anonym
• % Done changed from 50 to 100
• QA Check changed from Ready for QA to Pass

I’m convinced! Meanwhile I tried the simpler wrapper and it isn’t working. So I guess your wise best practices are justified. Closing this bug, but shall I open a new one to remember we’ll have to remove this wrapper in Jessie?

#23 Updated by anonym 2015-03-27 16:37:45

• Status changed from Fix committed to In Progress

Applied in changeset commit:3f8a8dc8b2521ab228145fe5efdcacbdf5f34068.

#24 Updated by anonym 2015-03-27 16:40:31

• Status changed from In Progress to Fix committed
• Assignee deleted (anonym)

bertagaz wrote:
> I’m convinced! Meanwhile I tried the simpler wrapper and it isn’t working. So I guess your wise best practices are justified.

:)

> Closing this bug,

Please reply to the thread on tails-dev@ too!

> but shall I open a new one to remember we’ll have to remove this wrapper in Jessie?

I have already fixed it in feature/jessie.

#25 Updated by anonym 2015-03-31 19:02:12

• Status changed from Fix committed to Resolved