Ticket #425 (closed enhancement: fixed)

Opened 4 years ago

Last modified 4 years ago

Use AUX button for locking the screen

Reported by: Detructor Owned by: ainulindale
Priority: minor Milestone:
Component: SHR Image Version: SHR-testing
Keywords: Cc:

Description

Please use the AUX button for locking the screen

Change History

comment:1 Changed 4 years ago by KaZeR

As suggested somewhere in the mailing list, you can use the following to avoid searching in the setup menu until it's fixed in shr :

enlightenment_remote -binding-key-del ANY "Keycode-177" NONE 1 "simple_lock" ""
enlightenment_remote -binding-key-add ANY "Keycode-177" NONE 1 "simple_lock" ""

Has to be launched from the phone, not via ssh.

I do vote too for having this setting shipped by default, it's really useful imo.

comment:2 Changed 4 years ago by Detructor

thanks for the code. But, just for my understatement: What are this two commands are doing? The first removes all bindings for the AUX key (keycode-177) in enlightment(?), but what does the 2nd do?

simple_lock is the "command" that locks the screen.

It works, even after reboot...but I'm a little bit confused.

comment:3 Changed 4 years ago by spaetz

Yes, that key binding got lost as a default, nobody really knows why. We'll try to add it back (plus make it issue some command when pressing AUX long (see http://trac.shr-project.org/trac/ticket/291))

comment:4 Changed 4 years ago by Detructor

yay would be cool (longpress and add it back).

comment:5 Changed 4 years ago by dos

  • Status changed from new to closed
  • Resolution set to fixed

comment:6 Changed 4 years ago by galadh

Locking via AUX still does not work on my up-to-date testing installation. Should this bug be reopened?

comment:7 Changed 4 years ago by dos

No. That's you who shouldn't use shr-testing. Use shr-unstable.

comment:8 Changed 4 years ago by galadh

I know - actually I'm using SHR unstable most of the time. I'm not using testing because there's this bug which doesn't let me lock the screen ;-). Yet I'd like to use the NEXT release of testing - if there will ever be one. Therefore I'd like to reopen this bug so it will be fixed in the next testing release.
So why shouldn't this bug be reopened?

Note: See TracTickets for help on using tickets.