Simulating a lower resolution on the OLPC XO Laptop

Mathieu Comandon strycore at gmail.com
Tue Nov 25 19:04:24 EST 2008


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 :)



More information about the Devel mailing list