Hello On 8/20/07, Jordan Crouse <[EMAIL PROTECTED]> 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 _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
