Forgot your password?
typodupeerror
User Journal

Journal: How to add new events to new keys in RedHat 9.0 2

Journal by bittmann

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:

keycode 115 = F30
! Windows key
keycode 174 = F31
! Vol down
keycode 176 = F32
! Vol up
keycode 160 = F33
! Mute
keycode 137 = F34
! eject (busted!)
keycode 117 = F35
! Menu key

Note that the eject key doesn't seem to work well for me...need to get back to that.

So, now, when you press the Windows key, Xwindows will receive an F30.

Now, the obscure (but easy) part:

Go into System Tools/More System Tools/Configuration Editor (GConf)
Drill down to apps/metacity.

Step 1: Add a custom command to an unused entry.

Under keybinding_commands, I edited the following:

command_2 became aumix -v-5
command_3 became aumix -v+5
command_4 became aumix -v0
command_5 became gnome-terminal

I left out eject after I couldn't get the key to work. Will try again "later".

Step 2: Bind the new commands to the new keycodes

Under global_keybindings, I edited the following:

run_command_2 is set to F31
run_command_3 is set to F32
run_command_4 is set to F33
run_command_5 is set to F35

(I left the "windows" key unmapped...I keep bumping it! But I mapped gnome-terminal to the menu selector key (above F9), so pressing that key gives me a new terminal. Slick.)

Restart X, and now the volume keys work.

I have been cautioned that function keys above F35 may not work. I haven't tried it to see. YMMV.

User Journal

Journal: Linux on a Dell Latitude D800

Journal by bittmann

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.

Section "Monitor"
                Identifier "Monitor0"
                VendorName "Monitor Vendor"
                ModelName "Dell 1920x1200 Laptop Display Panel"
                HorizSync 28-110
                VertRefresh 43-90
                Modeline "1920x1200" 162 1920 1984 2176 2480 1200 1201 1204 1250 +hsync +vsync
                Option "dpms"
EndSection

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...

More to come...

User Journal

Journal: Kansas joke 2

Journal by bittmann

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?"

"A: Either way, someone's losing a trailer."

User Journal

Journal: Annoyances - RedHat 8.0 Dial-up networking 1

Journal by bittmann

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!

OK. I feel better now. Got *that* off my chest!

New crypt. See /usr/news/crypt.

Working...