General TC > Tiny Core Netbooks

Dell Mini 9

<< < (8/12) > >>

tetonca:
Dell Mini 9 report  -- tetonca

10 January 2009 - Northeast USA


INCLUDES: complete xorg.conf listing.

Brightness in other environments

Fn keys work in latest Puppy Linux, on the X11 desktop.

xrandr reports the internal (1024x600) Mini 9 display
as type 'LVDS'.

Check or set LVDS brightness (in Puppy; Debian Lenny).

--- Code: ---# cat /proc/acpi/video/GFX0/LCD/brightness
levels: 25 30 35 ... 90 95 100
current: 40
# echo 25 > /proc/acpi/video/GFX0/LCD/brightness

--- End code ---
(it changes)

This /proc/acpi/video path is unavailable in stock Tiny Core.

Brightness in Grub 2.0:
Fn keys work.

Brightness in Debian Lenny:
Same as in Puppy (at CLI looking at /proc tree; or use Fn keys
in the Linux Virtual Console -- X11 brightness untested in
Lenny, for this survey).


Mute speaker in Tiny Core Linux 2.7

Ossmix is the default command-line interface for sound, in TC.

--- Code: ---$ ossmix jack.int-speaker.mute ON

--- End code ---
(Use the GUI 'ossxmix' not the CLI 'ossmix' to get a sense of the
CLI; when one changes the other is updated.)

Headphone Jack

Works as expected.

Synaptics touchpad

Works as expected; have not looked into turning it off when
using an external USB mouse.

USB flash drives

Dell Mini 9 boots Tiny Core from a USB stick just fine.  The in-
structions in the Grub extension work well; be sure to use
the --device-map switch:

--- Code: ---# grub --device-map /tmp/devmap

--- End code ---

Copy Grub to the boot directory:

--- Code: ---$ sudo su
# fsck.extM /dev/sdX1
# mount /mnt/sdX1
# cd /mnt/sdX1/boot/grub
# cp -p /usr/lib/grub/i386-pc/* .
# cd
# sync ; sync
# umount /mnt/sdX1

--- End code ---
Anything seen in capital letters is a replaceable  (single-
character) parameter.

So:  fsck.extM  becomes  fsck.ext3  or  fsck.ext2.

Critical:

--- Code: ---# echo "(hd0) /dev/sdX" > /tmp/devmap
# exit

--- End code ---

Install:

--- Code: ---$ sudo su
# grub --device-map /tmp/devmap
> root (hd0,Y)
> setup (hd0)
> quit
> exit

--- End code ---

Those instructions are in Appbrowser window.  Nice job!

    You must include menu.lst in the same
    directory ... in /mnt/sdX1/boot/grub ... for this
    to succeed.  See elsewhere on this site, or the
    Wiki, for example menu.lst files.

I only boot from USB now; the SSD I mount as required (gen-
erally only for short-term storage between backups). Entire
system runs from RAM, to save life of SSD and USB stick flash
media.  If the system is stolen, I only lose the hardware; they
get Grub, and a barren TC base install; the real TC is on USB
stick in my pocket.

To power off, I hold down the power button for 10 sec-
onds (after verifying in the shell that no write-enabled mass
storage is mounted).

I generally backup by plan, not by shutdown ritual.

Grub 2.0 was installed to the SSD with Debian Lenny;
works fine on this hardware.  I use Grub 0.97 on USB sticks.


USB mouse
Works great.  Xorg.conf has a section that deals with
the mouse.

--- Code: ---$ cat /etc/X11/xorg.conf | egrep Opt | egrep "Im|mi|Bu"
        Option      "Protocol" "ImPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "Buttons" "5"

--- End code ---
The options helped wake up the third mouse button, instead of
chording the other two for a paste operation.


Dvorak Keyboard support

--- Code: ---# /sbin/loadkmap <  /opt/private/dvorak-mine.kmap

--- End code ---
I brought my kmap over from an earlier tc system (see below).  You
must be root (or use sudo) for loadkmap to succeed.
See the BusyBox Command Help page (busybox.net)
for terse details in the use of loadkmap.

This works great on the Console, and may also propagate to X11.  To
be sure, xmodmap should also be invoked in ~/.xsession.

--- Code: ---$ cat /home/tc/.xsession | grep vo
/usr/bin/xmodmap /home/tc/dvorak.xmodmap

--- End code ---
which is also homebrew.  The combination provides Dvorak
support wherever there is a place to type.

I modded the Dell Mini 9 keycaps to be arranged similar to
Dvorak.  Several compromises were made to do so.  I have
an external USB keyboard (a cheap $15 Logitech, from an
office supply retail chain) set up as Dvorak with only 4 keys
in the wrong spot (F and J could not be swapped to other
locations).


VGA port
Xorg: supports simultaneous displays either sharing the
display space or adjacent spaces.  Fn 8 toggles ext. display
on and off, both at Grub 2.0 and at TinyCore logo boot
screen (vga=789 framebuffer mode).

Linux Virtual Console supported on external VGA.

lxrandr controls Xorg's use of LVDS (internal) and
VGA (external) quite well.

xrandr (CLI program that comes with the Xorg extension)
works nicely.

--- Code: ---$ xrandr --output VGA  --mode 1024x768
$ xrandr --output LVDS --mode 1024x600
$ xrandr --output LVDS --pos 0x300 (offsets display 300px vert.)
$ xrandr --output LVDS --pos 0x0 (mirror)

--- End code ---
Can't get beyond --pos 0x425 or so without artifacts (should
go all the way to --pos 0x600).

Use Virtual 2048 1368 (xorg.conf) with an external 1024x768
display.

It's additive (1024x600 + 1024x768 == 2048x1368).

915resolution is *not* needed with Xorg (only needed
with Xvesa on Dell Mini 9, Tiny Core 2.7).

Video blanking timeout

--- Code: ---$ xset s 900 (900 second timeout)

--- End code ---
This seems to reset itself on a whim, so I loop it in a script:

--- Code: ---#!/bin/sh
for i in 1 1 1 1 1 \
    1 1 1 1 1 1 1 1 \
    1 1 1
  do
    xset s 900
    sleep 912
  done

--- End code ---
(change the loop to get it to run a very long time).

Sleep 912 makes sure that the display can go blank, at all.
Make it 'sleep 840' or somesuch to keep it from blanking.
This is just an ugly hack and needs work.


Wireless Support
WPA2

--- Code: ---# wpa_supplicant \
  -BWdddd \
  -D wext \
  -i eth1 \
  -c /etc/wpa_supplicant.conf

--- End code ---
That's called after a modprobe of 'wl' (if needed; not required
as far as I can tell).


--- Code: ---# wpa_cli  \
  -a /path/to/any/shell/script-of-mine.sh \
    >/dev/null 2>&1 &
# wpa_cli  status

--- End code ---

Place the two 'wpa_cli' commands in bootlocal.sh -- this will
prod the wireless to connect to the router, using WPA2 (it
won't, otherwise).

Do this after calling wpa_supplicant.


--- Code: ---# cat script-of-mine.sh
#!/bin/sh
# does absolutely nothing of use; dummy script for wpa_cli
echo
exit 0

--- End code ---

Every WPA2 user wants a configured wpa_supplicant.conf.

--- Code: ---# cat /etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ap_scan=2

network={
        ssid="corytine"
        scan_ssid=0
        proto=WPA RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP TKIP
        group=CCMP TKIP
        #psk="some-funky-wpa-seekrit-passphrase-enlightenment-40327"
        psk=700521cc0bea96fef88872e7757e7c3afb46a1b7ace09a7422b13e9439c9ab1f
}

--- End code ---
Seems to default to CCMP when forced in the wireless
router; this is AES-128, IIRC, and is most desirable for
encryption.


--- Code: ---# wpa_cli
Selected interface 'eth1'

Interactive mode

> status
bssid=00:24:b2:0a:bc:23
ssid=corytine
id=0
pairwise_cipher=CCMP
group_cipher=CCMP
key_mgmt=WPA2-PSK
wpa_state=COMPLETED
ip_address=192.168.1.38
> quit

--- End code ---
The above says it is in CCMP rather than the inferior TKIP
mode -- a better encryption standard.

Generate the business in the above wpa_supplicant.conf.

--- Code: ---$ wpa_passphrase corytine
# reading passphrase from stdin
some-funky-wpa-seekrit-passphrase-enlightenment-40327
network={
        ssid="corytine"
        #psk="some-funky-wpa-seekrit-passphrase-enlightenment-40327"
        psk=700521cc0bea96fef88872e7757e7c3afb46a1b7ace09a7422b13e9439c9ab1f
}

--- End code ---

WPA must be setup fully, prior to getting a DHCP lease from
the router.


DHCP

--- Code: ---# udhcpc -b -i eth1 # wifi

--- End code ---
cpanel defaults to eth0.

Open Access Point Wifi (no WPA2)

--- Code: ---# iwconfig eth1 essid "chauncey"
# udhcpc -b -i eth1 # wifi

--- End code ---


Battery
Turn AC CHARGING on and off.

--- Code: ---# /usr/bin/aircraft-manager-util  AC_CHARGING off  (or on).
      Turning AC_CHARGING off

--- End code ---

(Needs Aircraft Manager from Ubuntu 8.x, as distributed by
Dell/Canonical -- or somesuch named utility.  Runs fine in
Tinycore if you ignore the GUI, and run the Python control
script -- see above -- at CLI.)


Xorg
Xorg.conf (complete and verified).
See attached file.


Attachments
uuencoded dvorak.kmap as file attach, as well as the
binary.  xorg.conf is the third file attach.

md5sum.

--- Code: ---$ md5sum *
a6a9dbd8e1dfe2ad799640d8cbdf5ba6  dvorak-kmap.txt
60c284c353ebd602e782fcac08056025  dvorak.kmap
97d2404eb48f188364a40354b0de21c9  xorg.conf

--- End code ---

tetonca:

--- Quote from: h-munster on November 23, 2009, 01:42:56 AM ---I have been playing around with the brightness keys during
boot-up, and the brightness can sometimes be adjusted with
the keys, when viewing the grub menu.  It doesn't always work.

However, the brightness keys have no effect when TC is running.

--- End quote ---

Method A:Install Grub 2.0, which is consistently responsive to the
Dell Mini 9 brightness hotkeys (Fn 9, Fn 0) here (ymmv).

This should be a clue how to do it without specific acpi
support; Linux hasn't booted yet.

Method B:At the SSD password prompt, the brightness hotkeys
are also responsive.  The 8GB SSD from Dell accepts
a password; the 4GB SSD does not seem to (therefore no
prompt, so this may fail with a 4GB SSD installed).

As Grub hasn't booted yet, looks like the SSD password
prompt video environment is not harmed by subsequently
booting Grub 2.0; whereas booting Grub 0.97 does seem to
trash the state of the machine, to the extent that the
brightness keys are sometimes unresponsive.

In both instances, the display remains more dim (or bright)
througout the subsequent Linux session, than it would be
if the hotkeys were never used to change the brightness.
There's persistence here.

Method C:

If the goal is to preserve the electrical integrity of the LVDS
(internal display on the Mini 9) over the life of the unit, and
an external VGA display is customarily employed, xrandr can
shut off the LVDS.  You can toggle this as often as you wish.
Therefore this is the most dynamic method I can demonstrate,
with TC 2.7 running:

--- Code: ---$ xrandr --output LVDS --off # turns off LVDS
$ xrandr --output LVDS --mode 1024x600  # turns on LVDS

--- End code ---

Method D:

Close the lid.  This creates a thermal management issue,
but otherwise preserves the life of the LVDS and its
backlight.

jur:

--- Quote from: tetonca on January 10, 2010, 12:39:04 PM ---... xrandr can
shut off the LVDS.  You can toggle this as often as you wish.
Therefore this is the most dynamic method I can demonstrate,
with TC 2.7 running:

--- Code: ---$ xrandr --output LVDS --off # turns off LVDS
$ xrandr --output LVDS --mode 1024x600  # turns on LVDS

--- End code ---

--- End quote ---
Have you tried running extended period with '$ xrandr --output LVDS --off'? Because I tried using this but the VGA screen freezes after some minutes. I have to have LVDS on.

tetonca:

--- Quote from: jur on January 11, 2010, 07:35:29 AM ---Have you tried running extended period with

$ xrandr --output LVDS --off    ?

Because I tried using this but the VGA screen freezes after
some minutes. I have to have LVDS on.

--- End quote ---

jur, I do not remember one way or the other, as I have not
shut down the LVDS habitually.

Today I ran for an hour using yet another Method .. I used
Fn 8 at the SSD password prompt, which shuts off the LVDS
and turns on VGA.

X11 was invoked and not much jumping back and forth into
the Linux VC.  Keyboard input was steady; X never idled to blank
video.  May've been Xvesa -- I run both at different times.

Session terminated under operator control.  No problems seen.

curaga:
The X screensaver timer should only reset itself on X restart. There's likely something else touching it, like xscreensaver.

Navigation

[0] Message Index

[#] Next page

[*] Previous page