Discussion:
disable and re-enable keyboard in X
(too old to reply)
John Forkosh
2019-10-17 10:04:33 UTC
Permalink
I got a teclast f5r tablet/laptop last week
and got it dual-booting -current64 (as of 9/1/19)
with the pre-installed win10.

X works fine and the output from xinput list is below...

Virtual core pointer id=2 [master pointer (3)]
Virtual core XTEST pointer id=4 [slave pointer (2)]
SYNA3602:00 0911:5288 Touchpad id=9 [slave pointer (2)]
Goodix Capacitive TouchScreen id=10 [slave pointer (2)]
Virtual core keyboard id=3 [master keyboard (2)]
Virtual core XTEST keyboard id=5 [slave keyboard (3)]
Video Bus id=6 [slave keyboard (3)]
Power Button id=7 [slave keyboard (3)]
USB Camera: USB Camera id=8 [slave keyboard (3)]
Intel HID events id=11 [slave keyboard (3)]
Intel HID 5 button array id=12 [slave keyboard (3)]
AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
Goodix Capacitive TouchScreen id=14 [slave keyboard (3)]

...so most of that stuff seems to already have low-level drivers.
And the touchscreen works out-of-the-box.
But the keyboard and touchpad continue to work even when
I've rotated it 360 degrees, to use it as a tablet.
In windows they're disabled when rotated like that,
and then re-enabled when rotated back to "laptop position".

Now, I can use xinput to separately disable first the touchpad
and then the keyboard. But then there's no apparent way to
re-enable anything. Any way to do that? Or, better yet, to
recognize when the keyboard's rotated 360 to "tablet mode"?

Also, by the way, I'm not really using the usb camera,
but windows has a pre-installed app for it, and I'd
spend a few minutes to install a slackware app.
Google seems to suggest webcamoid, but that looks like
more than a few minutes to get working. Anything
out-of-the-box for slackware?
Thanks,
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Eli the Bearded
2019-10-17 19:18:39 UTC
Permalink
Post by John Forkosh
Now, I can use xinput to separately disable first the touchpad
and then the keyboard. But then there's no apparent way to
re-enable anything. Any way to do that? Or, better yet, to
recognize when the keyboard's rotated 360 to "tablet mode"?
How are you running xinput? I'd probably look for ACPI events on rotate
and use those to trigger xinput commands.

Elijah
------
probably would practice with just acting on touchpad then go for keyboard
Sylvain Robitaille
2019-10-17 21:38:26 UTC
Permalink
I'd probably look for ACPI events on rotate and use those to trigger
xinput commands.
You beat me to it! I was going to suggest exactly the same.
probably would practice with just acting on touchpad then go for keyboard
Well, I would have suggested using logger to practice with (syslog the
intended command instead of running it) until you know you're catching
only the expected events. /etc/acpi/acpi_handler.sh already uses logger
so that should help.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
Eli the Bearded
2019-10-18 01:40:19 UTC
Permalink
Post by Sylvain Robitaille
Post by Eli the Bearded
probably would practice with just acting on touchpad then go for keyboard
Well, I would have suggested using logger to practice with
Oh, sorry. I'm assuming he has found the proper event and needs to test
toggling of state. Does it do the right thing when put to sleep in one
orientation and woken up in another type stuff.

Keyboard is easier to use to manually recover.

Elijah
------
and testing how it works when not logged in
John Forkosh
2019-10-18 05:53:20 UTC
Permalink
Post by Sylvain Robitaille
I'd probably look for ACPI events on rotate and use those to trigger
xinput commands.
You beat me to it! I was going to suggest exactly the same.
probably would practice with just acting on touchpad then go for keyboard
Well, I would have suggested using logger to practice with (syslog the
intended command instead of running it) until you know you're catching
only the expected events. /etc/acpi/acpi_handler.sh already uses logger
so that should help.
Thanks, Sylvain. Please see preceding lengthy followup to Eli,
where I detailed the tests I performed, and their results,
based on your suggestions. Thanks again,
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Sylvain Robitaille
2019-10-18 20:33:52 UTC
Permalink
Post by John Forkosh
Thanks, Sylvain. Please see preceding lengthy followup to Eli,
where I detailed the tests I performed, and their results,
based on your suggestions. Thanks again,
Well, I'm sorry it didn't help. I'm afraid that was the best I can
come up with. I think I would next try to examine whether there's a
kernel module that can do what you're after, but either isn't loaded
or is unavailable on your system.
--
----------------------------------------------------------------------
Sylvain Robitaille ***@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------
John Forkosh
2019-10-19 05:36:03 UTC
Permalink
Post by Sylvain Robitaille
Post by John Forkosh
Thanks, Sylvain. Please see preceding lengthy followup to Eli,
where I detailed the tests I performed, and their results,
based on your suggestions. Thanks again,
Well, I'm sorry it didn't help. I'm afraid that was the best I can
come up with. I think I would next try to examine whether there's a
kernel module that can do what you're after, but either isn't loaded
or is unavailable on your system.
Thanks, Sylvain, it's actually helped >>lots<<. Now at least I'm
barking up the right tree (ACPI and maybe "friends"). And I hadn't
thought to check lsmod for anything that looked related, and for
which there might be updated/different/whatever versions.
I'll do some more googling to try to locate other relevant discussions.
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
John Forkosh
2019-10-18 05:47:56 UTC
Permalink
Post by Eli the Bearded
Post by John Forkosh
Now, I can use xinput to separately disable first the touchpad
and then the keyboard. But then there's no apparent way to
re-enable anything. Any way to do that? Or, better yet, to
recognize when the keyboard's rotated 360 to "tablet mode"?
How are you running xinput? I'd probably look for ACPI events on rotate
and use those to trigger xinput commands.
Elijah
------
probably would practice with just acting on touchpad then go for keyboard
Thanks, Eli. I'm just typing xinput etc from a konsole terminal.
I run fvwm2 (along with an fvwm95 layer on top) for X -- nothing fancy.

I was aware of "ACPI" as something-or-other, but never knew what it does.
Reading man acpid shows me that's certainly the right approach.
Unfortunately, there doesn't seem to be any linux-recognized event
associated with 360 opening all-the-way, but there are open/close events...

Firstly, /proc/acpi/buttons/lid/LID0/state seems to be the only relevant
thing, and that state file just says state: open whether the lid's open
90 ("laptop mode") or 360, or anything else, although I can't see what
it says when it's closed (there should be a "Catch-22" event:).

In addition to /etc/acpi/events/default, I added alleventstest containing
event=.*
action=echo acpi_test `date`: %e >> /var/log/allmessages
after reading that man acpid page. That seemed like a good first
test of this stuff.

And nothing shows up in allmessages after rotating the lid back and forth
between 90 and 360. But closing and then opening the lid gives me a bunch
of messages there, not all very nice:) ...
acpi_test Fri Oct 18 01:18:17 EDT 2019: button/lid LID close
Oct 18 01:18:17 psibook1 root: ACPI action lid is not defined
Oct 18 01:18:21 psibook1 kernel: [ 6356.241723] ACPI:
button: The lid device is not compliant to SW_LID.
acpi_test Fri Oct 18 01:18:23 EDT 2019: button/lid LID open
Oct 18 01:18:23 psibook1 root: ACPI action lid is not defined
So it seems to recognize the close and open events, and maybe my
little alleventstest isn't quite kosher, causing those additional
apparent errors, although that "not compliant" message maybe has
something to do with the uneventful 360-versus-90.

Anyway, if I'm right that the open-to-360 versus open-to-90 isn't
generating any event, then I'd guess I need some low-level-driver
replacement, since windows does recognize such events. Is that
more-or-less right, or is there some other workaround, or am I doing
something wrong above (or any other alternative I overlooked)?
Thanks again,
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Eli the Bearded
2019-10-18 19:11:10 UTC
Permalink
Post by John Forkosh
I'd probably look for ACPI events on rotate and use those to trigger
xinput commands.
I was aware of "ACPI" as something-or-other, but never knew what it does.
Reading man acpid shows me that's certainly the right approach.
Unfortunately, there doesn't seem to be any linux-recognized event
associated with 360 opening all-the-way, but there are open/close events...
That is unfortunate. You might want to check if there is a bleeding edge
ACPI modification that works with your device.
Post by John Forkosh
Firstly, /proc/acpi/buttons/lid/LID0/state seems to be the only relevant
The named "buttons" are for things that are known to the code. You can
have just numbered ones that get triggered as well. On some of my
devices "function" keys like screen brightness, wifi toggle, etc show
up as just numbered events.
Post by John Forkosh
thing, and that state file just says state: open whether the lid's open
90 ("laptop mode") or 360, or anything else, although I can't see what
it says when it's closed (there should be a "Catch-22" event:).
You don't need to personally see the event to act on it in code.
Post by John Forkosh
In addition to /etc/acpi/events/default, I added alleventstest containing
event=.*
action=echo acpi_test `date`: %e >> /var/log/allmessages
after reading that man acpid page. That seemed like a good first
test of this stuff.
And nothing shows up in allmessages after rotating the lid back and forth
between 90 and 360.
That sounds like your ACPI isn't getting all the device events.
Post by John Forkosh
acpi_test Fri Oct 18 01:18:17 EDT 2019: button/lid LID close
Oct 18 01:18:17 psibook1 root: ACPI action lid is not defined
button: The lid device is not compliant to SW_LID.
acpi_test Fri Oct 18 01:18:23 EDT 2019: button/lid LID open
Oct 18 01:18:23 psibook1 root: ACPI action lid is not defined
So it seems to recognize the close and open events, and maybe my
little alleventstest isn't quite kosher, causing those additional
apparent errors, although that "not compliant" message maybe has
something to do with the uneventful 360-versus-90.
I think "not compliant" means that the device does not alternate open
close events. It's possible your device does something like

fully closed to partially open -> send open event
90 degresss open to 360 open -> send another open event

That would qualify as "not compliant" with my understanding of the
expected compliance while also being something you might be able to work
with. But if you are only seeing that in "fully closed to partially open"
tests, then maybe not.

Elijah
------
wondering if there is some other device file to check
John Forkosh
2019-10-19 05:30:29 UTC
Permalink
Post by Eli the Bearded
Post by John Forkosh
I'd probably look for ACPI events on rotate and use those to trigger
xinput commands.
I was aware of "ACPI" as something-or-other, but never knew what it does.
Reading man acpid shows me that's certainly the right approach.
Unfortunately, there doesn't seem to be any linux-recognized event
associated with 360 opening all-the-way, but there are open/close events...
That sounds like your ACPI isn't getting all the device events.
That is unfortunate. You might want to check if there is a bleeding edge
ACPI modification that works with your device.
Thanks, Eli...
Okay, so "ACPI modification" rather than my earlier guess about
"low-level device driver"? A few minutes of googling didn't cough
up anything relevant that I can find. I'll try googling how windows
recognizes the 360-events, and then combine any relevant win keywords
with "linux" to hopefully find some related linux stuff about it.
Post by Eli the Bearded
Post by John Forkosh
Firstly, /proc/acpi/button/lid/LID0/state seems to be the only relevant
The named "buttons" are for things that are known to the code. You can
have just numbered ones that get triggered as well. On some of my
devices "function" keys like screen brightness, wifi toggle, etc show
up as just numbered events.
My only /proc/acpi/ subdirectories are ac_adapter/, battery/, button/
and wakeup/, and only lid/LID0/state under button/. But I guess your
other stuff would show up if I actually changed screen brightness, etc.
Meanwhile, I recursively examined all the stuff that's there, before
amd after 360 rotations, and nothing else seemed remotely relevant, and
nothing additional (that I could find) showed up after 360 lid rotations.
Post by Eli the Bearded
Post by John Forkosh
thing, and that state file just says state: open whether the lid's open
90 ("laptop mode") or 360, or anything else, although I can't see what
it says when it's closed (there should be a "Catch-22" event:).
You don't need to personally see the event to act on it in code.
Yeah, I just wanted to check for the expected or any unexpected behavior,
you know -- just in case. I'll change that alleventstest from
action=echo... to action=echo...;cat state>>allmessages which should
do the trick.
Post by Eli the Bearded
Post by John Forkosh
In addition to /etc/acpi/events/default, I added alleventstest containing
event=.*
action=echo acpi_test `date`: %e >> /var/log/allmessages
after reading that man acpid page. That seemed like a good first
test of this stuff.
And nothing shows up in allmessages after rotating the lid back and forth
between 90 and 360.
That sounds like your ACPI isn't getting all the device events.
(I cut-and-pasted this sentence along with your related remark above)
Post by Eli the Bearded
Post by John Forkosh
acpi_test Fri Oct 18 01:18:17 EDT 2019: button/lid LID close
Oct 18 01:18:17 psibook1 root: ACPI action lid is not defined
button: The lid device is not compliant to SW_LID.
acpi_test Fri Oct 18 01:18:23 EDT 2019: button/lid LID open
Oct 18 01:18:23 psibook1 root: ACPI action lid is not defined
So it seems to recognize the close and open events, and maybe my
little alleventstest isn't quite kosher, causing those additional
apparent errors, although that "not compliant" message maybe has
something to do with the uneventful 360-versus-90.
I think "not compliant" means that the device does not alternate open
close events. It's possible your device does something like
fully closed to partially open -> send open event
90 degresss open to 360 open -> send another open event
That would qualify as "not compliant" with my understanding of the
expected compliance while also being something you might be able to work
with. But if you are only seeing that in "fully closed to partially open"
tests, then maybe not.
Unfortunately, I think "maybe not" is what's happening.
I've twisted/turned/rotated/opened/closed the lid every which way,
trying to find any/every physical action that generates any event,
and I get nothing in that /var/log/allmessages file unless I fully
close the lid (and then re-open it to see what's in the file).
By the way, twisted/turned because windows automatically flips
the display from landscape to portrait if you turn the screen that way.
But I'm not getting any corresponding linux events for this action.
Post by Eli the Bearded
Elijah
------
wondering if there is some other device file to check
Lots of stuff under /dev/; I'll take a more careful look.
Thanks again,
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Loading...