tde-guidance/TODO

TODO
====

BUG: Mountconfig has no "enable/disable" in the context menu.

BUG: Mountconfig: "enable/disable" can sometime be available for normal users.

BUG: mountconfig: The disk details dialog (sizeview.py) doesn't show *unpartioned* free space.

BUG: Live gamma changes didn't seem to work on one of the S3s.

BUG: mountconfig. Authentication details in the SMSShareSelectDialog are sometimes not
correctly used when browsing.



TODO: Some S3 cards need to have the video ram specified, and some later model don't.
      It would be good if we could tell the difference and only offer the ram pulldown
      when strictly needed.


TODO: Monitor type selection (CRT, lcd etc). needed for clone mode on ATI at least.

TODO: When using the proprietary nVidia driver, choose between the nVidia AGP
and kernel agpgart based on what is best the of the machine's chipset.

TODO: The proprietary ATI drivers have a 'Option "BusType" "PCI"' thing which may
of may not need to be set for PCI based ATI cards.

TODO: 3D accel on the 9250 with open source drivers.


Future TODO
===========

setup.py
~~~~~~~~
.

userconfig
~~~~~~~~~~
.

unixauthdb.py
~~~~~~~~~~~~~
* LDAP (post-1.0) in-progress
* (others?) (post-1.0)

serviceconfig
~~~~~~~~~~~~~
* Change os.system() to the calls Simon uses in some cases.
* Some services are running, but not in /var/run, implement special treatment. :>
* Remove commented line from /etc/shells in userconfig -> Modify -> Shell.

mountconfig
~~~~~~~~~~~
* Add 'proper' GUIs for editing some of the more common FS types.
    - NFS.
* AttributeError when mounting Samba volume
* Handle the 'managed' mount entry options. See http://www.die.net/doc/linux/man/man8/fstab-sync.8.html
  This is stand on Mandriva 2005.
* Implement "real" HAL backend.

displayconfig
~~~~~~~~~~~~~
* Use HAL for fetching PCI and card info? alongside existing systems (ldetect)?


        
Extra?
~~~~~~
* Swap/kernel config:
  http://kerneltrap.org/node/view/3000
  "To tune, simply echo a value from 0 to 100 onto /proc/sys/vm/swappiness."

* Hardware detection info:

 http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=lyit5wc14g.fsf%40leia.mandrakesoft.com&rnum=1&prev=/groups%3Fq%3Ddebian%2520ldetect%2520hardware%2520detection%26hl%3Den%26lr%3D%26ie%3DUTF-8%26sa%3DN%26tab%3Dwg

----------------------------------------------------------------------------  
From: Pixel (pixel@mandrakesoft.com)
Subject: Re: Why so many HW detection packages? 
Newsgroups: linux.debian.devel
Date: 2002-05-09 17:20:07 PST 

On Fre, 26 Apr 2002, Petter Reinholdtsen wrote:

[...]

> The reson is that there are 3 hardware detection system:
> - Mandrake (libdetect, old)

truly libdetect is old and deprecated 
(harddrake (was lothar) used to use it)

we (mandrake) are now mostly using ldetect & ldetect-lst

AFAIK here are the various free software hardware databases:

--------------------------------------------------------------------------------
- pci ----------

  - pci.ids (in pciutils)
    maps vendor+device -> description
     and vendor+device+subvendor+subdevice -> description
    also has device classes names

  - modules.pcimap (in kernel /lib/modules/2.4*/)
    maps vendor+device -> module
     and vendor+device+subvendor+subdevice -> module

  - XFree's xf86PciInfo.h (in XFree's source: xc/programs/Xserver/hw/xfree86/common/xf86PciInfo.h)
    maps vendor+device -> description

  - RedHat's pcitable (in hwdata)
    maps vendor+device -> module+description
      and a few vendor+device+subvendor+subdevice -> module+description
      when needed     
    module can also be "Card:xxxx" for XFree (using Cards, see below)

  - Mandrake's pcitable (in ldetect-lst)
    same format as RedHat's (except for a few syntactical changes since mandrake kept old RedHat's format)
    module can also be 
      "Card:xxxx" for XFree (using Cards+, see below)
      "Server:xxxx" for XFree3
      "ISDN:xxxx" for hisax special parameters
      "Bad:xxxx" for warning about unhandled devices (mainly winmodems)

  - Mandrake old detect's pci.lst (in detect-lst)
    maps vendor+device -> class+module+description

  - Progeny's pci.lst (in discover-data)
    same format as detect
    maps vendor+device -> class+module+description
    module can also be 
      "Server:XFree86(module)" for XFree4
      "Server:XF86_xxx" for XFree3

some comments:

  - the "class" in pci.lst is not useful when "module" is given since
    from the module name, one can have the "class"

  - the subvendor+subdevice distinction is sometimes useful 
    (not very often though)

  - hopefully one day modules.pcimap will be the reference :)
    (except for XFree of course)

tools using those databases:

  - kudzu and anaconda are using pcitable from hwdata

  - library ldetect accesses pcitable from ldetect-lst,
    this library is used by DrakX and drakxtools.
    Mandrake's patched kudzu uses pcitable from ldetect-lst

  - discover uses pci.ids from discover-data

  - i don't know if tools are using modules.pcimap

- XFree --------------------

  - XFree comes with Cards
 
  - Redhat has its own version (in hwdata)

  - Mandrake has its own version Cards+ & CardsNames (in ldetect-lst)
    (mainly a merge of XF3 Cards and XF4 Cards)

  - discover doesn't need it since it's precising the server name
    (XF3) or the module name (XF4) (?)
    this is usually enough (except if you want to propose the choice,
    but who wants XF3 nowadays :)


- usb --------------------

  - usbutils's usb.ids
    maps vendor+device -> description
    also has device classes names and some more stuff

  - modules.usbmap (in kernel /lib/modules/2.4*/)
    maps vendor+device -> module  (?)

  - Mandrake's usbtable (in ldetect-lst)
    maps vendor+device -> module+description
    module can also be 
      "Mouse:xxxx" for mouse configuration (fed to mousedrake)
      "Tablet:wacom" for wacom tablet configuration
      "Flag:xxxx" for DrakX package choosing
      "Floppy:normal"

  - Progeny's usb.lst (in discover-data)
    maps vendor+device -> class+module+description
    (but current's version only have module=unknown, so what's it
    for, why not usb.ids?)


tools using those databases:

  - library ldetect accesses usbtable from ldetect-lst
    this library is used by DrakX and drakxtools

  - i don't know if tools are using modules.usbmap

- scanner --------------------

  - ScannerDB (in ldetect-lst)
    maps name -> driver+kind(usb,scsi,serial,parallel)+options+various
    (i don't know much about it, i don't know if yves made it from
     scratch or what. ask yduret@mandrakesoft.com for more)

- isdn --------------------

  - isdn.db (in ldetect-lst)
    list of internet providers by country
     -> phone number + domainname + dns1 (ip) + dns2

- old or small databases ----------

  - isa.lst (detect), isatable (ldetect-lst), modules.isapnpmap (kernel)
  - pcmcia.lst (detect, discover-data), pcmciatable (ldetect-lst)
  - modules.parportmap (kernel but empty?)
  - modules.ieee1394map (kernel but empty?)

--------------------------------------------------------------------------------

There may be some errors, or some missing stuff, please correct me!

I've written a tool to keep in sync with as many databases as
possible. see merge2pcitable.pl in
http://www.mandrakelinux.com/cgi-bin/cvsweb.cgi/soft/ldetect-lst/convert/

Maybe some common mailing list could be set up to deal with this? 

*but* note that the database is quite kernel dependent. 
- our pcitable doesn't handle this nicely
- redhat has "upgradelist" in hwdata to partly handle this
- i know we handle some pbs via /lib/modutils/macros with things like
"if `kernelversion` = 2.4", debian seems to have it in
/etc/modutils/arch


Once again, hopefully one day modules.pcimap and modules.usbmap will
be the reference! :)



[...]

> Mandrake switched from libdetect to kudzu, afaik
> (latest mandrake (8.2) version is using kudzu for HW detection).

well, mandrake has many tools doing more or less the same thing (and
alas, not exactly always the same thing): DrakX (during install),
drakxtools (when called, after install), kudzu (at boot, usually
calling a drakxtools)

----------------------------------------------------------------------------


List of hardware probing tools to use for displayconfig:
--------------------------------------------------------


[1] xvinfo - Print out X-Video extension adaptor information

    xvinfo  prints  out  the  capabilities of any video adaptors
    associated with the display
    that are accesible through the X-Video extension.

[2] xresprobe - Prints out resolutions, frequency and displaytype.
    Doesn't work in all cases. Works via ddc, I guess.

[3] ddcprobe - Uses VESA BIOS Extension
    Detects VGA + OEM, modes (only set up modes?), vid mem (kudzu)

[3] read-edid
    get-edid|parse-edid prints out a "good-looking" Monitor Section for
    xorg.conf, not reliable (failed on notebook)

[4] ddcxinfo - prints out modelines, hsync and vsync (kudzu)

[5] svgamodes - prints out supported video modes (kudzu)




--
Pixel
programming languages addict      http://merd.net/pixel/language-study/

----------------------------------------------------------------------------