Thanks a lot Jim!
That's a point I wanted to bring for a while but I was too deep in other
things to look at it.
On Thu, 26 Oct 2000, Jim Gettys wrote:
> 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
>
> _______________________________________________
> iPAQ mailing list
> iPAQ@handhelds.org
> http://handhelds.org/mailman/listinfo/ipaq
>
Received on Thu Oct 26 12:12:00 2000
This archive was generated by hypermail 2.1.8 : Tue May 04 2004 - 09:43:45 EDT