If the height and width don’t match the corresponding values in the vinfo
structure, the vinfo structure is updated to include the new height and
width. That makes sense. But why are the *_virtual fields changed?
That seems to be the root cause of my problem with the Yopy. The
Yopy lcd driver requires the *_virtual fields to be left alone (i.e.
the same as what it told the app they were).
Another question. Is it okay to add a resolution to the checkres array
for 240 width, 320 height? Is this something that should be checked
into CVS or should I just have my own copy?
If the height and width don’t match the corresponding values in the vinfo
structure, the vinfo structure is updated to include the new height and
width. That makes sense. But why are the *_virtual fields changed?
That seems to be the root cause of my problem with the Yopy. The
Yopy lcd driver requires the *_virtual fields to be left alone (i.e.
the same as what it told the app they were).
That’s a good question. It’s been too long since I worked with the fbcon
stuff, and I don’t remember the implications of setting the _virtual fields.
I think it was related to setting up the framebuffer layout for panning.
e.g.
xvirt = 2 * x
yvirt = y
/----------------
|XXXXXXXX| |
|XXXXXXXX| |
|XXXXXXXX| |
|XXXXXXXX| |
--------/--------/
v.s.
xvirt = x
yvirt = 2 * y
/--------
|XXXXXXXX|
|XXXXXXXX|
|XXXXXXXX|
|XXXXXXXX|
--------/
| |
| |
| |
| |
--------/
Obviously the second layout is better for double-buffering on the Y axis.
Another question. Is it okay to add a resolution to the checkres array
for 240 width, 320 height? Is this something that should be checked
into CVS or should I just have my own copy?
Yes, that’s fine. Go ahead and send a patch to the list.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
The framebuffer on the Yopy PDA uses 16 bit pixels, but requires 32 bit
writes. This, of course, breaks many assumptions in SDL I think,
certainly the assumptions made in FillRect and many of the test programs.
So, what, if anything, is recommended?
The framebuffer on the Yopy PDA uses 16 bit pixels, but requires 32 bit
writes.
Uuurgh! This isn’t too far from tho old days of bitmapped displays…
This, of course, breaks many assumptions in SDL I think,
certainly the assumptions made in FillRect and many of the test programs.
So, what, if anything, is recommended?
Well, I think the easy way would be not to support SDL_HWSURFACE for the screen. That is, use a “normal” 16 bit software shadow buffer, and then deal with the 32 bit weirdness only in the FlipSurface() and UpdateRect(s)() callbacks of the backend. (The rest will be plain s/w surfaces, so few other things should be affected.)
The alternative seems to be implementing new versions of pretty much all blitting code, using read-modify-write for single pixels, and various “specialcase the start and/or end” hacks for other stuff. Could be faster, since it avoids some memory copying. If VRAM reads are slow, this could also slow down some applications.
//David
.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se
|
| Address: |
| REOLOGICA Instruments AB |
| Scheelev?gen 30 |
| 223 63 LUND |
| Sweden |
| --------------------------------------- |
| Phone: 046-12 77 60 |
| Fax: 046-12 50 57 |
| Mobil: |
| E-mail: david.olofson at reologica.se
|
| WWW: http://www.reologica.se
|
|
`-----> We Make Rheology RealOn Mon, 24/06/2002 16:41:42 , Steve Drach <Steve.Drach at Sun.COM> wrote: