topic title: Idea for Pre-Installation Test of Video Driver
Posts: 1,028
SamK
Joined: 21 Aug 2011
#1
The idea is to enable the video driver to be changed when running in live-usb mode.


Scenario
I have been asked to replace Windows7 with antiX on a Toshiba laptop (Satellite Pro C660D-1D9). Usually before doing this a fall-back position is created in the form of a disk image. It is not practicable in this case.

In order to verify the suitability of antiX on this hardware a live-usb was created of 13.1-Full. This has enabled most tests to be run. There is one noteable exeception, the video driver.

A working X environment is obtained via all the F5 boot modes (default, safe, auto res, very safe). However, all are unable to adjust the screen brightness via the keyboard (FN+increase/decrease keys). These keys are known to work from a USB stick running Tinycore using Xorg-7.6 and an ATI/Radeon driver from Xorg (xf86-video-ati). In fact they also work in Tinycore using Xvesa with no driver.

antiX reports

Code: Select all

inxi -c 0 -G
Graphics:  Card: Advanced Micro Devices [AMD] nee ATI Wrestler [Radeon HD 6320] 
           X.Org: 1.12.4 drivers: ati,radeon (unloaded: fbdev,vesa) Resolution: 1366x768@60.0hz 
           GLX Renderer: Gallium 0.4 on AMD PALM GLX Version: 2.1 Mesa 8.0.5
Using smxi/sgfxi recommends installing the fglrx driver: 13.9.

Starting smxi reports

Code: Select all

smxi
------------------------------------------------------------------
Error No: (7) smxi cannot locate any /boot/grub/ config files. Unable to continue.
smxi requires grub config files: /boot/grub/menu.lst or /boot/grub/grub.cfg
smxi does not support lilo or unmounted /boot partitions.
You can start smxi with option: -! 32 to override this at your own risk!!
smxi cannot continue. Exiting now.
------------------------------------------------------------------
The live-usb was created with GRUB and root persistence. The live system was booted via GRUB with root persistence enabled.
Note: smxi was restarted using -! 32 to find the recommended video driver and version.

The video driver is prevented from updating in live mode. Prior to installation on the hard disk it cannot be eliminated as the cause of the inability to alter screen brightness.
Posts: 4,164
rokytnji
Joined: 20 Feb 2009
#2
However, all are unable to adjust the screen brightness via the keyboard (FN+increase/decrease keys). These keys are known to work from a USB stick running Tinycore using Xorg-7.6 and an ATI/Radeon driver from Xorg (xf86-video-ati). In fact they also work in Tinycore using Xvesa with no driver.
@Samk. Can you check if acpi and acpi-tools are installed in Tiny Core as I am pretty sure they are not in AntiX but need to be installed after.
Posts: 1,028
SamK
Joined: 21 Aug 2011
#3
rokytnji wrote:@Samk. Can you check if acpi and acpi-tools are installed in Tiny Core as I am pretty sure they are not in AntiX but need to be installed after.
TC
acpi and acpi-tools are not installed in the Tiny Core system


antiX

Code: Select all

apt-cache policy acpi
acpi:
  Installed: 1.6-1
  Candidate: 1.6-1
  Version table:
 *** 1.6-1 0
        100 /var/lib/dpkg/status
apt-cache policy acpitool
acpitool:
  Installed: (none)
  Candidate: 0.5.1-3
  Version table:
     0.5.1-3 0
        500 http://ftp.uk.debian.org/debian/ wheezy/main amd64 Packages


TC
Running Xvesa i.e. no video driver

Code: Select all

lsmod | grep video
uvcvideo        49152    0
videodev        49152    1 uvcvideo
video            16384    0
backlight        12288    1 video

antiX

Code: Select all

lsmod
Module                  Size  Used by
af_packet              22023  2 
nfsd                  189634  2 
auth_rpcgss            23739  1 nfsd
nfs_acl                 1912  1 nfsd
nfs                   104166  0 
lockd                  51394  2 nfs,nfsd
fscache                25151  1 nfs
sunrpc                145522  6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
dm_crypt               12549  0 
dm_mod                 58787  1 dm_crypt
ath3k                   4735  0 
btusb                  10226  0 
bluetooth             147946  3 ath3k,btusb
joydev                  8578  0 
snd_hda_codec_realtek    48871  1 
snd_hda_intel          24005  1 
snd_hda_codec          70735  2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep               5302  1 snd_hda_codec
snd_pcm_oss            30601  0 
snd_mixer_oss          12303  1 snd_pcm_oss
snd_pcm                62704  3 snd_pcm_oss,snd_hda_codec,snd_hda_intel
snd_page_alloc          6099  2 snd_pcm,snd_hda_intel
snd_seq_dummy           1288  0 
snd_seq_oss            23853  0 
snd_seq_midi            4097  0 
snd_seq_midi_event      4509  2 snd_seq_oss,snd_seq_midi
snd_rawmidi            15803  1 snd_seq_midi
snd_seq                41867  6 snd_seq_midi_event,snd_seq_oss,snd_seq_dummy,snd_seq_midi
snd_seq_device          4546  5 snd_seq,snd_rawmidi,snd_seq_oss,snd_seq_dummy,snd_seq_midi
acpi_cpufreq            6422  0 
mperf                   1118  1 acpi_cpufreq
snd_timer              15560  2 snd_pcm,snd_seq
kvm_amd                39805  0 
kvm                   211712  1 kvm_amd
snd                    49827  16 snd_hda_codec_realtek,snd_pcm_oss,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec,snd_hda_intel,snd_seq_oss,snd_seq_device,snd_mixer_oss,snd_seq_dummy,snd_seq_midi
arc4                    1784  2 
evdev                   8307  7 
uvcvideo               60232  0 
videobuf2_vmalloc       2001  1 uvcvideo
psmouse                59815  0 
microcode              11284  0 
videobuf2_memops        1771  1 videobuf2_vmalloc
ath9k                  77356  0 
sp5100_tco              4057  0 
videobuf2_core         17937  1 uvcvideo
videodev               85860  2 uvcvideo,videobuf2_core
ath9k_common            1761  1 ath9k
k10temp                 2729  0 
mac_hid                 2938  0 
radeon                718323  2 
pcspkr                  1745  0 
serio_raw               4087  0 
media                   8769  2 uvcvideo,videodev
i2c_piix4               7453  0 
toshiba_bluetooth       1978  0 
soundcore               4355  1 snd
ath9k_hw              319754  2 ath9k_common,ath9k
battery                 6603  0 
ac                      2313  0 
ath                    13442  3 ath9k_common,ath9k,ath9k_hw
mac80211              213920  1 ath9k
i2c_algo_bit            4330  1 radeon
toshiba_acpi           11833  0 
sparse_keymap           2369  1 toshiba_acpi
wmi                     7228  1 toshiba_acpi
ttm                    51849  1 radeon
drm_kms_helper         21006  1 radeon
video                  10743  0 
cfg80211              141737  3 ath,ath9k,mac80211
rfkill                 13311  3 cfg80211,toshiba_acpi,bluetooth
drm                   188891  4 ttm,drm_kms_helper,radeon
r8169                  44908  0 
agpgart                22859  2 drm,ttm
processor              26225  3 acpi_cpufreq
button                  4369  0 
thermal_sys            12638  2 video,processor
mii                     3276  1 r8169
ums_realtek             6287  0

As adjusting brightness works in TC when neither acpi or acpitools is present
it seems reasonable to tentatively infer that neither are obligatory.

TC seems to have a kernel element"backlight" which antiX does not.
Perhaps this is pointing towards a clue.

Whether or not missing packages or kernel modules are causing the
lack of adjustment in 13.1, I think being able to change driver in a pre-installation
(live-usb) environment will be a useful addition (if it is possible to implement).
anticapitalista
Posts: 5,955
Site Admin
Joined: 11 Sep 2007
#4
I just did the following running antiX-13.5-full-amd64 beta live with persistence (set up using antix2usb.py) on a 4GB usb stick.
YMMV __{{emoticon}}__

Firstly, my desktop has nvidia not ati, but maybe this will work.

1. Boot live usb stick with persistence and choose safe option in F4 (vesa) and add 3 to the end of the menu line (only to save time killing X)
2. login as root
3. run sgfxi
4. sgfxi will download the drivers and packages needed to build the driver eg fakeroot, build-essentials.
5. sgfxi complained about no /boot/grub, but it continued to build the nvidia driver.
6. sgfxi completed successfully and boot into desktop.
7. inxi -G in a terminal verifies that the new ndidia driver is indeed running.
8. reboot via exitantix dialog so persistence is saved and reboot to desktop running nvidia.
Posts: 1,028
SamK
Joined: 21 Aug 2011
#5
anticapitalista wrote:I just did the following running antiX-13.5-full-amd64 beta live with persistence (set up using antix2usb.py) on a 4GB usb stick.
YMMV __{{emoticon}}__
It does.

Before making the opening post I had tried a similar procedure.
Because it was unsuccessful I did not mention it to help with clarity.
Your suggestion is annotated with my results.

antiX-13.1-Full-amd64
  1. anticapitalista wrote:1. Boot live usb stick with persistence and choose safe option in F4 (vesa) and add 3 to the end of (only to save time killing X)
    In 13.1 all the F5 boot modes result in vesa unloaded.
    Booted very safe.
  2. ...
  3. ...
  4. ...
  5. ...
  6. ...
  7. anticapitalista wrote:inxi -G in a terminal verifies that the new ndidia driver is indeed running.
    In 13.1 the boot-time driver is still running.
  8. anticapitalista wrote:reboot via exitantix dialog so persistence is saved and reboot to desktop running nvidia.
    Saved changes, rebooted with root persistance enabled.
    The new driver is not used, the original driver is used.