Simulating a lower resolution on the OLPC XO Laptop

[Mathieu Comandon]

On Wed, Nov 26, 2008 at 1:04 AM, Mathieu Comandon <strycore at gmail.com>wrote:

> Jordan Crouse a écrit :
>
>  Bert Freudenberg wrote:
>>
>>>
>>> On 25.11.2008, at 17:37, Jordan Crouse wrote:
>>>
>>>  Bert Freudenberg wrote:
>>>>
>>>>> On 25.11.2008, at 11:57, Strider wrote:
>>>>>
>>>>>> Hi,
>>>>>> I have a XO Laptop which is a nice machine machine with a high res
>>>>>>  display of 1200x900 pixels. The problem with this is that the laptop  isn't
>>>>>> powerful enugh to handle fullscreen applications at this  resolution. If
>>>>>> only the display could switch to a lower resolution  things would be much
>>>>>> better but it seems that this laptop only  supports a single resolution.
>>>>>>
>>>>>> So I was wondering if it would be possible of simulating lower res  at
>>>>>> a low level, that is the xf86-video-geode driver.
>>>>>> I'm not an expert in video drivers but i imagine that there are
>>>>>>  functions to request a pixel to be drawn on screen based on what's  in the
>>>>>> video ram.
>>>>>> Now let's say that it's not one pixel but two that we put on screen,
>>>>>>  and that we draw each lines two times. That would result in a  600x450
>>>>>> resolution.
>>>>>> If we do the same thing but repating the operations three times , we
>>>>>>  would have a 400x300 resolution.
>>>>>> Some emulators have a scale option to do such a thing and manage it
>>>>>>  quite well, but if we had such an option in the video driver, the  result
>>>>>> would be even faster !
>>>>>>
>>>>>> So what do you think about this? Is it possible ?
>>>>>>
>>>>> The Geode actually can do real upscaling (that is, scale multiple
>>>>>  graphics resolutions to the panel resolution), it works fine on other
>>>>>  machines and LCDs. But latest word is that this somehow interacts  badly
>>>>> with our DCON, so no-one has gotten it to work correctly on the  XO yet.
>>>>>
>>>>
>>>> Indeed.  I think there is a DCON interaction happening, because the
>>>> mouse gets "corrupted" during upscaling as well - and that implies that the
>>>> issue is happening after the screen is constructed.  The upscaling works
>>>> fine on a CRT and on a "standard" TFT panel, so that is what leads me back
>>>> to the DCON.  Its also a long shot that the 1200x900 resolution is confusing
>>>> the scaler, but I doubt it since the aspect ratio is still 4:3.  I would
>>>> love for other people to try the driver (it is in the latest debxo, I
>>>> think); perhaps you can see the pattern that I can't.
>>>>
>>>>  There still may be hope, because the video upscaler can take RGB 5:6:5
>>>>>  data, so in theory a lower-res 16 bpp frame buffer could be upscaled
>>>>>  on-the-fly (and the upscaler does 30 fps easily). But I guess getting  this
>>>>> to work would require a very determined X hacker ...
>>>>>
>>>>
>>>> The RGB video overlay should just work (TM).  So it would take less of a
>>>> determined X hacker, and more of a determined application hacker to put all
>>>> the pieces together.
>>>>
>>>
>>>
>>> Well, I meant that this could be used to actually provide, say, an
>>> 800x600x16 mode in the driver, without having to hack applications. While
>>> adapting a single app may be comparatively easy, it's still a major hassle
>>> to patch each and every app. Having it in the driver would make things just
>>> work (TM). But that would be a major hack, don't you agree?
>>>
>>
>> So if I understand what you are getting at - you want to set up a single
>>  overlay over the whole screen, and render everything on that?  Thats
>> probably doable - you could set up a shadow framebuffer like we do for
>> rotation, and hook the damage code into the video overlay.  It might work
>> out well, but it would preclude using the video overlay for anything else
>> (such as, video).  It would probably also preclude rotation - maybe not.
>>
>> But rather then invent fanciful ways to handle this, the efforts would be
>> better spent figuring out how to fix the current driver.  Mitch reports that
>> the Windows driver works just fine, so clearly the bug is on our side.
>>
>> We need developers to start understanding how the driver works. Everybody
>> with a professional interest in the X driver has moved on to other pastures,
>> and OLPC desperately needs community members to pick up the slack.
>>
>> Jordan
>>
>>  Knowing that changing resolution on Windows XP sure brings hope to solve
> this problem :)
> I have installed the latest DebXO on a SD Card and xrandr shows several
> choices where Ubuntu and Fedora showed only the native 1200x900.
> I tried the other modes but they're all messed up. It's clearly a problem
> about timings.
> Here's a photo of what it looks like when I try run run Scummvm in
> fullscreen mode : http://img155.imageshack.us/img155/5589/img0700qg4.jpg
>
> I had a similar "out of sync" problem on my other laptop back when the
> radeon driver had problems on my display.  Windows XP had no problems and I
> had a tool which allowed me to find the correct timing to add valid
> ModeLines to xorg.conf. Later versions of Ubuntu corrected this problem and
> I could switch resolutions without any problems. I hope the same thing will
> happen with the Geode driver soon :)
>

The tool is was talking about in my last message is powerstrip , I has an
advanced timings options window (Screenshot here :
http://img383.imageshack.us/img383/3429/powerstriprw1.jpg ) which can be
used to get values for the xorg.conf.
Hope this can help.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20081126/af4d0de2/attachment.html>