When testing my irrelavant grub config changes yesterday, I got the password dialog, which led me to believe they changes had been successful. However, this seems to happen occasionally when the lid is  closed and opened quickly.

• System Power Saving Never

• When Laptop Lid is Closed Lock Screen

• Security Lock screen when System is going to sleep

When re-opening the lid I am presented with the Desktop, the keyboard  does not appear to be working, and the trackpad moves the cursor within a small rectangle in the centre of the screen.

With the above settings I should be presented with the XScreenSaver login dialog.
And that is what happens, only the dialog is invisible.
The cursor is in the invisible dialog's password field. I can unlock the screen by  blind typing the password.

I changed the subject of this thread to make the thread more relevant for posterity.
I had previously referred to it as  hibernation, which my system doesn't even support. The problem occurs after lid closure.

Success !

No. It doesn't work everytime.

Log in  as root using su - to make sure that /usr/sbin is in the PATH.

I changed  GRUB_CMD_LINUX_DEFAULT in /etc/default/grub:

GRUB_CMD_LINUX_DEFAULT="i8042.reset i8042.nomux i8042.nopnp i8042.noloop"

Then I ran the following command:

update-grub

Marjorie wrote:

Did you do this as root / using sudo (...) or as yourself as user?

grub-mkconfig won't be found is you run /usr/sbin/update-grub as a regular user.

As root.

Sorry.
PATH wasn't set because I didn't use su -

Did you do this as root / using sudo (...) or as yourself as user?

grub-mkconfig won't be found is you run /usr/sbin/update-grub as a regular user.

As root.

grub-mkconfig won't be found is you run /usr/sbin/update-grub as a regular user. This in on my machine (I use sudo):

marjorie@grendel:~$ which grub-mkconfig
marjorie@grendel:~$ sudo which grub-mkconfig
[sudo] password for marjorie: 
/usr/sbin/grub-mkconfig

He changed GRUB_CMD_LINUX_DEFAULT in /etc/default/grub, adding i8042.reset i8042.nomux i8042.nopnp i8042.noloop to the options.

Following this post, I tried to update-grub, but it fails:

/usr/sbin/update-grub: 3: exec: grub-mkconfig: not found

When I run synclient I get:

Couldn't find synaptics properties. No synaptics driver loaded? 

The synaptic Xorg driver in being superseded by the newer libinput driver in Debian 9 "Stretch".

Do you really need to hibernate? It writes down quite a lot to ssd or hard drive. May be you can disable hibernate and use suspend?
I had other problem with touchpad. Installed synclient added one command line " synclient..." in rc.local and it works. Probaly it"s not the best solution but it works.

When I wrote the original post I didn't know the terminology.
I presume the laptop suspends when I close the lid.

When I run synclient I get:

Couldn't find synaptics properties. No synaptics driver loaded? 

You may well be right to focus on the screen and display side of things, then the X configuration for the input devices, and then the device adapters themselves... but I'd do the opposite order.

As I understood it, the display shows up fine but the mouse and keyboard play up.

You are absolutely right! The screen is displayed correctly at 1920x1080.
But the mouse moves within a (I guess) 320x180 or rectangle and the keyboard is dead.

I haven't given up yet, I'm not one to throw the towel quickly.

But if I fail to solve this problem, I wonder whether I could set up the PC to shut down on closure of the lid. It's a bit severe.
At the moment I do a manual shutdown.

As I understood it, the display shows up fine but the mouse and keyboard play up. That suggests to me that the suspend/resume implementation of the Desktop Environment that you are using doesn't juggle all the device handling modules enough; something that "used to" be handled by pm-utils ("power management utilities").  In other words, that the device adapters modules that interact with the input hardware (not the display) don't get reset properly upon resume.

If you'd know which modules, you'd then go to the suspend/resume implementation used by your desktop environment and make those modules reset/reload upon resume (assuming that implementation of the suspend/resume function provides the required hooks).

There is no harm in installing xrandr and synclient as ways of getting more insight; xrandr is the command used for inspecting and controlling the display setup for X, and synclient is the command for inspecting and configuring the touchpad handling for X (which also partly concerns the mouse). Both of those interact with the X server.

At the module level, I think it concerns the hid (human interface device) modules and the hcd (host controller driver) modules; namely that one or some of those lose their configuration upon suspend+resume. I remember for example that the xhci_hcd module at some time had difficulty with suspend+resume which typically got resolved by reloading.

But not all computers are the same, so it might be a different module for your problem, and of course, maybe the problem sits elsewhere.