Notices
Page 4 of 4 « First 23 4
Reply
Thread Tools
twaelti is offline twaelti
2008-10-07 , 20:43
Posts: 883 | Thanked: 980 times | Joined on Jul 2007 @ Bern, Switzerland
#31
fms - thank you for your superb and absolutely bloody brilliant work! Much admired indeed. The fullscreen mode and the labeled styles cues make VGBA just superb.
 
Serge is offline Serge
2008-10-09 , 15:38
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#32
Originally Posted by fanoush View Post
Ah, I see it now, page 19 from datasheet

The description of input and output window register does not mention such limitation. It is strange anyway. I thought the data is scaled on the fly and the internal epson RAM has already scaled/enlarged data so I wonder why any subsequent transfer cannot have different scaling. What happens when first rectangle is already scaled and then you reconfigure window registers and send another rectangle with different scaling?
Zoomed area just moves to another place. Your old data is shown unscaled unless it is still within newly updated area. This all works like moving "magnifying glass" around. See "Pixel doubling problems and workarounds" at http://maemo.org/community/wiki/gamedevelopment/ and aliens-1.0.2_Nokia.tgz demo game which shows this effect. XSP extension really does not fit well N8x0 hardware.

Or is the scaling up done only on output side of things (i.e between epson chip and lcd panel) and not on input (i.e between omap and epson)? That would somehow explain.
Yes. It is the important difference from Nokia 770. This is also explained in Epson manual, though in a bit cryptic way

Just noticed this when trying something simple with direct fb access. Worked fine on N800/OS2007 but got tearing on N810/OS2008. Looks better with latest kernel indeed.
Tearing synchronization did not work well with frequency scaling before this fix (it only worked fine at 330MHz). Now tearing synchronization works at all operating points. RFBI speed depends on CPU clock frequency and a nice thing about running at OP0 operating point (400MHz) is that graphics bus bandwidth crosses over (800 * 480 * 2 * 55 / 2) barrier for those who understand what it means

This one is in xorg xserver?
It is https://bugs.maemo.org/show_bug.cgi?id=1278
Last edited by Serge; 2008-10-09 at 16:19. Reason: a minor clarification about RFBI speed
 

The Following 2 Users Say Thank You to Serge For This Useful Post:
Serge is offline Serge
2008-10-09 , 15:50
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#33
Originally Posted by fanoush View Post
So what is the best solution? Hack X server to allow some sort of synchronization between X server access and direct fb access? Or somehow extend Xv to support more formats (RGB)?
I have not given up on http://www.gossamer-threads.com/list...rs/34502#34502. Implementing accelerated SDL for N8x0 devices is still in the list of my personal hobby projects.
 
Serge is offline Serge
2008-10-09 , 16:02
Posts: 503 | Thanked: 267 times | Joined on Jul 2006 @ Helsinki
#34
Originally Posted by Serge View Post
Well, this is not completely trivial as it involves understanding of a somewhat weird 'destructible' vs. 'background' types of screen updates (see Epson manual). But the fix is not too difficult from the technical point of view either. In any case, direct framebuffer access makes it very hard or impossible to avoid graphics glitches when used concurrently with X server.
Here is some update regarding this issue: http://www.mail-archive.com/linux-om.../msg05592.html
 
Reply
Page 4 of 4 « First 23 4

« Previous Thread | Next Thread »
Thread Tools

 
Forum Jump


All times are GMT. The time now is 20:48.

Contact Us - Home - Archive - Top