Thread (18 messages) 18 messages, 5 authors, 2009-01-22

Re: [RFC 2.6.28 1/2] fbdev: add ability to set damage

From: "Magnus Damm" <magnus.damm@gmail.com>
Date: 2009-01-20 04:18:00

Hi Jaya!

On Tue, Jan 20, 2009 at 12:15 AM, Jaya Kumar [off-list ref] wrote:
On Mon, Jan 19, 2009 at 12:44 PM, Magnus Damm [off-list ref] wrote:
quoted
Wow, I think there's a lot to discuss and its late so I'll focus on
one question for now.
Yeah. =)
quoted
I guess the main question is how the user space interface should look
like. Should it export hardware capabilities?
I agree that above is the key question for now. What is the best way
for userspace to expose this information to the kernel? Two approaches
have been proposed which are that userspace does:

a) provide a tile based bitmap with bits set for modified tiles.
driver will provide information about expected tile size.
Just to make sure we are on the same page: We could let user space
provide the bitmap for us - that may be interesting - but I think it's
good enough to keep your array of rectangles as interface. It's clean
and simple. The tile bitmap can be handled internally, so each damage
call with N rectangles gets all the rectangles applied to the tile
bitmap. This over and over until the frame gets updated and the tile
bitmap gets cleared. In this case there is no maximum rectangle count
provided to user space.
b) provide an array of rectangles. driver will provide information
about preferred rectangle count, preferred alignment. i took out
overlap (since i think it is always preferable to not have any
overlapping rectangles)

Okay, since I have been backing approach b up till now, I will try to
switch positions and defend a. The main benefit I see of point a is
that it is always a fixed amount of memory to represent the updated
pages. The other is that it would be fairly easy for this to hook into
the deferred IO pagemap/tilemap approach. Are there other benefits?
What are the weaknesses? Okay, I need to reread your mails and will
try to summarize this tomorrow. Then I will do same for approach b.
The weakness IMO for a is that we're not clear how to transform the
tile bitmap data into DMA requests. Also, if passing the bitmap from
user space then copying an entire bitmap may be heavy on a big screen
if the tile size is small enough.

Regarding b, I'm not sure if maximum rectangle count is enough
information to allow user space to make smart decisions for a wide
range of hardware. And how this will work together with for instance
deferred io is a bit unclear to me.

Cheers,

/ magnus

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help