[Libdlo] udlfb rotation performance issue

Bernie Thompson bernie at plugable.com
Wed Sep 21 16:20:25 PDT 2011


Hi Alexander,

On Tue, Sep 20, 2011 at 8:15 AM, Alexander Todorov <atodorov at otb.bg> wrote:
> Hi folks,
> I'm having very bad experience using rotation in udlfb.

Yes, unfortunately running displays in portrait mode is slow.  The
actual rotation work happens within the fbdev xorg driver, all in
software (udlfb itself is not aware or involved).

> I enabled fb_defio=1 in modprobe.conf

Actually, since you're running the fbdev org driver patched with
damage support, you can set the ReportDamage option to true in
xorg.conf, and turn off fb_defio.  That will speed things up a little
bit.  (See http://plugable.com/2010/01/02/displaylink-linux-rotation/)

But rotation itself is the biggest performance hit, and there's no
better way today.

> Has anyone seen such behaviour? What can I do to debug the performance issue
> and possibly fix it?

I don't know the best fix.  There are two general options:

1) Speed up how the generic fbdev xorg driver handles rotation
2) Add rotation support to udlfb (which is quite doable, but would be
a bunch of work; few fbdev drivers have gone to this trouble).

#1 is probably the best way to start - I don't know how much scrutiny
it has gotten (I didn't look any deeper than just using the
functionality already available).

There is no standard way to do #2 that I know of.  You'd just create
extra udlfb module or sysfs options to set the rotation.  Then you'd
have udlfb "lie" about the size of the default mode (swapping X and Y)
and then add a different rotated rendering path that would
(inefficiently) read memory "perpendicular" to the scan lines, and
then output contiguous (rotated) scan lines to the USB hardware in the
normal way.  And there may be better ways than what I'm describing.

But I agree, today's rotation support is too slow for most uses.  Hope
that background helps!

Regards,
Bernie
http://plugable.com/


More information about the Libdlo mailing list