[Bug 39] New - PrgWin95: Wrong message sequence for keyboard auto-repeat

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(a)winehq.com                                         |
+ |  Reported By: fgouget(a)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(a)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(a)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(a)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