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.
