In my last entry (July 8), I noted that I needed to document how I added keybindings to the volume keys in RedHat 9.0.
First of all, it isn't as easy as it might be. There is documentation in RH9 under Preferences/Keyboard Shortcuts that indicates that there is an "Add a Custom Binding" function in the Gnome Keyboard Shortcuts tool. No, there isn't. So...it's harder than editing an "add" screen. But not TOO hard...
First of all, the keybindings must be put in place to map a keyboard scancode to an event. I added the following to/etc/X11/Xmodmap:
Going to list some of the triumphs and pitfalls of Linux on a Dell D800 "Centrino" system here. If it goes far enough, I'll update my own homepage with a Howto:...but want to get this down while I'm thinking of it.
Using RedHat 9.0.
RH9 installed "OK" out of the box. Needs a couple of things to get it going, and a little *more* work to get it actually usable.
1) Download Broadcom 5700 driver from Broadcom's site. Compile and get module ready. Set up/etc/modules to load driver when ethernet comes up. You can either use a (supported) USB or PCMCIA NIC, or do the floppy shuffle (it's small).
2) (optional) If you have access to high-speed Internet, go ahead and run up2date. Take the trouble to get the new RedHat kernel (it does IDE chipset DMA, and will make the rest of this less painful).
3) (optional) Get NVIDIA drivers from NVIDIA's site. Or, use the open-source 2d drivers...that'll work, too.
If you only get 1600x1200, you may need to add a modeline to XF86config to allow 1920x1200.
The box should now be usable. There's no power management, however (and you'll have to "push the button" to turn off the computer at shutdown).
What I did to make it "better":
Downloaded modem drivers (they build and connect... but I haven't tried them after upgrading the kernel. To-Do).
Downloaded 2.4.22-pre2 kernel, which has ACPI working. Quick and dirty: use one of the Configs in one of the RedHat sources directories (I used the "686" config from 2.4.20-18.9). Enable ACPI (I did it modularized for better control). Turn off APM. Turn off whatever else you don't want (ATM? whatever). Build. Set up modules to load in rc.local (or wherever).
Now, I have ACPI working!
Note: processor.o won't set anything but the first 2 clocking states. Haven't had time to look at it yet. Downloaded developer binary from Intel...it works for all 7 processor states. Now I can underclock to the lowest setting, and still play a video at full speed without buzzing the fan.
Note: The linux AGPGART has trouble with the lid switch...if the linux AGPGART is loaded, the lid switch will hang the machine. For now, don't load it (it won't load unless you set the "try unsupported" flag), and it'll work fine. Or never touch the lid switch:).
Downloaded acpid, and have "borrowed" a few scripts for suspend, power off, etc.
Note: Suspend works, but mouse is hung upon return. Can Ctrl_Alt_F1, the Ctrl_Alt_F7 to go back, and it'll work again.
Have added keymappings for volume up, down, mute. Note: Need to tell how under RH9...it isn't obvious (at least to me). Also added a command to the "menu selector" button (above F9) to pop up a terminal. Slick...
Had a "week from hell", as my real-life workplace implemented a new Digital Transcription system. Many problems/long hours/Microsoft SQL server issues (ugh!)...but anyway, was finally able to do the standard post-install "thing" and get out for a vendor-paid-for bash at the Scotch and Sirloin (a local establishment of some repute...good food, and a waitstaff containing serious eye-candy). One of the vendor's techs, who had *quite* a bit to drink, motioned me over...
"Q: What does a Kansas divorce and a Kansas tornado have in common?"
Note To Those Who Build System Configuration Scripts: Make Sure What You're Doing Carries Through To The Rest Of The System!
Yes, most of this is my fault for not completely auditing the system that I sent away with my parents. However, I do think that there is something in here that says *something* about the lack of coordination within the RedHat 8.0 install.
Bear with me, here...
Just set up RH8 for my parents. They dug it. Looked good to them, gave them a good, integrated "feel", and did away with most of their complaints about arcane commands/editing config files, etc.
They took it home and set up dial-up-networking themselves (the wizard actually runs well enough that they had the modem configured and DUN up and running on the first try!) However, my folks are hooked on the "Modem Lights" applet that shipped with RH7.x. No demand dial for them! No problem...they added the applet to the panel. Except that, in its default state, it doesn't work.
A phonecall and a couple of "ssh" sessions later, and here's what I found:
1) Modem Lights is (by default) pointing at "ifup" and "ifdown" as the commands to do the dirty deeds--commands which aren't in a base user's path. So for root this ran just fine, but the basic user couldn't use it. Click on Modem Lights, get no error message, no response, no nothing. No problem...I saw that one fairly quickly, and told them to change the path to the commands. It would now dial...
2) But now, it won't disconnect. Grrr...it's pointing at the wrong lockfile, so it doesn't know it's connected, so it doesn't try to disconnect (it wants to connect again!). The Internet Cofiguration Wizard sets up the device to generate a lockfile using the device name (/var/lock/LCK..ttyS0 or some such). Modem Lights by default was looking for/var/lock/LCK..modem). What gets to me is that the hardware detection seemingly created the correct link in the device directory (/dev/modem >/dev/ttyS0). Why the networking setup didn't use/dev/modem (or even/dev/modemn for that matter), along with the appropriate lockfile, I can't fathom.
OK, so we got THAT figured out and changed. But wait, it gets better! Being a parent ("Dad, why did you do that?" "I don't know. I just did."), the next thing that happened was that *somehow* the applet was removed from the panel. So it was put it back--And lo and behold! All of the changes that he made were reset to the default values, losing all of the work we just went through. Now, this may have taken place because he hadn't exited/saved, but then again, I didn't want to risk him losing this data later, so...
No problem, we'll just symlink ifup/down from/usr/local, and change the Networking setup to use/dev/modem. But the next time the networking wizard was run...grrr. Back to the tty device.
So: in a nutshell, here's what I'd like to see fixed:
1) RedHat's configuration of the basic tools/configurators/applets/etc. that they deliver in the base desktop install are not necessarily configured in a compatible fashion. This is frustrating to the adept, and confusing/maddening to the newbie, which doesn't help for user acceptance at all. Audit your system installs, and make certain that all tools/applets/etc. can agree on the basics. If something doesn't, then change it (to use a config file/command-line arguments/whatever) and submit the source back to the author. After all, that's what your value-add is supposed to be: Making things "just work". Otherwise, you're no better than (insert distrubution name here).
2) Some of the apps that RedHat ships don't give the user ANY indication of an error. Again...fix the problem! If all they did was give the user some easy/consistent way to view stdout/stderr, at least he'd get some feedback about what was happening. It's made even more tough to troubleshoot when GDM runs...there isn't even a pseudoterminal that's easy/quick to get to. And no, this didn't appear in the System Log, either. As far as my parents were concerned, they were flying blind.
So: Here's what I suggest.
1) If you're going to support abstract devices, make the configurators abstract the devices in a consistent fashion. Add a number if you have more than one of a given device (/dev/modem and/dev/modem1 instead of/dev/ttyS0 and/dev/ttyS1 or whatever).
2) Make all applications that use these devices default to the lowest-common-denominator abstract device (/dev/mouse or/dev/mice,/dev/modem,/dev/cdrom, etc.). Worst-case scenario: Tell the user that they can add a number if they need to differentiate between devices. But in most cases, the device should select "appropriately".
3) And for pity's sake: Test the system install as a user, not just as root. How RedHat managed to ship something that a user would run (Modem Lights) with a command path that is completely non-functional is beyond me. Imagine how much flack M$ would get if THEY pulled this. Hey--maybe their wizards make things run at the lowest common denominator...but at least they kinda-sorta run, or at least pop up an undecipherable error message or blue screen...they don't just sit there and do NOTHING!