Re: accessibilities first tests - many questions
On 24/08/07 15:47 +0200, Guylhem Aznar wrote: > 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? Don't make the assumption that this hasn't been tested. This hardware goes through extensive testing before we even get to see it. From Linux even. > 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. I told you how you could test it easily, and I stick by that. Adding the sysfs entry costs time, code size, and further confuses the interface (which is already pretty darn confusing). If the only viable usage is "I want to see how it works" then i2dump is two doors down and to the right. It comes for free with the bus. > > 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. Not really, when you have the i2c tools, then its just a single command as well - and the interface comes for free. Its not always easy being a low end developer. But here's an alternative - use OFW to change the values instead - that absolutely comes for free - the functionality is already built in. Ask Mitch, and he'll give you a recipe. > 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 possibilities we provide. Its not about dictating whats best for them, its about providing the knobs that make sense to turn. There are hundreds of interesting looking registers in the chips on this platform, and I'm sure that we could go through and toss them all into syfs or some other interface, but the odds are that every single one of them will go untouched, except for the occasional guy who reads the datasheet and thinks he has found something "creative" that the rest of us missed. So we don't provide the interfaces that aren't useful in production. Thats not to say that you still can't twiddle the registers - there are several great ways to play with the internals of the chipsets from the privacy of your own userspace. We're not in the business of making it impossible for people to tinker, but we are in the business of optimizing the experience for the end user. > Therefore, I think we should not currently be removing possibilities > 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. Actually, it will. It will make the kernel larger, and it will eat more memory due to the additional infrastructure. We know exactly the cost - my question is, whats the benefit? Nobody really knows (or I suspect, cares), they just read the spec and say "wow, I want to try that because its a knob I can twiddle". But hey, this is open source. I'm sure Andres will take a patch against olpc-dcon if you really care that much. -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
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 Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
On 19/08/07 21:20 -0400, Albert Cahalan wrote: > Guylhem Aznar writes: > > On 8/18/07, Jordan Crouse wrote: > > >> We didn't enable this ability in the sysfs/ interface. I have > >> never been too clear on what the actual practical uses are for > >> something like this, so the control never got added. > ... > > It's just an experiment - I would like to have data proving users > > actually prefer using the display when the algorithm is enabled. > > I wrote a patch to provide the functionality. Here you go: > http://lists.laptop.org/pipermail/devel/2007-March/004287.html > > 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. 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. Jordan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
Guylhem Aznar writes: > On 8/18/07, Jordan Crouse wrote: >> We didn't enable this ability in the sysfs/ interface. I have >> never been too clear on what the actual practical uses are for >> something like this, so the control never got added. ... > It's just an experiment - I would like to have data proving users > actually prefer using the display when the algorithm is enabled. I wrote a patch to provide the functionality. Here you go: http://lists.laptop.org/pipermail/devel/2007-March/004287.html 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. In another email you mentioned using test images. I made one that seems to do a nice job. Note that you mustn't view a scaled version, as that messes up the measurement. The web browser scales images by default now, so don't use that. The "xli" program works OK. http://wiki.laptop.org/go/Image:Zone_plate_boys.png ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
Hello, On 8/18/07, Jordan Crouse <[EMAIL PROTECTED]> wrote: > We didn't enable this ability in the sysfs/ interface. I have never > been too clear on what the actual practical uses are for something like > this, so the control never got added. > In a pinch, you can use the i2c-tools utilities to write to the device > directly (use at your own risk!) I'd prefer not touching the kernel yet and concentrating on the software side. If you have a chance to add this to sysfs, I will test it. Basically, I would like to compare the screen readability in as many different modes as possible, letting people freely switch between display modes in different situations so they can chose the one they best like. It's just an experiment - I would like to have data proving users actually prefer using the display when the algorithm is enabled. Sometimes you have surprising results. > This is difficult to do - since it would involve synchronizing with the > video driver which with X and the framebuffer driver will invariably result > in a screen glitch (note that just switching the rate on the DCON itself > doesn't cause a glitch - its the software that is braindead > here). But we don't have any support for this in the kernel. Hmm - that I won't touch at all. If you plan to add support sometime in the future, I think it could be quite handy to let applications lower the refresh rate at will (ex: when switching pages in ebook mode, a lower refresh rate would save power, while during a page read, the dcon display mode could be used) > > I have done some shell scripts to test my stuff (ugly but handy, esp Here it is BTW. > Thats because the DCON driver does the freeze on its own while the system > is suspending, and it restores it long before userspace gets unfrozen, > so from your perspective, it will always be 0. I thought about it but I wasn't 100% certain. Ok, at least that is sure :-) Regarding the zoom/overlay, I will see what can be done in software. Guylhem contrast.sh Description: Bourne shell script ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
>> Can I also ask for some help there?
>>
>> Regarding the X being used, I am curious to know if there is a way to
>> do live screen scaling ("zoom" function, where the whole screen is
>> magnified) ? Ideally, it would be hardware managed, but that could
>> also be done by software.
>>
>
> No. The hardware doesn't have any way of zooming the graphics screen,
> so you would have to do it in software, which is probably not ideal on
> the Geode.
>
>
Actually you can create a video overlay which can be scaled at will. The
only problem is that there is only one video overlay and as far as I
know you can only create an YUV one from SDL...
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
On Fri, 2007-08-17 at 17:34 -0600, Jordan Crouse wrote: > On 17/08/07 11:56 +0200, Guylhem Aznar wrote: > > Hello, > > > > The only things I don't know yet how to do with the DCON : > > - how to disable the smoothing algorithm applied in color mode > > We didn't enable this ability in the sysfs/ interface. I have never > been too clear on what the actual practical uses are for something like > this, so the control never got added. > > In a pinch, you can use the i2c-tools utilities to write to the device > directly (use at your own risk!) > > > - how to reduce the framerate (for ex for ebook reading, but it could > > also be handy in text mode) > > This is difficult to do - since it would involve synchronizing with the > video driver which with X and the framebuffer driver will invariably result > in a screen glitch (note that just switching the rate on the DCON itself > doesn't cause a glitch - its the software that is braindead > here). But we don't have any support for this in the kernel. Actually, if the frame rate drop is just done by the dcon when it is in control of the screen, it is glitchless; it's resetting the geode's mode which is glitchful, and we'll avoid that. - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: accessibilities first tests - many questions
On 17/08/07 11:56 +0200, Guylhem Aznar wrote:
> Hello,
>
> The only things I don't know yet how to do with the DCON :
> - how to disable the smoothing algorithm applied in color mode
We didn't enable this ability in the sysfs/ interface. I have never
been too clear on what the actual practical uses are for something like
this, so the control never got added.
In a pinch, you can use the i2c-tools utilities to write to the device
directly (use at your own risk!)
> - how to reduce the framerate (for ex for ebook reading, but it could
> also be handy in text mode)
This is difficult to do - since it would involve synchronizing with the
video driver which with X and the framebuffer driver will invariably result
in a screen glitch (note that just switching the rate on the DCON itself
doesn't cause a glitch - its the software that is braindead
here). But we don't have any support for this in the kernel.
> I have done some shell scripts to test my stuff (ugly but handy, esp
> Regarding power management, I have a problem with the DCON freeze
> before suspend to ram: the display looks like frozen, but when I query
> the freeze file just before and right after the suspend, I only get 0
> while I should get 1.
Thats because the DCON driver does the freeze on its own while the system
is suspending, and it restores it long before userspace gets unfrozen,
so from your perspective, it will always be 0.
> Can I also ask for some help there?
>
> Regarding the X being used, I am curious to know if there is a way to
> do live screen scaling ("zoom" function, where the whole screen is
> magnified) ? Ideally, it would be hardware managed, but that could
> also be done by software.
No. The hardware doesn't have any way of zooming the graphics screen,
so you would have to do it in software, which is probably not ideal on
the Geode.
Jordan
--
Jordan Crouse
Systems Software Development Engineer
Advanced Micro Devices, Inc.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
accessibilities first tests - many questions
Hello,
As explained before, I started playing with the DCON (displaying test
images in X, changing various parameters, etc) and other stuff.
The results are interesting. For example, a black and white mode will
backlight on, even if it reduces the percieved resolution, could be
usefull to read at night, or for people with sigh problems who need
high contrast. I am exploring other similar options.
The only things I don't know yet how to do with the DCON :
- how to disable the smoothing algorithm applied in color mode
- how to reduce the framerate (for ex for ebook reading, but it could
also be handy in text mode)
I have done some shell scripts to test my stuff (ugly but handy, esp
when you are only testing ideas) ; I will post them here when I will
get back home for feedback.
If someone can help with the smoothing/framerate, some quick&dirty
bash code to do it would help.
Regarding power management, I have a problem with the DCON freeze
before suspend to ram: the display looks like frozen, but when I query
the freeze file just before and right after the suspend, I only get 0
while I should get 1.
Can I also ask for some help there?
Regarding the X being used, I am curious to know if there is a way to
do live screen scaling ("zoom" function, where the whole screen is
magnified) ? Ideally, it would be hardware managed, but that could
also be done by software.
See this if you don't know this function:
http://www.youtube.com/watch?v=LFQAqxoKyAE
The idea would be to do as fast as possible for moving around, then
when stopped on something, try to be as detailed as possible:
http://lists.freedesktop.org/pipermail/xorg/2005-April/007640.html
I am also wondering where/how the cursors are set. Matchbox theme is
only changing some cursors. I found a sugar gtk theme fixing
additional cursors as well, but it is not clear how everything
interacts. That's because I am looking for a way to magnify the mouse
cursor when a special keyboard sequence is pressed, to reveal where it
is on the screen, along with a way of magnifying the whole screen to
ease reading of content (ex: text from the internet, a small
picture...)
Finally, how can I interact in pen mode with the whole pad? Jim said
it was possible, so I tried to run a "cat" on various /dev input
devices, while moving my fingers on the left and right part around the
zone used for the pointer. However, I can't generate any data. What's
the problem ?
Side question - is is possible to get data when two objects (ex: 2
fingers) are moving ? (either in the same surface, or one in the pen
area mode and the other one in the mouse mode)
Guylhem
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
