Re: [PATCH] Input: serio: make HYPERV_KEYBOARD depend on SERIO_I8042=y

[Dmitry Torokhov]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/