[Libdlo] [PATCH 2.6.32-rc7 1/1] udlfb: add dynamic modeset support

[Bernie Thompson]

On Thu, Nov 26, 2009 at 2:13 AM, Roberto De Ioris <roberto at unbit.it> wrote:
> Surely the B and C part could be removed, but an ioctl to force blitting
> to the device is needed.

Ah, I was wrong to say the displaylink-mod ioctl does a blit.  Rather,
no data passes through the ioctl other than the hint of where damage
to the mmap'd framebuffer has occurred.

So it was wrong to say this is a standard fbdev op -- it isn't.

But it should be -- this is an issue that all indirect-framebuffer
devices (the e-ink drivers like broadsheetfb, drivers for devices like
omapfb) have been struggling with and fiddling with private IOCTLs
for, so we're not alone.

So that goes back to the question, then, of the patch and discussion
Jaya had with the fbdev-devel list in January of this year, to add
damage hint support to defio (he called the IOCTL FBIOPUT_DAMAGE in
that patch).

My thoughts are similar to what Jaya decided upon for broadsheetfb.
That is, without any update notification, our only choice is to
refresh the whole screen -- unacceptable.  By using the defio/CPU's
MMU, we at least get page-granularity damage, which is a great backup
mechanism which will work with any framebuffer client, but it's not
fully performant.  With X's damage extension, we finally get precise
damage info and best-case performance.

The fbdev thread appeared to end with the question of how to reconcile
when multiple methods are in use. I'd think of it as "switch to
relying on the best one you have available" (and assume
fillrect/copyarea/imageblit is able to be handled alongside any).

So to resolve the question about how the different update
notifications relate to each over, I'd think of going the simple route
of specifying that once a client says it is able to provide damage
info, the fbdev driver is allowed to rely on it completely (e.g. defio
would not need to fault anymore on page access).

With all the new eink devices rushing to market right now, I'm sure
Jaya is swamped.  But it would be cool for him to weigh in on where he
thinks we aught to go with this, and if there was any later discussion
that led to different conclusions...

For context, the *long* discussion is at
http://sourceforge.net/mailarchive/message.php?msg_name=12319779622958-git-send-email-jayakumar.lkml%40gmail.com

Once we get our story straight here, we probably should move the
discussion over to that list, to pick up where they left off.

Bernie

Plugable Technologies
http://plugable.com/