> Hi James,
> Since you seem to be very busy, here's an idea for the framebuffer
> cursor API.
I looked over your patch and even tested it out. Then I thought about it a
long time. The question I had to ask myself is what do we want when we
have fbdev stand alone and fbdev with framebuffer console. Also how to use
a little code as possible (for embedded systems). So the goals are
1) For stand alone fbdev we want the maximum support for a cursor. But
what if we don't have a hardware cursor. In this case we should leave
it to userland to handle making it own cursor. The userland app might
not even want a cursor. So we avoid having extra code in the kernel for
a software cursor.
2) For fbcon the only thing we need for a cursor is a little rectangle. We
could still use imageblit but is seems really heavy when you consider
saving a bitmap of the current text under the cursor. True you have a
cost at reading the framebuffer when using fillrect but doesn't it cost
also to save the text bitmap under the cursor as well ? The question is
which cost more.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 22:00:44 EST