Ok, this time the patch is all good. It enables the use of all extended
keycodes generated by the K_MEDIUMRAW mode. Although no keycodes over
127 have default mappings, they can be remapped using remap_key in the
molrc files.
The patch also fixes the related bug of "unknown" keycodes having a
de
Now I found the code in the kernel which generates these sequences.
Actually they are not mouse sequences as such, but "extended raw codes",
used for keycodes that don't fit in 7 bits (3 bytes are used to send a
keycode of 14 bits, with one up/down bit and two dummy bits, and 7 bits
for the "escape
Ok, here's a patch which fixes the problem, and also makes some moderate
amount of sense.
** Attachment added: "Patch to console_key_event for skipping linux style mouse
events in the stream"
http://librarian.launchpad.net/5045469/the_patch
--
USB mouse in console (fullscreen) mode generates
I added some trace printouts to the code, and found the following: When
the left mouse button is pressed, console_key_event processes the
following byte sequence:
0x00 0x82 0x90
After the first byte, post_osi_key_event() gets called with the
arguments 126,65536.
When the left mouse button is re
