On Wed, Aug 13, 2014 at 05:24:35AM +0000, Dexuan Cui wrote: > > -----Original Message----- > > From: Dmitry Torokhov > > Sent: Wednesday, August 13, 2014 1:55 AM > > > > > To decouple the dependency between the hyperv-keyboard and i8042 > > > > > modules, I suppose we probably have to re-implement hyperv- > > keyboard by > > > > > 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. > > > > 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? Hmm, that would make i8042 depend on libps2, which might be OK, but how do you deal with the locking here? I.e. what happens if you unload i8042 right when we go through this sequence? Maybe we need to split i8042_lock_chip() and friends into a separate module that always loads, even if i8042 is not present. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
