[PATCH] glamofb: Hide instead of disable hwcursor and wait for vsync.
balrogg at gmail.com
Wed Jun 18 00:02:10 CEST 2008
This fixes the Glamo lock-ups I was seeing with the hwcursor on. Also
fixes the cursor mask generation, teaches it the difference between
ROP_COPY and ROP_XOR and fixes the cursor colours (linux gives us
palette indices rather than rgb value).
So the lockups, as I noticed from the register dump earlier, occured
whenever the cursor was being disabled and the Glamo internal DMA was
just sending the fb data in the same scanline of the screen, to LCD.
I looked at the original wince driver and found that
* When we enable or diable the cursor we always do some voodoo loop
before that, which looks like a wait for the current scanline to be
far enough from the cursor, which kind of makes sense.
* Actual disabling or enabling the hw cursor is almost never done,
except for permanent effect. Normally the cursor is just hidden and
shown by setting the width to zero or non-zero.
This fixed the issue.
The patch still leaves the hw cursor disabled because I can't find out
why the leftmost column of pixels is blinking together with the
unmasked part of the cursor, no matter what mask is set. It seems as
if the glamo ignores the first pixel of every row of the mask. I
spent the last couple of hours on this and couldn't figure it out.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5422 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080618/5c6b32ae/attachment.bin
More information about the openmoko-kernel