-----Original Message-----
From: Dmitry Torokhov
Sent: Wednesday, August 13, 2014 1:55 AM

quoted

quoted

quoted

To decouple the dependency between the hyperv-keyboard and i8042
modules, I suppose we probably have to re-implement hyperv-

keyboard by

quoted

quoted

quoted

using input_allocate_device(), input_register_device(), and using
input_report_key() to pass the key strokes to the high level.

Yes, that would be the best thing to do,

Why? The backend still delivers AT keyboard data, so why does it make
sense to write a new driver instead of making sure you can load
atkbd/libps2 even without i8042 loaded?

Hi Dmitry,
Thanks for pointing this out!
I didn't realize input_report_key() can't accept AT keyboard scan codes.

quoted

The issue is: the latest Arch Linux release doesn't have a working (virtual)
keyboard when it runs as Generation 2 hyper-v guest -- when it runs as
a "traditional" Generation 1 hyper-v guest, everything works fine.
I hope this patch can temporarily help Arch users if they find the issue
and if they can rebuild the kernel.

The Arch users can simply select to build i8042 into the kernel as a
workaround.

I agree.

The proper solution is to allow loading libps2 module even if i8042 did
not find its device. I wish I could simply drop this i8042_lock_chip and
stuff, but unfortunately i8042 ports are not truly independent. We need
to figure a way for libps2 to engage locking in i8042 if the driver is
loaded, otherwise just ignore it.

Dmitry

Yeah, this seems the right solution.

How about this:
in libps2.c let's add  and export a function pointer
i8042_lock_chip_if_port_owner: it is used to replace the current 
	if (i8042_check_port_owner(ps2dev->serio))
		i8042_lock_chip();
The function pointer has a default value NULL, and in i8042.c: i8042_init()
we set the function pointer if an i8042 device is found?

Thanks,
-- Dexuan