Yes, you are right, this bug still exists in the currently released kernel. It should not affect anything on "normal" system use though, so you can only encounter it working with the framebuffer directly.
Should I file a bug report at bugs.maemo.org or do you already have this bug tracker in the internal database? It should be really easy to fix, right?
Should I file a bug report at bugs.maemo.org or do you already have this bug tracker in the internal database?
Submitting a bugreport will not do any harm for sure
Originally Posted by
It should be really easy to fix, right?
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.
Unfortunately I'm not allowed to tell whether a fix for this problem already exists, is planned to be fixed or whether it is going to be released in any update...
Fms your VGBA port to the maemo platform is just awesome, finally I get to have all my Zelda collection (big fan since the first nes game) with me while carrying just one device
I need help with the key-mapping of the hardware keyboard on my N810 - could somebody tell me where are the buttons mapped now? Where is the select button, the start button? a, b, l, r?
I need help with the key-mapping of the hardware keyboard on my N810 - could somebody tell me where are the buttons mapped now? Where is the select button, the start button? a, b, l, r?
Ever tried visiting the project homepage and reading the documentation?
That's a hardware limitation of Epson LCD controller in N8x0. It supports exactly a single scaled area which works as some kind of magnifying glass. That's why XSP extension does not work as expected on N8x0 when you try to have multiple parts of screen using pixel doubling (it just moves zoomed area). It is OK for video overlay, but is not very suitable for more general use.
Ah, I see it now, page 19 from datasheet
Originally Posted by
A single window can be scaled-up. If that single window constitutes the background
image, then all subsequent windows will automatically use the same scale-up ratio as
the background (this allows for multiple scaled-up windows). If the scaled-up window
was not the background (destructive overlay), then only a single scaled window is
supported. The window can be scaled to a maximum size as determined by the physical
LCD panel.
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? 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.
PS. Two of the video&graphics related improvements managed to get into the latest diablo 36-5 update: the fix for tearing synchronization problems when running at 400MHz
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.
In any case, direct framebuffer access makes it very hard or impossible to avoid graphics glitches when used concurrently with X server.
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)?
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)?
The best solution is to limit direct fb usage to the full screen mode so that you do not interfere with X11.
Making Xv support RGB image plane should be relatively easy (i.e. use fb0 instead of fb1/fb2) but it will still interfere with X11 using the same device at the same time.
Hacking X11 server is probably not a good idea because the synchronization should happen in the fb device driver.
Basically, one can implement a couple of ioctl()s in that driver that let multiple clients lock/release driver's blitter. For scenarios where it is only used occassionally, this should work. I expect severe tearing and performance problems though (but not screen corruption), when more than one client uses this feature on the constant basis.
Many thanks for the VGBA update. Pokemon Emerald (yes, I'm insanely sad =P) plays much better, practically full speed now. My N800 nearly does everything my old PSP did now
