From: Brion Vibber (brion@pobox.com)
Date: Mon 06 Jul 1998 - 13:10:02 IDT
I've made some updates to the mouse & keyboard code for svgalib, and have patches for 1.3.0 (12 June snapshot) and 1.2.13. The patches are available from my web site at http://pobox.com/~brion/linux/svgalib.html. Please test this patch - even if you don't need or want its features I might have broken something else and need to know about it to fix it... Here's a quick rundown on the changes: Mouse changes: * Turning the wheel now turns the mouse around the X axis. (Think about it a sec - it makes sense. Just like POV-Ray!) * I added a mouse_wheel_steps option to control the amount of rotation along the axis when the wheel is turned; default is 18 steps (20 degrees each), the real-world amount for the MS IntelliMouse. The Logitech FirstMouse+ takes 24 steps (15 degrees), and you can set either the correct amount or a fudged amount as is your preference. * Added a way for a program to ask svgalib for the capabilities of the mouse (which buttons, axes, and other features are available) without resorting to checking the mouse type (which is no good if new types are added after a program is released!). Right now this is done through a particular sequence of mouse_setposition_6d() and mouse_getposition_6d() to allow programs to use it if available without breaking on older versions of the library, and I have provided an inline function called mouse_getcaps() which encapsulates this and can be made into a real function in a later version. Read README.wheel in the archive for detailed info. * Updated the mousetest demo to use the middle button (randomizes cursor position) and wheel/rx-axis (changes size of the dot), checking the mouse caps to determine if the wheel is available. Keyboard changes: * For the heck of it, I threw in keyboard remapping for raw keyboard apps. It's primitive as it must convert scancodes to the scancode in the layout expected by the program, and so will be of limited use for mixing national keyboards. But I can now use the Dvorak layout in Quake, so it's at least good for something... Read README.keymap for more detail on this. * The fake mouse and keyboard events now run their scancodes through this little goody so both numeric raw scancodes in any base and symbolic key names can be accepted. When alternate keymaps are used, symbolic names are taken from the keymap file and are appropriately mapped. For users of fake keyboard events from the previous release: the symbolic names are different! Please change them to match. * The keymap file is generated from a perl script called svgakeymap which reads two keytable files from /usr/lib/kbd/keytables and tries to match characters up. It will probably choke on most non-US layouts, please try it out and see. Two sample keymaps are provided - dvorak-us.keymap (Dvorak keyboard with US-QWERTY app) and default.keymap (plain US QWERTY keyboard) which performs no conversion and has the same names as the defaults when no map is loaded. * The keymap can be set with kbd_keymap in the config file or the SVGALIB_KEYMAP environment variable. * In order to reduce the security threat of arbitrary keyboard remapping in raw mode, (possible hung console) there is a kbd_only_root_keymaps option which if enabled causes keymaps to be rejected if they are not owned by root. Documentation changes: * Added README.wheel and README.keymap to describe the wheel and keymap stuff. * Made updates to the man pages for libvga.config(5), mousetest(6), and vga_getmousetype(3); added pages for svgakeymap(1) and mouse_getcaps(3). To apply the man page patches make sure you uncompress the old man pages first. Caveats: * As mentioned, the keymaps are limited with non-US keymaps and the map generator will probably blow up on them. * I had to mess with the fake keyboard events (1.3.0 only) to get them to work with symbolic key names and properly update when the keymap is changed. I don't think I broke anything, but I'm not sure and the resulting code's a little ugly... feel free to test it and help clean it up. * Not all cases of out of range scancodes may be caught, resulting in some possible weirdness. * The root only keymaps isn't a complete security solution (for instance a file that is owned by root but writable by a user could be modified into a bad keymap and used). -- brion vibber (brion@pobox.com)
This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:22 IST