tpctl -- ThinkPad configuration tool for Linux
Stein Vrale
linux-thinkpad@www.bm-soft.com
Tue, 13 Jul 1999 18:30:47 +0200
"J.d.thomas Hood" wrote:
> I like the LinuxConf idea.
>
> Would it be best to interface with the smapi module directly via
> ioctl() or to do it via tpctl?
I recommend using linuxconf as a frontend for tpctl only, then users
still have the option to use it from other frontends, scripts, etc. It
may be easier to maintain also, the technical details in tpctl and the
GUI stuff in linuxconf. Most parts of linuxconfs works this way,
avoiding touching the system directly, but mostly using the distribution
provided scripts/tools (when available). The usual approach is to define
the path to the tool (tpctl), make dialogs where you bind buttons or
menuchoices to the various commandline options, send this commands to
tpctl, and show the result in a textbox.
For the control and info arguments this should be easy to implement in
linuxconf. But for the configuration it may be a bit more tricky. I
asume it would be preferable if the user have a config dialog, where he
set the wanted options, and press ok when satisfied. But this requires
the tool to parse the current BIOS config, show it to the user, record
what options he changes, and then send all needed changes to tpctl in
one run. This is not so easy to implement in linuxconf, you probably
need to define a data structure for the various BIOS options inside
linuxconf, duplicating the stuff in tpctl. Maybe overkill, and maybe
better to with a dedicated X tool, which will give you more control with
the GUI design also.
Anyway I started the module, still need to give it a few control and
info buttons, and then I will send you the result so you may consider if
this is the way to go.
> (I find it a bit funny that in order to twiddle a single bit in
> the CMOS RAM, we use tpctl which talks to the kernel which talks
> to smapi.o which talks to the SMAPI BIOS which actually talks to
> the RAM. Whatever happened to POKE ? :-)
hehe, Linux is the meaning of life, filling our boring lifes with
development of endless chains of frontends :-)
Stein Vråle