Re: [Qemu-devel] [PATCH v2] ui/input: fix event emitting of repeated combined keys

[Amos Kong]

On Fri, Sep 26, 2014 at 01:24:05PM +0200, Gerd Hoffmann wrote:
> On Fr, 2014-09-26 at 18:53 +0800, Amos Kong wrote:
> > On Fri, Sep 26, 2014 at 12:36:50PM +0200, Gerd Hoffmann wrote:
> > > On Fr, 2014-09-26 at 18:23 +0800, Amos Kong wrote:
> > > > Currently we emit press events of combined keys first, then emit
> > > > release events by reverse order. But it doesn't match with physical
> > > > keyboard if the keys contain continued & repeated keys.
> > > > 
> > > > For example, (qemu) sendkey a-b-b
> > > 
> > > Hmm, somehow I don't feel like building too much magic into this.
> > > If you want send Ctrl-somekey twice just use two sendkey commands ...
> > 
> > 
> > Before this patch, If 'sendkey r-o-o-t', only 'rot' can be inputted.
> 
> To type 'root' you should use
> 
> sendkey r
> sendkey o
> sendkey o
> sendkey t
> 
> Multiple keys in sendkey is meant for multiple keys pressed at the same
> time, i.e. ctrl-alt-del, not for sending key sequences and typing words.
> 
> > People want to panic windows by sending Ctrl-Scrool-Scrool
> > http://msdn.microsoft.com/en-us/library/windows/hardware/ff545499(v=vs.85).aspx
> > But current events order doesn't work.
> 
> sendkey Ctrl-Scroll
> sendkey Ctrl-Scroll
> 
> > In physical keyboard. We can prese Ctrl first, then press & release
> > Scroll twice, then release Ctrl. It's very common behavior.
> 
> In most cases it doesn't matter whenever you release the modifier key or
> not.  The windows panic hotkey might be the exception from the rule
> though.

It doesn't matter, so users might release the modifier key or not.
we should make both works

1)
sendkey Ctrl-Scroll
sendkey Ctrl-Scroll

2)
sendkey Ctrl-Scroll-Scroll
 
> > So this fix just reference the physical implement, if you want to
> > input same key twice, you have to release it before second pressing.
> > (here we ignore the auto-repeat feature)
> 
> sendkey doesn't cover that use case indeed.

original sendkey didn't cover it, but my change isn't added a split
feature, but try to adapt native behavior by a little change.
It doesn't effect original right behavior, but process repeated case
in native way.
 
> /me wonders what happened to the input-send-event patch from marcelo,
> see http://patchwork.ozlabs.org/patch/360649/
> 
> According to patchwork I've picked it up.  But it is neither upstream
> nor in my local input branch.  And I can't remember what happened :(
> Marcelo, any clue?  Maybe I should just re-queue it ...
> 
> The input-send-event gives you fine-grained control about the exact
> input event sequence and it can handle your use case without problems.
> 
> cheers,
>   Gerd

-- 
                        Amos.