Projective transforms in RandR

[Pat Kane]

Keith,

I have a device that has a display with non-square pixels, I think it
was optimized to display text .   Your rotation proposal could help
make pixmaps look better on the device.  But I am  worried
about jaggies and expect I will  need to apply a filter before/after
the transform.   Is that outside the scope of your fix?

Pat
---



On 7/14/07, Keith Packard <keithp at keithp.com> wrote:
> I've got this application which needs to scale screen output from
> 1024x768 to 1024x600 -- the device screen just isn't as big as many web
> pages would like it to be. As the device doesn't have any kind of magic
> down-sampling display hardware, this needs to be done in software.
>
> If you look at the current RandR rotation support, you'll note that it
> computes a projective transformation matrix and just uses Render to
> rotate the application-visible frame buffer to a shadow which is mapped
> to the hardware. Making this accept an arbitrary projective
> transformation matrix turns out to be fairly easy. A nice side-effect of
> the implementation rework is that reflection now works.
>
> In any case, now that the server can support arbitrary projective
> transformations, the question is how I should expose these through the
> protocol.
>
> Right now, I kludged together a pending TRANSFORM property; set that,
> change the mode and the new mode will use the contents of the TRANSFORM
> property to modify the shadow update path. I fixed the mouse motion code
> to also follow the transformation, so pointer coordinates are reflected
> accurately. What I didn't do is run the mouse image through the
> transformation, so you get the original untransformed mouse image.
>
> There are three problems with this implementation:
>
>  1) The existing "mode must fit within framebuffer" constraints
>     don't make sense any more.  I could simply eliminate these;
>     potentially using the existing shadow mechanism to ensure that
>     a scanout buffer of sufficient size was available.
>
>  2) When reporting the 'size' of the crtc through RandR and Xinerama,
>     the DIX code will continue to refer only to the mode and rotation,
>     the result is that applications see an inaccurate picture of the
>     system.
>
>  3) This is really a property of the CRTC, not the output, and yet we
>     don't have 'crtc properties'. I kludge this by just looking at all
>     of the outputs and pulling the first TRANSFORM I find. Setting
>    different transforms on different outputs has no effect.
>
> I could fix these by making the transform explicit in the protocol
> instead of using a property.
>
> A second order effect is that this mechanism overlaps with the existing
> LVDS scaling techniques. The LVDS output always runs at the native
> resolution and frequency; changing to a different mode simply engages
> the LVDS scaler to source a smaller number of pixels. The result is that
> you really have only one mode with an LVDS panel, but the hardware will
> scale from an arbitrary source image. Effectively, we're lying right now
> about the modes the LVDS supports, and we limit what people can do by
> limiting the scaling to a subset of the potential capabilities of the
> hardware. Yes, you can add a new mode to the LVDS output and use that,
> but still, you'll be scanning at the native LVDS frequency. Should we
> remove this kludge and instead expose the hardware capabilities
> directly?
>
> The code for this stuff is on the randr-transform branches of:
>
> xserver git://people.freedesktop.org/~keithp/xserver.git
>
> xrandr  git://people.freedesktop.org/~keithp/xrandr.git
>
>
> --
> keith.packard at intel.com
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
>