http://bugs.winehq.com/show_bug.cgi?id=39
*** shadow/39 Sat May 25 17:17:26 2002 --- shadow/39.tmp.365 Sat May 25 17:17:26 2002 *************** *** 0 **** --- 1,68 ---- + +============================================================================+ + | PrgWin95: Wrong message sequence for keyboard auto-repeat | + +----------------------------------------------------------------------------+ + | Bug #: 39 Product: Wine | + | Status: NEW Version: unspecified | + | Resolution: Platform: | + | Severity: normal OS/Version: All | + | Priority: P1 Component: wine-kernel | + +----------------------------------------------------------------------------+ + | Assigned To: wine-bugs@winehq.com | + | Reported By: fgouget@codeweavers.com | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | Milestone: TargetMilestone: --- | + | URL: | + +============================================================================+ + | DESCRIPTION | + The message sequence that Wine generates when a key is in auto-repeat mode is + incorrect. + + In Windows one gets a series of WM_KEYDOWN messages. The first one has the + 'previous state' bit (30th of LPARAM) set to 0, and all those that come after + have it set to 1. Then when the key is released the application gets a single + WM_KEYUP message. + + In Wine the application receives a succession of WM_KEYDOWN and WM_KEYUP + messages instead. Note that this description is valid for a key like the down + arrow key. + + If the key generates characters, 'a' for instance, then these messages streams + are interspersed with WM_CHAR messages. But the principle remains the same. + + This problem is best illustrated by a couple of programs from programming books: + - the keylook example of the chapter 5 of the 'Programming Windows 95' Petzold + - the KeyView1 example of the chapter 6 of the 'Programming Windows 98' Petzold + - the VirtualKey example of the chapter 3 of 'Programming Windows 95 with MFC' + + See also: + http://fgouget.free.fr/wine/PrgWin95/Chap5.shtml#keylook + http://fgouget.free.fr/wine/PrgWin98/Chap6.shtml#KeyView1 + http://fgouget.free.fr/wine/PrgMFC/Chap3.shtml#VisualKB + + ------- Additional Comments From dtimoshkov@codeweavers.com 2000-11-03 03:33 ------- + The root of this problem lies in the way X server sends keyboard events. + X *always* generates Down/Up events for the single key press. It could + be seeing with the xev tool. I don't know a way yet how to work around it. + + One ugly hack could be to delay sending WM_KEYUP message, but for what + amount of time: until next key press, 1 ms, next X event, ...? + + ------- Additional Comments From fgouget@codeweavers.com 2000-11-12 15:01 ------- + + Disclaimer: I don't know anything about the way X handles the keyboard. + + But I just got an idea. In most systems you can receive an event saying that + such and such key has been pressed/released, but you can also query whether a + given key is up or down. + When we receive the KeyUp event, would it be possible to query X to determine + if the key is really up or if it is pressed? If it is still pressed, then we + would ignore the KeyUp event, mark the key as pressed internally, and on the + next KeyDown event we would send a VM_KEYDOWN with the bit 30 set to 1. + Of course doing so probably won't be very simple: I guess there will be nasty + key mapping issues, it will introduce a (small) delay if the X server is + remote... But the point is moot if we cannot query the state of a key with X. + + + ------- Additional Comments From Speeddymon@yahoo.com 2002-05-25 17:17 ------- + Should this bug be closed? no comment on it for over a year...... \ No newline at end of file