After a long pause in this podcast, let me continue with more great music, this time from Scott Altham — a very nice ambient/chillout tune...
Say you have a bunch of PDFs and you want to know how many pages each of them has. You could of course use some graphical software to display every single PDF and check the page count (xpdf, evince, whatever), but that gets tedious very fast.
So here's (mostly as a reminder for myself) one way to count pages of many PDFs (in the current directory) using pdfinfo from the xpdf-utils package:
$ cat countpdfpages #!/bin/sh for f in *.pdf; do echo -n "$f: " pdfinfo "$f" 2>/dev/null | grep Pages | cut -d ":" -f 2 done
A sample run:
$ ./countpdfpages S71147.pdf: 25 S71226.pdf: 38 S71242-01.pdf: 25 S71258.pdf: 26 S71315.pdf: 35 S72045.pdf: 2
I'm sure there are many other ways to do this, e.g. using pdftk foo.pdf dump_data (in the pdftk package), please leave a comment if you know a simpler way to achieve this. Especially so if you don't need an extra script to do it (i.e. if there's a PDF command line tool which can already count pages in multiple PDFs). Thanks!
I have mentioned the flashrom utility in my blog in the past. This is a small command line tool which allows you to update your BIOS/coreboot/firmware chips without opening the computer and without any special boot procedures.
Yesterday, flashrom 0.9 was finally released. Here's a short passage from the release announcement:
After nine years of development and constant improvement, we have added support for every BIOS flash ROM technology present on x86 mainboards and every flash ROM chip we ever saw in the wild.
Highlights of flashrom include:
Please note that rewriting your flash chip can be dangerous and flashrom developers make no guarantees whatsoever. That said, many users have successfully replaced proprietary tools such as awdflash, amiflash and afudos with flashrom.
Do yourself a favor and try flashrom next time you want to upgrade your BIOS. No more floppies or bootable CD-ROMs with DOS/Windows binaries or similar crap. Run flashrom conveniently from the Linux command line, or even via SSH or serial console if you want...
I recently got a new (well, refurbished) laptop as a replacement for my old Toshiba A80-117 laptop which has more or less died. It's an IBM/Lenovo T40p laptop (model 2373-CG6), with an Intel Pentim M at 1.5 GHz. I chose this laptop for multiple reasons:
Downsides and missing hardware features (nothing too important, though):
Pretty much all of the hardware works flawlessly out of the box with a recent distro/kernel, see below for details.
Not needed, I simply popped out the 40 GB drive from the T40p and inserted my 160 GB (PATA) drive from my old laptop and that was it. Pretty much everything worked out of the box (see below), even though this is a totally different manufacturer, model, chipset, graphics card, wireless card, and so on. The only exception being (of course) my small Windows partition on that disk, which is now unusable as the drive is on different hardware and Microsoft doesn't like me to do that. Free Software: 1, Microsoft: 0.
Works out of the box using the snd_intel8x0 driver. The hardware is onboard audio in the southbridge (82801DB / ICH4) and uses the Analog Devices AD1981B codec.
Works out of the box using the bluetooth and hci_usb driver. The laptop's Bluetooth device is USB-attached internally and shows up in lsusb as:
$ lsusb Bus 003 Device 004: ID 1668:0441 Actiontec Electronics, Inc. [hex] IBM Integrated Bluetooth II
The device is not enabled per default though (which is a good thing), you can enable it like this:
$ echo enable > /proc/acpi/ibm/bluetooth
Disabling is equally simple:
$ echo disable > /proc/acpi/ibm/bluetooth
After that, you can use hcitool / hciconfig etc. as usual, and/or enable more related stuff with /etc/init.d/bluetooth restart.
Untested, I don't need it.
Untested so far.
Works out of the box.
$ sensors acpitz-virtual-0 Adapter: Virtual device temp1: +51.0°C (crit = +93.0°C) thinkpad-isa-0000 Adapter: ISA adapter fan1: 3698 RPM temp1: +51.0°C temp2: +42.0°C temp3: +32.0°C temp4: +49.0°C temp5: +33.0°C ERROR: Can't get value of subfeature temp6_input: Can't read temp6: +0.0°C temp7: +28.0°C ERROR: Can't get value of subfeature temp8_input: Can't read temp8: +0.0°C
$ dmesg | grep -i hpet pci 0000:00:1f.0: Force enabled HPET at 0xfed00000 hpet clockevent registered HPET: 3 timers in total, 0 timers will be used for per-cpu timer hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 hpet0: 3 comparators, 64-bit 14.318180 MHz counter
You can check with powertop that the number of wakeups-from-idle is drastically reduced (from 70 to less than 10) when adding hpet=force to the kernel command line.
Works out of the box using the e1000 driver.
$ modprobe e1000 Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11 e1000: 0000:02:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:11:22:33:44:55 e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Works out of the box, both in X as well as in the console using gpm.
Works out of the box, both in X as well as in the console using gpm.
Both work out of the box (on 2.6.26 or 2.6.29 kernels), or at least it used to; I think I'm seeing some hangs upon resume nowadays (Capslock LED is blinking, schreen is blank. I'll investigate.). I'm using the hibernate Debian package. You can explicitly force the usage of either method in /etc/hibernate/hibernate.conf by uncommenting the respective lines.
# TryMethod suspend2.conf TryMethod disk.conf # TryMethod ram.conf
Works out of the box using the ath5k driver. I tested WEP as well as WPA.
Works out of the box using the acpi_cpufreq driver.
$ cpufreq-info analyzing CPU 0: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 0 hardware limits: 600 MHz - 1.50 GHz available frequency steps: 1.50 GHz, 1.40 GHz, 1.20 GHz, 1000 MHz, 800 MHz, 600 MHz available cpufreq governors: userspace, powersave, ondemand, conservative, performance current policy: frequency should be within 800 MHz and 1.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency is 800 MHz (asserted by call to hardware). cpufreq stats: 1.50 GHz:69.76%, 1.40 GHz:0.11%, 1.20 GHz:0.13%, 1000 MHz:0.16%, 800 MHz:29.83%, 600 MHz:0.00% (4010)
Use cpufreq-set -g performance if you need full CPU power, cpufreq-set -g powersave otherwise.
Works fine out of the box, tested with beep.
Works out of the box. You can play DVDs or CD-ROMs, and burn CDs (but not DVDs):
$ wodim foo.iso [...] Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'MATSHITA' Identification : 'UJDA745 DVD/CDRW' Revision : '1.02' Device seems to be: Generic mmc2 DVD-ROM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R96R
Ejecting a CD-ROM/DVD using the eject command line tool also works fine.
Works out of the box using the radeon driver.
$ xrandr Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 2048 VGA-0 disconnected (normal left inverted right x axis y axis) DVI-0 disconnected (normal left inverted right x axis y axis) LVDS connected 1400x1050+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1400x1050 50.0*+ 1280x800 60.0 1280x768 60.0 1024x768 60.0 800x600 60.3 640x480 59.9 S-video disconnected (normal left inverted right x axis y axis)
DRI works out of the box with the (mainline, open-source) driver:
$ glxinfo | grep direct direct rendering: Yes
If you attach an external monitor or projector, you can enable it using xrandr as usual:
$ xrandr --output VGA-0 --auto
You can also use a dual-head setup by adding this to your "Screen" section in /etc/X11/xorg.conf:
SubSection "Display" # Virtual 2048 2048 Virtual 1400 2048 EndSubSection
After restarting the X server, you can play with xrandr and move the external screen (VGA-0) "below" the laptop's LCD screen (LVDS) for a simple dual-head setup. The GUI tools arandr or grandr are probably a bit simpler to use than plain command line xrandr.
The maximum size for the "Virtual" line is 2048x2048 if you want to keep DRI enabled (you can use higher values if you don't care about DRI).
Untested so far.
Yes, this model still has an actual parallel port, which is nice as I can use it for random JTAG stuff (e.g. OpenOCD) with several cheapo parallel port JTAG adapters I own.
This laptop has a type II/III PCMCIA slot which works out of the box using the pcmcia and yenta_socket drivers. You can probe/handle PCMCIA cards using the pccardctl tool:
$ pccardctl status Socket 0: no card Socket 1: no card
Works fine, of course. Luckily it's USB 2.0 (not USB 1.1) so I can successfully do high-speed stuff, e.g. watching DVB-T using kaffeine. The only small problem is that there are only two USB ports, more would have been better.
Works fine, of course, it's just a normal PATA drive. You can check if DMA gets properly enabled with hdparm /dev/hda | grep dma.
Works out of the box (Fn + PgUp). This is a tiny, but useful light embedded in the screen, which is helpful if you're working in dark rooms or in trains during the night etc.
What works out of the box: brightness control buttons, audio volume control + mute buttons, thinklight button.
TODO: Access IBM, F3, F4, F5, F7, F12, left/right special keys, Fn+Space.
All of them seem to work fine, including the Bluetooth on/off and Wireless on/off LEDs, as well as the suspend LED.
-[0000:00]-+-00.0 Intel Corporation 82855PM Processor to I/O Controller [8086:3340] +-01.0-[0000:01]----00.0 ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] [1002:4c66] +-1d.0 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] +-1d.1 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] +-1d.2 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] +-1d.7 Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] +-1e.0-[0000:02-08]--+-00.0 Texas Instruments PCI1520 PC card Cardbus Controller [104c:ac55] | +-00.1 Texas Instruments PCI1520 PC card Cardbus Controller [104c:ac55] | +-01.0 Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) [8086:101e] | \-02.0 Atheros Communications Inc. AR5212 802.11abg NIC [168c:1014] +-1f.0 Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] +-1f.1 Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] +-1f.3 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] +-1f.5 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] \-1f.6 Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6]
processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Pentium(R) M processor 1500MHz stepping : 5 cpu MHz : 1500.000 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe up bts est tm2 bogomips : 2997.72 clflush size : 64 power management:
All in all it's a really nice piece of hardware, and it works without much hassle with recent distros/kernels.
If you recently upgraded your kernel to the 2.6.29 Debian package, you might have noticed some (e.g. graphics) drivers stopped working or are working slower. In my case, this was the radeon driver, which inexplicably seemed to cause lots of slowdowns in some applications and games. A quick look into dmesg revealed the reason:
[drm] Initialized radeon 1.29.0 20080528 on minor 0 agpgart-intel 0000:00:00.0: AGP 2.0 bridge agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode pci 0000:01:00.0: putting AGP V2 device into 4x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode platform radeon_cp.0: firmware: requesting radeon/R200_cp.bin radeon_cp: Failed to load firmware "radeon/R200_cp.bin" [drm:radeon_do_init_cp] *ERROR* Failed to load firmware!
As noted in the changelog file, the radeon firmware R200_cp.bin has been removed from the kernel, and is now available in the separate firmware-linux Debian package. So the simple fix for this issues is:
$ apt-get install firmware-linux $ dpkg -L firmware-linux | grep R200_cp.bin /lib/firmware/radeon/R200_cp.bin
After restarting X, the dmesg output looks more sane again:
agpgart-intel 0000:00:00.0: AGP 2.0 bridge agpgart-intel 0000:00:00.0: putting AGP V2 device into 4x mode pci 0000:01:00.0: putting AGP V2 device into 4x mode [drm] Setting GART location based on new memory map [drm] Loading R200 Microcode platform radeon_cp.0: firmware: requesting radeon/R200_cp.bin [drm] writeback test succeeded in 2 usecs