I see a problem with the right-handed "windows" key sending a button-4 (!!!) event. Both emacs and xev claimed it was sending a mouse button-4 event. I do have a scroll-wheel 5-button mouse on the machine and the right windows key does do the same scroll-up action as the mouse does. Weird.
This is under the default installation on an amd64 FC4 system w. a standard 104 key US keyboard and selecting US as the language. Are others seeing the same thing or is something screwed up on my system?
-wolfgang
On Fri, 2005-07-01 at 23:19 -0700, Wolfgang S. Rupprecht wrote:
I see a problem with the right-handed "windows" key sending a button-4 (!!!) event. Both emacs and xev claimed it was sending a mouse button-4 event. I do have a scroll-wheel 5-button mouse on the machine and the right windows key does do the same scroll-up action as the mouse does. Weird.
This is under the default installation on an amd64 FC4 system w. a standard 104 key US keyboard and selecting US as the language. Are others seeing the same thing or is something screwed up on my system?
Yes. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154448
Gérard Milmeister gemi@bluewin.ch writes:
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154448
Thanks!
Looks like there are some kbd keystrokes that intentionally get mapped to mouse buttons.
http://lkml.org/lkml/2005/5/26/119
Now to figure out how to rebuild the kernel. The release notes seem to be wrong. Did they leave out a step?
$ up2date --get-source kernel
Fetching all package list for channel: updates-released... An error has occurred: exceptions.TypeError See /var/log/up2date for more information
The referenced log file has what looks like a line-by-line python trace. If there is useful info in that file it is hidden by thousands of lines of low-level printf's.
-wolfgang