13.1 NEWS: 2Fixed a 3 years old bug about volume level showing up as "0" when it's 3actually set to 10. Thank to all 20 or so people who e-mailed me about this. 4Changed struct mixer_info name to allow compiling wmix under 2.6.1+ kernels. 5Thanks Neil Burch <burch@cs.ualberta.ca> for the patch. 6Added a patch to enable exclusion of channels from display - allows you to 7remove mixer channels you never use. adds '-e <channame>' command line option 8which can be repeated any number of times. Thanks to Nicolas Descomps <nico_206@noos.fr>. 9Added #include <string.h> since glibc finally fixed most of the includes since 2001. 10 113.0 NEWS: 12Major code rewrite. Now uses much better mixer library. New knob drawing code. 13New config parsing code - no more segfaults. New mouse control code for knob 14and slider dragging - more intuitive. Documentation updates. Removed runtime 15config parsing, only reading config file once on startup. New command line 16options to specify X display, config file, and mixer device. Removed "mixermax" 17code until someone complains. Current channel title scrolling is now 18configurable. 19 202.2 NEWS: 21This is a bugfix release. On-Screen-Display code now looks for some common 22large bitmap font. Check that $HOME is set before trying to write a config 23file. Wmix makes a pid file for use with signal changing volume up/down. 24Minor code reorganization. 25 262.11 NEWS: 27Mostly bugfixes and other random stuff. OSD now really stays on top provided 28you run a GNOME-compliant window manager (wmaker/E/saw-what-ever,etc) 29 302.1 NEWS: 31Configuration file implemented. Mousewheel functionality, OSD display, 32OSD color, main mixer device, and OSS bug work-around can now be selected 33through WMixer rc file, by default placed in ~/.wmixrc 34Changes to the rc file are loaded dynamically, while the mixer is running - 35you can change the OSD color, for example, and see the results right away. 36 372.04 NEWS: 38New feature: Volume of the current channel can be controlled using signals. 39Sending SIGUSR1 will increase the volume by 1 step, and SIGUSR2 will decrase 40the volume by 1 step. This could be useful if you have a newer style keyboard 41with volume buttons and all the other extra shit. You can tell your favorite 42window manager to run a program on keypress, and that program could be 43something like "killall -USR1 wmix" for volume up key, and "killall -USR2 wmix" 44for volume down. How to assign programs to specific keys is up to you. I know 45Blackbox and WindowMaker can both do it. Keep in mind most X-servers don't 46automatically support those extra keys, so some hacking might be required. 47Usually they are sent as a Win95 key scancode plus another scancode. I don't 48have one of these keyboards so I don't know. If enough people ask for it 49I will add 2 more signal handlers to switch the current "channel" back and 50forth. 51 522.02 NEWS: 53Version 2.02 adds mouse wheel support to adjust volume, thanks to the 54patch from Gilles QUERRET <gilles.querret@free.fr>. Now instead of 55dragging the knob, you can use your mouse wheel to adjust the current channel 56volume. Position the cursor anywhere on the dockapp, and move the wheel. 57This behaviour is off by default, but you can compile wmix with -DMOUSEWHEEL 58in the Makefile to enable this feature. Incase your mouse has more than 2 59buttons and a wheel, you can set which button signals the wheel generates as 60"up" and "down" in mix.c, lines 45 and 46. The default is for a standard 61mouse with 2 buttons and a wheel. WHEEL_STEP is the amount to adjust the knob. 62The default of 3 should be good for everyone. Changing the volume using the 63wheel also brings up OSD for the current channel following same rules as if the 64knob was used directly. 65 662.01 NEWS: 67New feature, which isn't really new, but a feature move from WMixer 1.5, is the 68On-Screen-Display (OSD), just like the one you probably have on your TV. The 69concept was the only thing copied from Wmixer 1.5 though, the code has been 70rewritten to use a modeless window instead of drawing on the root window, 71and draw code has been optimized not to draw any unnecessary stuff. The OSD 72only comes up when the Knob is turned, i.e. during manual adjustment. OSD stays 73hidden during automatic updates due to mixer reads or changing rec/balance etc. 74However, due to the way the OSD timer is done, as long as you are moving inside 75the dockapp (adjusting balance, or just generally moving the mouse inside the 76dockapp window, the OSD will stay lit. After all movement is gone, and in 77approximately 1.5 seconds, the OSD fades out. If some Xlib programmer knows 78a /NON GAY/ way to handle always-on-top, feel free to mail me a diff that makes 79the OSD continuously on top while being displayed. Right now, it comes up 80on top, but if you move a window over it or something, it gets hidden. Not 81too much of a loss, but still could be improved. OSD follows the same low-CPU 82use guidelines as the rest of the code. No updates happen unless something 83changes that requires an update. Also, expose events after uncovering the OSD 84window are not handled - if you can manage to obscure it in 1.5 seconds and 85want to see it again after that, you can always go back and twiddle the knob 86or something. 87