accessibilities first tests - many questions

[Guylhem Aznar]

Hello

On 8/20/07, Jordan Crouse <jordan.crouse at amd.com> wrote:
> > It'd be great if this could be included. Better yet would be
> > to allow specifying the raw register value, of course with
> > an -EINVAL if bits unrelated to swizzle and backlight are set.
>
> Again - can I ask why?  The sysfs/ interface exists to provide the
> right interface to the applications and the user to accomplish what
> they want to do.  If you have a good reason for exposing this
> functionality, then I'm all ears, but I think that "just for giggles"
> doesn't quite cut it.

What about because it has not been tested?

In the end, I guess it depends on how you design your software.
Personally, I write quick and dirty test code where I do my best to
keep every possibility open. Then I work around some specific parts.
Sometimes, I even avoid includes to have some nearly identical version
and play with tiny parts of the code (which way is faster, how does it
react to tests with real data, etc).

If I can't get any measurable difference, I consider running
benchmarks ten thousands of loops, etc.

But unless some feature has been *tested* (not "considered") to be
useless, I keep it at that step. When I remove something, that's for a
serious, documented reason.

Then comes optimisation time, and I decide what makes it in, and what
doesnt, based on the data gained on the previous tests. Lot of stuff
get removed then, and some parts are even fully rewritten and fully
tested again.

Removing a feature that people want to test, doing someway instead of
the other way, just because you are guessing it won't be helpful, is
just wrong to me.

That's "Premature optimisation", "design by commitee" - name it how
you want. I only trust tests, data and conclusions.

Likewise, I have a friend who is a damn good coder - far better than I
am. However, he has this tendancy to ignore tests and error checks,
write evrything in one shot, and then spend some serious time
wondering why it isn't working as it should.

Same mistake IMHO.

> If you want to write directly on the device for testing purposes, then
> the i2c-tools work great - you can bang on the registers all day.

But you are making that unreasonably complex. What about other
features? Will everyone will have to do i2c? What about switching
GPIOs? (I haven't checked that yet) An echo 0/echo 1 in /sys really
saves testing time.

A real life example with the XO - did you try the script I posted with
black and white + backlight mode? Some people I showed it to actually
enjoyed it, not for the high contrast mode as I initially supposed (bw
with full backlight), but for reading ebooks at night (!!!) - they
said it was easier on the eyes, at least according to them, than the
color mode. The pale backlight made it suitable to be used with the
lights off.

Do you want to actually prevent creative uses?

Something even more funny - someone turned the screen to pda mode, but
did not close the keyboard all the way, so that it made the screen
stand at a strange angle suited for standing on a desktop, like a
picture holder.

How clever users are - they think in ways we don't. So we shouldn't be
arrogant and try to dictate them what's best for them, but see what
they do with the possibilites we provide.

Therefore, I think we should not currently be removing possibilites
but adding them instead, test them, and remove what has been *proved*
to be useless. Wild guessing is not a good strategy. And anyway,
what's the cost ? That's won't make your kernel bigger. That won't
make it run slower or eat more power.

Guylhem