I just typed a long email in reply to someone asking about the keyboard not working by email. The contents of that email are likely useful for other people who are still experiencing the keyboard not working too, so I've copy and pasted my entire reply below.

If you still need help with this please follow the provided debug instructions and provide the requested info.

###

First of all lets see if we can find the root cause. Bug 1894017
is about the keyboard events being discarded in userspace, because
userspace thinks the device is folded in tablet mode with the
keyboard behind the display (and any key-presses are thus done
accidentally).

Please install evemu and then run:

sudo evemu-record

This will give you a list of available input devices. The problems
reported in bug #1894017 are caused by a false-positive
reporting of SW_TABLET_MODE with a value of 1. By one of the
following input-devices:

"Intel HID events"
"Intel HID switches"
"Intel Virtual Buttons"
"Intel Virtual Switches"

Or something like this, you can select a device by typing the
number of its /dev/input/event# node.

After selecting a device evemu-record will print which events the
device can report. If it can report SW_TABLET_MODE then the
output will also contain the current value of SW_TABLET_MODE,
if this is 1 then that is the cause.

(press CTRL+c to exit evemu-record)

But you write "seems to stop responding at random" where as with
the SW_TABLET_MODE problem I would expect it to simply not work
at all (with certain kernel versions).

So you may very well have a different problem then the one described
in launchpad issue 1894017.

What you can also try is running "sudo evemu-record" and then selecting
the "AT Translated Set 2 keyboard" keyboard. After this if you type some
keys on the keyboard they should show up in evemu-record as key-presses.

If this works, then try doing it again (over e.g. ssh, or with an
external usb kbd) when the keyboard has stopped responding. I suspect
that you will find that at this point evemu-record will also no longer
report keys, which means that the problem is happening at a lower
level.

I suspect that you will find that the problem indeed is happening at
a lower-level and that you need something like this:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=addab6febc42ed94e4eee1abbe486150e4f8b9e9
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5b1032a656e9aa4c7a4df77cb9156a2a651a5f9

In order to determine what is necessary to fix things I need
a number of things:

1. output of: "grep . /sys/class/dmi/id/* 2> /dev/null" run from a terminal

2. Install acpica-tools and then run: "sudo acpidump -o acpidump.txt" and then
   attach the generated acpidump.txt file to your next email

3. It would help a lot if we can go from
   "seems to stop responding at random" to "stops responding when I do a,
   followed by b..." some ideas here are:
3.1 perhaps it stops responding after folding the display past 180 degrees
(so a little beyond it lyinf fully flat on the table) and then back again?
3.2 perhaps it stops responding after folding the display all the way back
so that the device is fully in tablet mode; and then back to laptop mode again ?
3.3 perhaps it stops responding after a suspend/resume?

Regards,

Hans