LJ Archive


No Virtual Panning for You!

Having recently read the Laptop Buying Guide in the December 2007 issue of LJ, I thought I'd let you know about something not mentioned in the article. Anyone who enjoys using a virtual screen resolution should steer clear of any notebook based on the Intel Graphics Media Accelerator X3100 (found in the Dell Inspiron 1420N mentioned in the Laptop Buying Guide). This chipset is unfortunately quite common and used in many of the “lower-end” modern notebooks.

I just bought a Lenovo Y410 to replace my six-plus-year-old HP N5450, which I use as a table-top PC at home. Going from a PIII-850 with 384MB RAM, S3 Savage video and 60GB drive (upgraded—the 20GB original drive died a year or so ago), you'd think I'd be thrilled with a Core 2 Duo 1.5GHz, 2GB RAM, 160GB SATA drive, built-in dual-layer DVD burner, 802.11g and so on, and for just $650 after rebate—if I get that rebate! But the truth is, I'm still using that old HP a month and a half after buying the Lenovo.

The Lenovo came with Vista, but of course the first thing I did when I got it home was boot up an Ubuntu 7.10 CD. Running live from the CD, I was amazed that the 1280x800 native screen resolution worked automatically, and that I was able to get the Intel Pro/Wireless 3945ABG working on the home wireless without any hacking. Getting the built-in 1.3M Webcam working did require actually downloading and compiling linux-uvc, but that was relatively painless. Sound support is a little sketchy. Under Ubuntu 7.10, it doesn't work automatically. You have to edit /etc/modprobe.d/alsa-base, and set the snd-hda-intel model to fujitsu. That gets the internal speakers working, but the headphones jack is totally nonfunctional (no sound output, and plugging in to it doesn't silence the internal speakers). For my intended use (table PC at home), that's not a huge deal.

But as I mentioned, the biggest issue I have with this notebook is the X3100 and Intel GM965 graphics chipset, or rather the X.org X server written for it. I've been using Linux since about 1994 (and incidentally, I've been an LJ subscriber since about issue #2), and this is the first X server I can remember running into that doesn't support panning around a virtual screen resolution greater than the actual screen resolution. From talking to other Linux users, I gather this is one of those emacs/vi issues. Some people hate and never use Virtual. Others always use it when there's enough video memory to support it. On my old HP, I use Virtual 1600 1200. On my desktops at home and work, I use Virtual 2500 2048. These virtual resolutions allow me to have several terminal windows, a browser, IM client, MP3 player and so on, all “visible” on one screen with little or no overlapping windows. I just pan around with my trackball/touchpad to the part of the virtual screen I want to see.

Nobody seems to mention the death of this feature when talking about current notebooks. It was only after considerable Googling that I found this thread where one of the authors of the Intel X server clearly states, “no Virtual panning for you!” (lists.freedesktop.org/archives/xorg/2007-April/023841.html).

This is a big enough issue for me that as soon as Xi Graphics supports the i965GM, I'm going to gladly pay them $129 for a full-featured X server.

In the meantime, I'll have to get by with multiple workspaces and have installed brightside so that I can “pan” to adjacent workspaces just by moving the pointer off the edge of the current workspace. It's not the same, but it's apparently the best I can do for now.

Jon Lewis

We Don't Need No Stinking Perl (in Our Shell Scripts)!

Well, Dave (Taylor) threw down an irresistible challenge in his January 2008 column when he remarked that he couldn't imagine a shell-only method of calculating the ordinal value of a letter, “without extraordinary levels of effort”.

I actually found three different ways of doing this, and while it did take a certain amount of effort to refresh my memory on some details, I think the resulting methods are all reasonably simple. I've presented them below; the following examples are intended to be drop-in replacements for this line on page 31 of the January 2008 issue:

ordvalue="$(echo $letter | \
   perl -e '$a=getc(); print ord($a)-96' )"

Solution 1:

# Do this array initialization prior 
# to using "LETTERS".
LETTERS=(0 {a..z})

while [ ${LETTERS[$ordvalue]} != $letter ]; do
   ordvalue=$(( ordvalue + 1 ))

The LETTERS array is initialized with the letters of the alphabet, each in its ordinal position—that is, a is in the [1] position. The while loop simply uses ordvalue as an index into the array, incrementing it until it points to the array element that matches the desired letter. Note: Using 0 as the value of the first array element is quite arbitrary; any value will do.

Solution 2:

# Do this string initialization prior 
# to using "LETTERS".


The FOO= line matches a pattern in the LETTERS string; the pattern is the specified letter, then anything else. This pattern is removed from the end of the LETTERS string, and the length of the resulting string is determined. Since this length is simply the number of characters that precede the specified letter in the alphabet, it gives the letter's ordinal value. Note that as in the first solution, the 0 at the start of LETTERS is an arbitrary character. There is simply a need to have one extra character at the start of the string to get the string lengths right, given the way that the pattern matching/string truncation works.

Solution 3:

FOO=$(eval echo {a..$letter})
ordvalue=$(( (${#FOO} + 1) / 2 ))

This one is a little bit more arcane; the FOO= line puts a string of the form “a b c d e f” into FOO (assuming in this case that letter is f), and the next line finds the length of that string, adds 1 to it, and then divides that result by 2. This effectively gives the length of the string abcdef, which is the ordinal value of f.

Now, my question for Dave: is there some way of nesting operations, such that the temporary variable FOO could be eliminated from Solutions 2 and/or 3? I can't seem to figure out what it is, if such a way exists!

Mike Henders

Correction: February 2008 LJ Index

Regarding number 12 on the February 2008 LJ Index—I'm thinking this is a typo or something: 900 billion Nokia phones in use? 150 for every human being on the planet? That seems a little not right.

Keith Blackwell

Doc Searls replies: My error, Keith. It's 900 million. Thanks for pointing it out.

LJ Archive