Shallow Thoughts : tags : X11

More on kernel options needed for new X servers

A week ago I wrote about my mouse woes and how they were solved by enabling the "Enable modesetting on intel by default" kernel option.

But all was still not right with X. I could boot into a console, start X, and everything was fine -- but once X was running, I couldn't go back to console mode. Switching to a console, e.g. Ctrl-Alt-F2, did nothing except make the mouse cursor disappear, and any attempt to quit X to go back to my login shell put the monitor in sleep mode permanently -- the machine was still up, and I could ssh in or ctrl-alt-Delete to reboot, but nothing else I did would bring my screen back.

It wasn't strictly an Ubuntu problem, though this showed up with Karmic; I have a Gentoo install on another partition and it had the same problem. And I knew it was a kernel problem, because the Ubuntu kernel did let me quit X.

I sought in vain among the kernel's various Graphics settings. You might think that "enable modesetting" would be related to, you know, being unable to change video modes ... but it wasn't. I tried different DRM options and switching framebuffer on and off. Though, oddly, enabling framebuffer didn't actually seem to enable the framebuffer.

Finally I stepped through the Graphics section of make menuconfig comparing my settings with a working kernel, and saw a couple of differences that didn't look at all important: "Select compiled-in fonts" and "VGA 8x16 font". Silly, but what could they hurt? I switched them on and rebuilt.

And on the next boot, I had a framebuffer, and mode switching.

So be warned: those compiled-in fonts are not optional if you want a framebuffer; and you'd better want a framebuffer, because that isn't optional either if you want to be able to get out of X once you start it.

Tags: linux, intel, X11, kernel
[ 19:22 Nov 16, 2009    More linux/kernel | permalink to this entry ]

Mouse failures with 2.6.31, Karmic and Intel

I've been seeing intermittent mouse failures since upgrading to Ubuntu 9.10 "Karmic". At first, maybe one time out of five I would boot, start X, and find that I couldn't move my mouse pointer. But after building a 2.6.31.4 kernel, things got worse and it happened nearly every time.

It wasn't purely an X problem; if I enabled gpm, the mouse failed in the console as well as in X. And it wasn't hardware, because if I used Ubuntu 9.10's standard kernel, my mouse worked every time.

After much poking around with kernel options, I discovered that if I tunred off the Direct Rendering manager ("Intel 830M, 845G, 852GM, 855GM, 865G (i915 driver)"), my mouse would work. But that wasn't a satisfactory solution; aside from not being able to run Google Earth, it seems that Intel graphics needs DRM even to get reasonable performance redrawing windows. Without it, every desktop switch means watching windows slowly redraw over two or three seconds.

(Aside: why is it that Intel cards with shared CPU memory need DRM to draw basic 2-D windows, when my ancient ATI Radeon cards without shared memory had no such problems?)

But I think I finally have it nailed. In the kernel's Direct Rendering Manager options (under Graphics), the "Intel 830M, 845G, 852GM, 855GM, 865G (i915 driver)" using its "i915 driver" option has a new sub-option: "Enable modesetting on intel by default".

The help says:

CONFIG_DRM_I915_KMS:
Choose this option if you want kernel modesetting enabled by default, and you have a new enough userspace to support this. Running old userspaces with this enabled will cause pain. Note that this causes the driver to bind to PCI devices, which precludes loading things like intelfb.

Sounds optional, right? Sounds like, if I want to build a kernel that will work on both karmic and jaunty, I should leave that off so as not to "cause pain".

But no. It turns out it's actually mandatory on karmic. Without it, there's a race condition where about 80-90% of the time, hal won't see a mouse device at all, so the mouse won't work either in X or even on the console with gpm.

It's sort of the opposite of the "Remove sysfs features which may confuse old userspace tools" in General Setup, where the name implies that it's optional on new distros like Karmic, but in fact, if you leave it on, the kernel won't work reliably.

So be warned when configuring a kernel for brand-new distros. There are some new pitfalls, and options that worked in the past may not work any longer!

Update: see also the followup post for two more non-optional options.

Tags: linux, ubuntu, intel, X11, kernel
[ 22:34 Nov 10, 2009    More linux/kernel | permalink to this entry ]

Crikey 0.8.3: bug fixes and several new syntaxes

Sometimes I love open source. A user contacted me about my program Crikey!, which lets you generate key events to do things like assign a key that will type in a string you don't want to type in by hand. He had some thorny problems where crikey was failing, and a few requests, like sending Alt and other modifier keys.

We corresponded a bit, figured out exactly how things should work and some test cases, went through a couple iterations of changes where I got lots of detailed and thoughtful feedback and more test cases, and now Crikey can do an assortment of new useful stuff.

New features: crikey now handles number codes like \27, modifier keys like \A for alt, does a better job with symbols like \(Return\), and handles a couple of new special characters like \e for escape. It also works better at sending window manager commands, like "\A\t" to change the active window.

I've added some better documentation on all the syntaxes it understands, both on the web page and in the -h and -l (longhelp) command-line arguments, and made a release: crikey 0.8.3.

Plus: a list of great regression tests that I can use when testing future updates (in the file TESTING in the tarball).

Tags: programming, crikey, X11, linux
[ 16:38 Aug 19, 2009    More programming | permalink to this entry ]

Which app owns a particular X window?

Someone on a mailing list was trying to figure out what app brought up a particular Gnome window, so she could run it on a machine that didn't have the Gnome desktop menus or panel.

Sounded like an interesting puzzle. I found a couple of ways, neither of them totally reliable. They both use xprop.

A lot of apps set something called WM_COMMAND to the original command that was run. So

xprop | grep COMMAND

and then click on the window you're interested in, and it gives you something ugly like

WM_COMMAND(STRING) = { "xterm", "-geometry", "80x69+0+0" }

That doesn't seem to work for more modern apps (at least, xchat and firefox don't set WM_COMMAND) so for those, try this:

xprop | grep PID

For apps that support NET_WM_PID, that gives you the process id, e.g.

_NET_WM_PID(CARDINAL) = 4095

and then you can

ps aux | grep 4095

Neither method is perfect, and there are a few apps that won't respond to either one. But most will yield to at least one of these approaches.

Tags: X11
[ 14:32 Apr 15, 2009    More linux | permalink to this entry ]

Upgraded to Intrepid: X keyboard options and losing network after suspend

I finally got around to upgrading to the current Ubuntu, Intrepid Ibex. I know Intrepid has been out for months and Jaunty is just around the corner; but I was busy with the run-up to a couple of important conferences when Intrepid came out, and couldn't risk an upgrade. Better late than never, right?

The upgrade went smoothly, though with the usual amount of babysitting, watching messages scroll by for a couple of hours so that I could answer the questions that popped up every five or ten minutes. Question: Why, after all these years of software installs, hasn't anyone come up with a way to ask all the questions at the beginning, or at the end, so the user can go have dinner or watch a movie or sleep or do anything besides sit there for hours watching messages scroll by?

XKbOptions: getting Ctrl/Capslock back

The upgrade finished, I rebooted, everything seemed to work ... except my capslock key wasn't doing ctrl as it should. I checked /etc/X11/xorg.conf, where that's set ... and found the whole file commented out, preceded by the comment:

# commented out by update-manager, HAL is now used

Oh, great. And thanks for the tip on where to look to get my settings back. HAL, that really narrows it down.

Google led me to a forum thread on Intrepid xorg.conf - input section. The official recommendation is to run sudo dpkg-reconfigure console-setup ... but of course it doesn't allow for options like ctrl/capslock. (It does let you specify which key will act as the Compose key, which is thoughtful.)

Fortunately, the release notes give the crucial file name: /etc/default/console-setup. The XKBOPTIONS= line in that file is what I needed.

It also had the useful XKBOPTIONS="compose:menu" option left over from my dpkg-configure run. I hadn't known about that before; I'd been using xmodmap to set my multi key. So my XKBOPTIONS now looks like: "ctrl:nocaps,compose:menu".

Fixing the network after resume from suspend

Another problem I hit was suspending on my desktop machine. It still suspended, but after resuming, there was no network. The problem turned out to lie in /etc/acpi/suspend.d/55-down-interfaces.sh. It makes a list of interfaces which should be brought up and down like this:

IFDOWN_INTERFACES="`cat /etc/network/run/ifstate | sed 's/=.*//'`"
IFUP_INTERFACES="`cat /etc/network/run/ifstate`"

However, there is no file /etc/network/run/ifstate, so this always fails and so /etc/acpi/resume.d/62-ifup.sh fails to bring up the network.

Google to the rescue again. The bad thing about Ubuntu is that they change random stuff so things break from release to release. The good thing about Ubuntu is a zillion other people run it too, so whatever problem you find, someone has already written about. Turns out ifstate is actually in /var/run/network/ifstate now, so making that change in /etc/acpi/suspend.d/55-down-interfaces.sh fixes suspend/resume. It's bug 295544, fixed in Jaunty and nominated for Intrepid (I just learned about the "Nominate for release" button, which I'd completely missed in the past -- very useful!) Should be interesting to see if the fix gets pushed to Intrepid, since networking after resume is completely broken without it.

Otherwise, it was a very clean upgrade -- and now I can build the GIMP trunk again, which was really the point of the exercise.

Tags: ubuntu, linux, install, X11, net
[ 17:28 Mar 11, 2009    More linux/install | permalink to this entry ]

Widescreen laptop for presentations

I've written before about how I'd like to get a netbook like an Asus Eee, except that the screen resolution puts me off: no one makes a netbook with vertical resolution of more than 600. Since most projectors prefer 1024x768, I'm wary of buying a laptop that can't display that resolution.

(What was wrong with my beloved old Vaio? Nothing, really, except that the continued march of software bloat means that a machine that can't use more than 256M RAM is hurting when trying to run programs (*cough* Firefox *cough) that start life by grabbing about 90M and goes steadily up from there. I can find lightweight alternatives for nearly everything else, but not for the browser -- Dillo just doesn't cut it.)

Ebay turned out to be the answer: there are lots of subnotebooks there, nice used machines with full displays at netbook prices. And so a month before LCA I landed a nice Vaio TX650 with 1.5G RAM, Pentium M, Intel 915GM graphics and Centrino networking. All nice Linux-supported hardware.

But that raised another issue: how do widescreen laptops (the TX650 is 1366x768) talk to a projector? I knew it was possible -- I see people presenting from widescreen machines all the time -- but nobody ever writes about how it works.

The first step was to get it talking to an external monitor at all. I ran a VGA cable to my monitor, plugged the other end into the Vaio (it's so nice not to need a video dongle!) and booted. Nothing. Hmm.

But after some poking and googling, I learned that with Intel graphics, xrandr is the answer:

xrandr --output VGA --mode 1024x768

switches the external VGA signal on, and

xrandr --auto

switches it back off.

Update, April 2010: With Ubuntu Lucid, this has changed and now it's
xrandr --output VGA1 --mode 1024x768
-- in other words, VGA changed to VGA1. You can run xrandr with no arguments to get a list of possible output devices and find out whether X sees the external projector or screen correctly.

Well, mostly. Sometimes it doesn't work -- like, unfortunately, at the lightning talk session, so I had to give my talk without visuals. I haven't figured that out yet. Does the projector have to be connected before I run xrandr? Should it not be connected until after I've already run xrandr? Once it's failed, it doesn't help to run xrandr again ... but a lot of fiddling and re-plugging the cable and power cycling the projector can sometimes fix the problem, which obviously isn't helpful in a lightning talk situation.

Eventually I'll figure that out and blog it (ideas, anyone?) but the real point of today's article is resolution. What I wanted to know was: what happened to that wide 1366-pixel screen when I was projecting 1024 pixels? Would it show me some horrible elongated interpolated screen? Would it display on the left part of the laptop screen, or the middle part?

The answer, I was happy to learn, is that it does the best thing possible: it sends the leftmost 1024 pixels to the projector, while still showing me all 1366 pixels on the laptop screen.

Why ... that means ... I can write notes for myself, to display in the rightmost 342 screen pixels! All it took was a little bit of CSS hacking in my HTML slide presentation package, and it worked fine. Now I have notes just like my Mac friends with their Powerpoint and their dual-head video cards, only I get to use Linux and HTML. How marvellous! I could get used to this widescreen stuff.

Tags: laptops, X11, linux, speaking, projector, lca2009, linux.conf.au
[ 21:12 Feb 06, 2009    More linux/laptop | permalink to this entry ]

Running a second X: Xnest, Xephyr and xinit

I had a silly problem: I needed to make some screenshots, but my window borders were too pretty.

The problem isn't actually that they're pretty; it's that the theme I wrote for openbox is very different from the much simpler theme I used to use in fvwm, and I needed new screenshots that matched the old fvwm look. Preferably without actually going back to using fvwm -- I'm quite happy with openbox these days.

Anyway, the obvious solution is to run a second X. I had done that in the past (when I needed to test something repeatedly, like a wacom tablet, and didn't want to be restarting X all the time) so I knew that was possible. But then someone told me about Xnest. It's a way to run an X server embedded in a window of the current X session. What a neat idea! I wanted to try it.

I made a simple .xinitrc.xnest file that starts fvwm after loading .Xdefaults. It took some fiddling to find a combination of arguments that worked. In the end, this was it:
xinit ~/.xinitrc.xnest -- /usr/bin/Xnest -ac :1 -geometry 1024x768
And indeed, a 1024x768 window popped up with an fvwm running inside it. Cool! Except it turned out to be not so cool -- because as soon as I switched desktops, I found that the Xnest window wouldn't repaint itself. Not even after being covered with another window then uncovered -- it just didn't seem to get any expose events. Bummer!

Next I tried Xephyr -- I heard that it was similar to Xnest, a little more heavyweight but a little more reliable. It turned out the arguments were just the same, so I ran it exactly like Xnest:
xinit ~/.xinitrc.xnest -- /usr/bin/Xephyr -ac :1 -geometry 1024x768
but Xephyr was even worse about window redrawing, plus it had some problems with the mouse pointer, which kept jumping to random places.

Too bad! They both sounded fun, and I'm sure they'll improve and will eventually become usable. But for now, I'm back to the simpler solution, running a second X server. Here's how that works: first I have to log in on console 2 (ctl-alt-F2). For some reason, I can't run a second X except from there. Then I run:
startx ~/.xinitrc.xnest -- :1 and I get a new X session, on ctl-alt-F8 (with my regular session still accessible on ctl-alt-F7).

Tags: X11, screenshots
[ 20:01 Jul 16, 2008    More linux | permalink to this entry ]

Crikey in Python, and generating key events with XTest

A user on the One Laptop Per Child (OLPC, also known as the XO) platform wrote to ask me how to use crikey on that platform.

There are two stages to getting crikey running on a new platform:

1. Build it, and
2. Figure out how to make a key run a specific program.

The crikey page contains instructions I've collected for binding keys in various window managers, since that's usually the hard part. On normal Linux machines the first step is normally no problem. But apparently the OLPC comes with gcc but without make or the X header files. (Not too surprising: it's not a machine aimed at developers and I assume most people developing for the machine cross-compile from a more capable Linux box.)

We're still working on that (if my correspondant gets it working, I'll post the instructions), but while I was googling for information about the OLPC's X environment I stumbled upon a library I didn't know existed: python-xlib. It turns out it's possible to do most or all of what crikey does from Python. The OLPC is Python based; if I could write crikey in Python, it might solve the problem. So I whipped up a little key event generating script as a test.

Unfortunately, it didn't solve the OLPC problem (they don't include python-xlib on the machine either) but it was a fun exercises, and might be useful as an example of how to generate key events in python-xlib. It supports both event generating methods: the X Test extension and XSendEvent. Here's the script: /pykey-0.1.

But while I was debugging the X Test code, I had to solve a bug that I didn't remember ever solving in the C version of crikey. Sure enough, it needed the same fix I'd had to do in the python version. Two fixes, actually. First, when you send a fake key event through XTest, there's no way to specify a shift mask. So if you need a shifted character like A, you have to send KeyPress Shift, KeyPress a. But if that's all you send, XTest on some systems does exactly what the real key would do if held down and never released: it autorepeats. (But only for a little while, not forever. Go figure.)

So the real answer is to send KeyPress Shift, KeyPress a, KeyRelease a, KeyRelease Shift. Then everything works nicely. I've updated crikey accordingly and released version 0.7 (though since XTest isn't used by default, most users won't see any change from 0.6). In the XSendEvent case, crikey still doesn't send the KeyRelease event -- because some systems actually see it as another KeyPress. (Hey, what fun would computers be if they were consistent and always predictable, huh?)

Both C and Python versions are linked off the crikey page.

Tags: programming, crikey, X11, python
[ 14:50 May 25, 2008    More programming | permalink to this entry ]

A minimal xorg.conf

Dave has been experimenting with xorg configuration lately -- trying to figure out why the latest Xorg no longer supports 1600x1200 on his monitor. (I've looked for bug reports and found gazillions of them, all blaming it on the video card but involving three different makes of video card, so color me skeptical.)

Anyway, part of this has involved taking out parts of his /etc/X11/xorg.conf file to see which parts might be causing the problem, and he's found something interesting.

What do you suppose is the minimal useful xorg.conf file? You might suppose, oh, screen and monitor sections, an input section for the keyboard and another one for a generic mouse, and that might be all you need ... right?

Okay, try it. Let's start with a really minimal file -- nothing -- and gradually add sections. To try it, make a backup of your current xorg.conf, then zero out the file:

cd /etc/X11
mv xorg.conf xorg.conf.sav
cp /dev/null xorg.conf

Now exit X if you hadn't already, and start it up again (or let gdm do it for you). Be prepared to do repairs from the console in case X doesn't start up: e.g. sudo cp /etc/X11/xorg.conf.bak /etc/X11/xorg.conf

What happened?

In my case, on the laptop running Hardy beta, X starts right up and looks just the same as it did before.

xorg.conf -- who needs it?

A specious question, of course, which has a perfectly good answer: anyone who needs a resolution other than whatever xorg picks as the default; anyone with additional hardware, like a wacom tablet; anyone who wants customizations like XkbOptions = ctrl:nocaps. There are lots of reasons to have an xorg.conf. But it's fun to know that at least on some machines, it's possible to run without one.

Update: turns out this is part of Ubuntu's new BulletProof X feature. It doesn't work on other distros or older versions. Thanks to James D for the tip.

Tags: linux, X11
[ 10:25 Apr 10, 2008    More linux | permalink to this entry ]

Synaptics and USB mouse simultaneously

A month or so back, I spent some time fiddling with the options for the Synaptics touchpad driver. The Alps (not Synaptics) trackpad on my laptop has always worked okay with just the standard PS/2 mouse driver, but in recent kernels it's become overly sensitive to taps, registering spurious clicks when I'm in the middle of typing a word (so suddenly I'm typing in a completely different window without knowing it).

I eventually got it working. I tried various options, but here's what I settled on:

Section "InputDevice"
        Identifier      "Trackpad"
        Driver          "synaptics"
        Option          "SHMConfig"             "true"
        Option          "SendCoreEvents"        "true"
        Option          "Device"                "/dev/psaux"
        Option          "Protocol"              "auto-dev"
        Option          "MinSpeed"              "0.5"
        Option          "MaxSpeed"              "0.75"
# AccelFactor defaults to .0015 -- synclient -l to check
        Option          "TouchpadOff"           "2"
        Option          "Emulate3Buttons"       "true"
EndSection

Section "InputDevice"
        Identifier      "Configured Mouse"
        Driver          "mouse"
        Option          "CorePointer"
        Option          "Device"                "/dev/input/mice"
        Option          "Protocol"              "ExplorerPS/2"
        Option          "ZAxisMapping"          "4 5"
        Option          "Emulate3Buttons"       "true"
EndSection

Life was groovy (I thought). Fast forward to LCA, a few days before my talk, when I decide to verify that I can run my USB mouse and the slide-advancing presentation gizmo through a hub off the single USB port. Quel surprise: the USB mouse doesn't work at all!

I didn't really need a mouse for that presentation (it was on GIMP scripting, not GIMP image editing) so I put it on the back burner, and came back to it when I got home. As I suspected, the USB mouse was working fine if I commented out the Synaptics entry from xorg.conf; it just couldn't run both at the same time.

A little googling led me to the answer, in a thread called Can't use Synaptics TouchPad and USB Mouse -- it wasn't the first google hit for synaptics "xorg.conf" usb mouse, so perhaps this entry will help its google-fu. The important part I was missing was in the "ServerLayout" section:

        InputDevice     "Trackpad"              "AlwaysCore"
        InputDevice     "Configured Mouse"      "CorePointer"

Adding "AlwaysCore" and "CorePointer" parts was what did the trick. Thanks to "finferflu" who posted the right answer in the thread.

Tags: linux, X11
[ 21:54 Feb 05, 2008    More linux | permalink to this entry ]

Widescreen Monitor, Intel Graphics on Ubuntu

On a seemingly harmless trip to Fry's, my mother got a look at the 22-inch widescreen LCD monitors and decided she had to have one. (Can't blame her ... I've been feeling the urge myself lately.)

We got the lovely new monitor home, plugged it in, configured X and discovered that the screen showed severe vertical banding. It was beautiful at low resolutions, but whenever we went to the monitor's maximum resolution of 1680x1050, the bands appeared.

After lots of testing, we tentatively pinned the problem down to the motherboard. It turns out ancient machines with 1x AGP motherboards can't drive that many pixels properly, even if the video card is up to the job. Who knew?

Off we trooped to check out new computers. We'd been hinting for quite some time that it might be about time for a new machine, and Mom was ready to take the plunge (especially if it meant not having to return that beautiful monitor).

We were hoping to find something with a relatively efficient Intel Core 2 processor and Intel integrated graphics: I've been told the Intel graphics chip works well with Linux using open source drivers. (Mom, being a person of good taste, prefers Linux, and none of us wanted to wrestle with the proprietary nvidia drivers). We found a likely machine at PC Club. They were even willing to knock $60 off the price since she didn't want Windows.

But that raised a new problem. During our fiddling with her old machine, we'd tried burning a Xubuntu CD, to see if the banding problem was due to the old XFree86 she was running. Installing it hadn't worked: her CD burner claimed it burned correctly, but the resulting CD had errors and didn't pass verification. So we needed a CD burned. We asked PC Club when buying the computer whether we might burn the ISO to CD, but apparently that counts as a "data transfer" and their minimum data transfer charge is $80. A bit much.

No problem -- a friend was coming over for dinner that night, and he was kind enough to bring his Mac laptop ... and after a half hour of fiddling, we determined that his burner didn't work either (it gave a checksum error before starting the burn). He'd never tried burning a CD on that laptop.

What about Kinko's? They have lots of data services, right? Maybe they can burn an ISO. So we stopped at Kinko's after dinner. They, of course, had never heard of an ISO image and had no idea how to burn one on their Windows box. Fearing getting a disk with a filesystem containing one file named "xubuntu-7.04-alternate-i386.iso", we asked if they had a mac, since we knew how to burn an ISO there. They did, though they said sometimes the CD burner was flaky. We decided to take the risk.

Burning an ISO on a mac isn't straightforward -- you have to do things in exactly the right order. It took some fast talking to persuade them of the steps ("No, it really won't work if you insert the blank CD first. Yes, we're quite sure") and we had to wait a long time for Kinko's antivirus software to decide that Xubuntu wasn't malware, but 45 minutes and $10 later, we had a disc.

And it worked! We first set up the machine in the living room, away from the network, so we had to kill aptitude update when the install hung installing "xubuntu-desktop" at 85% (thank goodness for alternate consoles on ctl-alt-F2) but otherwise the install went just fine. We rebooted, and Xubuntu came up ... at 1280x1024, totally wrong. Fiddling with the resolution in xorg.conf didn't help; trying to autodetect the monitor with dpkg-reconfigure xorg crashed the machine and we had to power cycle.

Back to the web ... turns out that Ubuntu "Feisty" ships with a bad Intel driver. Lots of people have hit the problem, and we found a few elaborate workarounds involving installing X drivers from various places, but nothing simple. Well, we hadn't come this far to take all the hardware back now.

First we moved the machine into the computer room, hooked up networking and reinstalled xubuntu with a full network, just in case. The resolution was still wrong. Then, with Dave in the living room calling out steps off a web page he'd found, we began the long workaround process.

"First," Dave suggested, reading, "check the version of xserver-xorg-video-intel. Let's make sure we're starting with the same version this guy is."

dpkg -l xserver-xorg-video-intel ... "Uh, it isn't installed," I reported. I tried installing it. "It wants to remove xserver-xorg-video-i810." Hmm! We decided we'd better do it, since the rest of the instructions depended on having the intel, not i810, driver.

And that was all it needed! The intel driver autodetected the monitor and worked fine at 1680x1050.

So forget the elaborate instructions for trying X drivers from various sources. The problem was that xubuntu installed the wrong driver: the i810 driver instead of the more generic intel driver. (Apparently that bug is fixed for the next Ubuntu release.)

With that fix, it was only a few more minutes before Mom was happily using her new system, widescreen monitor and all.

Tags: linux, X11, ubuntu
[ 13:23 Aug 25, 2007    More linux | permalink to this entry ]

Openbox 3.4

It was a bit over two years ago that I switched from icewm to fvwm as my window manager. Fvwm proved to be very fast, very configurable, and "good enough" most of the time. But lately, I've found myself irritated with it, particularly with its tendency to position windows off screen (which got a lot worse in 2.5.18). It looked like it was time to try another window manager, so when I learned that the Openbox project is headed by a fellow LinuxChixor, I had to try it.

Openbox impressed me right away. I'd tried it once before, a couple of years ago, when I found it a little inconsistent and immature. It's grown up a lot since then! It's still very fast and lightweight, but it has good focus handling, excellent window positioning, a good configuration window (obconf), and a wide variety of themes which are pretty but still don't take up too much of my limited screen space.

But more important, what it has is a very active and friendly community. I hit a couple of snags, mostly having to do with focus handling while switching desktops (the problem that drove me off icewm to fvwm), so I hopped onto the IRC channel and found myself chatting with the active developers, who told me that most of my problems had already been fixed in 3.4, and there were .deb files on the website for both of the distros I'm currently using. Indeed, that cured the problem; and when I later hit a more esoteric focus bug, the developers (particularly Dana Jansens) were all over it and fixed it that same day. Wow!

Since then I've been putting it through its paces. I have yet to see a window positioned badly in normal usage, and it handles several other problems I'd been seeing with fvwm, like focus handling when popping up dialogs (all those secondary GIMP Save-as dialogs that don't get focused when they appear). It's just as flexible as fvwm was when it comes to keyboard and mouse configuration, maybe even more so (plus it has lots of useful default bindings I might not have thought of, like mousewheel bindings to change desktops or "shade" a window).

I was going to stay out of theme configuration, because there were several pretty good installed themes already. But then in response to a half-joking question on my part of whether a particular theme came in blue, someone on the IRC channel made me a custom theme file -- and I couldn't resist tweaking it from there, and discovered that tweaking openbox themes is just as easy as fiddling with its other defaults.

I don't use transparency (I find it distracting), but my husband is addicted to transparent windows, so when I noticed on the web site that openbox handles transparency I pointed him there. (He's been using an old Afterstep, from back when it was still small and light, but it's been a constant battle getting it to build under newer gccs.) He reports that openbox handles transparency as well as afterstep did, so he's switched too.

I haven't looked at the openbox code yet, but based on how fast the developers add features and fix bugs, I bet it's clean, and I hope I can contribute at some point.

Anyway, great focus handling, great window positioning, fast, lightweight, super configurable, and best of all a friendly and helpful developer and user community. What more could you ask for in a window manager? I'm an openbox convert. Thanks, Dana, Mikachu and all the rest.

Tags: linux, X11, window managers
[ 13:13 Jun 17, 2007    More linux | permalink to this entry ]

Getting a Wacom Tablet Working under Edgy

Another person popped into #gimp today trying to get a Wacom tablet working (this happens every few weeks). But this time it was someone using Ubuntu's new release, "Edgy Eft", and I just happened to have a shiny new Edgy install on my laptop (as well as a Wacom Graphire 2 gathering dust in the closet because I can never get it working under Linux), so I dug out the Graphire and did some experimenting.

And got it working! It sees pressure changes and everything. It actually wasn't that hard, but it did require some changes. Here's what I had to do:

1. Install wacom-tools and xinput
2. Edit /etc/X11/xorg.conf and comment out those ForceDevice lines that say "Tablet PC ONLY".
3. Reconcile the difference between udev creating /dev/input/wacom and xorg.conf using /dev/wacom: you can either change xorg.conf, change /etc/udev/rules.d/65-wacom.rules, or symlink /dev/input/wacom to /dev/wacom (that's what I did for testing, but it won't survive a reboot, so I'll have to pick a device name and make udev and X consistent).

A useful tool for testing is /usr/X11R6/bin/xinput list (part of the xinput package). That's a lot faster than going through GIMP's input device preference panel every time.

I added some comments to Ubuntu's bug 73160, where people had already described some of the errors but nobody had posted the steps to work around the problems.

While I was fiddling with GIMP on the laptop, I decided to install the packages I needed to build the latest CVS GIMP there. It needed a few small tweaks from the list I used on Dapper. I've updated the package list on my GIMP Building page accordingly.

Tags: linux, X11, imaging, gimp, ubuntu
[ 15:12 Dec 09, 2006    More linux | permalink to this entry ]

Screen Blanking Under X

An unexplained change in the screen blanking timeout sent me down the primrose path of learning about dpms, vbetool and screen blanking. I guess it had to happen eventually.

It started when my laptop, which normally can sit for about ten minutes before the screen goes black, suddenly started blanking the screen after only two minutes.

After a few days of sporadic research, I now know what pieces are involved and how to fix the timeout. But it turns out not everything works the way it's supposed to. I've written up my findings: A Primer on Screen Blanking Under Xorg.

Tags: linux, X11
[ 11:55 Jul 10, 2006    More linux | permalink to this entry ]

Getting rid of all those .serverauth.???? files

Dave has been complaining for a long time about the proliferation of files named .serverauth.???? (where ???? is various four-digit numbers) in his home directory under Ubuntu. I never saw them under Hoary, but now under Breezy and Dapper I'm seeing the same problem.

I spent some time investigating, with the help of some IRC friends. In fact, Carla Schroder, author of O'Reilly's Linux Cookbook, was the one who pinned down the creation of the files to the script /usr/bin/startx.

Here's the deal: if you use gdm, kdm, or xdm, you'll never see this. But for some reason, Ubuntu's startx uses a program called xauth which creates a file containing an "MIT-MAGIC-COOKIE". (Don't ask.) Under most Linux distributions, the magic cookie goes into a file called .Xauthority. The startx script checks an environment variable called XENVIRONMENT for the filename; if it's not set to something else, it defaults to $HOME/.Xenvironment.

Ubuntu's version is a little different. It still has the block of code where it checks XENVIRONMENT and sets it to $HOME/.Xenvironment if it isn't already set. But a few lines later, it proceeds to create the file under another, hardwired, name: you guessed it, $HOME/.serverauth.$$. The XENVIRONMENT variable which was checked and set is never actually used.

Programmers take note! When adding a feature to a script, please take a moment and think about what the script does, and check to see whether it already does something like what you're adding. If so, it's okay -- really -- to remove the old code, rather than leaving redundant and obsolete code blocks in place.

Okay, so why is the current code a problem? Because startx creates the file, calls xinit, then removes the file. In other words, it relies on xinit (and the X server) exiting gracefully. If anything else happens -- for example, if you shut your machine down from within X -- the startx script (which does not catch signals) can die without ever getting to the code that removes the file. So if you habitually shut down your machine from within X, you will have a .serverauth.???? file from each X session you ever shut down that way.

Note that the old setup didn't remove the file either, but at least it was always the same file. So you always have a single .Xauthority file in your home directory whether or not it's currently in use. Not much of a problem.

I wasn't seeing this under Hoary because under Hoary I ran gdm, while with Dapper, gdm would no longer log me in automatically so I had to find another approach to auto-login.

For Ubuntu users who wish to go back to the old one-file XAUTHORITY setup, there's a very simple fix: edit /usr/bin/startx (as root, of course) and change the line:

xserverauthfile=$HOME/.serverauth.$$

to read instead

xserverauthfile=$XAUTHORITY

If you want to track this issue, it's bug bug 35758.

Tags: linux, X11, ubuntu
[ 20:24 Mar 20, 2006    More linux | permalink to this entry ]

Enabling Remote X

Another in the series of "I keep forgetting how to do this and have to figure it out again each time, so this time I'm going to write it down!"

Enabling remote X in a distro that disables it by default:

Of course, you need xhost. For testing, xhost + enables access from any machine; once everything is working, you may want to be selective, xhost hostname for the hosts from which you're likely to want to connect.

If you log in to the console and start X, check /etc/X11/xinit/xserverrc and see if it starts X with the -nolisten flag. This is usually the problem, at least on Debian derivatives: remove the -nolisten tcp.

If you log in using gdm, gdmconfig has an option in the Security tab: "Always disallow TCP connections to X server (disables all remote connections)". Un-checking this solves the problem, but logging out won't be enough to see the change. You must restart X; Ctrl-Alt-Backspace will do that.

Update: If you use kdm, the configuration to change is in /etc/kde3/kdm/kdmrc

Tags: linux, X11, net
[ 12:52 Aug 01, 2005    More linux | permalink to this entry ]

Back to the Future -- fvwm

I've been alternating between icewm and openbox for my window manager, but I'm not entirely happy with either one. They're both fast to start up, which is important to me, but I've had frustrations mostly relating to window focus -- which window becomes focused when switching from one desktop to another (icewm's biggest problem) or when a window resizes (openbox), and also with initial window positioning and desktop location (e.g. making one window span all desktops without having to select a menu item every time I run that app).

Someone was opining on IRC about fvwm and its wonderful configurability, and that made me realize that I haven't really given fvwm a chance in a long, long time. Time to see if I was missing anything!

The defaults are terrible. No wonder I didn't stick with fvwm after newer windowmanagers came out! It's definitely not an install-and-go sort of program. Nor is the documentation (a long and seemingly thorough man page) clear on how to get started configuring it.

Eventually I figured out that it looks for ~/.fvwm/config, and that some sample configs were in /usr/share/doc/fvwm/sample.fvwmrc (which is a directory), and I went from there. After several hours of hacking, googling, and asking questions on #fvwm, I had a setup which rivals any window manager I've found: it's fast, lets me configure the look of my windows, lets me bind just about anything to keys, and seems pretty well behaved focus behavior. More important, it also allows me to specify special behavior for certain windows, for example, making xchat always occupy all desktops:

Style "xchat"    Sticky

which is something I've wanted but haven't been able to do in any other lightweight window manager. That alone may keep me in fvwm for the forseeable future.

Tips for things that were non-obvious:

Rotating through three desktops

In other window managers, I define three desktops, and use ctrl-alt-right and left to cycle through them, rotating, so going right from 3 goes to desktop 1. fvwm has both "pages" (a virtual desktop can be bigger than the screen, and mousing off the right side scrolls right one page) and desktops. I didn't want pages, only desktops, so DeskTopSize 1x1 turns off the pages, and it was clear from the man page that

PointerKey Left        A CM     GotoDesk -1

would go left one desk (the only unclear part about that is that A in the modifier list means "Any", not "Alt", and "M" (presumably for "meta" means alt, not the windows-key which some programs use for meta). "PointerKey" is needed instead of "Key" because otherwise fvwm gets confused when using the "sloppy focus" model (the man page warns about that).

The question was, how to limit fvwm to three desktops, and wrap around, rather than just going left to new desktops forever? The answer (courtesy of someone on IRC) turned out to be:

PointerKey Left        A CM     GotoDesk -1 0 2
PointerKey Right       A CM     GotoDesk 1 0 2
PointerKey Left        A CMS    MoveToDesk -1 0 2
PointerKey Right       A CMS    MoveToDesk 1 0 2

The only problem at this point is that MoveToDesk doesn't then change to the new desktop, the way other window managers do, but I'm confident that will be easily solved.

Titlebar buttons

I had the hardest time getting buttons (e.g. maximize, close) to appear on the titlebars of my windows. You'd think this would happen by default, but it doesn't. It turned out that titlebar buttons aren't drawn unless there's a key or mouse action bound to that button, which they aren't by default. So to get buttons for window menu, maximize, and close, I had to do:

Mouse 1 6       A       Close
Mouse 1 8       A       Maximize
Mouse 1 1       A       Menu Window-Ops Nop

But then showing buttons 6 and 8 (the even buttons are numbered from the top right) automatically turns on 2 and 4 (I chose 6 and 8 because their default shapes were vaguely mnemonic), so they have to be turned off again:

Style * NoButton 2
Style * NoButton 4

Smaller titlebar and window frame

I also wanted to reduce the titlebar height and the width of the window frame: I don't like wasting all that screen real estate. That, too, took a long time to figure out. It turns out I had to define my own theme in order to do that, then add a couple of undocumented items to my theme. There's lots of documentation around on how to make buttons and background images and menus and key bindings in themes, but none of the documentation mentions simple stuff like titlebar height.

DestroyDecor MyDecor
AddToDecor   MyDecor
+ TitleStyle Height 16
+ Style "*"       BorderWidth 5, HandleWidth 5
+ ButtonStyle All -- UseTitleStyle
Style "*" UseDecor MyDecor

New windows should grab focus

Most window managers do this by default, but fvwm doesn't, and requires: Style * FPGrabFocus

Full config file

For any other settings, see my fvwm config file.

Tags: linux, X11, window managers
[ 17:14 Dec 13, 2004    More linux | permalink to this entry ]

Trying ion3, the window manager

Searching, as always, for the perfect window manager ...

Helix likes ion3, because it handles key accelerators very well, so I thought I'd try it.

I don't really like the "tiled or fullscreen" model it uses by default, but found the answer in the FAQ (after a rude RTFM comment which made no sense, since I already had RTFM and it doesn't give information on anything but runtime arguments): press F9 and get it to prompt for the type of the new workspace (the correct answer is the one with "Float" in the name).

All of the available themes use the "small grab handle around the title, but the rest of the titlebar isn't there" look. I don't like that (it's harder to find a place to grab to move windows around) though I suppose I could get used to it. Not a big deal.

It does look like it has good key binding support, and ways to specify different behavior for different apps, both of which would be very nice. Focus behavior on resize seems to be the same as openbox and icewm, though: if the window resizes out from under the cursor, it loses focus. Also the root menus (right-click) are a pain: they don't stay posted, and they're small, so it's hard to navigate them.

I'm sure ion3 has some coolnesses, but I decided that it didn't look likely enough to solve my problems to be worth learning how to configure it (and that unjustified RTFM left a bad taste in my mouth about how easy that configuration was likely to be). So I'm back on openbox for a little while, anyway.

Here's what I want out of a window manager:

• First, startup speed and basic operation comparable to icewm or openbox (my two faves so far).
• Intelligent handling of keyboard focus even when in "focus follows mouse" mode. That means:
  • When switching workspaces, focus goes either to the window under the mouse, or the window on that workspace which last had the focus (either one would be fine). Openbox does this pretty well; icewm's focus is pretty random.
  • When resizing a window that has focus, it should keep the focus even if it resizes out from under the mouse.
  • Click in a window focuses (but doesn't necessarily raise) that window. (Again, openbox does this well, icewm doesn't.)
  • A new window or dialog gets focused.
• A way of setting up rules for different windows: e.g. I want xchat to be on all workspaces, or I want moonroot to come up with no window borders. I shouldn't have to do a right-click-and-menu-selection operation every single time I run xchat.
• Easy configuration to start apps with from a menu on the root or via key bindings (or, ideally, both). No dependance on having a panel (which was why I quit using xfce4). Both icewm and openbox handle this well.
• A way of navigating among windows using only the keyboard. Both openbox and icewm allow for easy movement between workspaces and moving windows between workspaces, but in both of them, alt-tab toggles between the current app and the last app on that workspace, and there seems to be no way to get to anything besides those two.

Tags: linux, X11, window managers
[ 17:36 Aug 09, 2004    More linux | permalink to this entry ]

Got the external mouse working again

For some reason X on the laptop hasn't been seeing the external USB mouse. But last night I got it working again. Turns out that /dev/input/mouse0 no longer works; I have to use /dev/input/mice because the mouse number changes each time it's plugged in (which I don't think was a problem with earlier kernels). Thanks to Peter S. for helping me track the problem down.

I also learned (unrelated to the mouse issue) about a couple of very useful Debian apps, deborphan and debfoster, for finding orphaned and no longer needed libraries. I'd always wanted something like that to help clean up my crufty debian systems.

Tags: linux, X11, debian
[ 18:39 Jul 31, 2004    More linux | permalink to this entry ]

DRI works after all

Got an account on alioth, akkana-guest.

Discovered that the tuxracer problem I've been having isn't actually Debian sid having broken DRI, but merely some problem with the commercial tuxracer (probably not loading the gl libs properly or something). Free tuxracer still works. Yay.

Tags: linux, debian, X11, games
[ 19:00 Jul 07, 2004    More linux | permalink to this entry ]