[iPAQ] RE: Restructuring the h3600_ts.h file/driver...

Jim,

Thanks for the writeup on how the driver and its header file should be
restructured. I agree with what you wrote. I think fbdev should have a way
of controlling the front light (on/off and brightness) and that this should
integrate with the apm/powermgr appropriately.

-Jamey

-----Original Message-----
From: jg@pa.dec.com [mailto:jg@pa.dec.com]
Sent: Thursday, October 26, 2000 2:56 PM
To: flynn@ozy.dec.com; jamey@crl.dec.com
Cc: ipaq@handhelds.org
Subject: Restructuring the h3600_ts.h file/driver...

This file is really a misnomer: it is really the "junk" driver on the iPAQ,
all typically interfaced one way or the other via the Atmel microcontroller.

The big problem is that the h3600_ts.h file is that it describes a number
of devices, not particularly related. People only wanting to emulate one
of these get the others (e.g. the touch screen interface), which it turns
out we'd like to make generic.

1) the programming interface to the touch screen driver.

2) the programming interface to the front light.

3) the programming interface to the battery and/or whether power
is available via the power supply.

4) the programming interface to the silly led's.

5) the programming interface to the buttons on the iPAQ.

6) the internal protocol interface to talk to the microcontroller in
the iPAQ H3000 series.

Right now these are all glommed together into a single header file.

In the long term, we'd like the following:

1) the touch screen driver programming interface described in its own
header file, without any of the other stuff.

2) The front light interface seperated out, and we probably also need
an interface developed for contrast control (for black and white units,
like the iPAQ 3150, where you need some way to adjust contrast.

Both of these, at least in the long term, need to get subsumed back into
the fbdev driver, but as an interim step, separating this out would be
a first good step. These clearly apply to the screen, and that is the
most appropriate place for the interface to reside.

We've had a bit of discussion on the fbdev mailing list about this topic,
and it sounded like if we did something reasonable, it would get accepted
back into the fbdev driver.

3) I think the programming side of this probably gets subsumed in the long
term by the apm interface. Jamey, is this right?

4) Dunno what to do about the LED's, if anything. Not clear they
should be programmable by users. X has an obscure interface for
lighting leds on keyboard, which is seldom used, and may or may
not be relevant. Opinions?

5) the programming interface to the buttons on the iPAQ aren't needed
anymore, as they look like keyboard keys.

6) the internal programming stuff for talking to the atmel wants to be
independent from any of the other header files for user level API's. Future
devices from others and us may look quite different, and we don't want
to have to mess with the API's to change them.

The first step is probably to just restructure the header file into a
set of header files per the above description, and delete the button
interface entirely (in the public API's; the internal Atmel interface
still exists, of course).

Getting this first step done quickly makes it easier for people to share
X server development.

The second step is probably to implement fbdev interfaces for
front/backlight
and contrast.

The third step will be to delete our interfaces for front/backlight and
contrast control, in favor of fbdev interfaces.

Charly, Jamey, what say you to the above proposal?
                                - Jim

--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
jg@pa.dec.com